...
(The full correspondence is available at https://list.unm.edu/cgi-bin/wa?A2=ind0701&L=jasig-portal&T=0&F=&S=&P=2733.)
Although this here.)
This question exposes gaps in the functions of the groups manager channel, it seems like it could be solved at least in the short term , which should have permissions covering operations on groups and their descendants. However, you could also get the desired behavior with a custom permissions policy, and this might buy you some time to work out a more viable solution that involves changes to the groups and permissions manager channels. The policy would use a wildcard syntax to indicate, e.g., a permissions target is a group and its ancestors. I'm attaching sample that uses this approach here. perform a special evaluation on permissions that are owned by the groups manager channel:
| Code Block |
|---|
owner = "org.jasig.portal.channels.groupsmanager.CGroupsManager"
|
and have targets with a known wildcard syntax like
| Code Block |
|---|
target = "group.local.123*"
|
A target in one of these permissions would be known to refer to a group and its descendants. Permissions like these would have to be maintained outside of the permissions manager. This is a very brittle approach, but it does work, and perhaps someone can think through and generalize it, maybe introducing a configurable wildcard syntax and list of permission owners. A follow-up step would be to make the permissions manager channel able to write and evaluate such permissions.
For starters, I'm attaching a sample policy that addresses just the groups manager issue.