GitLab issues navigation tab should only be associated with GitLab issues

Background

• Currently, if you configure JIRA integration on per a project, GitLab issues is essentially disabled.
• When you click on the Issues link in the navigation, GitLab redirects you to JIRA. This should not be the case.
• Clicking on the Issues link should bring you to GitLab issues as normal.
• You should be able to use GitLab issues normally even when you have JIRA integration on. All features of GitLab issues work, including all integrations with merge requests.

Description

• The GitLab issues tab/link in the main navigation for a project should be visible, if the GitLab issues functionality is configured on in the project settings.
• When you click on the issues tab/link, it goes to the GitLab issues list.
• If the GitLab issues functionality is configured off in the project settings, then the issues tab should not be visible.
• When you configure any external integrated issue tracker within GitLab (e.g. JIRA, Redmine), that does not affect the GitLab issues tab/link in any way. The GitLab issues link never goes to an external location. It only goes to the GitLab issues list.

Blocked by

• This should not be merged until https://gitlab.com/gitlab-org/gitlab-ce/issues/33679 is merged first.

Related

https://gitlab.com/gitlab-org/gitlab-ce/issues/33517

added Deliverable label

Unless Gitlab issues are disabled in the project settings, in which case the behavior should be as it is today.

mentioned in issue #31129 (closed)

assigned to @jarka

@jarka @smcgivern : here's the new issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/33517. Let me know if we should combine them or separate them in a different way, since they seem to be all inter-related.

changed the description

@victorwu I think we could do both together, but I'm interested in what @jarka thinks.

Yep I think it makes sense to do it together, it is touching the same functionality. Doing them separately doesn't make any sense and would only require more time to implement/review (while changing the same lines of code)..

mentioned in issue #33517 (closed)

changed title from Issues should be usable when JIRA integration is active to GitLab issues navigation tab should only be associated with GitLab issues

changed the description

@jarka : See the updated description. Feel free to update if it's not clear. As mentioned in #33517 (closed), we will worry about navigating to external locations in separate issues in the future if that is a highly requested feature.

Thanks @victorwu - it makes sense. Happy we'll simplify the logic here

mentioned in merge request !12050 (merged)

mentioned in merge request !12130 (merged)

@victorwu I think that some customers / users will consider this as a breaking change. Before this change they had a link from GitLab to their external issue tracker and now this link is totally gone. I anticipate some pushback and I can understand this pushback. What do you think of at least keeping this link somewhere?

mentioned in issue #33649 (moved)

@adamniedzielski : I'm guessing there won't be too big of a pushback since users can actually get to JIRA from within merge requests with the mentions functionality of autogenerating JIRA issue links. Furthermore, I expect the JIRA flow to be a user starting at a JIRA issue, and then they click through to a GitLab merge request.

That being said, I do understand it is change with existing flows. So if there is pushback, we can users to this issue, and mediate the discussion there: https://gitlab.com/gitlab-org/gitlab-ce/issues/33649. And that should help drive how important this is.

mentioned in issue #27073 (moved)

changed the description

mentioned in issue #33679 (closed)

Finally. Having this implemented allows gradual migration from jira issues to GitLab issues.

For Bugzilla, Redmine and custom issue tracker integration we support #1234 (hash plus number) as a valid reference to an external issue that will create a link in GFM. This is not formalized in the documentation (let's discuss that in #34070 (moved)), but it works and I found some evidence that it is expected by the users. See https://gitlab.com/gitlab-org/gitlab-ce/issues/18827#note_12568147 where a user expresses a concern that this feature is now broken and we commit to fixing it (which we did).

When connected with this feature proposal, it creates an ambiguity, because now #123 may refer to GitLab issue 123 or Redmine issue 123 and we have no way to tell which one is it.

@victorwu @smcgivern I believe that it's a blocker for implementing this feature proposal. If we acknowledge the implicit support for #1234 pattern for external issues then we cannot implement it. If we decide to break this implicit backwards compatibility then we should be aware that there are users who rely on that. I could not come up with a solution to overcome this problem (other than deprecate and wait until GitLab 10).

@adamniedzielski wdyt about just making this apply to Jira, as opposed to any external issue tracker?

from my personal point of view: do it for jira, i don't use other external trackers :)

Thanks @adamniedzielski . I'll comment on the other issue (#34070 (moved)).

Why does that block this issue here? This issue is about changing the navigation right? How is it impacted by the link schemes?

@smcgivern

wdyt about just making this apply to Jira, as opposed to any external issue tracker?

That sounds possible from the product perspective, although it introduces yet another special case in the product area which is already underdocumented and already causes a lot of confusion (visible in all issues related to our Jira integration).

From the technical perspective, this makes the code more complex as we have to handle:

"#1234 refers to an issue from the internal issue tracker, but if you have an external issue tracker enabled it refers to an issue from the external issue tracker, but if that's JIRA, it refers to an issue from the internal issue tracker."

I'm not a huge fan of complicating an area of code that already nobody understands.

@victorwu On the surface it's "changing the nagivation", but under the hood it is "remove the invariant that a project has either the internal issue tracker or an external issue tracker, but not both". This invariant is part of our code and the code is built on this assumption.

We can change the code, but #123 notation for external issue trackers is a feature.

@adamniedzielski true, but we're specifically trying to improve our JIRA integration in the next few months, as opposed to other issue trackers, which are more in maintenance mode at present.

"#1234 refers to an issue from the internal issue tracker, but if you have an external issue tracker enabled it refers to an issue from the external issue tracker, but if that's JIRA, it refers to an issue from the internal issue tracker."

I proposed a slightly different scheme in https://gitlab.com/gitlab-org/gitlab-ce/issues/34070#note_33190041.

But yours could also be simplified to:

• If any non-JIRA external issue tracker is enabled, #1234 refers to the external issue tracker.
• Otherwise, #1234 refers to the internal tracker.
• If the JIRA tracker is enabled, FOO-1234 refers to JIRA.

JIRA is already treated quite differently to other trackers in some ways, so it might make sense to make that more explicit. (I believe it is also the most popular of the external trackers.)

@smcgivern if we do https://gitlab.com/gitlab-org/gitlab-ce/issues/34070#note_33232850 then we won't need a special case for JIRA.

@adamniedzielski yep, let's go with that option.

closed via merge request !12130 (merged)

mentioned in commit 6d13bc58

mentioned in issue #36694 (closed)

mentioned in issue #36974 (closed)

mentioned in issue #37915 (closed)

mentioned in issue gitlab#7906