GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2024-03-29T10:27:11Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/449085[Test] ee/spec/features/account_recovery_regular_check_spec.rb | Account reco...2024-03-29T10:27:11ZTEST_FAILURES_PROJECT_TOKEN[Test] ee/spec/features/account_recovery_regular_check_spec.rb | Account recovery regular check callout when signed in when user has two-factor authentication enabled hides callout on next session if user dismissed it### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`ee/spec/features/account_recovery_regular_check_spec.rb#L89`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/spec/features/account_recovery_reg...### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`ee/spec/features/account_recovery_regular_check_spec.rb#L89`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/spec/features/account_recovery_regular_check_spec.rb#L89) |
| Filename | `ee/spec/features/account_recovery_regular_check_spec.rb` |
| Description | `Account recovery regular check callout when signed in when user has two-factor authentication enabled hides callout on next session if user dismissed it` |
| Test level | system |
| Hash | `1ba04ad784ee520b5f9f80eb7649dac31de9c230c` |
| Reference duration | 19.21 seconds |
| Expected duration | < 50.13 seconds |https://gitlab.com/gitlab-org/gitlab/-/issues/444684[Test] spec/features/admin/users/users_spec.rb | Admin::Users GET /admin/user...2024-03-29T10:24:13ZTEST_FAILURES_PROJECT_TOKEN[Test] spec/features/admin/users/users_spec.rb | Admin::Users GET /admin/users shows the user popover on hover### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`spec/features/admin/users/users_spec.rb#L54`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/features/admin/users/users_spec.rb#L54) |
| File...### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`spec/features/admin/users/users_spec.rb#L54`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/features/admin/users/users_spec.rb#L54) |
| Filename | `spec/features/admin/users/users_spec.rb` |
| Description | `Admin::Users GET /admin/users shows the user popover on hover` |
| Test level | system |
| Hash | `9a532f8d8695d3833d6190d5dcf4469d123980f76` |
| Reference duration | 4.22 seconds |
| Expected duration | < 50.13 seconds |
### Reports (2)
1. 2024-03-08: https://gitlab.com/gitlab-org/gitlab/-/jobs/6349791837 (https://gitlab.com/gitlab-org/gitlab/-/pipelines/1206085763)
1. 2024-03-08: https://gitlab.com/gitlab-org/gitlab/-/jobs/6350370869 (https://gitlab.com/gitlab-org/gitlab/-/pipelines/1206174051)https://gitlab.com/gitlab-org/gitlab/-/issues/433177FE: Add a “Pending promotion” tab to the admin panel2024-03-29T00:12:58ZKos PalchykFE: Add a “Pending promotion” tab to the admin panelWe need to display pending promotions requests tab on the admin panel users page (`/admin/users`), for instance admins to review and approve or reject the applications.
We'll need to create a tab, where we'll display the list and inject...We need to display pending promotions requests tab on the admin panel users page (`/admin/users`), for instance admins to review and approve or reject the applications.
We'll need to create a tab, where we'll display the list and inject or fetch the data in a table form. With UI, similar to other tabs, and Approve and Reject actions.
BE issues for this:
| link | header |
| ------ | ------ |
| https://gitlab.com/gitlab-org/gitlab/-/issues/433175 | provide data for tab |
| https://gitlab.com/gitlab-org/gitlab/-/issues/433176 | create API endpoints for the actions |
_Actions (approval and rejection) might be split into a separate implementation issue._
Draft UI for the new Pending Promotion tab:
![image](/uploads/a9d722393f07d5bb94d340d0bb98f928/image.png)
Draft MR implementation for integration purposes: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/14242317.0https://gitlab.com/gitlab-org/gitlab/-/issues/433174FE: Add a “Pending promotion” tab to the group and project, list the pending ...2024-03-29T00:12:31ZKos PalchykFE: Add a “Pending promotion” tab to the group and project, list the pending promotions thereWe need to add Pending Promotion tab to display promotion request lists at Group and Project membership management pages (e.g. http://127.0.0.1:3000/groups/gitlab-org/-/group_members and http://127.0.0.1:3000/h5bp/html5-boilerplate/-/pro...We need to add Pending Promotion tab to display promotion request lists at Group and Project membership management pages (e.g. http://127.0.0.1:3000/groups/gitlab-org/-/group_members and http://127.0.0.1:3000/h5bp/html5-boilerplate/-/project_members).
Relevant BE issue to integrate with: https://gitlab.com/gitlab-org/gitlab/-/issues/433173
UI should match that in other tabs. Filtering and sorting is a nice-to-have at this stage.
This very page will later be used to display ~"All SaaS" pending promotions.
Draft UI: ![image](/uploads/10195bf5b47fe9a77b22ebc20c4c74ea/image.png)
Draft MR for integration PoC: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/14724916.11Kos PalchykKos Palchykhttps://gitlab.com/gitlab-org/gitlab/-/issues/449139Follow-up: Update counter and list of pending promotion requests, after inlin...2024-03-29T00:11:52ZKos PalchykFollow-up: Update counter and list of pending promotion requests, after inline change of the roleThis is a follow-up after https://gitlab.com/gitlab-org/gitlab/-/issues/441275+
When a role in members table was changed in-line, and the role change is going through the approval flow, we should update the Pending Promotion tab counter...This is a follow-up after https://gitlab.com/gitlab-org/gitlab/-/issues/441275+
When a role in members table was changed in-line, and the role change is going through the approval flow, we should update the Pending Promotion tab counter and the tab list with the new entry.https://gitlab.com/gitlab-org/gitlab/-/issues/442705Follow up for Adding request spec instead of Controller spec for Queue Existi...2024-03-29T00:11:09ZSuraj Tripathistripathi@gitlab.comFollow up for Adding request spec instead of Controller spec for Queue Existing NonBillable MemberPromotion Request if Feature EnabledFollow Up issue to add Controller Request Spec
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142202#note_1784122036+sFollow Up issue to add Controller Request Spec
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142202#note_1784122036+s16.11Suraj Tripathistripathi@gitlab.comSuraj Tripathistripathi@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/433175BE: Add data to list pending promotion members on Admin Page2024-03-29T00:10:56ZKos PalchykBE: Add data to list pending promotion members on Admin Page## Objective
**Objective**: create the BE list of user pending promotion that will be surfaced to the admin for approval
**Scope:** ~"self-managed" ~"GitLab Ultimate"
## Work to be done
| Summary of work | Description | MR |
|-------...## Objective
**Objective**: create the BE list of user pending promotion that will be surfaced to the admin for approval
**Scope:** ~"self-managed" ~"GitLab Ultimate"
## Work to be done
| Summary of work | Description | MR |
|-----------------|-------------|----|
| Listing the pending promotion users for the Admin to Approve in Admin Area | The Backend changes which will integrate with the new [UI tab](https://gitlab.com/gitlab-org/gitlab/-/issues/433177 "FE: Add a “Pending promotion” tab to the admin panel") and provide the list of data that would be used to display the pending promotion users. | |
## Open Items
- [ ] **FE / BE Alignment**: determine what the Backend should return as response, which will then be consumed by the frontend to display the "Pending Promotion" tab. Something similar to [this](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/143585#note_1754505194 'Draft: Resolve "FE: Add a “Pending promotion” tab to the group and project, list the pending promotions there"') MR which discusses the Backend/Frontend handshake to display the "Pending Promotion" on the Group and Project Members page.
- [ ] **Re-usability**: determine if changes made as part of the [Project/Group member listing](https://gitlab.com/gitlab-org/gitlab/-/issues/433173) (structure of backend response and such) can be reused here
<details>
<summary>Original Issue Contents</summary>
List Pending Promotion requests.
1. Identify how data will be shown on FE
2. Make BE changes to return data for the same
</details>16.11https://gitlab.com/gitlab-org/gitlab/-/issues/433176BE: Allow Admin to approve/reject the promotion request2024-03-29T00:10:18ZKos PalchykBE: Allow Admin to approve/reject the promotion request## Problem
* Allow Admin to Approve or Reject Promotion Request
## Use Cases
<table>
<tr>
<th>Use Cases</th>
<th>Expectation</th>
</tr>
<tr>
<td>
1. Admin Approves the Pending Promotion Request
</td>
<td>
* Users Member Role Gets Ch...## Problem
* Allow Admin to Approve or Reject Promotion Request
## Use Cases
<table>
<tr>
<th>Use Cases</th>
<th>Expectation</th>
</tr>
<tr>
<td>
1. Admin Approves the Pending Promotion Request
</td>
<td>
* Users Member Role Gets Changed/Updated
* Pending Promotion Entry gets updated
</td>
</tr>
<tr>
<td>
2. Admin Rejects the Pending promotion request
</td>
<td>
* Pending Promotion Entry gets updated
</td>
</tr>
</table>
## Work to do
* [ ] Frontend Backend discussion to understand how would FE consume this change
* [ ] Backend logic to update the Promotion Request16.11https://gitlab.com/gitlab-org/gitlab/-/issues/433173BE: List Pending Promotion Members for Group/Project Member listings2024-03-29T00:09:03ZKos PalchykBE: List Pending Promotion Members for Group/Project Member listingsUnderstand what is the best way to display this information on FrontEnd
1. Change/Add BE logic to display this data on FrontendUnderstand what is the best way to display this information on FrontEnd
1. Change/Add BE logic to display this data on Frontend16.11Suraj Tripathistripathi@gitlab.comSuraj Tripathistripathi@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/433179BE: update invitations API, or create a new one, to handle invites with the a...2024-03-29T00:04:28ZKos PalchykBE: update invitations API, or create a new one, to handle invites with the approval flow## Problem
* Pending promotion can happen to non-members and such promotion requests don't have a relevant member entry, which makes it challenging to display on the `/members` page since that code is heavily focused on displaying parti...## Problem
* Pending promotion can happen to non-members and such promotion requests don't have a relevant member entry, which makes it challenging to display on the `/members` page since that code is heavily focused on displaying particularly members. We had to detach Promotion Requests from Members table, and thus have a breakout in `/members` page code to display non-members entities.
* Now that we have made that change, we will be able to account for our 2nd user case below where we are able to account for approval of new members.
* PS: New users (invited via Email) are already handled with the current UserCap feature(i.e they get queued for approval), and will not be dealt with as part of this change
###
## Use Cases
<table>
<tr>
<th>Use Cases</th>
<th>Issue</th>
<th>Status</th>
</tr>
<tr>
<td>
1. **Accounting for Role Changes of Existing Members:** changing the role of existing members (users who are already member of the group but with a different role) from non-billable to billable.
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/433172
</td>
<td>
:white_check_mark: Complete
</td>
</tr>
<tr>
<td>
2. **Accounting for New Users/New Members**: when we 'invite' new users to the group.
* **New members**: Invite "Existing Users" who are already existing users in the system but new to the group
</td>
<td>The one we're on</td>
<td>
:point_left: we are here
</td>
</tr>
</table>
## Work to do
- [x] Change the table structure to allow MemberApprovals to be independent of Members table https://gitlab.com/gitlab-org/gitlab/-/merge_requests/144882
- [ ] Queueing members added via the invitation API
<details>
<summary>Initial Issue Content</summary>
Current flow, vs expected flow
<table>
<tr>
<td>
1\. A POST Request goes to "api/v4/groups/\<group_id\>/invitations" [here](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/api/invitations.rb#L39), which returns with 201 created<br>2. The request triggers [InviteService](https://gitlab.com/gitlab-org/gitlab/blob/master/app/services/members/invite_service.rb#L5) which is extended from the [Members::CreateService](https://gitlab.com/gitlab-org/gitlab/blob/master/app/services/members/create_service.rb#L22), which then adds the user by inserting a record in the Members table. <br>↳ app/services/members/creator_service.rb:208:in \`commit_changes'
</td>
<td>
Change flow to stop User Role Updating<br>1. If user role \> Guest and FF enabled, queue the request in a table, and return a corresponding message from Invitations API.<br>2. FE changes to display "Invited or Asked to be promoted" users with their role change from X to Y, and corresponding BE changes (Should be same as Case1)
</td>
</tr>
<tr>
<td>
1\. Users Role is changed and it is reflected to the User
</td>
<td>
1\. Users Role remains the same. It should seem like nothing has happened to the Invited User
</td>
</tr>
<tr>
<td>
1\. Currently No action on Admin
</td>
<td>
1\. FE changes and corresponding BE changes to display list of "Pending promotion/Invitation" tab<br>2. BE changes to Approve Request which should<br>1. Trigger InviteService which is extended from the Members::CreateService, which then adds the user by inserting a record in the Members table.<br>2. Delete the request from the table.<br>3. Corresponding FE changes to integrate Approval Flow
</td>
</tr>
</table>
</details>16.11Suraj Tripathistripathi@gitlab.comSuraj Tripathistripathi@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/452276FE: add UI to the SM admin settings, to enable the promotion controls2024-03-29T00:01:11ZKos PalchykFE: add UI to the SM admin settings, to enable the promotion controls_This is a placeholder for the UI to enable Promotion Approval flows_
_Related to https://gitlab.com/gitlab-org/gitlab/-/issues/433166__This is a placeholder for the UI to enable Promotion Approval flows_
_Related to https://gitlab.com/gitlab-org/gitlab/-/issues/433166_https://gitlab.com/gitlab-org/gitlab/-/issues/443491Handle Custom Role scenarios for Role Promotions2024-03-29T00:01:05ZSuraj Tripathistripathi@gitlab.comHandle Custom Role scenarios for Role PromotionsDetails: https://gitlab.com/gitlab-org/gitlab/-/issues/433166#note_1742599408
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/143545Details: https://gitlab.com/gitlab-org/gitlab/-/issues/433166#note_1742599408
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/14354516.11https://gitlab.com/gitlab-org/gitlab/-/issues/446080[Test] spec/features/admin/users/admin_sees_user_spec.rb | Admin::Users::User...2024-03-28T23:27:26ZTEST_FAILURES_PROJECT_TOKEN[Test] spec/features/admin/users/admin_sees_user_spec.rb | Admin::Users::User GET /admin/users/:id remove users secondary email is expected not to have text secondary@example.com### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`spec/features/admin/users/admin_sees_user_spec.rb#L201`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/features/admin/users/admin_sees_user_...### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`spec/features/admin/users/admin_sees_user_spec.rb#L201`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/features/admin/users/admin_sees_user_spec.rb#L201) |
| Filename | `spec/features/admin/users/admin_sees_user_spec.rb` |
| Description | `Admin::Users::User GET /admin/users/:id remove users secondary email is expected not to have text "secondary@example.com"` |
| Test level | system |
| Hash | `231b7010e698f3e60c0e84a4b2ad3ce7f8fdd8dc7` |
| Reference duration | 6.42 seconds |
| Expected duration | < 50.13 seconds |https://gitlab.com/gitlab-org/gitlab/-/issues/297441Make credential inventory GA on gitlab.com2024-03-28T20:12:21ZMatt Gonzales (ex-GitLab)Make credential inventory GA on gitlab.com### Problem to solve
<!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." -->
We released the [credential inventory](https://...### Problem to solve
<!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." -->
We released the [credential inventory](https://docs.gitlab.com/ee/user/admin_area/credentials_inventory.html#credentials-inventory) in `12.6` and have released several related credential management features, such as [PAT expiration](https://docs.gitlab.com/ee/user/admin_area/settings/account_and_limit_settings.html#limiting-lifetime-of-personal-access-tokens) and [list and revoke PATs via API](https://docs.gitlab.com/ee/api/personal_access_tokens.html); however, these features are largely available only for self-managed customers leaving GitLab.com customers in a painful spot for credential management.
### Intended users
* [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager)
* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
### User experience goal
<!-- What is the single user experience workflow this problem addresses?
For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>"
https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ -->
### Proposal
<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
The credential inventory will need logic to support a GitLab.com implementation. We should:
* Remove the group-managed account restriction
* Ensure only Project Access Tokens and group-scoped tokens scoped to the group are populated in this inventory
### Further details
<!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. -->
This issue likely needs to be broken down into several smaller issues.
### Permissions and Security
* [x] Add expected impact to Owner (50) membersBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/452349Rate limit Users API endpoints2024-03-28T11:04:11ZChristina Lohrclohr@gitlab.comRate limit Users API endpointsThere are a couple of endpoints in the Users API that need to have a rate limit added. The endpoints and suggested limits are listed below:
Based on this comment https://gitlab.com/gitlab-org/gitlab/-/issues/421905#note_1832435121 we'll...There are a couple of endpoints in the Users API that need to have a rate limit added. The endpoints and suggested limits are listed below:
Based on this comment https://gitlab.com/gitlab-org/gitlab/-/issues/421905#note_1832435121 we'll be rate limiting based on user if authenticated and on IP if unauthenticated. We can have the same values for both limits.
| Endpoint | Requests per minute Limit |
|----------|---------------------------|
| GET /users/:id/followers | 100 |
| GET /users/:id/following | 100 |
| GET /users/:user_id/status | 240 |
| GET /users/:user_id/keys | 120 |
| GET /users/:id/keys/:key_id | 120 |
| GET /users/:id/gpg_keys | 120 |
| GET /users/:id/gpg_keys/:key_id | 120 |
See also https://gitlab.com/gitlab-org/gitlab/-/issues/421905#note_1832435121, https://gitlab.com/gitlab-org/gitlab/-/issues/421905#note_1806884841 and https://gitlab.com/gitlab-org/gitlab/-/issues/421905#note_1820899320.https://gitlab.com/gitlab-org/gitlab/-/issues/429450Refactor "User#unfollow into a service2024-03-28T08:57:56ZTed Trantedtran2019@gmail.comRefactor "User#unfollow into a service## Why are we doing this work
Same benefits as https://gitlab.com/gitlab-org/gitlab/-/issues/375061. Also, it makes sense to turn User#unfollow into a service after User#follow was turned into a service
Should be similar to the work do...## Why are we doing this work
Same benefits as https://gitlab.com/gitlab-org/gitlab/-/issues/375061. Also, it makes sense to turn User#unfollow into a service after User#follow was turned into a service
Should be similar to the work done here https://gitlab.com/gitlab-org/gitlab/-/merge_requests/135060
## Non-functional requirements
* [ ] Documentation:
* [ ] Feature flag:
* [ ] Performance:
* [ ] Testing:
## Implementation plan
1. Create `app/services/users/unfollow_service.rb`
2. Move the logic from `User#unfollow` into this service
3. Delete `User#unfollow`
4. Replace usages of `User#unfollow` with `Users::UnfollowService`16.11Ishmeet SinghIshmeet Singhhttps://gitlab.com/gitlab-org/gitlab/-/issues/452115[Test] spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb | Admin ...2024-03-26T23:40:57ZTEST_FAILURES_PROJECT_TOKEN[Test] spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb | Admin sees unconfirmed user when user has an unconfirmed email path_helper: -> (user) { admin_user_impersonation_tokens_path(user) } allows an admin to force confirmation of the use...### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb#L32`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/features/admin/users/admin...### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb#L32`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb#L32) |
| Filename | `spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb` |
| Description | `Admin sees unconfirmed user when user has an unconfirmed email path_helper: -> (user) { admin_user_impersonation_tokens_path(user) } allows an admin to force confirmation of the user's email` |
| Test level | system |
| Hash | `70d6304650c9f262352fa582da72f01c5a9fa76ef` |
| Reference duration | 126.65 seconds |
| Expected duration | < 50.13 seconds |https://gitlab.com/gitlab-org/gitlab/-/issues/452114[Test] spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb | Admin ...2024-03-26T23:40:55ZTEST_FAILURES_PROJECT_TOKEN[Test] spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb | Admin sees unconfirmed user when user has an unconfirmed email path_helper: -> (user) { admin_user_identities_path(user) } allows an admin to force confirmation of the user's email### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb#L32`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/features/admin/users/admin...### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb#L32`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb#L32) |
| Filename | `spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb` |
| Description | `Admin sees unconfirmed user when user has an unconfirmed email path_helper: -> (user) { admin_user_identities_path(user) } allows an admin to force confirmation of the user's email` |
| Test level | system |
| Hash | `37e6dc0e5b1d2e2bf8832c17747e1f4ebf4f3414d` |
| Reference duration | 126.4 seconds |
| Expected duration | < 50.13 seconds |https://gitlab.com/gitlab-org/gitlab/-/issues/452113[Test] spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb | Admin ...2024-03-26T23:40:54ZTEST_FAILURES_PROJECT_TOKEN[Test] spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb | Admin sees unconfirmed user when user has an unconfirmed email path_helper: -> (user) { keys_admin_user_path(user) } allows an admin to force confirmation of the user's email### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb#L32`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/features/admin/users/admin...### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb#L32`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb#L32) |
| Filename | `spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb` |
| Description | `Admin sees unconfirmed user when user has an unconfirmed email path_helper: -> (user) { keys_admin_user_path(user) } allows an admin to force confirmation of the user's email` |
| Test level | system |
| Hash | `58992c8c1aeaf4964e172f3ea94750d012bd900df` |
| Reference duration | 126.26 seconds |
| Expected duration | < 50.13 seconds |https://gitlab.com/gitlab-org/gitlab/-/issues/452112[Test] spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb | Admin ...2024-03-26T23:40:52ZTEST_FAILURES_PROJECT_TOKEN[Test] spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb | Admin sees unconfirmed user when user has an unconfirmed email path_helper: -> (user) { projects_admin_user_path(user) } allows an admin to force confirmation of the user's email### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb#L32`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/features/admin/users/admin...### Test metadata (don't modify)
| Field | Value |
| ------ | ------ |
| File URL | [`spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb#L32`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb#L32) |
| Filename | `spec/features/admin/users/admin_sees_unconfirmed_user_spec.rb` |
| Description | `Admin sees unconfirmed user when user has an unconfirmed email path_helper: -> (user) { projects_admin_user_path(user) } allows an admin to force confirmation of the user's email` |
| Test level | system |
| Hash | `d2a62264733c2aa5975b149c6870af3aa438b8d45` |
| Reference duration | 126.34 seconds |
| Expected duration | < 50.13 seconds |