Chris Hubick at Athabasca University wrote in to the uPortal discussion list with the following question:
| Panel |
|---|
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 (at least in the short term) 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, i.e.,:
| Code Block |
|---|
owner = "org.jasig.portal.channels.groupsmanager.CGroupsManager" |
...
| Code Block |
|---|
target = "group.local.123*" |
actually point are known to refer to a group and its descendants. This is a very brittle approach that uses a hard-coded syntax to resolve an exceptional case. But , but it does work, and perhaps someone could can think through and generalize the approach, perhaps maybe introducing a configurable wildcard syntax and list of permission owners.
For starters, I'm attaching a sample policy that addresses the groups manager issue.