...
Failsafe to not remove too many members by mistake
You can configure the loader to not make changes if too many members are to be removed. The use case is if the source for the loader groups gets blanked out accidentally, it shouldnt remove everyone. However, if groups are supposed to drastically change, it means a user needs to manually change this flag, run the sync, and change it back.
| Code Block |
|---|
# if the loader should check to see too many users were removed, if so, then error out and |
...
# wait for manual intervention |
...
loader.failsafe.use = false |
...
# if a group has a size less than this (default 200), then make changes including blanking it out |
...
loader.failsafe.minGroupSize = 200 |
...
# if a group with more members than the loader.failsafe.minGroupSize have more than this percent (default 30) |
...
# removed, then log it as error, fail the job, and don't actually remove the members |
...
# In order to run the job, an admin would need to change this param in the config, |
...
# and run the job manually, then change this config back |
...
loader.failsafe.maxPercentRemove = 30 |
Possible to do's
- add subject souce to group attribute (or default at least) so it doesnt have to be a sql column if all are the same
- make specific blackout times (runtime via config file?)
- make jobs based on person trigger. If there is a query that says when people change, then update that person's memberships in the groups that are dynamic based on that person-change-query
- make full refresh jobs for the incremental jobs (e.g. weekly)
- save quartz info to DB so that stopping / starting isnt that drastic
- make an RMI server so that interactions can happen at runtime (to see status, stop/start jobs, etc). Maybe this would happen from gsh
- try the name pattern after loader is done, and if the number of groups is less than the number of groups in this round of loader, set the job status to WARNING and add a descriptive message
...