Style people in search bar

Resources

FE @ClemMakesApps @winh

• In the search bar for issues and merge requests and boards.
• Style assignee and style author.
• The x is in issue https://gitlab.com/gitlab-org/gitlab-ce/issues/30466, and out of scope here.

cc @jschatz1 @ClemMakesApps @cperessini

@jschatz1 : Can we make this 9.2

added ~874211 frontend ~897282 ~14281 to schedule labels

I think style label's was in the other issue?

changed milestone to %Backlog

added Deliverable label

changed milestone to %9.2

@ClemMakesApps : Yes, that was a typo in the description. Corrected it.

removed ~897282 to schedule labels

@cperessini @tauriedavis : Design good?

It would also be good to know what the default image would be in case we are unable to load an avatar

Do we have that in other places @ClemMakesApps? It's a good idea, wondering if we need an issue to include that everywhere?

Right now we have a few patterns. Default image for a group is a ? but default image for a repo is a circle with the first letter of the repo name. As for users, we just get it through gravatar (but in this case, we wouldn't be able to because that requires getting their email address first)

assigned to @ClemMakesApps

I see the first letter design in many places, I think in a good number of google products. I find it weird. Just a personal take.

Don't we assign a generic pattern image to users without a profile picture? I think that would look a little weird in the tokens and it may be better to simply not show an image

@cperessini I think that's using gravatar. Just checked and gravatar has a default image. I think I'm just going to defer to that for now

As seen on https://en.gravatar.com/site/implement/images/

@ClemMakesApps cool. I think it's acceptable. If it does look weird we can remove it in another iteration.

Here are the measurements for the tokens:

There are currently multiple scenarios for a user (assignee, author) to be added to the search bar.

1. User types out the username (Eg. author:@ClemMakesApps)
2. User clicks on the username that is displayed on the dropdown (same as if the user filters and clicks)
3. User pastes the username to the search bar

In terms of architecture, it is easy to display the user's name and avatar when the user goes through scenario 2 because it is already received by the API. The implementation for the other 2 scenarios could probably be shared but I wanted to double check with the team before I proceeded.

For scenarios 1 and 3, I propose we perform an ajax request to get that specific username's name and avatar. The downsides of this proposal is that in scenario 3, if a user pastes something such as assignee:@ClemMakesApps assignee:@jschatz assignee:@filipa (multiple assignees), we would be doing 3 separate requests to get their information. It would be nice if we could have a separate API that would return all of these user's names and avatar information but AFAIK, backend does not have any bandwidth for this. Although this would have some impact to the DB/infrastructure, I think the impact should be minimal because the number of API requests would still be the same as though we typed and filtered each user's username.

In terms of UX, I was thinking that for scenarios 1 and 3, we display the author:@username and convert it into the avatar + name visual once we receive that information from the backend.

@filipa does this architecture sound good to you?

mentioned in issue #30467 (closed)

@ClemMakesApps In scenario 3 - where we paste data in the search bar, the request are made exactly the same like 1. and 2.

So no need for extra request, we already have all the data we need in the 3 scenarios above

Actually @filipa, it looks like in scenario 3, the last filter is loaded using JSON (Probably because the paste triggers the dropdowns to load) but not all the filters before are loaded.

In that case let's make it behave the same for all pasted data. :) No request should be made correct? Maybe we should open a bug with this, since we thought no request was being made in the first place?

mentioned in issue #31153 (moved)

In that case let's make it behave the same for all pasted data. :)

not sure what you mean by this @filipa. Created issue #31153 (moved) to reference the extra unnecessary ajax request

Multiple assignees (FE) review ended up taking a lot of my time this release month. I don't think I will be able to ship this Deliverable in time along with my others. Assigning to @jschatz1 as discussed in slack.

assigned to @jschatz1

assigned to @timzallmann

mentioned in merge request !11047 (merged)

assigned to @winh

Making this 9.3, because it didn't make it for 9.2 right?

changed milestone to %9.3

@victorwu Yes , @winh picked it up as he already did another search bar issue, will be his first prio as it was already planned for 9.2

I will start working on this as soon as I have finished #32127 (closed) (unless there are other regression s which need my attention).

I propose we perform an ajax request to get that specific username's name and avatar.

Judging from a first look into this, we will need a new backend route. User routes currently don't have that information.

I feel comfortable adding this route myself but it will take me some time.

It would be nice if we could have a separate API that would return all of these user's names and avatar information

I agree that this would be nice but I would keep that as a performance optimization for later. Especially since we are having trouble with pasting (#31859 (moved)) and do not have a way to copy filters (#31854 (moved)).

if a user pastes something such as assignee:@ClemMakesApps assignee:@jschatz assignee:@filipa (multiple assignees)

@ClemMakesApps I just noticed that it is not possible to filter by multiple assignees nor by multiple authors. Even though it is possible to write multiple assignee:@user / author:@user tokens, only the last one is considered.

@victorwu Is having multiple assignees / authors intended? If so, it probably makes sense to introduce along with #27747 (moved).

@winh : For multiple authors, that's fine. We'll have to fix that later. Not blocking anything here right?

For multiple assignees, should be addressed in https://gitlab.com/gitlab-org/gitlab-ee/issues/1967.

Judging from a first look into this, we will need a new backend route. User routes currently don't have that information.

I feel comfortable adding this route myself but it will take me some time.

It would be ideal to get another backend call but I think we can still do without having an extra API

wdyt @smcgivern

Not blocking anything here right?

@victorwu Yes, this is not blocking just leaning me towards doing performance optimization for multiple users in a second iteration.

@ClemMakesApps @winh I'm not sure what happened to @filipa's suggestion above, but I think it makes sense, with a slight twist: in cases 1 and 3 (https://gitlab.com/gitlab-org/gitlab-ce/issues/30468#note_27592347), we explicitly request the autocomplete information for users, as it contains all project members.

I have a theory that this would cover most of the cases this is used for, but the only way we can confirm that is by searching the logs (https://log.gitlap.com/app/kibana) which aren't really structured for this

If someone isn't a project member, we could fall back to getting their information from /$user.json - adding that information there should be fine - but I'm not really sure what else uses that

Oh wait, I just remembered we have a global users autocomplete endpoint: https://gitlab.com/autocomplete/users.json?search=&per_page=20&active=true&project_id=&group_id=&skip_ldap=&todo_filter=&todo_state_filter=&current_user=true&push_code_to_protected_branches=&author_id=&skip_users=

As you can see, that already takes a lot of params. But perhaps we could make it also take an array of usernames, and then we'd be good?

I'm not sure what happened to @filipa's suggestion above No request should be made correct?

Sorry, @filipa, I ignored your suggestion because I didn't understand it. If we make no request for pasted data, we can't show user name and avatar. Am I misunderstanding your suggestion?

@winh but we can make a request to the same endpoint on purpose, even if we currently do it by mistake

@winh we have 3 scenarios:

• User types out the username (Eg. author:@ClemMakesApps)

A request is made when you type. No need for an extra request

• User clicks on the username that is displayed on the dropdown (same as if the user filters and clicks)

A request is made when we open the dropdown. No need for an extra request

• User pastes the username to the search bar

A request is made when we paste data. No need for an extra request.

My suggestion is we do not need any request to style the data because we already have the data.

In this comment https://gitlab.com/gitlab-org/gitlab-ce/issues/30468#note_27592347 is stated that for scenarios 1 and 3 we need to make a request to the server but the truth is we don't because we already have all the information we need.

Currently in scenario 3 we make a request to the server, but according to the @ClemMakesApps's comments we do not do it on purpose.

Does it make sense?

we explicitly request the autocomplete information for users, as it contains all project members. I have a theory that this would cover most of the cases this is used for

@smcgivern There are only 20 users queried in the autocomplete and authors don't have to be project members (so they are not queried at all). I would definitely use the information from autocomplete if we have it but we can not rely on it being always available.

There are only 20 users queried in the autocomplete

We can request more, though!

authors don't have to be project members (so they are not queried at all)

I mentioned that in the very next paragraph!

we could fall back to getting their information from /$user.json - adding that information there should be fine - but I'm not really sure what else uses that

@smcgivern That endpoint is used for user activity. Fetching user activity just to get user name and avatar doesn't seem right to me.

If we want to use that endpoint we could

1. move activity events to another endpoint
2. make inclusion of events a query parameter
3. use the API instead?

Sorry, it seems using thread here was a bad idea. Continuing unthreaded:

• User types out the username (Eg. author:@ClemMakesApps)

A request is made when you type. No need for an extra request

@filipa We need an extra request if user is not within 20 autocompleted users or is not project member.

A request is made when we open the dropdown. No need for an extra request

Yep, agreed.

A request is made when we paste data. No need for an extra request.

Currently, pasting data doesn't make a request for every user (which should be fixed, probably in #31859 (moved)). But I agree that if we make the request when pasting, there is no need to make an additional request.

From the available options the API is the only one which already returns the necessary data and not much more—no backend modification would be necessary.

---

So my plan here would be:

1. User types out the username (Eg. author:@ClemMakesApps)

Use autocomplete data if available. Otherwise make API call.

2. User clicks on the username that is displayed on the dropdown (same as if the user filters and clicks)

Use data from dropdown.

3. User pastes the username to the search bar

For every pasted user that is neither fetched by autocomplete nor by dropdown, make API call.

---

@filipa @smcgivern Does that sound right to you?

For scenario 1, when I type my name this request is made:

https://gitlab.com/autocomplete/users.json?per_page=20&active=true&project_id=13083&current_user=true&search=filip

and returns

[{
  "id": 482476,
  "name": "Filipa Lacerda",
  "username": "filipa",
  "avatar_url": "https://gitlab.com/uploads/user/avatar/482476/avatar.png"
}]

In which cases doesn't this happen?

For scenario 3:

For every pasted user that is neither fetched by autocomplete nor by dropdown, make API call.

Does this means:

1. Make 1 API call with all the users
2. Make an API call for each user

For scenario 1 [...]
In which cases doesn't this happen?

@filipa If you type author:@winniehell for example. (autocomplete is empty, but the author exists)

For scenario 3:

Make one call for each user in first iteration (since we support at most 2 right now).

Make one call for all users at once after pasting is fixed and multiple users are supported.

If you type author:@winniehell for example. (autocomplete is empty, but the author exists)

Is this a bug? @smcgivern

There is an issue about including non-members in autocomplete but I can't find it.

@filipa not a bug, exactly, but there is an issue somewhere to improve it.

@winh sounds good to me

since we support at most 2 right now

Not sure where you got this information but multiple assignees doesn't have a max limit

since we support at most 2 right now

Not sure where you got this information but multiple assignees doesn't have a max limit

@ClemMakesApps By "right now" I meant current version on gitlab.com—so without multiple assignees. The 2 comes from one author + one assignee filter as every additional author or assignee overwrites the previous one in the search bar.

mentioned in merge request !11374 (merged)

Perfect, glad we are on the same page

mentioned in merge request !11402 (merged)

mentioned in merge request !11404 (merged)

mentioned in issue #32497 (moved)

mentioned in merge request !11643 (merged)

closed via merge request !11402 (merged)

mentioned in commit 51c19616

@victorwu @filipa Any news?

@timofonic This has been released as part of GitLab 9.3.

@timofonic, as @winh mentioned, this was released in %9.3 you can already use it

mentioned in issue gitlab#9948