Skip to content

Resolve "Being able to change email in Service Account UI and REST-API"

Fernando Cardenasrequested to merge
537976-edit-service-account into master

What does this MR do and why?

Adds frontend support for allowing users to Create/Edit Service accounts with custom e-mail addresses

Note: Behind a feature flag

editServiceAccountEmail

Expected Behavior

  • By default if the email field is blank, the server will generate a random one
  • We hide server generated emails in the table
  • We show custom defined email addresses in the table
  • ~Backend work is incomplete, needs #550983 (closed) to enable feature flag

Testing

  • You can create service accounts with custom email addresses for testing, you cannot edit the email address on an existing service account until #550983 (closed) is complete.

UX Considerations

  • The user and project members page, allows for a hover over that shows the e-mail address in a hover over. The problem is that it also shows the hover over with the user avatar. The table does not contain user avatar URLs in the service account list API endpoint, so we can't show them right now. The easier thing was just to show the email address in the table because a hover over with only email text looked odd.

References

Screenshots or screen recordings

Before After

Screenshot 2025-06-29 at 2.19.30 PM.png

Screenshot 2025-06-29 at 2.19.36 PM.png

Screenshot 2025-06-29 at 2.18.33 PM.png

Screenshot 2025-06-29 at 2.18.41 PM.png

How to set up and validate locally

  • Turn on feature flag with Feature.enable(:editServiceAccountEmail)

  • Log in as admin/root into your local gitla instance

  • Navigate to https://gdk.test:3000/admin/application_settings/service_accounts

  • Attempt to create a service account by clicking "Add Service Account" with a custom email address

  • Click the ... button on the newly created service account and click "edit"

  • Edit the service account by changing the email address to a new one

  • Confirm the service account is edited/updated

  • Repeat the steps at the top-level group by navigating to a group in your workspace.

  • For example: https://gdk.test:3000/flightjs

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 #537976 (closed)

Edited by Fernando Cardenas

Merge request reports