Provide complete safe current user entity to frontend

Currently, the gon object only contains current_user.id, current_user.username, current_user.name. For #32464 (closed), #22921 (closed) and #30468 (closed) we need the current user's avatar. So we should instead serialize the complete UserEntity / API::Entities::UserBasic to gon.

/cc @kushalpandya @blackst0ne @lbennett

@grzesiek Can we have your opinion on that, too?

Also, once !11404 (merged) is merged, we should consider adding a UsersCache.currentUser and prefill UsersCache from gon. Then we could solely rely on UsersCache in frontend code.

Since this is necessary for at least one Deliverable , I haven't labeled it technical debt.

Related: https://gitlab.com/gitlab-org/gitlab-ce/issues/32151

Not only we need to know the current user we also need to know the namespace and the project name often in order to build link paths.

@winh I think we are deprecating the gon object

cc @iamphill @fatihacet @mikegreiling

@winh I think we are deprecating the gon object

@filipa I heard that, too. But I couldn't find a replacement. Do you know of any?

@filipa we shouldn't build the links on the frontend at all though

@winh We are following a flux architecture. For each section/app we use a store. Currently is only documented for vue.js but the goal is to move in that direction https://docs.gitlab.com/ce/development/fe_guide/vue.html#vue-architecture

@iamphill I though the main reason we did not want to do that was because we did not knew what the project and namespace were. Are there other reasons?

Not only we need to know the current user we also need to know the namespace and the project name

@filipa Since we need the current user's avatar for the issues mentioned above and I haven't found a way without making an additional Ajax call, I'd like to focus on a solution for that particular problem rather than creating a general context right now.

We are following a flux architecture. For each section/app we use a store.

@filipa That means we have to store the current user separately for every component?

@filipa Nope. What if the paths change in the future? We'd have to go through all the frontend to check. We'd also have to take into consideration that GitLab can be hosted in a sub-directory. Its doable, but much easier to let the backend give us the full link we need, single source of truth.

We are following a flux architecture. For each section/app we use a store.

@filipa Also, how does the current user get into the store? Should that be an Ajax call?

What if the paths change in the future? We'd have to go through all the frontend to check.

@filipa @iamphill please see https://gitlab.com/gitlab-org/gitlab-ce/issues/31953#note_29064950

Yah, so to clear up gon... We don't want to use it for much at all, but I wouldn't say its deprecated. In some cases its the only sane solution. I could have missed a big discussion about this however.

It's not a good solution for you to simply share any backend data with some frontend component. It will get too bloated and eventually when we want to remove that final inline script it will be a huge task.

It is however a fine solution for sharing backend data that is used on a lot of pages. So, I'd say current_user applies.

Here is discussion on building paths on frontend: https://gitlab.com/gitlab-org/gitlab-ce/issues/32378

This still can follow "flux". We have a service. This service queries (through dom, object accessor, or network) for some specific data. In this case current_user data in object. This is then in the store, and component can use it one way.

From docs:

1. Calling the Service to get data from the serverobject
2. Calling the Store to store the data received
3. Mounting all the other components

@winh yes!

Following our docs what would happen is:

• We make a request to the API
• We store the received data in the store
• We use the data from the store in our views

Following our docs what would happen is:
We make a request to the API

@filipa I don't mind implementing it like this but it feels like an unnecessary Ajax call to me.

mentioned in issue #32151 (moved)

@winh isn't this ajax call made somewhere? How do we get the data in the first place?

@winh isn't this ajax call made somewhere? How do we get the data in the first place?

@filipa Currently, we use gon for that which inserts a script tag into the current page and assigns data to the global window.gon object. This is ugly, but we get this data "for free" (without an extra Ajax call).

If we do the Ajax call for user data upon page load, it probably doesn't slow down any component that needs it. I'm only a bit hesitant because if that call fails for whatever reason, we would not be able to display the data until we make another call.

Like I said, nothing so grave that it would keep me from using that approach.

/cc @timzallmann as requested in 1:1

@iamphill @fatihacet what is you opinion on this?

If we do the Ajax call for user data upon page load, it probably doesn't slow down any component that needs it. I'm only a bit hesitant because if that call fails for whatever reason, we would not be able to display the data until we make another call.

So we are going to do the same things twice:

1. Backend grabs data from DB and renders HTML with user data.
2. Frontend makes an AJAX call and grabs the part of already rendered user data.

Maybe it's worth to add a thin JS function which will take data from gon (backend will put it while rendering HTML), place the data to a frontend storage, and clear gon.

Pros:

1. No need to make things twice.
2. No need to use global variable (gon).
3. Ability to use storage and synchronize it with different AJAX calls if they'll fired later on the page.

Cons:

1. A bit much work on frontend.

What do you think?

Maybe it's worth to add a thin JS function which will take data from gon

@blackst0ne That was my idea with the UsersCache. (https://gitlab.com/gitlab-org/gitlab-ce/issues/32497#note_29978618) That way frontend code would never access gon.current_user but always UsersCache.currentUser.

@blackst0ne That was my idea with the UsersCache. (https://gitlab.com/gitlab-org/gitlab-ce/issues/32497#note_29978618) That way frontend code would never access gon.current_user but always UsersCache.currentUser.

Ooops! Sorry.

@grzesiek Can we have your opinion on that, too?

@winh I all for making our internal API via serializers usable and complete.

moved to gitlab#9948

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue