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 at https://list.unm.edu/cgi-bin/wa?A2=ind0701&L=jasig-portal&T=0&F=&S=&P=2733.)
Although this question exposes gaps in the groups manager channel, you could also get the desired behavior with a custom permissions policy, and this might buy you some time to work out a long term solution. The policy would evaluate permissions owned by the groups manager channel:
owner = "org.jasig.portal.channels.groupsmanager.CGroupsManager"
such that permission targets that have a wildcard syntax, i.e.,
target = "group.local.123*"
are known to refer to a group and its descendants. These permissions 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 the approach, 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 the groups manager issue.