[MAGNOLIA-4652] Provide capability of having folders in security for groups and roles out of the box Created: 12/Nov/12  Updated: 06/Nov/13  Resolved: 30/Oct/13

Status: Closed
Project: Magnolia
Component/s: security
Affects Version/s: 4.5.6
Fix Version/s: 5.2

Type: Improvement Priority: Neutral
Reporter: Lars Fischer Assignee: Tobias Mattsson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive magnolia456-security-folders.zip    
Issue Links:
Relates
relates to MAGNOLIA-5455 Replace use of queries with node trav... Closed
causality
is causing MAGNOLIA-5450 Adjust user/group/role-related tasks ... Closed
dependency
is depended upon by MGNLUI-2322 As a user I can organise roles and gr... Closed
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)
Release notes required:
Yes
Date of First Response:
Epic Link: Security improvements
Sprint: 5.2-rc1

 Description   

It would be a benefit having folders for groups and roles for the security section by default.

Folders enable some kind of "multi-tenancy" behavior where sub-admins can manage users contained in a folder (a folder could be a department, site, ...).

Besides ACL settings in Magnolia, the following additional changes are needed for Magnolia 4.5.x to make use of folders in groups and roles:

  • Change classes tree configuration in admin interface for users and groups (add context menu to add folders)
  • change groups-, roles- and user-managers to be able to handle folders

You can find a working example webapp attached - but before taking this into a production release more tests are needed!



 Comments   
Comment by Lars Fischer [ 22/Oct/13 ]

The demo has been slightly extended and put on the Git repository

https://git.magnolia-cms.com/gitweb/?p=services/magnolia-security-folders.git;a=summary

Comment by Jan Haderka [ 01/Nov/13 ]

GroupManager/RoleManager interface

  • changes break LDAP/AD modules ... if those are bundled (they are right?) ... we need to fix them as well
  • furthermore since we are unlikely to support creation of groups for anything else then our own group manager and since main use of the interface is to provide read only functionality, i would think that all methods for manipulation of groups would deserve their own interface
    that might extend the GroupManager

updateGroupListWithAllChildren

  • uses recursion, stores groups and folders on given level in collection ... both have potential for blowing up later
  • javadoc of the method says "* Updates collection with all groups located under provided node." but reality is different. All it does is collect all the groups it finds in the groups collection passed in as param (instead of returned) making it even more obscure.

MgnlGroupManager, MgnlRoleManager

  • findPrincipalNode() seems to be the same in both classes except for the node type name ... perhaps it's an opportunity to extract this method upwards?
  • now we ignore the fact that there might be multiple groups or roles w/ same name and just return the first one. This should be at the very least documented. And I'm still not convinced that it is correct. Seems like this change was driven only by need to use getRole/Group() method in validateRole/Group() method
Generated at Mon Feb 12 03:57:45 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.