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 functions of the groups manager channel, it seems like it could be solved at least in the short term with a custom permissions policy. The policy would evaluate permissions owned by the groups manager channel, i.e.,
owner = "org.jasig.portal.channels.groupsmanager.CGroupsManager"
such that permission targets that have a wildcard syntax, i.e.,
target = "group.local.123*"
actually point to a group and its descendants. I'm attaching a sample policy uses this approach.Â