When adding members to a tag, the member: * Cannot be the tag itself (trivial loop prevention) * Cannot already be a member (database unique constraint would catch this) * Cannot already include the receiver as a member, either directly or indirectly (loop prevention). * Must be a valid member of the tag, by calling *Tag.valid_member? * Cannot be the Admin subject tag, if receiver is subject tag. I think the add member code for preventing loops would be subject to race conditions, so this uses a serializable transaction for it. I'm not positive even that will prevent all loops, but it should make creating loops very difficult. We do have a configurable recursion limit in all recursive queries, so loops are not catastrophic. This adds the same validation we have on project names to tag names. It also removes any references to the tag when deleting it: * Removes memberships in tag itself * Remove memberships of current tag in other tags * Removes any access control entries directly on the tag itself This adds Config.recursive_tag_limit, as it is used for the recursive queries in the validations.
6.9 KiB
6.9 KiB