Convert Admin "Users" view from HAML to Vue
Problem to solve
Currently the Admin "Users" view is built with HAML. It should be converted to Vue to support:
Proposal
The Admin "Users" view should be converted to Vue.
MVP Implementation
Convert the admin users table to Vue. &4961 (closed)
This is the minimum implementation we need to deliver the issues listed above.
What's next after we converted the table to Vue?
- Add the missing fields to our REST / GraphQL API
- Create admin users store
- Migrate the admin actions to the store
- edit
- block
- deactivate
- delete
- delete-with-contributions
- Use the URL filter params to fetch the data from the API
- Migrate the admin actions to the store
See the full implementation with next-ups discussed in &4683 (comment 435131368).
Related links
- @peterhegman explained this conversion to Vue would be helpful for 2 groupauthentication and authorization [DEPRECATED] features (both mentioned above).
- Show closed items
- View on a roadmap
- Issuegitlab-org/gitlab#3209223Next Up [deprecated] Accepting merge requests devops software supply chain security frontend group authentication priority 4 section sec type maintenance workflow ready for development
- Issuegitlab-org/gitlab#2851052UX FY21-Q4 [deprecated] Accepting merge requests devops software supply chain security feature enhancement frontend group authentication priority 4 section sec type maintenance workflow ready for development
- Issuegitlab-org/gitlab#290276Backlogbackend devops software supply chain security feature enhancement frontend group authentication section sec type feature workflow planning breakdown
- Epic#49611017Nov 18, 2020 – Jun 17, 2021
- Show labels
- Show closed items
Activity
@dennis given this is blocking showing user group counts for %13.5 release, is there any chance we could scramble and get it prioritized? Maybe that feature will still slip, but at least we could line it up for %13.6
- Edited by Dennis Tang
I'm sure we could do that, @djensen. However, isn't this just a duplicate of gitlab#238181, which is to also convert the Admin "Users" view to Vue?
Sorry, perhaps "convert" is a trigger word but gitlab#238181 speaks to more about the functionality of adding sortable columns, so we can use this issue to represent the actual Vue conversion.
No you're fine @djensen, I straightened it out between both issues, we'll use this to track our work on the Vue conversion itself. There's still more work to be done if they want sortable columns which that issue is now for.
I wanted to pass on a few notes since I am finishing up some work on &4233 (closed) which is related.
- I think you may be able to use a few components in the admin table
- UserAvatar - May depend on the format of the data from the backend
- CreatedAt - May depend on the designs
- I used &4233 (closed) to split the work up into 5 issues. This worked pretty well but in hindsight it could have been nice to break it down even more as a few of the issues required a number of MRs to complete.
Anyways feel free to ping me if you need anything!
- I think you may be able to use a few components in the admin table
Thanks so much for all the info & resources you've shared @peterhegman!
I think we'll definitely be able to use a lot of the existing resources, albeit with some minor modifications if needed.@peterhegman & @rob.hunt WDYT about this rough breakdown to convert the table from HAML -> Vue:
- Create a admin/users store that can request the data from the Users API.
- Update the admin/users store to support admin actions like block, delete, etc with the Users API.
- Create a admin/users/actions component (the edit button & cog dropdown).
- Update any of the reusable components if needed.
- Create a admin/users table using the store and reusable components.
Thanks for the breakdown @jiaan! I entirely agree with you. Although this is going to take a bit more work, I think the longer-term benefits to this pages maintainability and ease of adding additional features greatly outweigh the short-term timescales.
I was actually mapping out a similar direction, this is slightly more detailed but my aim was to try and consider how we could break this work down into small MR's. Of course, this can be tweaked and adjusted but I think it aligns quite well with your thinking
- Set up feature branch (since we can't deploy an vertical or lateral MVC within one MR)
- Create admin users store with:
- Generate list of users based upon filters
- User avatar
- User name
- User link
- User email
- Projects count
- Created on
- Last activity
- Edit link
- Block with modal
- Deactivate with modal
- Delete with modal
- Hard delete with modal
- Generate list of users based upon filters
- Create wrapping component with base table headers and store connection
- Display table headers
- Initiate store
- Run the list generation with URL filter param
- Create user row(s) using store data
- Create pagination of users
- Create an edit button using store data
- Create cog button dropdown using store data
- Create a block link with modal using store data
- Create deactivate link with modal using store data
- Create delete link with modal using store data
- Create hard delete link with modal using store data
- Edited by Jiaan Louw
Fantastic detailed breakdown @rob.hunt!!
I'm in full agreement and thank you for catching that we also need to migrate the modals to Vue. How would you suggest we deliver these points? All together that's 11 tasks without counting the sub points, would you suggest an issue for each one? I'd imagine that we could group the action buttons. @jiaan To be fair, I haven't gone too far into how much work each point might be
. I think there is scope for grouping definitely .Since we're going to have a single feature branch with lots of MR's going into it: WDYT about having an implementation issue with the breakdown of tasks. Then complete the initial steps (store setup and initial table vue app) and then see how we feel about where to break down the remaining points? We should have a much better idea of how "hard" things might be to implement at that point
.- Edited by Jiaan Louw
Thanks for the quick response @rob.hunt!
I'm supportive of grouping small tasks into a single issue, however for larger tasks I'd suggest we rather create separate issue, that way it should be easier to track progress & effort in a release context.complete the initial steps (store setup and initial table vue app) and then see how we feel about where to break down the remaining points?
This seems like a very sensible approach and I'm all for it.
@rob.hunt @jiaan that plan looks great to me! A few things that caught my eye:
- Based on the Users API docs it looks like there may be a few filters the API does not yet support. There may be some undocumented filters though.
- "Pending approval" filter
- "Deactivated" filter
- The API may not support the "Is using seat" badge. This is how it is currently rendered: ee/app/helpers/ee/users_helper.rb#L15
- There will probably be some feature specs that need to be updated. What I did was use
stub_feature_flags
to stub the feature flag while I was developing. Then I updated the selectors in the feature specs after I was done. Not sure if this is the best approach, but since the development spanned across multiple milestones I thought it was better to keep the feature specs intact until I was close to enabling the feature flag.
- Based on the Users API docs it looks like there may be a few filters the API does not yet support. There may be some undocumented filters though.
Thanks for the heads-up @peterhegman
Based on the Users API docs it looks like there may be a few filters the API does not yet support. There may be some undocumented filters though.
- "Pending approval" filter
- "Deactivated" filter
Having tested these points out, I agree, we're going to need to update the
app/finders/users_finder.rb
to includeblocked_pending_approval
anddeactivated
.The API may not support the "Is using seat" badge. This is how it is currently rendered: ee/app/helpers/ee/users_helper.rb#L15
In terms of license seat checks, the API does return whether a user is using a license seat, it's just not shown on the API example
. Not entirely sure how to check for::Gitlab.com?
in Vue thoughThere will probably be some feature specs that need to be updated. What I did was use
stub_feature_flags
to stub the feature flag while I was developing. Then I updated the selectors in the feature specs after I was done. Not sure if this is the best approach, but since the development spanned across multiple milestones I thought it was better to keep the feature specs intact until I was close to enabling the feature flag.I think the simplest approach is to have a "with feature"/"without feature" variant for each expected spec and then delete the "without feature" when the feature flag is removed
.WDYT @jiaan?
Thanks for spotting this @peterhegman!
And @rob.hunt for your thoughts & investigation!Not entirely sure how to check for
::Gitlab.com?
in Vue thoughWDYT about replicating gitlab.rb#L47 as a JS utility function or adding it into the
gon
object?I think the simplest approach is to have a "with feature"/"without feature"
I think this would depend on when we merge our feature branch, but in general I agree that we should be testing our features even if they are behind a flag.
In terms of license seat checks, the API does return whether a user is using a license seat, it's just not shown on the API example
.I asked @doniquesmit from devopsfulfillment to confirm and it was recently added with gitlab#36750 (closed) in gitlab!43057 (diffs).
we're going to need to update the
app/finders/users_finder.rb
to includeblocked_pending_approval
anddeactivated
.Agreed, in any case this would be useful ~"group::access" information to have in our users API.
So I've gone ahead and created issues gitlab#276195 and gitlab#276196 to add this to the admin users API. @manojmj WDYT about adding this? I spotted that you're currently working a related issue gitlab#263106 (closed)./cc @mushakov