Update secret routes to use `id` instead of `key`
What does this MR do and why?
Pre-work for #424460 (closed).
In the index page for secrets, where we show the table, we use secret.key
as the identifier when redirecting to other routes e.g. /:key/edit
and /:key/details
.
However, the secret key
is editable and not necessarily unique, so it makes more sense to use id
for the routes. See !152005 (comment 1897122941).
There's ongoing discussions on whether or not to replace secret.name
with secret.key
, so this MR will not change these fields for now. Similarly, updating the secrets details/edit page to show the secret key instead of the id as the page title will be implemented in another MR for #424460 (closed).
This MR only concerns the routes and updating the breadcrumb to fetch the secret key for the given id. For now, we are using client resolvers since the API is not yet available.
Note: This breaks the redirection from the create form to the secret details page. This will be fixed in a separate MR (!154875 (b3c40ffb)) since this also fixes the GraphQL response from the client resolver.
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
The links are shown on the lower right of the screen. Also note that the breadcrumbs still show the secret key, not the ID.
How to set up and validate locally
- Enable the
ci_tanukey_ui
feature flag for your project. - Visit
<path-to-project>/-/secrets
. - Clicking on a secret should lead to the
<secret_id>/details
route (page is currently blank as it's still a WIP). - From here, clicking on the edit button (upper right corner) should lead to
<secret_id>/edit
(form is also a WIP). You can also visit the audit log tab, which leads to:id/auditlog
- Verify that the routes are updated to use
id
instead ofkey
. Also verify that the breadcrumbs still show the secret key.