Issue links in issues list should visit linked issue URL

Summary

Links from the issue list to issues, when clicked, do not direct the browser to the issue URL. This breaks common expectations of web application behaviour and introduces user friction.

Before "✨ Enhanced issue and epic experience", clicking an issue in the list of issues would link the browser to the issue URL, eg https://gitlab.com/gitlab-org/gitlab/-/issues/123456. There was a meaningful relationship between the link, the resulting URL, and the "object" in Gitlab.

After "✨ Enhanced issue and epic experience", clicking an issue in the list of issues produces a URL like https://gitlab.com/gitlab-org/gitlab/-/issues?show=eyJpaWQiOiI2IiwiZnVsbF9wYXRoIjoiYmVoYXQtY2hyb21lL2RvY2tlci1jaHJvbWUtaGVhZGxlc3MiLCJpZCI6MTc4MTkxMDk2fQ%3D%3D. Copying, saving or bookmarking the URL is no longer meaningful.

The user must perform a secondary action to obtain the canonical issue URL (a new UI element has been introduced to "fix" the UI).

This change is not in line with common expectations of web behaviour. Gitlab historically has been really good on that front, presenting the user with meaningful URLs consistently through the interface.

The bug introduces friction to communication and generally makes Gitlab harder to use.

Steps to reproduce

  1. Visit https://gitlab.com/gitlab-org/gitlab/-/issues
  2. Click any issue
  3. Copy the resulting browser URL (ends with /-/issues?show=<hash>)
  4. Share the resulting URL to a colleague (or open it in a "private" browser window)
  5. Note that the selected issue will not be displayed

Example Project

Can be demonstrated with any Gitlab hosted project.

What is the current bug behavior?

When clicking an issue link in the issue list, the resulting URL in the browser is non-functional except for the viewing user. As a result, the URL viewed in the browser cannot be shared with others.

What is the expected correct behavior?

UI should function as it did before, in accordance with https://www.w3.org/Provider/Style/URI

Some comments worth seeing from the original feedback issue:

Relevant logs and/or screenshots

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Patch release information for backports

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖