CEXT-6151: Add ACL admin UI schema and helper to check permissions#522
CEXT-6151: Add ACL admin UI schema and helper to check permissions#522oshmyheliuk wants to merge 10 commits into
Conversation
🦋 Changeset detectedLatest commit: 9ec1234 The changes in this PR will be included in the next version bump. This PR includes changesets to release 11 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| // → "Magento_CommerceBackendUix::adminuisdk_app_acme_promotions" | ||
|
|
||
| // Check access in a runtime action: | ||
| const client = getAdminUiPermissionClient({ |
There was a problem hiding this comment.
would it be possible to create a function in aio-commerce-lib-app that returns a permission client which auto resolves the app id from the one set in the commerce config so we don't need to pass this value on each function call.
Something like
const app = getAppPermissionClient({httpClient}); // resolves appId from app.commerce.config
There was a problem hiding this comment.
resolves appId From app.commerce.config
That's something we may need to be cautious with. Runtime code (that runs in a runtime action) that depends on that file can not easily read the configuration unless it's bundled with the action, which requires extra setup in ext.config.yaml via include or via some import trick (messy bundle/build stuff).
It's the same problem we have (for now) with lib-config: we need to receive the schema in initialize. There are ways to make this work, but they are not trivial.
| * @returns The full Commerce ACL resource id for the menu leaf node (e.g. | ||
| * `"Magento_CommerceBackendUix::adminuisdk_app_approval_dashboard_app_menu_approval_dashboard"`). | ||
| */ | ||
| export function getMenuAclResourceId( |
There was a problem hiding this comment.
Should be documented in usage.md?
There was a problem hiding this comment.
This documentation should be completely agnostic of app.commerce.config, it doesn't know about it.
|
|
||
| const permissionClient = getAdminUiPermissionClient({ | ||
| httpClient, // AdobeCommerceHttpClient — reuse the one from createAdminUiApiClient | ||
| appId: "acme-promotions", // metadata.id from your app config; enables no-argument calls |
There was a problem hiding this comment.
What's the appId used for? What happens if I am not an App Management user? If this is intended to be used with App Management shouldn't it be in lib-app?
There was a problem hiding this comment.
appId is used to generate the ACL resource ID for future permission checks in the permission client.
I think it should be a part of the admin-ui library. The comment in usage.md was confusing, so I updated it.
| * This is a cross-repo contract shared with the Commerce module. Both sides must produce | ||
| * the exact same output for the same input. Any change here must be coordinated with the | ||
| * Commerce module's ACL id generator. |
There was a problem hiding this comment.
This will end up in public docs. Isn't this kind of an internal comment?
There was a problem hiding this comment.
Yeah, it's more like an internal comment. We need to maintain consistent logic between Commerce and aio-commerce-sdk to generate the same ACL resources.
I updated comments https://github.com/adobe/aio-commerce-sdk/pull/522/commits
| /** Options used to create an Admin UI SDK permission client. */ | ||
| export interface AdminUiPermissionClientOptions { | ||
| /** The application's `metadata.id` value. When provided, `check()` and `require()` can be called with no resource argument. */ | ||
| appId?: string; |
There was a problem hiding this comment.
Now that I see how appId works, I would challenge the fact that it is tightly coupled to a concept outside this library (app IDs). It's a useful convenience, but I am not sure it's the right layer to implement it.
There was a problem hiding this comment.
The appID is optional; the client can check permissions directly by providing the full ACL Resource ID.
But this client can check only resources created by the Admin UI commerce module. All ACL resources are created based on the installed apps, so the client is tightly coupled to the Admin UI and the installed applications' logic.
It's not like you can use this client to check any ACL Resource in Commerce; for resources not created by the Admin UI module, the API endpoint would always return false.
| * Throws `AdminUiPermissionDeniedError` if denied. | ||
| * Throws `AdminUiPermissionError` on 401, network, and parse errors. | ||
| * When called with no argument, defaults to the ACL resource id derived from `appId`. | ||
| * Throws `AdminUiPermissionError` immediately when neither `resource` nor a valid `appId` is available. |
There was a problem hiding this comment.
These lines should use proper JSDoc so that the autogenerated documentation picks those correctly. @throws with proper @link
| }); | ||
| } | ||
|
|
||
| /** Creates a client for checking Admin UI SDK ACL resources. */ |
There was a problem hiding this comment.
options is not documented as @param.
| .post("adminuisdk/permission/check", { | ||
| json: { resource: params.resource }, | ||
| }) | ||
| .json<unknown>(); |
There was a problem hiding this comment.
I believe unknown is the default so .json() should be equivalent.
| * @param httpClient - The {@link AdobeCommerceHttpClient} to use to make the request. | ||
| * @param params - The resource to check. | ||
| * | ||
| * @throws An `HTTPError` if the status code is not 2XX. |
There was a problem hiding this comment.
Maybe @link is better for this throws?
|
|
||
| public constructor( | ||
| resource: string, | ||
| options?: ErrorOptions & { traceId?: string }, |
There was a problem hiding this comment.
From where is this ErrorOptions sourced? In any case, I would create a custom Options for each error even if equivalent to the default, this way we decouple both and we avoid type contract changes in the future if we need to add some options.
There was a problem hiding this comment.
I added an export for error options from the core package
9ec1234. It sounds logical to re-use them.
There was a problem hiding this comment.
This wasn't merged separately? In any case Implemented should be marked.
…data id - add example to usage.md
…data id - update comment
…data id - update commentі
…data id - update docs
…data id - code review
…data id - code review
Description
https://jira.corp.adobe.com/browse/CEXT-6151
Related Issue
https://github.com/magento-commerce/adobe-commerce-backend-uix/pull/352
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: