Automatically close "assignee select" dropdown after selection when multiple assignees is disabled

With the addition of !11089 (merged) we've changed the behavior of the "assignee" selection dropdown menu in the issuable sidebar to remain open after selecting in order to allow multiple selections.

However, in CE where this multi-selection feature is disabled it doesn't make sense to keep this dropdown open after selecting a user and this will feel like a bug to most users. I recommend we return to the behavior of closing the dropdown menu automatically after selection when this feature is disabled or unavailable.

/cc @ClemMakesApps

assigned to @ClemMakesApps

created branch 31987-automatically-close-assignee-select-dropdown-after-selection-when-multiple-assignees-is-disabled

mentioned in merge request !11189 (merged)

@ClemMakesApps i am going to unlabel this UX

Is the milestone still relevant?

I think @mikegreiling wanted to say that this is a %9.2 regression but idk if that's how we do issue milestones

@ClemMakesApps do you have a link handy for the issue milestone guidelines? I know the MR needs to be set to %9.2 so the RM knows which stable branch to pick into, but I'm not sure how we're supposed to tag the corresponding issues.

Not 100% sure. @rymai do you know? AFAIK, issue milestone has only been important for Deliverable

Perhaps @victorwu might know too

I don't think it's explicit in the handbook. But that's how I've been tagging issue milestones for regressions.

I know @DouweM has occasionally been pedantic about these issues. Can you point us in the right direction on this?

I thought I recall a point being raised on a GitLab team call a while back on the subject, but I don't remember the take away...

@mikegreiling @ClemMakesApps Every issue that's scheduled needs a milestone. That milestone should be the first release we need that issue's MR to end up in. For a new feature that's the upcoming release, for a regression that's the release the issue was introduced. So in this case 9.2, not 9.3, since multiple assignees are in 9.2.

Okay cool. There was one point where someone said that the issue milestone should match the milestone that we are working in.. Guess that was wrong

@ClemMakesApps I think that changed recently! :)

@ClemMakesApps : The way I like to think about it, is that we are never really "working in" any milestone. We (not me, engineers ) are always working on software. Sometimes that code goes toward patching older releases (security fixes, regressions), and sometimes that code goes toward what is upcoming in a future release. We don't have to define we are in the "9.2 working period" or the "9.3 working period" now, because that is ill-defined. So if we avoid that, we don't have to get caught up in trying to figure out weird overlapping timelines, but instead, we just have guideposts on code freeze dates and release dates, and just work on highest priority items.

If you look at the section here, it doesn't talk about "time periods", but dates, which I find very helpful to understand. (Also it says merge requests should be marked properly with the associated milestone, but doesn't mention the issue.) https://gitlab.com/gitlab-org/gitlab-ce/blob/master/PROCESS.md#feature-freeze-on-the-7th-for-the-release-on-the-22nd

Cool, thanks for clarifying

closed via merge request !11189 (merged)

mentioned in commit 69019797