PAGS Best Practices

Owned by Andrew Petro
Last updated: Aug 18, 2006Version comment

This page came into being as a result of a thread on jasig-dev that was active July 24th and 25th 2006.

On using PAGS alongside other group services

Yuji uses wrapper groups to abstract the group implementation

We use PAGs in combination with FilesystemGroups (FSG's) and internal groups.
We use a naming convention to identify the type of group to avoid confusion.
So our PAGs are postfixed with PAG and our FileSystemGroups are postfixed with FSG.

And, like Dan, we always have the PAGs and FSGs nested inside an internal group, so that we can do "manual" additions to the internal group if necessary. But we try to keep the manual additions to a minimum, to keep the management burden light.

For Example:

  • Students
    • StudentsPAG
    • New Students
      • NewStudentsFSG
    • Transfer Students
      • TransferStudentsFSG
  • Faculty
    • FacultyPAG
  • Staff
    • StaffPAG

And we only refer to the internal groups in DLM.xml and anywhere else the group might be used. (Akin to only referring to Interfaces in OOP). So we would use "New Students" or "Students" and avoid using "NewStudentsFSG" or "FacultyPAG". (Note that there might be some redundancy in the nesting of groups, but that has not caused any problems).

This structure also has the advantage that we can change the implementation (from a PAG or FSG, or combination thereof, as needs change).

We have written one or two custom PersonAttributeDAO's to provide attribute information that is not readily available through LDAP.

Our FSG's are user lists are typically generated from other systems (our legacy student systems, hand-managed lists, etc), usually by some automated batch process but a few are manually edited.

In general we use the FSG as a stop gap where we have to apply special logic or need to have some external entity (person or system) manage the list. And where it is not advantageous to write a custom PersonAttributeDAO.

We find this arrangement has the flexibility we need and is reasonable to manage.

yuji

Dan places PAGS within local groups for flexibility.

We've found it helpful to use a combination of PAGS and local groups. We typically put PAGS groups inside "higher level" groups defined in the local service, and we associate permissions with the higher level groups. This lets us control access to content in real time thru the local service, and gives us the flexibility as well to add in extra, exceptional users.

Dan

On adopting PAGS

Susan shares her PAGS adoption experience

We use PAGS for almost all groups but use the local implementation for portal permissions - such as publishing channels and being portal administrator. When we converted to PAGS we purged tall the users so they ended up with new groups and new layouts. That was 2 years ago and we promised we wouldn't do it again. We also republished the channels with new categories.

When not to use PAGS

Jason articulates some downsides of PAGS

I think the biggest limitation of PAGS (an understandable one) is that you can't get a list of the members of a group. For smaller, especially ad-hoc or manually maintained groups this can be invaluable. It's nice to check to see who has Portal Admin privledges, for example. I guess it's trading flexibility for consistency.

Admittedly you could have some batch process go around and cache queries, or ask your backend directory or store.

Jason