-
Notifications
You must be signed in to change notification settings - Fork 91
Options for "unmanaging" certain aspects of configuration
Georg Henzler edited this page Nov 22, 2017
·
17 revisions
-- DRAFT --
Aspect | Behaviour when added via config | Behaviour when not present in config | Current config options for behaviour | Proposed config option |
---|---|---|---|---|
Users and Groups | are created | not removed |
obsolete_authorizables can be used docu
|
leave as is |
Relationships between users and groups within config not leaving the "config space" | are created | are removed | none | none |
Relationships of users and groups leaving the "config space" and hence inheriting permissions from elsewhere (isMemberOf ) |
are created | are removed |
keepExistingMembershipsForGroupNamesRegEx : docu
|
Proposal: unmanagedIsMemberOfRegex on authorizable config. Default in global config defaultUnmanagedIsMemberOfRegex that is taken as default for config beans that do not specify it. If nothing is configured manage everything |
Relationships of groups leaving the "config space" and pushing permissions to other, existing authorizables (members ) |
are created | are removed (if not regular user, regular users are often assigned by user administrators) | unfortunately same as in row above | Proposal: unmanagedMembersRegex on group config. Default in global config defaultUnmanagedMembersRegex that is taken as default for config beans that do not specify it. If nothing is configured manage everything |
ACEs for authorizables in the config | are created | are removed | none | Currently discussed in #212 proposing a property ignoreAcesInPaths or restrictAcesRegex - NEW Proposal: unmanagedAcePathsRegex on authorizable config. |
IMPORTANT HINT: The "current behaviour change configs" only affect the cleanup. The idea of the proposed unmanagedXXX properties would be that they also prevent creating relationships/ACEs that are explicitly marked as unmanaged by AC Tool Config - that way the create/remove-cycle would be consistent.