@fcatteau Yup I think that makes sense, thanks!

Verified on staging.

We can close this issue as well. cc @fcatteau

Verified on staging.

Table	Details

Closing this issue now. cc @fcatteau

@iamricecake Hm, so currently we show the list of secrets that needs rotation as a collapsible inside an alert message. I think if we paginated the list, we'd need a different UI for it. Might be a question for @jtouchstone1. cc @ahuss7

In the long run, we probably should paginate it though. I think the current UI for the secrets needing rotations list doesn't really lend itself for long lists. 🤔

@ahuss7 Generally we'd still have someone else do the maintainer review even if a maintainer did the initial review, unless the MR is small and trivial enough to merge straight away.

If the merge request is small and straightforward to review, you can skip the reviewer step and directly ask a maintainer.

In this case, I think it's good to have another maintainer to review the code 😄

@ahuss7 @ekigbo We recently updated the validation behavior and removed the disabled submit button for the secrets manager form, but looks like forgot to do the same for permissions. Thanks, great catch 🎣

Thanks @ahuss7, great work! 🎉

For future implementations, I think we can split MRs like this into multiple smaller ones to make them easier for the reviewer to go through them, especially if they don't have context or are not familiar with this part of the codebase yet. For example, we can break this down to:

• 1 MR for updating the fetching of the secrets manager status
• 1 for setting the rotation when creating/updating a secret
• 1 for fetching the group secret rotation for the table and the details page.

Though I completely understand we're trying to minimize merge conflicts and get this in for this milestone. 🙇

@shampton 👋 Are you free to give this MR a maintainer review?

What does this MR do and why?

This MR adds the secret rotation reminder UI for group secrets, including the status indicators showing when a secret is overdue or approaching rotation date, and the banner on the secrets page listing secrets that require attention. It extends the existing UI built for project secrets to now apply to group secrets as well. Much of the UI was already context agnostic so things like the secrets rotation alert banner did not need to be updated.

Main changes include:

• Created a query for groupSecretsNeedingRotation
• Updated the create/update queries for group secrets to pass on the rotationIntervalDays field
• Updated the group secrets list and detail queries to fetch rotationInfo
• Updated the relevant test files to extend the existing rotation related tests to the group context

References

The frontend MR that introduces the ability to fetch group secret details: !222583

The backend MR that introduces the various resolvers needed for group secret rotation reminders: !225935

The MR that added the UI elements for project secret rotation reminders: !207183

Screenshots or screen recordings

The secret list page showing the warning banner and the status indicator on a specific secret:

Expanding the warning banner details shows the specific secrets with clickable link to its detail page:

The secret detail page showing the warning banner and the rotation field is rendered:

How to set up and validate locally

1. Upload a Premium license (or above).
2. Set up openbao and enable the secrets manager on your gdk.
3. Enable the group_secrets_manager feature flag.
4. Go to your group settings (Settings > General) and expand Permissions and group features. Enable the secrets manager for your group with the settings toggle.
5. Go to /path-to-group-or-project/secrets/new to create a secret, set the rotation value to the minimum 7 days
6. In order to get the rotation banner and alert indicators to appear you will have to either move your system time into the future or what i found easier was:

• Run gdk rails console, then run the following:

rotation_info = SecretsManagement::GroupSecretRotationInfo.find_by(secret_name: 'your-secret-name')
rotation_info.update(next_reminder_at: 3.days.from_now)

7. Verify that the alert banner and status indicators show up on the secrets list and detail pages as seen in the screen shots above

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

@fcatteau Alright, works for me! I'll close this issue then 👌

Thanks @fcatteau. I just tested on staging but it looks like the changes aren't deployed there yet. I'll try again tomorrow morning and verify the changes. We can probably close both issues afterwards 👍

Thanks for taking over this earlier @fcatteau and @dpisek! I'll create a follow-up MR tomorrow for the suggested changes.

@dpisek Great catch, thank you! I'll update this in my next MR.

@dpisek Thanks, I actually thought about refactoring this and creating a wrapper template as well. But we've been getting more user feedback from the Closed Beta as we get the (project) secrets manager tested, and there's a high possibility that we'll overhaul our UI in the future. So I postponed doing any refactoring for now until we've gathered more insight and decide on the final design changes.

@jrandazzo @fcatteau We're not showing the createdAt field yet on the frontend. We'll implement it next, so let's not close this issue yet until that's implemented.

@thomasrandolph Are you free to do the maintainer review for this MR?

What does this MR do and why?

Previously the UI for the secrets manager was not checking nor handling if OpenBao was having issues, meaning a user would be able to proceed with actions like trying to create a secret when failure was guaranteed. Likewise on the project/group settings page, a user would try to enable or disable the secrets manager by interacting with the toggle, but with an unhealthy OpenBao instance, it would cause the toggle to enter an indefinite loading state.

The solution proposed is to use a OpenBao health query to figure out if the instance is healthy, and if it is not healthy, then make the UI reflect that in the following ways:

On the secrets manager page,

• show an error alert informing the user of the issue, and hide the action button to create a new secret on the empty state
• if a user enters the url to the new secret form directly, redirect to the main secrets page where they will encounter the above

On the project/group settings page,

• disable the secrets manager toggle
• hide the secrets permission table (it would not load values anyway, and interacting with it to try and add a new perm would fail)
• show an error alert indicating there is an issue

References

Issue/design: #582363

There are 2 other MRs currently working around this area that may conflict !226431 and !222583

Screenshots or screen recordings

SECRETS MANAGER PAGE:

Before: showed generalized error message, action button to create secret is still present

After: more specific error messaging, action button hidden

SETTINGS PAGE:

Before: all actions available even though it would fail

if a user interacted with the toggle, it would get stuck in this infinite loading state

After: permissions table hidden, error message displayed, toggle disabled

How to set up and validate locally

1. Upload a Premium license (or above).
2. Set up openbao and enable the secrets manager on your gdk.
3. Enable the secrets_manager and group_secrets_manager feature flags.
4. Go to your project/group settings (Settings > General) and expand Permissions and group features (for groups) or Visibility, project features, permissions for projects. Enable the secrets manager for your project/group with the settings toggle.
5. In your terminal, do gdk stop openbao to simulate a downed instance
6. Check the settings area from step 4 to confirm the error state is correct
7. Go to Secure > Secrets Manager and confirm the error state there

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

          'SecretsManager|Rails failed to connect with OpenBao. Secrets are unavailable at this time. Please try again later.',

Should this use a period? cc @marcel.amirault