@fcatteau @jrandazzo can we get alignment on what is required from a GUI/UX perspective? From what I'm reading --

For dedicated customers we need UI to support:

• A parent interface (group level?) where this workflow would live - do I understand correctly that an organization would have one instance of open bao that they need recovery keys for? Or is it that there can be multiple instances that they would need to manage recovery keys for?
  • Are we thinking at all about how these workflows could be impacted by a future state where GitLab supports enabling features (including SM) at the organization level?
• Generation/rotation of Open Bao recovery key - something to trigger the API call which saves the key to the database
  • When does rotation happen? Why/how often?
• ?? Display the recovery key - I'm confused on this one. Do we need to display the recovery key or just that a key exists? (Is it absolutely necessary to display the key given security considerations?)
• A way to verify the key works - Are users copy pasting keys to their clipboard for these workflows? Can any of this be done agentically, with machine accounts, or through automated processes?

@mgandres I'd say follow CI vars for now.

@mgandres Yeah, this work isn't ready for dev. What I've added so far are concepts so we can use them to drive discussion. If we find that we need to support a view secret state we can investigate how we might support that (could just be read-only fields in the side panel).

We've been hearing different things in beta research so far, but for those who think of secrets as a replacement to ci/cd variables, making the workflows match their existing mental models and would result in better usability.

In terms of whether we need a read-only view, IMO this becomes more important if we gave the ability to view or copy the secret value, which we aren't currently supporting. We have had someone mention wanting "human-retrievable" secrets, so if it turns out we need to support that the workflow could look different.

@ahuss7 yes, that makes sense

@nshechtmann here's the issue where I'm documenting design work for SLSA L3 attestations

@ahuss7 I was hoping there was guidance in pajamas docs on when to use the labelDescription (above field) or hint / description(below field), but there isn't specific guidance. I think what you have in the video ("Enter group path (e.g., my-group, or my-group/subgroup)" shown above the field) will work for this, and then we won't have to worry about what to display below the field (showing/hiding things depending on validation).

Approving this as it is an improvement over the current experience. For future reference (if technically feasible) we could improve usability if we display an error in the form within the modal, as we aren't resetting the scroll position of the page so this could still result in someone not seeing the error alert at the top of the table.

What does this MR do and why?

This MR makes two improvements to the error handling UX for the secrets manager settings permission modal:

1. Error alerts now appear right above the permissions table instead of at the top of the page which was out of sight. This makes the error easier to see and closer to the source.
2. The permission modal for adding group permissions now performs validation on the group path and shows the validation error below the input when theres an issue, saving time for users who may end up trying an invalid group path format

References

Designs and issue - #585263

Screenshots or screen recordings

Before	After
no validation, would allow submit and fail on server side

How to set up and validate locally

1. Follow the instructions for setting up OpenBao on your gdk.
2. Make sure you have a Premium+ license. Enable the secrets_manager feature flag
3. Enable the secrets manager for your project.
4. Simulate an error involving permissions, an easy example is modify ee/app/graphql/resolvers/secrets_management/project_secrets_permissions_resolver.rb and add a raise_resource_not_available_error! as the first line of the resolve method
5. Should observe the error alert right above the permissions table

To test the input validation:

1. Perform steps 1-3 of the above
2. Click the Add dropdown button at the top right of the permissions table, and click Groups
3. Type an invalid group path, an easy case is one with spaces in it, or put a double '/' somewhere, the added validation method describes allowed cases

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 #585263

@marcel.amirault I am also generally against using placeholders especially when the components have a hint available to display below the field.

Sounds good to me. Is there specific feedback you're seeking for this one?

It sounds like the inconsistency is that using the search with * results in different behavior/results, for environments it returns no results and only serves the purpose of creating a wildcard, for branches it returns all available branches. Is that accurate? And to complicate this, the Environments field is a component that is used in another heavily used part of the product, so if we want to change that behavior we would have to create a new component as to not impact CI/CD variables.

I'm also just realizing the the "Create wildcard: *" at the bottom of the dropdown is a selectable option. IMO it's not visually distinct enough to read as an option. (Could just be my opinion- none of this is backed by any data)

For now, putting all this aside, I don't feel like the inconsistency shown here is going to have a big impact on usability. Users will have the option to create wildcards for both environments and branches with the work that has been done so far.

Still getting designs together for this but to match the behavior in CI/CD variables, we would remove the view secret (details) page. Relevant fields and copy values would be displayed in the secret table, and the actions would be to edit or delete a secret.

@mgandres @mmishaev there seems to be a duplicate issue - designs here #590707 (closed). We want to bring the wildcard functionality/option to branches.

Updated with prototype and screen recordings to show the entire workflow, including success toast messages and form refresh.

if so, updated to remove the "Type" field until we can validate if that is a customer requirement