I feel like I've seen the suggestion to add 'filter' to the Labels page before, but couldn't find it. Not sure about the milestones page. I created this issue in response to the comment here: https://gitlab.com/gitlab-org/gitlab-ce/issues/21747#note_21488276. Let me know if it is a duplicate. Thanks!
For milestones, do you know how that milestones page is used primarily? If we want a list of issues in a milestone, we use the list view primarily?
The milestone page is used to view the progress of the milestone in it's entirety. Being able to search for a specific milestone would help because then you can more easily find a milestone that you want to drill down into to see the breakdown of not only issues but also merge requests. You can also view participants and labels used.
Thanks @tauriedavis . Let's get back to milestones when have more feedback (unless you already see a lot, I'm not seeing much.)
We do have issue boards per milestone in 9.0, and burn down charts in milestones for 9.1. So I do anticipate milestones will pick up usage soon and this is definitely something we should consider in a few releases out.
Are there any updated plans to fix this? Any ETA? I'm coordinating a possible migration to GitLab by the GNOME project and label scalability/manageability has been raised as a concern.
@victorwu I think this feature proposal could be opened for a gitlab-foss2091545 with gitlab-foss1890178. The UX in GitLab FOSS is ready to go and it seems that we're all in favour of the new functionality.
I've managed to make the "Filter by Name..." in both the labels and milestones pages but was not able to do it in ajax, can't seem to wrap my head around gitlab's codebase just yet. Can we divide the merge requests into, 1. Basic functional search (needs to reload to actually search) to make it readily available + 2. Ajax implementation (just like in the projects page).
Sorry took me a while, the gdk both amazed and challenged me at the same time lol
@jcgalbano if you can create a MR to this repository, we can try to help you out. Depending on complexity, breaking it out into two parts could make sense but until we take a look at the code, it's still hard to make a decision on it