Global Elements: Adds "Element or Element Folder" User Permission Condition - #23051
Conversation
Adds a combined permission condition that permits when a user has read access to elements OR element folders, using the OR semantics needed for the element recycle bin (which contains both entity types). The condition composes UmbElementUserPermissionCondition and UmbElementFolderUserPermissionCondition as child controllers and exposes configurable element/folder verb blocks (allOf/oneOf each side).
…mission The element recycle bin contains both trashed elements and trashed element folders, so users with only folder read access had legitimate contents but the bin was hidden from them. Replaces the element-read-only condition with UmbElementOrElementFolderUserPermissionCondition on both the menu item and the root workspace collection view.
Adds UmbElementUserPermissionCondition via createExtensionApiByAlias to the create-options modal; allowed element types are only fetched when the user has element-create permission. Users with folder-create permission only will see the folder option without element types. Also applies UmbElementOrElementFolderUserPermissionCondition to the Create entity action so it appears for users with either permission.
…-folder condition
|
Claude finished @leekelleher's task in 7m 41s —— View job PR ReviewTarget: Adds
Important
Suggestions
Approved with Suggestions for improvementThe OR-combinator pattern is clean and idiomatic — sub-conditions are composed as child controllers, context observation propagates correctly, and the manifest registrations are consistent. Logic is correct for all four scenarios described in the test plan. No breaking changes. Labels applied: |
leekelleher
changed the title
There was a problem hiding this comment.
Pull request overview
Adds a new extension-registry condition to express OR logic across Element vs Element Folder (container) permissions, then uses it to correctly gate the Element Library recycle bin visibility and the “Create” entry points (including limiting element type listing in the create-options modal).
Changes:
- Introduces
UmbElementOrElementFolderUserPermissionCondition(+ config types, alias constant, manifest registration) to support (element permissions) OR (folder permissions). - Updates Element recycle bin menu item + root workspace view to permit Umb.Element.Read OR Umb.ElementContainer.Read.
- Updates Element “Create” entity action gating to permit Umb.Element.Create OR Umb.ElementContainer.Create, and gates the create-options modal element type listing on Umb.Element.Create only.
Reviewed changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| src/Umbraco.Web.UI.Client/src/packages/elements/user-permissions/conditions/types.ts | Adds the new condition config type (element vs folder verb sets) and extends the global config map. |
| src/Umbraco.Web.UI.Client/src/packages/elements/user-permissions/conditions/constants.ts | Defines the new condition alias constant. |
| src/Umbraco.Web.UI.Client/src/packages/elements/user-permissions/conditions/manifests.ts | Registers the new condition as a condition manifest. |
| src/Umbraco.Web.UI.Client/src/packages/elements/user-permissions/conditions/index.ts | Exposes the new condition from the package index. |
| src/Umbraco.Web.UI.Client/src/packages/elements/user-permissions/conditions/element-or-element-folder-user-permission.condition.ts | Implements the OR-combinator condition (Element vs Element Folder permissions). |
| src/Umbraco.Web.UI.Client/src/packages/elements/user-permissions/conditions/element-or-element-folder-user-permission.condition.test.ts | Adds unit tests covering the OR logic permutations. |
| src/Umbraco.Web.UI.Client/src/packages/elements/recycle-bin/root/workspace/manifests.ts | Gates the recycle bin root collection view on combined read permissions. |
| src/Umbraco.Web.UI.Client/src/packages/elements/recycle-bin/menu/manifests.ts | Gates recycle bin menu item visibility on combined read permissions. |
| src/Umbraco.Web.UI.Client/src/packages/elements/entity-actions/create/manifests.ts | Gates the Create action on combined create permissions (element OR folder). |
| src/Umbraco.Web.UI.Client/src/packages/elements/entity-actions/create/element-create-options-modal.element.ts | Loads allowed element types only if the user has element-create permission (folder-only users won’t see element types). |
| src/Umbraco.Web.UI.Client/mocks/data/sets/user-permissions/user-group.data.ts | Extends mock permission data to support the new unit test scenarios. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…ssion condition - Only instantiate sub-conditions when the matching config side is provided, preventing always-permit when element/folder config is omitted - Add idempotency guard in create modal onChange to avoid duplicate fetches - Export UmbPermissionVerbsConfig for external reuse - Document why 200ms timeout is safe in the neither-permitted test
|
AndyButland
left a comment
AndyButland
left a comment
There was a problem hiding this comment.
All looks good to me @leekelleher, and I've run through the tests cases to make sure they all check out.
UmbElementUserPermissionCondition evaluated its permission state on every emit of the current-user context, including the `undefined` emits that occur before the user loads and during teardown. Because `#elementPermissions`/`#fallbackPermissions` defaulted to `[]`, those `undefined` emits recomputed against empty arrays and flipped `permitted` back to `false`. This surfaced through the new combined condition (UmbElementOrElementFolderUserPermissionCondition, #23051): in the test's success path `permitted` correctly went false -> true, but the teardown triggered by hostDisconnected() re-emitted the current-user context as `undefined`, flipping the child element condition (and therefore the combined condition) back to false and re-firing onChange. The assertion then ran against a `false` value and threw uncaught, failing all four tests in the file. Mirror the sibling UmbElementFolderUserPermissionCondition (#22274), which already solved this: keep `#elementPermissions`/`#fallbackPermissions` undefined until the current user has loaded and return early from #checkPermissions while they are undefined, so we never permit/deny on incomplete data and never re-emit a spurious `false` on teardown.
|
Just to add @leekelleher - I saw we had the FE test check failing on |
Description
There is an issue where the contents of the Element Library Recycle Bin is visible to users without "Read" permission. (This is the same issue that PR #23041 resolves for the Document Recycle Bin).
The complexity with the Element Library is that we have separate permissions for Elements and Element Folders, where a user could have various combinations of permission, e.g. "Read" on Element Folders but not Elements. So we needed a condition mechanism to handle the OR logic.
This new condition also resolves an issue with the Element Library's "Create" entity-action, e.g. where a user could have "Create" on Element Folders but not Elements.
Summary (AI/Claude generated) 🤖
UmbElementOrElementFolderUserPermissionCondition— a new condition that permits when a user has the configured element OR element folder permissions (AND-within-each-side, OR-across-sides). This is needed because the manifestconditionsarray is hard-AND, so an OR across permission types requires a dedicated combinator.Umb.Element.Read OR Umb.ElementContainer.Read, replacing the previous element-read-only check that wrongly hid the bin from folder-read-only users.Umb.Element.Create OR Umb.ElementContainer.Create.Umb.Element.CreateviacreateExtensionApiByAlias, so folder-only users see only the folder create option, not element types.Test plan
npm test -- --files "src/packages/elements/user-permissions/conditions/element-or-element-folder-user-permission.condition.test.ts"— all 4 OR-logic cases pass