[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: |
|
||||
| Issue Links: |
|
||||
| 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. |