No postDelete emitted for ldap groups
postDelete hook is not emitted when groups go missing (out of filter, removed, deleted etc).
What is the expectation here? Do we cleaneup? Do we wait for them to reappear?
This means some things dont get cleaned up properly. Like subadmin relationships. The users will still see 'Users' in the top right because they are seen to still be subAdmins because they have entries in oc_group_admin. Might be other user->group relations which are present, and not cleaned up because they only listen on OC\Group postDelete hook.
GitMate.io thinks possibly related issues are https://github.com/owncloud/user_ldap/issues/75 ([10.Beta] Can't update LDAP Groups manually), https://github.com/owncloud/user_ldap/issues/44 (Groups deleted in ldap server still appear in ldap group configuration.), https://github.com/owncloud/user_ldap/issues/20 (Some of the users are unknown for ldap:update-group), https://github.com/owncloud/user_ldap/issues/60 (LDAP Cache), and https://github.com/owncloud/user_ldap/issues/317 (Can't delete LDAP users).
@tomneedham what do we do when users go missing or are deleted with occ user:sync ? do we also trigger the user deletion hooks to cleanup their storages ?
we could align the groups part on that
We have the accounts table. So the sync command can mark them as disabled, or 'delete' them. Problem is the groups are still dynamic, we never merged the group sync table. With this, we could then mark as deleted / disabled (hidden), or trigger delete (which may cleanup group spaces, admins etc).
Since we have no cache of what exists, its hard for the backends to know when groups disappear.