Show current user immediately in filters

Resources

FE @winh

Description

I pretty often use filters to find issues authored by myself or assigned to me.
But if I click to a filter, I have to wait seconds just to see a fulfilled dropdown with many users that I don't need.

Proposal

• Show current user immediately in assignee and author dropdown while other members are being loaded via ajax.
• This applies to the project issues list search bar, the project merge requests lists search bar, and the issue boards search bar (both the regular view, and the modal view of the issue board when you click Add issues).

Author	Assignee

Mentioned in issue #21747 (closed)

Added ~19492 feature proposal ~14281 labels

Changed title: Show current user immediately if filters → Show current user immediately in filters

Any chance to get this feature proposal done before new filters have come?

mentioned in issue #26749 (closed)

mentioned in issue #27549 (closed)

mentioned in issue #27614 (closed)

@victorwu @cperessini @ClemMakesApps - This would be a good improvement to consider for the search bar work. Wanting to filter by yourself as author or assignee is common, and we could find tricks like this to make the overall experience feel faster.

Interesting. So how would that work with the new filters? When I select author or assignee, myself is already pre-selected?

Not preselected. Today, your own name is at the top of the dropdown. But you have to wait for everyone else to load. What if you could still select your name while we are loading in the other people?

Today

Loading	Loaded

Proposal

Loading	Loaded

@awhildy I think it can be beneficial to automatically select the first row. You currently have to hit the down arrow if you want to select a suggestion, even if you've typed something to narrow down results. If we automatically select the first option, users will be able to just press Enter in a lot of cases.

Also, I think it can make the dropdown look a little more balanced by dividing it into two sections

No auto-select	Auto-select

@awhildy @cperessini : Those designs make a lot of sense. @ClemMakesApps : Is this a quick one we can bump up in our search bar list of features?

I can look into this after the 9.0 direction issues but not confident this will be 9.0 material

@ClemMakesApps : Of course, it wasn't marked as 9.0 at all. Don't worry about it for 9.0.

Was asking more of a t-shirt sizing question. A quick win that we should schedule soon, or not worth the effort because it's bigger?

I think it can be a quick win @victorwu

mentioned in issue #25913 (moved)

Thanks @ClemMakesApps . I added it here: https://gitlab.com/gitlab-org/gitlab-ce/issues/25913.

changed milestone to %Backlog

removed milestone

This is already in the code. Closing.

closed

@victorwu I don't think this is already in the code. I think the idea is for the current user to be loaded in the dropdown immediately before the rest of the users are loaded

@victorwu, no, it is not in the code yet.
Please, see this comment: https://gitlab.com/gitlab-org/gitlab-ce/issues/22921#note_22755536

reopened

Sorry. I thought this is putting it at the the top of the list. My mistake.

changed milestone to %Backlog

added ~897282 to schedule labels

added ~874211 label

changed milestone to %9.3

removed to schedule label

added Deliverable label

added frontend label

By the way, such a behavior is already implemented in filters:

added search label

mentioned in issue #31949 (moved)

It seems to me that UX is ready. I've updated the description with the proposal and created https://gitlab.com/gitlab-org/gitlab-ce/issues/31949 regarding auto-selecting the first dropdown option.

mentioned in issue #32497 (moved)

assigned to @winh

mentioned in merge request !11608 (closed)

@victorwu @blackst0ne Just to be clear about it: This issue is only about the dropdowns for filters in the issuable search bar?

changed the description

Thanks @winh for checking. I should have been more clear. This is for the 4 places in GitLab where we have the new filter search bar. I updated the description to indicate this.

@cperessini Current behavior is hat No Assignee doesn't scroll along with the dynamic content:

not-scrolling

Should we have the same behavior for current user?

not-scrolling

Or should we change it to this?

scrolling

Also: Should the current user stay visible though it doesn't match the entered text?

@winh They should both scroll as in https://gitlab.com/gitlab-org/gitlab-ce/issues/22921#note_30370318

I don't think they should show up if they don't match the query.

They should both scroll as in https://gitlab.com/gitlab-org/gitlab-ce/issues/22921#note_30370318

@cperessini Thanks!

I don't think they should show up if they don't match the query.

Should we hide the No Assignee as soon as text is entered as well?

Should we hide the No Assignee as soon as text is entered as well?

I think it should behave as one more option, so if the user starts typing no or none, it shouldn't hide. But if that's too complicated we can hide when the first character is entered.

so if the user starts typing no or none, it shouldn't hide

Autocompletion is done on backend, but displaying No Assignee when (part of) none is typed should be easy to add on frontend.

mentioned in merge request !11630 (merged)

mentioned in merge request !11640 (merged)

Sounds good @winh

mentioned in issue #32865 (moved)

mentioned in issue #32986 (moved)

This is for the 4 places in GitLab where we have the new filter search bar. I updated the description to indicate this.

@victorwu The original issue description contains a screenshot of the filters in the dashboard which will not be affected by this change. Are there plans to use the new filter bar in the dashboard, too?

@winh : Yes, we definitely want to bring the filter into the dashboard view. When we start getting group boards and group milestones, we will start cleaning up those areas. thanks for the catch.

assigned to @cperessini

closed via merge request !11630 (merged)

mentioned in commit 15af4d56

mentioned in issue gitlab#7524

mentioned in issue gitlab#9948

mentioned in issue gitlab#10148