Skip to content
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

Merged
merged 4 commits into from
Sep 21, 2022
Merged

PKI Keys List View #17239

merged 4 commits into from
Sep 21, 2022

Conversation

Monkeychip
Copy link
Contributor

@Monkeychip Monkeychip commented Sep 20, 2022

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:

  • waiting for some design feedback on the Empty State. Shouldn't block this PR.
  • Will merge the Certificates List View first, and then merge in main into this branch, just in case I've done any duplication clean up work in this PR.

@@ -13,7 +13,7 @@ const validations = {
};

@withModelValidations(validations)
export default class PkiIssuersEngineModel extends Model {
export default class PkiIssuerEngineModel extends Model {
Copy link
Contributor Author

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;
}
}
Copy link
Contributor Author

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ticket created.

Copy link
Contributor

@hellobontempo hellobontempo left a 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));
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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!

Copy link
Contributor Author

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.

Copy link
Contributor

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
Copy link
Contributor

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;
}

Copy link
Contributor Author

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}}
Copy link
Contributor

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

Copy link
Contributor Author

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;
Copy link
Contributor

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!)

Copy link
Contributor Author

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>
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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}}
Copy link
Contributor

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)

Copy link
Contributor Author

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.

Here is the LIST response.
image

Copy link
Contributor Author

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.

Copy link
Contributor

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

@Monkeychip Monkeychip merged commit 613498c into main Sep 21, 2022
@Monkeychip Monkeychip deleted the ui/VAULT-6518/pki-keys-list-view branch September 21, 2022 14:41
jayant07-yb pushed a commit to jayant07-yb/hashicorp-vault-integrations that referenced this pull request Mar 15, 2023
* setup

* cleanup

* cleanup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants