Current functionality
Group types:
- Grouper allows administrators to create group types (typically using GSH or the API)
- There are several internal/built-in group types -- base, naming, attributeDef. There's also requireInGroups, addIncludeExclude, and grouperLoader.
- Group types can have one more more attributes and one or more custom lists.
- There are change log events when group types are created, updated, or deleted. The change log processor doesn't do anything with them.
- Special group type called grouperGroupMembershipSettings that's used to help users skin the lite membership UI.
- Hooks
- User audit
Group type assignments (GroupTypeTuple):
- In general, all users can assign a group type to groups that they admin.
- There are built-in hooks to limit who can assign a specific group type or edit attributes of a group associated with that group type.
- When assigning a group type to a group, a bundle of attributes and lists become available for that group. For example with the gruopLoader type.
- There are change log events when group types are assigned or unassigned. The change log processor does look at these events.
- Hooks
- User audit
Fields:
- Attributes and custom lists are fields. (Just like the fields used for group memberships and group/stem/attributeDef privileges.)
- Fields are associated with a group type.
- Fields have properties for read and write privilege.
- e.g. You must have read (or opt-in or update or admin, etc) privilege on a group to read an attribute value on a group.
- e.g. You must have update (or read or opt-in or admin, etc) privilege on a group to update/delete an attribute value on a group.
- Same with addMember, deleteMember, and getMembers on custom lists. You can have crazy settings like requiring opt-out privilege on a group to be able to add member to a custom list.
- Fields have a nullable property. This prevents deleting an attribute from a group if failOnRequiredAttribute is true in the API call and the nullable property is true on the field.
- Change log
- Hooks
- PIT audit
Attributes:
- Stored in the grouper_attributes table. Has a reference to the group and field.
- Single valued only.
- Can be copied when copying groups.
- Hooks
- User audit
Custom lists:
- Stored in the grouper_memberships table like regular memberships and privileges. Again has a reference to the group and field.
- Can be copied when copying groups.
- Change log
- Hooks
- User audit
- PIT audit
Requirements
- Prevent use of legacy attributes.
- Create old style attributes in the new attribute framework within a configurable folder (e.g. etc:attribute:legacy). By default, everybody can read and assign the attribute.
- Preserve the API methods that allow setting and getting an attribute from a group.
- Web services and UI should continue to work when dealing with getting and setting attributes.
- Hooks should continue to fire when setting and deleting attributes.
- Probably need to go ahead and add support for copying attributes in the new attribute framework when copying groups.
New Design
Migration
Thoughts
- Are we still keeping custom lists? If so, they need to be associated with fields which are associated with types. Any reason to change how types and lists work?
- If we're getting rid of group types, what to do about the built-in ones and how they're represented in the fields table.
- If we're keeping group types, then would you need to for example assign the grouperLoader group type before being allowed to assign the loader specific attributes? If we're not keeping them, would the group type assignment end up being a marker attribute assignment and again do the related attributes only become available if the marker attribute is assigned?
- Do we need to care about preserving the way read and write privileges work on fields and the nullable flag?
- Do we care changes to user audit?
- Allow creation of new attributes using the legacy API?