-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
ui: add capabilities to pki key model #18412
Conversation
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.
✨ gorgeous! A couple minor comments
<ToolbarLink @route="keys.key.edit" @model={{@key.model.name}}> | ||
Edit key | ||
</ToolbarLink> | ||
{{#if @canDelete}} |
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.
Super excited about this pattern 🤩
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.
Same! great idea 🥇
<nav class="menu"> | ||
<ul class="menu-list"> | ||
<li> | ||
<LinkTo @route="keys.key.details" @model={{pkiKey.keyId}} @disabled={{eq pkiKey.canRead false}}> |
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.
Since the boolean is calculated on the model you could use not
instead of eq ... false
. Also do we want to used a passed arg here?
<LinkTo @route="keys.key.details" @model={{pkiKey.keyId}} @disabled={{eq pkiKey.canRead false}}> | |
<LinkTo @route="keys.key.details" @model={{pkiKey.keyId}} @disabled={{not @canRead}}> |
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.
yeah - I was wondering about doing something similar to what I did for @canGenerateKey
so like the following. If we are okay with reading those capabilities just based on the first model?
@canReadKey={{this.model.keyModels.firstObject.canReadKey}}
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 thought we didn't want to use not
in case the capability is undefined
for some reason?
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.
oohhh ^ disregard, forgot its explicitly checking for false
in the model getter now
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.
🎉
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This reverts commit 6aae14b.
* add capabilities to pki key model * move key list from route into component * rename test file * rename test file * add tests * pass capabilities directly to key list componente * add test for key list component * rename test files * remove href assertion
* add capabilities to pki key model * move key list from route into component * rename test file * rename test file * add tests * pass capabilities directly to key list componente * add test for key list component * rename test files * remove href assertion
Adds capabilities to the key model and wraps actions in the key route