Bug #18339
Updated by Peter Amstutz about 3 years ago
# If the last sweep hasn't finished, currently it starts a new, overlapping sweep operation. Instead, it should probably do something like try to take the lock, but if it can't acquire the lock, don't do anything (it checks the sweep task periodically, so it'll eventually run again when lock is no longer held)
# The delete operations should run in a transaction, to reduce overhead from auto-commit, and to avoid flapping locks
# Destroying a group also destroys any permission links pointing to it. Ruby on Rails is running the before_destroy hook for the permission link, which does an update_permissions operation, which takes the table lock on materialized_permissions. We can set @Thread.current[:suppress_update_permissions] = true@ to prevent permissions from being recomputed.
side Q: how does should trash interact with 'role' groups? It appears a trashed 'role' group continues to be traversed for permissions until it is actually deleted from the system. Trashing a role group should either not be allowed if there are outgoing permissions, or the trash operation should delete the outgoing permissions.