-
Notifications
You must be signed in to change notification settings - Fork 4.4k
UI: Surfacing plugin version for Secret Engines #30712
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
CI Results: |
Build Results: |
* TODO: maybe add param on object that mentions secret or auth or enterprise | ||
*/ | ||
|
||
const ALL_ENGINES = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When Angel and I paired on this, we decided on removing the auth-display-names helper (that claire created when doing auth work) in favor of have just one centralized helper for getting display names (ie. this file)
However tests were being wonky with swapping the auth helper with this new one so i undid my changes and kept them separate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A helper that returns an array isn't really a good use case for creating a helper. I think it'd make much more sense to make thisconst
a util and the helper could be a find function (engine-display-data
) that takes a type
as an argument. We've historically used helpers for lots of things that should technically be utils.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to update use cases of auth-display-names
if you do the above!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Monkeychip - let me know if you disagree! I don't want to give conflicting suggestions 😄
@text={{if | ||
backend.isSupportedBackend | ||
(concat | ||
(get (find-by "type" backend.type (engines-display-name)) "displayName") | ||
(if (eq backend.version 2) " version 2" (if (eq backend.version 1) " version 1" "")) | ||
) | ||
"This secret engine type is not currently supported by the UI." | ||
}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this logic be moved into a template helper in the component file? It might make it a little easier to parse and reduce the chance for regressions if/when updates are made in the future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update per suggestion below - I think it'd make sense to update engine-display-names
to be engine-display-data
that was a find function which would clean this logic up as well
@@ -36,6 +36,7 @@ export default class SecretsEngineMountConfig extends Component<Args> { | |||
{ label: 'Secret Engine Type', value: model.engineType }, | |||
{ label: 'Path', value: model.path }, | |||
{ label: 'Accessor', value: model.accessor }, | |||
{ label: 'Running Plugin Version', value: model.runningPluginVersion }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to our capitalization policy (confirmed in the Figma file "Capitalization"), we use Title Case for headings and titles, but Sentence case for attributes and labels. I initially used Running Plugin Version
to match the existing labels on this form, but technically, it should be sentence-cased. If you feel so inclined, could you update the rest of the Labels on this model to match this pattern? Note: because of openAPI the only time we don't use sentence-case is with Default Lease TTL or Max Lease TTL.
{ label: 'Running Plugin Version', value: model.runningPluginVersion }, | |
{ label: 'Running plugin version', value: model.runningPluginVersion }, |
.dom('.hds-tooltip-container') | ||
.hasText( | ||
'This secret engine type is not currently supported by the UI.', | ||
'shows tooltip for unsupported engine' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'shows tooltip for unsupported engine' | |
'shows tooltip text for unsupported engine' |
await selectChoose(GENERAL.searchSelect.trigger('filter-by-engine-type'), 'kv'); | ||
|
||
await triggerEvent('.hds-tooltip-button', 'mouseenter'); | ||
assert.dom('.hds-tooltip-container').hasText('KV version 2', 'shows tooltip for kv version 2'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we add another section to this test to cover a non-versioned supported engine—like ssh—that won’t include a version in the text? It’s part of the logic, so I want to make sure that case is explicitly covered.
return ALL_ENGINES.slice(); | ||
} | ||
|
||
export default buildHelper(methods); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using buildHelper
is outdated syntax and no longer necessary, the function can just be exported https://guides.emberjs.com/release/components/helper-functions/#toc_global-helper-functions
{ | ||
displayName: 'LDAP', | ||
type: 'ldap', | ||
engineRoute: 'ldap.overview', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe engineRoute
keys should probably deleted as it's unrelated to the function of this const
?
Description
What does this PR do?
TODO only if you're a HashiCorp employee
backport/
label that matches the desired release branch. Note that in the CE repo, the latest release branch will look likebackport/x.x.x
, but older release branches will bebackport/ent/x.x.x+ent
.of a public function, even if that change is in a CE file, double check that
applying the patch for this PR to the ENT repo and running tests doesn't
break any tests. Sometimes ENT only tests rely on public functions in CE
files.
in the PR description, commit message, or branch name.
description. Also, make sure the changelog is in this PR, not in your ENT PR.