Skip to content
Snippets Groups Projects
Open Convert Admin "Users" view from HAML to Vue
  • Convert Admin "Users" view from HAML to Vue

  • Open Epic created by Jiaan Louw

    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

    See the full implementation with next-ups discussed in &4683 (comment 435131368).

    Related links

    Edited by Jiaan Louw

    Child items
    14
    22 77%

    22 77%

  • View on a roadmap
  • Linked items 0

  • Link items together to show that they're related or that one is blocking others.

    Activity

    • All activity
    • Comments only
    • History only
    • Newest first
    • Oldest first
    • Dan Jensen
      • Dan Jensen

        @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 :shrug:

      • 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?

        Edited by Dennis Tang
      • Dennis Tang

        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.

      • Dan Jensen

        @dennis ah, the proposal there is just "Move sorting to the table columns", so I didn't understand that meant converting the view to Vue. If this is a duplicate then absolutely please feel free to close! Sorry if I disrupted the frontend flow here :grimacing:

      • Dennis Tang

        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.

      • Please register or sign in to reply
      • Peter Hegman

        I wanted to pass on a few notes since I am finishing up some work on &4233 (closed) which is related.

        1. 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
        2. 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!

      • Jiaan Louw
        Author

        Thanks so much for all the info & resources you've shared @peterhegman! :handshake: :smiley: 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:

        1. Create a admin/users store that can request the data from the Users API.
        2. Update the admin/users store to support admin actions like block, delete, etc with the Users API.
        3. Create a admin/users/actions component (the edit button & cog dropdown).
        4. Update any of the reusable components if needed.
        5. Create a admin/users table using the store and reusable components.
      • Robert Hunt

        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 :slight_smile:

        • 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
        • 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
      • Jiaan Louw
        Author

        Fantastic detailed breakdown @rob.hunt!! :100: :smiley: I'm in full agreement and thank you for catching that we also need to migrate the modals to Vue. :thumbsup: 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. :thinking:

        Edited by Jiaan Louw
      • Robert Hunt

        @jiaan To be fair, I haven't gone too far into how much work each point might be :see_no_evil:. I think there is scope for grouping definitely :thumbsup:.

        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 :slight_smile:.

      • Jiaan Louw
        Author

        Thanks for the quick response @rob.hunt! :rocket: 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. :footprints:

        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. :thumbsup: :smiley:

        Edited by Jiaan Louw
      • Peter Hegman

        @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.
      • Robert Hunt

        Thanks for the heads-up @peterhegman :100:

        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 include blocked_pending_approval and deactivated.

        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 :thinking:. Not entirely sure how to check for ::Gitlab.com? in Vue though :see_no_evil:

        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.

        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 :slight_smile:.

        WDYT @jiaan?

      • Jiaan Louw
        Author

        Thanks for spotting this @peterhegman! :eagle: :eyes: And @rob.hunt for your thoughts & investigation! :clap:

        Not entirely sure how to check for ::Gitlab.com? in Vue though :see_no_evil:

        WDYT 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. :thumbsup:

      • Jiaan Louw
        Author

        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 :thinking:.

        I asked @doniquesmit from devopsfulfillment to confirm and it was recently added with gitlab#36750 (closed) in gitlab!43057 (diffs).

      • Jiaan Louw
        Author

        we're going to need to update the app/finders/users_finder.rb to include blocked_pending_approval and deactivated.

        Agreed, in any case this would be useful ~"group::access" information to have in our users API. :thumbsup: 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

      • Manoj M J

        @jiaan great find and thanks for creating the issues with the correct details :slight_smile: Agree this would be required, I've added weights to the issues as well based on my estimate :thumbsup_tone2:

        Edited by Manoj M J
      • Please register or sign in to reply
    Loading Loading Loading Loading Loading Loading Loading Loading Loading Loading