Chris Hubick at Athabasca University wrote in to the uPortal discussion list with the following question:
I have implemented a custom group store which exposes thousands of hierarchical groups, created dynamically based on our Banner registration system database.
After adding the root group from this dynamic store to the 'Everyone' persons group, the admin user is immediately capable of pushing fragments to any one of the dynamic groups at any depth in the hierarchy. Yay.
However... I would ideally like all content/fragments to be owned by our non-admin 'editor' account/group, which (unlike admin) can (by default) not see or push content to any of the dynamic groups. I tried to fix this by inserting rows into up_permission to grant the editors group view and select permissions on the root dynamic group. This enabled them to push fragments to that root only, but still none of the child groups show up.
How can I fix this?
a) Is there a way to give a user/group other than admin default (inherited?) access to all the dynamic groups beneath the root? b) Would an admin have to log in repeatedly and use 'select all' with the permissions manager to assign editor group access for all the groups existing at that moment? (blech) c) Do I have to implement a permissions store interface as well? d) Forget about limiting editor access, and add the editor account to the admin group? (Will this work, or must I...) e) Forget about the editor account, and just have the admin account own all the content? f) Something else? 
Â
 (The full correspondence is available here.)
This question exposes gaps in the groups manager channel, 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 perform a special evaluation on permissions that are owned by the groups manager channel:
owner = "org.jasig.portal.channels.groupsmanager.CGroupsManager"
and have targets with a known wildcard syntax like
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.