CEXT-6151: Add ACL admin UI schema and helper to check permissions#426
CEXT-6151: Add ACL admin UI schema and helper to check permissions#426oshmyheliuk wants to merge 18 commits into
Conversation
🦋 Changeset detectedLatest commit: 8142c69 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 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 |
Update require() JSDoc to document fail-closed behavior when denyOnError: true. Add test case verifying require() throws AdminUiSdkPermissionError on 401. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Lib-api is designed as generic Commerce API utility library, this PR adds Admin UI SDK code. The precedent is Commerce Events: eventing is wired up during installation (lib-app), the actual API client lives in its own dedicated lib-events package. Admin UI SDK is the same pattern, lib-app owns the config schema and the installation step, but the permission client is a standalone API concern. I'd spawn a new package dedicated for Admin UI SDK. The cost is another package to maintain, but given that Admin UI SDK is still growing and under refinement, doing the split now is lower effort than after more surface has accumulated across lib-app and lib-api. |
| } | ||
|
|
||
| /** Client for checking the current user's Admin UI SDK resource permissions. */ | ||
| export interface AdminUiSdkPermissionClient { |
There was a problem hiding this comment.
Wouldn't be better to do not limit the scope to just permissions? What if we need to add in the future an operation for AdminUiSdk but not related to permissions? We will create a new client?
I'd propose to open the scope of the client, so other concepts fit in:
interface AdminUiSdkClient {
checkPermission()
invalidatePermission()
requirePermission()
}
There was a problem hiding this comment.
We already have an admin ui sdk related operation, but they are using the Commerce Client directly.
https://github.com/adobe/aio-commerce-sdk/blob/main/packages/aio-commerce-lib-app/source/management/installation/admin-ui-sdk/helpers.ts#L36
Probably can be moved to the "new Client" as well.
| } as const; | ||
|
|
||
| /** Wraps an App Builder action handler with an Admin UI SDK permission check. */ | ||
| export function withAdminUiSdkPermission< |
There was a problem hiding this comment.
I like this idea but not sure if we have this kind of wrappers anywhere else
There was a problem hiding this comment.
Yeah, I wasn't too sure whether I should add this. This wrapper is optional, I can remove it.
There was a problem hiding this comment.
Maybe we could just create a require helper function instead of wrapping.
requireAdminUiSdkPermission("Acme_Promotions::edit", client)
Does it make sense change resource as array? In case of multiple permissions are allowed? Or even multiple permissions could be required?
obarcelonap
left a comment
There was a problem hiding this comment.
LGTM but I'd like to hear your opinion about spawning a new package before approving.
|
Creating a new package sounds like a logical step to me, to align with what we already have for eventing/webhooks. |
| return { statusCode: 200, body: { updated: true } }; | ||
| } | ||
|
|
||
| export const main = async (params) => { |
There was a problem hiding this comment.
I overlooked the wrapper I thought it was meant to be used wrapping the whole function so you don't need to create the clients.
export const main = withAdminUiSdkPermission(
"Acme_Promotions::edit",
(params) => {
// protected handler here
},
)| @@ -0,0 +1,111 @@ | |||
| # `@adobe/aio-commerce-lib-admin-ui-sdk` Documentation | |||
There was a problem hiding this comment.
should we add experimental warning
| }); | ||
| ``` | ||
|
|
||
| In install/uninstall actions where only a subset of operations is needed, prefer `createCustomAdminUiSdkApiClient` to keep the bundle lean: |
There was a problem hiding this comment.
While I understand this is to be more performant I don't think it is an issue in the app-management endpoints since they're not in the critical path of the applications. Therefore I'd remove it for the sake of simplicity.
| "CHANGELOG.md", | ||
| "README.md" | ||
| ], | ||
| "scripts": { |
There was a problem hiding this comment.
Missing docs script and @aio-commerce-sdk/config-typedoc devDependency
There was a problem hiding this comment.
review this docs because claude is flagging some ids may not work with the new validations
docs/usage.md in lib-app still has "my-app::menu" — which now fails the new regex
packages/aio-commerce-lib-app/docs/usage.md:476 still shows a hyphenated ID. The new id regex /^[A-Za-z0-9/:_]+$/ disallows hyphens, so any user copying from the docs
would get an unexpected parse failure. The example needs updating (e.g. "my_app::menu"). If real apps use hyphenated IDs this is potentially a major bump.
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: