Issuable sorting should be stored per page

Description

For now issuable sorting is stored in cookies as a global value per domain.

That means, if you set some sorting on a page A, it also will be set on a page B.

Steps to reproduce:

1. Open Issues List page. Set sorting to, say, Priority. Wait until page is reloaded.
2. Open Merge Requests page. The sorting is already set to Priority. Change it to anything else, then go back to the issues list page and you'll see the sorting is changed again.

Proposal

Store sorting values per issuable.

/cc @markglenfletcher

@blackst0ne Should this be per project too? I tend to use bookmarks that include the sort parameter so I've never really noticed this

added 874211 gitlab-foss14213 ~14281 ~13921 labels

@markglenfletcher, yes, it should be per project too.
If this issue is accepted to be merge and is Accepting Merge Requests in GitLab FOSS , I would like to fix it.

I think that it makes sense. Users may want to specify different sort orders for different projects and issuables, and this proposal won't affect users that don't. They'll be able to carry on as normal.

I think it's a safe change that would be nice to have for those users that would make use of it.

@victorwu Would you agree so that we can make it Accepting Merge Requests in GitLab FOSS ?

Actually, I already fixed it locally. If it's Accepting Merge Requests in GitLab FOSS, I'll create an MR.

Thanks @blackst0ne for creating this issue.

@jschatz1 @smcgivern : Do you know of any tech work / initiative ongoing that would impact this from perspective? Wanted to check in before we give the go ahead. I'm definitely on board with the suggestion. Welcome your feedback too of course.

I can see the case for doing this, but I think the existing sort has its merits too. For instance, if I have the 'wrong' sorting on a page, I can fix it once and know it's fixed everywhere. This is existing behaviour, so I think there should be quite a high bar to change it - not because it's perfect, but because people are already used to it.

Put another way: if we already did this, I'm sure we would have some requests saying 'how do I make sorting work by X everywhere?'. What would we do in that case?

I suggest to make sorting more independent (say, issues list is sorted by priority, but MR lsit is sorted by last update at the same time) and get users' feedback (if any).

If there will be many issues about it, we can make things settable:

So, can we move this feature proposal on?

@blackst0ne : Given what @smcgivern said, we'll be very careful before we make too many areas customizable and granular.

Can you chat about how this would be helpful to you and other users? How do you anticipate needing different sort orders? Would all issues be one way for you? And then all merge requests another way? Or would It be project? In what scenarios would you want differences and why?

My real case is:

1. In one project I use Last updated sorting both in issues list and in merge requests.
2. In another one I use Priority sorting in issues list and Last updated in merge requests.
3. In the third one I use Milestone due soon sorting in issues list and Priority in merge requests.

There are different workflows, so I often have to change sorting both per issuable and per project.

mentioned in issue gitlab-foss#30071 (closed)

marked this issue as related to gitlab-foss#35381 (closed)

mentioned in issue gitlab-foss#35381 (closed)

@tauriedavis @sarrahvesselov what do you think about this proposal?

changed the description

This is a very interesting one @blackst0ne. I do not typically sort at all so I had never noticed this behavior.

For instance, if I have the 'wrong' sorting on a page, I can fix it once and know it's fixed everywhere.

I expect sorting to apply to the current list I am viewing and not to persist across other lists in the UI. The current behavior actually feels like a bug.

This is existing behaviour, so I think there should be quite a high bar to change it - not because it's perfect, but because people are already used to it.

I agree that this could present an issue for those that are used to this behavior. I don't believe that is a good enough reason not to change it if the current behavior is not expected. Applied filters do not behave this way because they are also temporary by nature.

I want to clarify the proposal @blackst0ne. We will be removing the persistence of sort across projects and issuables. However, once I set an issue list on a project to 'Last Created' it will remain 'Last Created' until I change it again. Is this correct?

If so, I think that @smcgivern point about setting it once and knowing it is fixed will be taken care of the first time a user sets it. Yes, it may be annoying to have to set them all the first time but I think that is less annoying than the current paradigm.

I want to clarify the proposal @blackst0ne. We will be removing the persistence of sort across projects and issuables. However, once I set an issue list on a project to 'Last Created' it will remain 'Last Created' until I change it again. Is this correct?

Yes.

I want to use:

1. Option A in the project 1 -> issues list
2. Option B in the project 1 -> merge requests list
3. Option C in the project 2 -> issues list
4. Option B in the project 2 -> merge requests list

I agree with @sarrahvesselov here. Was writing up the exact same thing

I believe we should move forward with this @victorwu as long as it does not affect any other ongoing work as you asked earlier.

changed milestone to %Next 3-6 months in gitlab-foss

@victorwu are we fine to accept MRs for this proposal? Can we set it as Accepting Merge Requests in GitLab FOSS ?

added Accepting Merge Requests in GitLab FOSS label

added UX ready in GitLab FOSS label

@smcgivern : Do you still have the same concerns now as several months ago?

https://gitlab.com/gitlab-org/gitlab-ce/issues/29248#note_25079459

@victorwu yes, but: I am not a typical user. I know exactly how this sorting works, and I use different sorts quite often. Maybe we need some research here?

@tauriedavis @blackst0ne : I think it's worthwhile to do a little research validation for this one, given what @smcgivern mentioned. Perhaps users might be heavily relying on this sorting throughout GitLab. Thoughts?

I think the risk is pretty low.

If a user uses the same sort everywhere, but changes it in one place, it is easy to change it back in that one place. I think this is a more common use case, since filtering is temporary in nature. I don't see a strong use case for needing sort to persist throughout the application.

If we had unlimited research capacity/time, then Im all for doing research. But I dont think we should let research hold up changes like this that dont have a large risk factor.

@tauriedavis

The default sort for issues is last created, but I rely on it being last updated everywhere. I can of course go and change that on every view I use, as I use it, but there is a reason for it.

That would only need to happen once @smcgivern, whereas others who use different sorts have to change it back every time.

@tauriedavis right, but I'd need to do it once per page ... anyway, I'm fine with this, I just wanted to get my objections on record

moved from gitlab-foss#29248 (moved)