The idea behind volunteer groups is making it easier to handle logic in the form of "membership in user group X gets you access to Y resource". For example, board members get added to the board channel and the board user group and the board email. Ops has similar rules. General membership gets added to the mailing list. Getting trained on some equipment gets you added to channels.
This wouldn't be things such as "you're invited to our Slack instance" or "You're invited to our GitHub organization". Instead it's "You are invited to this specific channel" or "You have been invited to this specific team".
For the most part, this should make that type of logic easier to audit, understand, and less one off. We can end up with things such as "This group adds you to this Active Directory group" or "This group access to the badge reader upstairs".
I'm trying to break this work down into a series of PRs. Right now, I'm not focusing too much on the UI (though there were some UI changes in here, I realized that wasn't as important right now) and instead I'm focusing on functionality. There's a feature flag for slack channels and equipment authorizations. Each equipment authorization has a slack channel id and an email associated with it (one each for user / trainer). We can migrate these to the volunteer groups and I figured I'd start by handling those rows manually and using a feature flag. If it works well, we can make sure the volunteer group channel's are updated automatically in a future PR. Then we can remove those 4 columns on the trainable_equipment table.
The idea behind volunteer groups is making it easier to handle logic in the form of "membership in user group X gets you access to Y resource". For example, board members get added to the board channel and the board user group and the board email. Ops has similar rules. General membership gets added to the mailing list. Getting trained on some equipment gets you added to channels.
This wouldn't be things such as "you're invited to our Slack instance" or "You're invited to our GitHub organization". Instead it's "You are invited to this specific channel" or "You have been invited to this specific team".
For the most part, this should make that type of logic easier to audit, understand, and less one off. We can end up with things such as "This group adds you to this Active Directory group" or "This group access to the badge reader upstairs".
I'm trying to break this work down into a series of PRs. Right now, I'm not focusing too much on the UI (though there were some UI changes in here, I realized that wasn't as important right now) and instead I'm focusing on functionality. There's a feature flag for slack channels and equipment authorizations. Each equipment authorization has a slack channel id and an email associated with it (one each for user / trainer). We can migrate these to the volunteer groups and I figured I'd start by handling those rows manually and using a feature flag. If it works well, we can make sure the volunteer group channel's are updated automatically in a future PR. Then we can remove those 4 columns on the trainable_equipment table.