Type: New Feature
Affects Version/s: 2.1.3
Fix Version/s: None
- Add columns enabled, enabled_timestamp, disabled_timestamp to grouper_groups
- Modify all existing queries to take enabled='T' into account.
- What about queries that are not currently joining grouper_groups (if any)? They should join grouper_groups to make sure the group is enabled I assume. See below.
- Consider impact to some trivial queries? e.g. Attribute Assign findById wouldn't be a simple query anymore. e.g. If the assignment is on a membership, it would query the membership and if that membership was on a group, it would query the group to finally see if it's enabled? Chris - no don't need to update these. Focus on the queries that join grouper_groups and lean towards leaving others as is or use membership enabled/disabled as precedent.
- Internal things like composite updates should probably continue to happen and just not be sent to the change log?
- Deleting a folder in the UI should continue to show disabled groups during the confirmation screen.
- Need to manage group sets (and role sets?) properly so that they don't exist for disabled groups. Also update the scripts that would want to "fix" missing group sets.
- Update UI to show enabled/disabled dates and allow them to be edited. (UI is lower priority right now.)
- Update WS to show enabled/disabled dates and allow them to be edited.
- Have a way of showing disabled groups in the UI.
- What should we do about other screens like attribute assignments? Show those assignments on disabled groups with an indicator that the group is disabled. Maybe grayed out check marks (but it would require changes to other icons that are currently grey)?
- Have a way of returning disabled groups in WS.
- How should the change log and point in time be handled? Perhaps... (this may be lower priority)
- Send a disable event to the temp change log.
- Change log processor would consider that a group delete and put an end date on the group and all things dependent like memberships and attributes.
- All of those deletes go to the real change log
- Real change log would first get a disable event. The consumer can see all the deletes are related via context id. This could allow consumers to handle disabled groups differently from deleted groups.
- Enabling a group would do the opposite. (Enable event goes first.)
- Need to make sure the PIT stuff can handle multiple groups with the same "source id".
- Daemon job to update enabled flag based on dates.
- As far as subject resolution goes, should that work with disabled groups? No
- What happens if you try to add a group that exists and is disabled? For memberships, it would delete the disabled memberships and process it normally I think. I don't think we want to delete an entire group though... So it'll just be an error (though the caller would then know that the group exists even if the caller doesn't necessarily have privs to know that.)
- What should be done with existing database views? Use enabled flag for things that join grouper_groups and memberships at minimum.
- Don't allow entities to be disabled? Yes
- How should hooks be handled? Should we really call insert/delete hooks for the group along with all of its dependencies (memberships, attributes, etc)? Yes but lower priority. Also look at rules.
- Need to make sure XML export/import does the right thing.