[#432] Implement credentials deletion and generation

[shadcn]

Fixes #432

This PR implements credential generation, status update (revoke/approve) and deletion for key rotation.

[Update: Deleted outdated screenshots]

[mxr576]

What about regenerating a customer secret on an existing credential?

[cnovak]

Approve App

I am not sure, but I believe you may be adding "approve" into this PR which are used for API Providers to approve credentials from developers. This should not be done since the API provider may set up manual approvals on an API Product, and with this change the developer could self approve the app.

Check out what the internal portal is doing. They do not let users delete or approve credentials (they use "key" instead of "credentials" for this entity):

Generate Credentials

It seems odd to have a tab to create a new credential versus an add button.

[shadcn]

@cnovak OK so we remove approve and keep revoke or do we make revoke the delete action?

[cnovak]

What about regenerating a customer secret on an existing credential?

I created #459 to look into this @mxr576

[cnovak]

@arshad here are details for you:

Add Credentials

• The "Add Credentials" should be a button on the credentials listing page.
• Ideally, a modal would come up to allow user to add details.
• The add credentials form should not allow user to change the API Products for the app by default. However, add an admin setting to allow API products to be changed per credential.

Approve

• The approve functionality should be removed.

Revoke

When a credential is revoked, it should follow the integrated portal concept of hiding the revoked credentials when you open the page. There should be a way to see revoked keys:

• Currently the system will show a warning for apps that have revoked credentials. This should not be considered a warning state since revoking credentials is part of the maintenance of an app.

Delete

• The delete should be either removed or made as an optional admin setting to allow deletes on credentials.
• On an install, the delete functionality should default to not being shown.

[shadcn]

@cnovak Thanks. I'll make the changes.

Question about the following:

The add credentials form should not allow user to change the API Products for the app by default. However, add an admin setting to allow API products to be changed per credential.

OK so when a user adds new credentials, we use the API products from the app? What if we have two credentials with different products on the same app?

On the portal, API products are listed separately from API keys (which makes it look like API products are tied to the app and not keys).

But on both the Drupal portal and Edge UI, each key lists its own products.

Integrated Portal

Drupal

Edge

[arlina-espinoza]

@arshad I would use the API products of the first cred as the default, but let me circle back with the Apigee team to check.

[arlina-espinoza]

@arshad We should take the API products from the most recently created credential that is active (not revoked or expired), and have those as the default products for new creds. There is a getIssuedAt() method on the credential entity that would help with that.

[googlebot]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[minnur]

@googlebot I consent

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[minnur]

@arshad @arlina-espinoza I also made related fix in the Kickstarter apigee/apigee-devportal-kickstart-drupal#408

[googlebot]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[arlina-espinoza]

@googlebot I consent.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[arlina-espinoza]

Thanks @arshad . I've manually tested this PR and it all looks really good 💯
I only pushed an additional change after the latest conversation with the Apigee team, about the default permissions upon installing: developers should be able to add/revoke keys and edit api products in their own apps, and the same for team admins for their team apps. So the change was to add "edit_api_products developer_app" to the hook install/update.

[arlina-espinoza]

@arshad I've fixed the new functional tests so that they are able to run both with mocks and as integration tests. As part of it, I removed the static app name and consumer key, so that they are able to run (possible concurrently) against the remote API.