Folks, There are now 2 Pull Requests in GitHub related to this effort (aimed it breaking it into bite-sized segments)…
- https://github.com/Jasig/uPortal/pull/546 <https://github.com/Jasig/uPortal/pull/546> UP-4456: PAGS (JPA) -- Add constructors to IPersonTester implementations that accept a single IPersonAttributesGroupTestDefinition; deprecate the ones that accept String,String - https://github.com/Jasig/uPortal/pull/547 <https://github.com/Jasig/uPortal/pull/547> UP-4458: Expand the nature of the data than can be defined in a PAGS <test> element with Set<String> includes and Set<String> excludes Benito’s AdHocGroupsTester is built upon these 2 enhancements. drew > On May 6, 2015, at 9:43 AM, Drew Wills <[email protected]> wrote: > > James... > >> On May 5, 2015, at 1:41 PM, James Wennmacher <[email protected] >> <mailto:[email protected]>> wrote: >> >> I think >> >> <pags-group >> script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn >> <classpath://org/jasig/portal/io/import-pags-group_v4-1.crn>"> >> <name>Member of Students (PAGS)</name> >> <description>Member of Students group</description> >> <selection-test> >> <test-group> >> <member-of-group>Students</member-of-group> >> <not-member-of-group>Test Users</not-member-of-group> >> </test-group> >> </selection-test> >> </pags-group> >> >> is great and a much cleaner solution. I want to verify you could do >> something like the following: > > Except that (I feel) the child groups *need* to be wrapped in a <test> > element and the <tester-class> element *needs* to be there. I don’t want to > start teaching Import/Export about specific IPersonTester implementations and > whether you can “infer” one or another specifically based on the nature of > the child elements found within the <test-group>. > > Also, the element names “member-of-group” & “not-member-of-group” are > workable — that approach would be okay — but I think even better is > <includes> & <excludes>, here’s why… > > In the future we may want to create even more IPersonTester classes that do > new and innovative things. For their functioning, they may need some > parameters in the <test> element as well. These parameters, moreover, will > need to be modeled as members on IPersonAttributesGroupTestDefinition and the > JPA-managed implementation of that interface as well… so that means (albeit > minor) database schema changes. I’d like to avoid those, to the extent > possible, so I’d prefer to use names that are more likely to be reusable in > the future with other IPersonTesters. > > So my proposal for the XML corresponding to this example would be (note the > version change in the script attribute)… > > <pags-group > script="classpath://org/jasig/portal/io/import-pags-group_v4-3.crn > <classpath://org/jasig/portal/io/import-pags-group_v4-3.crn>"> > <name>Non-Test Students</name> > <description>Students who are not test accounts</description> > <selection-test> > <test-group> > <test> > > <tester-class>org.jasig.portal.groups.pags.testers.AdHocGroupTester</tester-class> > <includes>Students</includes> > <excludes>Test Users</excludes> > </test> > </test-group> > </selection-test> > </pags-group> > > This way, furthermore, it’s clear how you combine test definitions based on > the AdHocGroupTester with other criteria (just as we’ve always done). This > approach makes this new type of group less different or weird as compared > with existing groups, testers, data files, documentation, Import/Export > support, etc. > > drew > > > > > -- > > 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
