We currently only allow setting up the Jira issue integration and creating Jira issues for vulnerabilities on the project level.
Users would like to have the possibility to make a default setting to create Jira tickets out of the Gitlab GUI (e.g. from vulnerability findings). This default setting should be valid and inherited to all projects within group. So far it is possible to activate "Jira Ticket Creation Integration" in Gitlab GUI per project - not on group level and not via API requests as described in gitlab documentation https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#create-a-jira-issue-for-a-vulnerability
Solution proposal
Enable configuration of Jira issue integration and creating Jira issues for vulnerabilities at the group level.
Users should automatically get access to Jira issue lists at the project level for all projects in the group.
This should make the issue list appear on the project's sidebar that are inheriting from the group, so users don't have to set it up manually for each project, but not on the group sidebar.
This should enable user to create Jira issues for vulnerabilities in all the projects that inhering from the group that the setting is on.
Group integrations are currently only used to configure integrations for inheriting projects. Enabling a Jira integration on a group, will enable it for all the child projects, but it doesn't integrate with the group itself.
This brings up the question of what is expected of the issue list feature on a group level. Should this display the Jira issues link on the group sidebar?
The MVC can be to just enable the issue list form for group level integration. This will make the issue list appear on the project's sidebar that are inheriting from the group, but not on the group sidebar.
This will make the issue list appear on the project's sidebar that are inheriting from the group, but not on the group sidebar.
to be clear this will require some product / UX input to decide what the desired end-goal is.
The low hanging fruit is clear however: enable configuration of this at the group level and users would automatically get access to Jira issue lists at the project level for all projects in the group.
Just to clarify this point as I created the initial issue:
The low hanging fruit is clear however: enable configuration of this at the group level and users would automatically get access to Jira issue lists at the project level for all projects in the group.
Yes I think this is exactly what is expected here. When we talk about inheritance and group / instance level integrations, what we advertise will happen is that all projects under that group / instance will inherit those settings so you don't have to set them up manually for each project. We don't really have a concept of group-specific features for integrations (like the group sidebar you mentioned).
Side note: I am getting a very strong deja vu here since I recall a similar discussion talking about group-specific features for integrations and how they might be implemented / confusing for users when couple with the inheritance logic.
I can elaborate as the impact to me is more than just time spent. The reason for requesting this is that the necessary time spent to configure and maintain this for hundreds of projects is beyond what we consider viable.
It impacts our overall adoption of GitLab features and concretely:
makes analytics useless for a range of metrics
vastly reduces the value of vulnerability scanning and management since we need to create issues separately in Jira and don't have them linked
impacts cycle time and code quality since we don't want to manage issues separately in GitLab, and so MR reviews either take longer when smaller things either don't get punted, but fixed as part of the MR, or just ignored.
I fully agree with the intention of the low hanging fruit mentioned above - I have zero expectation in regards to how I see issues on a group level and would not find this confusing.
Why interested:
In order to make the entire "Shift Left" process with security scans more efficient, it is crucial to integrate the vulnerability findings & actions with the Jira workflow, and thus to configure this as a default for the whole group. This will also prevent problems of heterogenous settings when changes have to be made, like recently the new Jira URL after the migration (just related to telekom Jira).
Current solution for this problem: workaround is to set it separately for each project
This is a very large customer with 1000's of projects. Their Jira integration is the same for every project and should be default. So they would like to configure this on instance level so that they can also make configuration changes to the integration on instance level.
I can also think about a solution where you configure the integration on instance level once and that you can override the instance level setting on project or group level.
They need this integration to be able to centrally implement a vulnerability management workflow where vulnerability issues are created in jira.
The same issue applies as well for this customer (internal link) with this 4000 user Ultimate opportunity (internal link).
Same request from:
The following customer is interested in this capability
Customer would like to have the possibility to make a default setting to create Jira tickets out of the Gitlab GUI (e.g. from vulnerability findings). This default setting should be valid and inherited to all projects within group. So far it is possible to activate "Jira Ticket Creation Integration" in Gitlab GUI per project - not on group level and not via API requests as described in gitlab documentation https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#create-a-jira-issue-for-a-vulnerability
Project level: click main menu in project --> settings --> Integrations --> Jira --> Enable Jira issues --> Enable Jira issue creation from vulnerabilities
Group level: click main menu in group --> settings --> Integrations --> Jira --> Enable Jira issues is missing so it is not possible at least by this way to enable creation of Jira tickets for vulnerabilities on group level and make it default for all projects.
@bmarjanovic@justin_ho this has been weighted 2 and labelled backend, but it will require some frontend changes. Please discuss and if a separate frontend issue is needed, please create it. Scheduling for current milestone.
@bmarjanovic Yes. So if you apply the below diff and go to any group integration page (for example, http://127.0.0.1:3000/groups/flightjs/-/settings/integrations/jira/edit) you will be able to see the Jira issues section.
diff --git a/app/models/integrations/jira.rb b/app/models/integrations/jira.rbindex e8f283054a46..e9ba2b8516f9 100644--- a/app/models/integrations/jira.rb+++ b/app/models/integrations/jira.rb@@ -244,14 +244,14 @@ def sections ] # Jira issues is currently only configurable on the project level.- if project_level?- sections.push({- type: SECTION_TYPE_JIRA_ISSUES,- title: _('Issues'),- description: jira_issues_section_description,- plan: 'premium'- })- end+ # if project_level?+ sections.push({+ type: SECTION_TYPE_JIRA_ISSUES,+ title: _('Issues'),+ description: jira_issues_section_description,+ plan: 'premium'+ })+ # end sections enddiff --git a/ee/app/helpers/ee/integrations_helper.rb b/ee/app/helpers/ee/integrations_helper.rbindex c1d19a60400e..52f1a36cc4b8 100644--- a/ee/app/helpers/ee/integrations_helper.rb+++ b/ee/app/helpers/ee/integrations_helper.rb@@ -15,8 +15,8 @@ def integration_form_data(integration, project: nil, group: nil) if integration.is_a?(Integrations::Jira) form_data.merge!(- show_jira_issues_integration: project&.jira_issues_integration_available?.to_s,- show_jira_vulnerabilities_integration: integration.jira_vulnerabilities_integration_available?.to_s,+ show_jira_issues_integration: true.to_s,+ show_jira_vulnerabilities_integration: true.to_s, enable_jira_issues: integration.issues_enabled.to_s, enable_jira_vulnerabilities: integration.jira_vulnerabilities_integration_enabled?.to_s, project_key: integration.project_key,
The main thing here is to move the logic of jira_issues_integration_available? and jira_vulnerabilities_integration_available? away from the project model and make them available on the group / instance levels. Other than that, it's testing to make sure the form actually saves properly and propagates correctly to child group / projects (should already be the case, just needs to be tested).
From a quick look, it doesn't seem that we need frontend changes since form still renders properly with the above diff but if you run into any issues, I don't mind pairing to look into a solution.
Magdalena Frankiewiczchanged title from Enable setting up Jira issues integration on the group / instance level to Enable setting up Jira issues integration on the group level
changed title from Enable setting up Jira issues integration on the group / instance level to Enable setting up Jira issues integration on the group level
@jamie.harvey I think the first bit of documentation is saying that it can be configured instance-wide for self managed. Groups are available both for hosted and self-managed groups.