[MGNLUI-2356] Inconsistent behavior when enabling access for security app Created: 06/Nov/13  Updated: 17/May/21  Resolved: 17/May/21

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: 6.2.5
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Lars Fischer Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File ACLs_for_deptOne-admin.png    
Issue Links:
Cloners
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

After enabling the role "deptOne-admin" to access the securityApp by adding it to

/modules/security-app/apps/security/permissions/roles

I get different behavior when editing a group or a role within a folder structure "deptOne-admin" has permissions for (this is a multi-tenancy use case).

As user having the "deptOne-admin" role I'm able to select and edit a group within "my" "/departmentOne" folder but when selecting "Edit role" in "Roles" an exception is thrown:

info.magnolia.ui.api.action.ActionExecutionException: javax.jcr.PathNotFoundException: /modules/security-app/dialogs/role

After adding the ACL

Config - Read Only - Selected and sub node - /modules/security-app/dialogs/role

to the "deptOne-admin" role, everything works fine.

The behavior for groups and roles should be consistent and in an ideal way it would be enough to just add the "deptOne-admin" role to the list of allowed roles within the securityApp.



 Comments   
Comment by Lars Fischer [ 06/Nov/13 ]

With the ACLs set like in the attachment it works, when removing the config part I get the exception.

Comment by Lars Fischer [ 07/Jul/14 ]

Meanwhile the problem has been fixed.

Comment by Jan Haderka [ 17/May/21 ]

Currently when setting permissions at this level of granularity, one has to also explicitly set permissions for the dialogs. Resolving this case automatically would open up some other undesired cases, hence setting permissions explicitly is necessary.

The future security model will will likely go away from current granularity hence removing whole class of issues like this altogether. Until then workaround with explicit setting of permissions is necessary.

Generated at Mon Feb 12 08:55:47 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.