Take the project issues (and merge requests) search and filter bar, and port it over to the group issues page.
For this issue, do it only for the group issues page. Group merge requests will be a future issue.
Filter for author, assignee, milestone, labels, and weights
The filter scoping is exactly the same as the existing group issues list page. None of that is changed with this issue.
For labels, we will follow https://gitlab.com/gitlab-org/gitlab-ce/issues/33575#note_35797879. That is, if the same name is for multiple labels, they will be combined in the dropdown into a multi-colored label. This is the same exact design for the existing dropdown UI. But once the user has selected that from the dropdown, the label in the search bar becomes grey.
cc @cperessini@smcgivern : Again, I want to start with group level labels and milestones here. And only add in project-level filters if they are absolutely necessary in the future.
@smcgivern@cperessini : I'd like to target this as part of 9.5 along with group boards if possible. It would be nice to release together. But if that's not possible, I think group boards is first priority, and then this would be more clean up / consistency after group boards.
Or do you mean the autocomplete, not the search results?
Yes, I think this must mean the autocomplete. Same as project search, the autocomplete shows members of the project but you can always type in a full username of someone who is not part of the project and get results. Correct @victorwu?
The description looks good to me. I don't believe there is any UX needed here so adding ~"UX ready"
For a first iteration, it might make more sense/be more do-able to just take the filtered search UI and implement it on the groups issue page rather than adding these other tweaks on top of it.
There still seems to be some unanswered questions for @victorwu. Maybe @JobV can help answer them
@ClemMakesApps I think I agree with you! I'm slightly concerned we're missing something in functionality or overseeing something, but having a quick look, I think that should be OK.
The tweaks listed by Victor are mostly related to scoping. Want to call about it?
@ClemMakesApps as we discussed, keeping the existing queries as they are (i.e. don't scope them only to group level things), that is a good first iteration.
After recently finding out about our group issues feature whereby our label colors blend together (https://gitlab.com/gitlab-org/gitlab-ce/issues/35120), I've been trying to figure out how to incorporate that into our filtered search.
Currently on Gitlab.com
Group filtered search dropdown
Group filtered search after selection
I think it makes sense to make the dropdown match what we have right now. But what happens after we select? Previously, we will fill in the token with the color of the label. Imo, multi color tokens don't look so great.
Thanks for creating this issue @filipa. From a usability and consistency standpoint, wouldn't we want the label to be the same color globally? I understand that we are taking something that was scoped at the project level and making it available at the group level so there will be differences in color that already existed. I don't necessarily see the value in allowing a global label to have different colors across projects, but I recognize the headache this would cause for users who would need to re-align all the label colors...
These are my thoughts from the other issue @tauriedavis@ClemMakesApps. I do not believe we should be allowing multi-colored labels. My first question is, what is the user value in having different colors for the same label?
My first question is, what is the user value in having different colors for the same label?
This is displayed on the global dashboard, as well as the group dashboard. I think it would be weird to say that one project's ~P1 label can't be green, because another one already picked it to be red?
For this issue, I wouldn't change the current functionality. It looks super weird on the tokens and doesn't seem right at all. I agree it looks and feels like a bug. When there are 2+ colors for a label, I would strip the color for now on the search token itself and display it how we use to before we added the colors.
This way, we can move forward with this issue and figure out specifics for limiting color options (or something else) in the issue specifically related to that.
For this issue, I wouldn't change the current functionality. It looks super weird on the tokens and doesn't seem right at all. I agree it looks and feels like a bug. When there are 2+ colors for a label, I would strip the color for now on the search token itself and display it how we use to before we added the colors.
@ClemMakesApps : Regarding label colors, let's simply just make the labels grey for the group list here. I assume that is easiest and bypasses all the problems? I know you already have a WIP mr open. Just let me know what's implemented and I'll update the issue description here for posterity.
To clarify what's easiest per your earlier convos with @JobV that I see above, is this what you are doing in the WIP?
For filtering authors: search for all authors in the instance.
For filtering assignees: search for all assignees in the instance.
For milestones: search for all project milestones and group milestones that are part of the current group.
For labels: search for all project labels and project labels that are part of the current group.
@victorwu my current WIP adds the filtered search into group dashboard. Right now, it displays the multiple labels as separate labels, I am going to make adjustments so that
labels with the same name will have the multi-color label identifier (in the dropdown)
multi-color labels that are selected will not change the label token color (it will remain as default gray)