-
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
PKI Keys List View #17239
PKI Keys List View #17239
Conversation
@@ -13,7 +13,7 @@ const validations = { | |||
}; | |||
|
|||
@withModelValidations(validations) | |||
export default class PkiIssuersEngineModel extends Model { | |||
export default class PkiIssuerEngineModel extends Model { |
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.
trying to make things consistent with the model class names. There is some inconsistency with PKI and in the API with plural vs. non plural. Doing my best to be consistent.
return 'chevron-right'; // this is the default if no type is passed in. | ||
} else { | ||
return this.args.type; | ||
} | ||
} |
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.
My thoughts here: if we want to make this logic better. A separate PR to revamp this param is needed. Which will impact everywhere (a lot of places) we use this as well as tests (I suspect). I can make a separate ticket to tackle this as a nice-to-do.
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.
Ticket created.
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.
Some cleanup comments/questions!
|
||
async query(store, type, query) { | ||
const { backend, id } = query; | ||
let response = await this.ajax(this.urlForQuery(backend, id), 'GET', this.optionsForQuery(id)); |
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 think we can just return here and remove the async...await
?
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.
My understanding is that it's wrapping the ajax request in a promise—a good thing. It's essentially turning a sync call into an async call. I think it's a newer pattern for us. It's used in the named-path.js adapter query method and in the keymgmt/key adapter query method. Maybe a discussion for the team? I searched for some documentation on this, but couldn't find anything specific to our situation.
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.
Ahh okay - I had just peeked at some older query
methods and from what I could see we only make it async
if we need to manipulate or filter the response in some way. And that the error/promise handling happened in the route, in the model hook here for example - but I could definitely be missing something!
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'll bring this up in our next standup. As I'm curious because the pattern isn't totally clear. Thanks for bringing it up.
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.
Good idea!
* @param {boolean} disabled - pass true to disable link | ||
* @param {string} disabledTooltip - tooltip to display on hover when disabled | ||
*/ | ||
|
||
export default class ToolbarLinkComponent extends Component { | ||
get glyph() { | ||
return this.args.type == 'add' ? 'plus' : 'chevron-right'; | ||
// not ideal logic, but updating old system to allow for other kinds of icons |
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 agree on separate PR as a nice cleanup to address why we are just changing the word 'add' to 'plus' 😅
But in the interim the following feels easier to read to me
get glyph() {
const { type } = this.args;
if (!type) return 'chevron-right';
return type === 'add' ? 'plus' : type;
}
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.
Thank you for the cleanup. You rock at the tight logic statements.
/> | ||
{{outlet}} |
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 question here as the Issuer List PR
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.
It's a great point. Will revisit after we get all the routes headers generated and the pattern becomes a little clearer.
import Model, { attr } from '@ember-data/model'; | ||
|
||
export default class PkiKeyEngineModel extends Model { | ||
@attr('string', { readOnly: true }) backend; |
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 may be reading the wrong docs - but should there also be a type
and key_bits
attribute? API Docs
(Disregard if this model is still WIP!)
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.
You're not wrong, but yep, model is still a WIP. I only added the read and list params here. Something I've been doing for these list views. I should have left a comment about it.
</span> | ||
<div class="is-flex-row has-left-margin-l has-top-margin-xs"> | ||
{{#if model.isDefault}} | ||
<span class="tag has-text-grey-dark">default issuer</span> |
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.
should this read default key
?
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.
Good catch. I believe so, I'll also confirm with design. She actually didn't have this param on the designs, she had keyName, which is not available to us on the LIST endpoint.
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'll go ahead and remove this until I get the response from the backend and design. It could be the default issuer because I don't know of a parma where is_default relates to a key. So maybe it's a key associated with the default issuer. Either way, it should be removed until clarified.
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.
Gotcha - I had interpreted this bit from the docs as the default key name was default
key_name (string: "") - When a new key is created with this request, optionally specifies the name for this. The global ref
default
may not be used as a name.
{{model.id}} | ||
</span> | ||
<div class="is-flex-row has-left-margin-l has-top-margin-xs"> | ||
{{#if model.isDefault}} |
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.
Curious, where does this attribute come from? I noticed it on the model, but not in the docs. I may be missing context, but could we instead check for if (eq model.keyName "default)
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.
It comes from the LIST network request. So similar to how you had to clients serializer it gets added to the model from what is returned on the LIST endpoint. In this view we only have the model data built out from what is returned on the LIST endpoint. It's not the full model for the key, so keyName isn't available to us. When we go to the edit/read/update views we'll then have the model fully built out for the key.
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.
As an aside: the payload returned is slightly different than the docs. I have a question out about that. E.g. it shows the param is_default when the payload on the docs does not show that.
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.
Thank you for the screenshot! Super helpful. This makes sense now
This is the PKI Keys List View.
This is a new endpoint so the adapter does not extend, similar to the Issuers adapter.
keys_list.mov
Notes: