Skip to content

Group issue sort parameter in URL ignored when changed manually

Summary

If a user manually changes the sort parameter in the URL when viewing the group issues list, the new value for the sort parameter is ignored and the old value is used instead.

This was reproducible only on GitLab.com. Please note I could not reproduce this in 14.8.1-ee so a fairly recent change has broken this.

Steps to reproduce

  1. Navigate to https://gitlab.com/gitlab-org, and open the Issues. Change the filters to Updated Date in ascending order. The URL should change to https://gitlab.com/groups/gitlab-org/-/issues?sort=updated_asc&state=opened - with a sort of updated_asc.
  2. Change the sort parameter in the address bar to relative_position so the URL look like https://gitlab.com/groups/gitlab-org/-/issues?sort=relative_position&state=opened and then navigate to that link.
  3. The bug - The URL then changes back to https://gitlab.com/groups/gitlab-org/-/issues?sort=updated_asc&state=opened. The new sort value is completely ignored. This can be validated by checking the parameters passed to the /api/graphql calls.

I've attached a video below that demonstrates the bug under Relevant logs and/or screenshots.

Example Project

This bug can be reproduced on any group containing issues. I used https://gitlab.com/groups/gitlab-org above. This bug seems to be limited to group issues (the project issues seem unaffected).

What is the current bug behavior?

If the sort parameter is updated in the URL on the group issues page, the change is ignored and the previous setting is used.

What is the expected correct behavior?

If the sort parameter is updated in the URL on the group issues page, it should use the new value.

Relevant logs and/or screenshots

Untitled

Output of checks

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