Hi Arlo, I do think this feature likely is pretty trivial; it might involve a bit of tweaking of the permissions implementation. I think the particularly attractive use case for this feature is in making sure objects are always accessible for permissions assignment. It's theoretically possible that in some instances, an administrator could wind up not even able to view an object in order to assign permissions for it.
I wanted to mention, though, that Grouper work is moving forward, and an initial pass at the Grouper groups store is in the uPortal trunk now. We still need to do additional work to get it working as a read-only store, and I don't think uPortal's native groups and permissions code is going to disappear anytime in the near future, but we're making progress. - Jen On Aug 17, 2010, at 10:01 AM, Arlo White wrote: > I commented on the JIRA item: > > If this enhancement isn't trivial I'd much rather see the developers spend > their time working on the Grouper integration with uPortal. If uPortal's > native groups/permissions system is going to be deprecated soon there doesn't > seem to be much point in using developer time to enhance it. > > Though this feature might save a little time you can still achieve the same > thing by just updating your permissions. When you add a new permission > you need to decide who receives the permission anyway. So you already need to > go into the permissions/groups interface to deal with at least one group. The > extra effort of assigning the permission to Portal Admins as well is fairly > negligible. > > On 08/16/2010 09:45 PM, Eric Dalquist wrote: >> >> Seems reasonable. >> >> On 8/16/10 7:08 PM, Andrew Petro wrote: >>> >>> I have what I think is a simple and elegant idea for an enhancement to >>> uPortal permissions implementation, one that's not original (Academus had >>> something very much like this) but that I think could reduce the need for >>> explicit configuration of permission grants to Portal Administrators. >>> >>> https://issues.jasig.org/browse/UP-2803 >>> >>> My proposal is this: that, optionally, permissions be enhanced to allow >>> configuration of a group that is opted-out from all permissions checks and >>> is considered to have any permission. >>> >>> By default, Portal Administrators would be given this capability. >>> >>> The idea is that it would remain possible to grant permissions to other >>> groups, and even to not grant them to Portal Administrators by configuring >>> another or no group as the embued super-user group, but that by default in >>> cases where the only permission grant is to Portal Administrators, no grant >>> at all need be made, and in cases where there are interesting grants to be >>> made (to students, or graduate students, or chemistry lab assistants) the >>> explicit configuration focus on those interesting grants and not have to >>> bother to say "oh, and portal administrators have this permission too". >>> >>> This would have an advantage of it no longer being possible to overlook >>> granting permission to Portal Administrators to access some of the portlets >>> in the out of the box configuration, as in UP-2797. >>> >>> Thoughts on this wisdom of this potential enhancement? >>> >>> Andrew >>> >>> -- >>> >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- > > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- Jen Bourey Software Developer Unicon, Inc. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
