The reason why we didn't do this in the first place back then was mostly because we didn't have the concept of "scope" before, so supporting the above operations would mean that the groups would become visible in the users page and provisioning API. Now that we have the scopes concept, this is not needed any more and we can now use the group manager instead.
To do so, the CustomGroupsDatabaseHandler must implement the above operations "officially" and advertise these through implementsAction. Then the DAV code needs to use the group manager's methods instead of going directly to the database handler. See delete PR for an example.
[ ] get rid of customgroups specific symfony events. The admin_audit app would just work with the regular group events, just need to make sure it's using the group id AND display name.
Goal is to be able to have the group manager events (hooks) triggered automatically:
The reason why we didn't do this in the first place back then was mostly because we didn't have the concept of "scope" before, so supporting the above operations would mean that the groups would become visible in the users page and provisioning API. Now that we have the scopes concept, this is not needed any more and we can now use the group manager instead.
To do so, the CustomGroupsDatabaseHandler must implement the above operations "officially" and advertise these through
implementsAction
. Then the DAV code needs to use the group manager's methods instead of going directly to the database handler. See delete PR for an example.