@hmehra

As Adil mentioned, 2FA works similarly, UX wise it blocks user from accessing any other groups and projects if at least 1 group has required 2FA and forces user to enroll in 2FA before proceeding.

Currently, the design is to have an error message when user attempts to access endpoint for a group's resource: Access denied: "my/cool/project" requires a fine grained personal access token with the following permissions (Resource: Permission): [Group: Read, Repository: Read].

I do see what you mean in the similar wording. We could update the copy to make it more distinct, adding group resources to Top Level Group enforcement in SaaS, thoughts @idurham @NellyVahab e?

Self Managed
SaaS

@hmehra @NellyVahab

The UX issue says Set enforcement date: tokens used to access group resources after this date must be fine-grained.

Yes, this was as intended to support the decision then as PATs are owned by users and we will still support legacy tokens. This was also noted as an acceptable tradeoff in the doc. This differs from Self-Managed which was designed to be at instance level and can be enforced that all user's tokens in their instance be fine-grained (UX issue link).

I believe the decision to go forward with TLG instead of enterprise users then was partly due to dependency on GitLab's adoption of enterprise users and this path not covering external collaborators. Since GitLab users are now enterprise users, have we changed enforcement to enterprise users? How are we covering external collaborators? (cc: @jrandazzo for additional context)

@hmehra I see it now, apologies I had to update my local branch 😓 Few comments:

• Spacing in between the H3 sections to 40px

• The badge is intended to signal the progress through resource addition under each bound, could we instead reflect the number of resources added rather than the number of resources available?

  

• Sounds good about the resource group, I'll track it there.

• I see the CRUD on group/project access as well, thanks!

Looks good @hmehra, thank you!

What does this MR do and why?

• Updates the UX of the PersonalAccessTokenDrawer to render as a panel instead (similar to work items).

Screenshots or screen recordings

Before	After

How to set up and validate locally

1. Enable the granular_personal_access_tokens flag from the rails console.

Feature.enable(:granular_personal_access_tokens)

1. Log-in as any user and navigate to /-/user_settings/personal_access_tokens.
2. Click on Generate token > Fine-grained token
3. Once you have created the token, click on the token's name back on the table to view the token's panel.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #581759

Thanks @hmehra, since we don't have validation for requiring group and project resource permissions when group and project access selected, then this is fine. User must select at least one resource permission and this can be user permissions. #592968 (comment 3163826790)

@hmehra thanks, looking good! Just confirming that the description states what to review:

Addresses the first 4 UX improvements listed in the #592968

Changes not covered in the MR from the first 4 UX improvements:

• Item 2: Section changes: Basic Information, Group and project access, Add resource permissions in H3
• Item 3: Description for Group and project access, Dropdown realignment to the right, Group and project title in CRUD component
• Item 4: Resource group selectable, Empty state text: No resources added

@hmehra Currently, we don't have an error message, so user can select group and project access but only have added resource permissions for user and instance. There's no risk for user in this scenario, so no error message is as intended. We have an error message for when user adds resource permissions for group and project with no group and project access. This is supported by the description under Group and project access: Required only if you add group and project permissions. (cc: @NellyVahab )

@hmehra is the challenge that we need to include Inactive tokens in the filter?

Yes that could be confusing.. it almost needs to say something like "Grant permission to create/read.." thoughts @idurham?

@jrandazzo Good idea - something like this list? Anything else to add/remove? If all good, I will update the mock with the following data (cc: @NellyVahab )

@hmehra Oof glad we reverted it! What warning will we have for user when they use the fine-grained PAT with FF off?

Wdyt of also testing User access tokens as an option 3? I imagine we need to do some additional validation work to rename for Project and Group Settings?

@hmehra good catch, let's keep it to resource category for now.

Thanks @hmehra, great to see the panel work and information is nicely spaced and easier to follow

Visual updates:

• Add 16 px of spacing in between categories

  

• Move Expires to right alined consistent with all other items in table when viewport is small

  

Other comments

• When I create a token with "All groups and projects" should be reflected in the detail panel.

  

• I know we chatted about showing timezone in panel since we have space, on hover is good for now in case it's coming in a different MR. It's worth noting, there is no hover to reveal timezone under "Created date".

Thanks again, looking so good!

@NellyVahab and @idurham - We can use this image for hero 🦸, I made it look as similar as it is to beta today.

I agree that video is probably more suited for GA. Here's the one Joe did for job tokens as an example!

@alexbuijs @ajaythomasinc @NellyVahab @hmehra designs are populated in the description, pls let me know if you have any questions or concerns - otherwise this can be moved to workflowready for development