Draft: Add UI to trust/untrust a user
What does this MR do and why?
UI-side follow-up to !123430 (merged) and part of https://gitlab.com/gitlab-org/gl-security/security-engineering/security-automation/spam/spamcheck/-/issues/17
Adds UI elements to allow admins to trust/untrust users for purposes of creating issues, notes, snippets, etc. that are detected to be possible spam.
We use UserCustomAttributes to indicate when a user is trusted to create possible spam. These UI changes expose that capability to admin users in the user admin panel and the abuse report dashboard.
Screenshots or screen recordings
| Before | After |
|---|---|
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
- Log into your GDK as an admin
- Visit
/admin/usersand ensure there's aTrustedtab - Visit
/admin/spam_logs - Ensure there's a
Trust userbutton on each row - Click the
Trust userbutton on one spam log and note the user - Revisit
/admin/users?filter=trusted - Ensure the newly trusted user is there and that there's an
Untrust useraction available in the dropdown menu. - Click the
Untrust userbutton and confirm the action - Ensure that the user no longer shows up in the
Trustedtab - Visit
/admin/abuse_reports - Select the first report
- Click the
Actionsbutton - Select
Trust user - Verify that the user now appears in the
Trustedtab in/admin/users - Repeat steps 10-14 but also check the
Close reportcheckbox and verify the Abuse report is closed in/admin/abuse_reports
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Ethan Urie






