Hi Andrew, This change is backend support for a new admin feature. The goal is to give administrators the ability to manage a set of dynamic groups that are composed of other groups from portlets. Yet, it does seem to have value on its own.
Integrating Grouper further into uPortal as a key part of revamping the group subsystem sounds promising. It is out of scope for my current effort and skill, but I would like to hear more about this. Should we add it to the list of topics for uPortal Project and Product Vision BoF <http://lanyrd.com/2015/apereo/sdmmhy/>? Thank you for the feedback! Benito J. Gonzalez - Unicon [email protected] <mailto:[email protected]> 480.558.2360 PS: Thanks for the suggestion. PPS: The PAGS group import CRN file seems to be working. Next, I will focus on the JPA classes, then wrap up with the export code changes. It’s moving along! > On May 4, 2015, at 9:41 AM, Andrew Petro <[email protected]> wrote: > > Benito, > > This seems fine as far as it goes. If it were in the uPortal product we > might find a use for it in MyUW. > > It feels like PAGS is less and less about person attributes and more and more > PAGS is “The Groups System”. Maybe it could be re-named and re-scoped and > done more deliberately for a uPortal 5 or so? > > More and more our strategy in MyUW has been to externalize groups management > into Manifest, which is a groups service with among other things Grouper > inside of it. It does data-driven groups and ad-hoc groups and delegated > administration and … But its killer feature is that it’s the enterprise > group store and so group policy problems become less of a portal problem. We > pick up these group memberships via SAML assertions from our friendly > neighborhood Shibboleth IdP, which represents the group memberships we’re > entitled to know about as user attributes. > > The technology exists to query the IdP as if it were a directory to ask about > user attributes outside the context of that user logging in. That would get > us back to the ability to ask about the user attributes (and group > memberships) of users outside the context of their very own session. We > haven’t actually implemented this in MyUW yet, but at least one other > application on campus is doing this trick, so there’s some comfort that we > could do it if we had to, and that helps us to feel we’re not missing much > moving away from portal-managed groups and user attributes from LDAP and all > that. > > In the details, of course, we’re still using PAGS with a PAGS group shadowing > each Manfiest group, with the PAGS group configured to do its testing based > on the user attribute representing that group membership. This is kind of a > pain and from time to time we kick around the idea of implementing something > lighter. > > I suspect that rather than building out its own group system, uPortal would > be better off internally implementing Grouper, or having something very > lightweight internally for which all the interesting functionality is > achieved by pointing it at an external grouper. > > So > >> <adhoc-group-test> >> <include> >> <group-name>Students</group-name> >> <group-name>Mobile Device Access</group-name> >> </include> >> <exclude> >> <group-name>Testers</group-name> >> </exclude> >> </adhoc-group-test> > > is cute and all, and even practical and useful, and I understand why you’re > building it, and heck I’ll even use it if I end up needing to, but it’s also > kind of a cartoon version of what Grouper does for group math, and there’s > some alternate universe in which uPortal just uses Grouper for this and > thereby realizes that sophistication and we skip this ad-hoc stuff. > > That alternate universe may well not co-incide with this universe. > > Kind regards, > > Andrew > > PS : Anathem. Great book. > > PPS: How’s the entity-driven-PAGS import-export going for this new > adhoc-group-test featureset? > > >> On May 1, 2015, at 3:57 PM, Benito J. Gonzalez <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi uPortal Devs, >> >> Some of you might recognize my name. I had been with University of >> California, Merced for the last 9 years. Recently, I joined Unicon to >> increase my participation with this awesome community! >> >> I am currently working on a PAGS tester that will test membership in other >> groups. The idea is that this tester will be used to check for membership in >> combinations of other groups. This avoids duplication and synchronization of >> test criteria. >> >> An example would be a test for persons that are students currently using a >> mobile device that are not in a test group. Assuming appropriately named >> groups: >> ... >> <adhoc-group-test> >> <include> >> <group-name>Students</group-name> >> <group-name>Mobile Device Access</group-name> >> </include> >> <exclude> >> <group-name>Testers</group-name> >> </exclude> >> </adhoc-group-test> >> ... >> >> Ramping up on the groups subsystem has been challenging, but I have a >> working tester class for a single group check. It currently (mis-) uses the >> attribute and value stanzas for the normal tests to allow me to address >> recursion when checking for group membership. Working on the changes needed >> to the import code. >> >> Anyone else interested in this feature? Comments more than welcome. >> >> Benito J. Gonzalez - Unicon >> [email protected] <mailto:[email protected]> >> 480.558.2360 >> >> >> >> -- >> >> You are currently subscribed to [email protected] >> <mailto:[email protected]> as: [email protected] >> <mailto:[email protected]> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> <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 -- 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
