UI: Update behavior when deleting nested secret from list #26845
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
hashicorp-contributed-pr
|
Build Results: |
|
CI Results: |
Monkeychip
approved these changes
May 6, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TL;DR
This PR removes the
withNavToNearestAncestormixin and updates the UX behavior in nested secret lists that are not KV version 2 (eg. KV version 1, cubbyhole).Previous Behavior
Say there's a secret engine with a secret at a deeply nested path (eg.
kv1/one/two/three/four). A user viewing the list atkv1/one/two/three/can seefourin the list, and can delete from the list view. In the previous behavior, the UI would then try to attempt to navigate to each segment ancestor above until it got to a successful response, or got back to the list-root.New Behavior
After updating everything to use
router.transitionTo(required for upgrading to Ember 5), we could no longer catch the transition error from where it was called in the mixin. Instead, we are matching the updated pattern in KV version 2, and showing an empty state message while allowing the user to navigate back to the root themselves OR adjust the filter bar to move back up the tree. This behavior is more deterministic, and simplifies the error logic slightly.