Systems Admin Guide
This guide describes the concepts of the membertility Systems Module.
Systems and Access Levels
A system is anything a member may need access to because of a position they hold – Google Workspace, MailChimp, Canva, the club website, a RunSignUp race, or membertility itself. Systems are defined using the Systems view.
Some systems have more than one level of access – for example, membertility has several administrative security roles. Each system needs at least one access level, defined using the System Access Levels view, even if there’s really only one level of access (in which case a single access level, e.g. “Access”, is enough).
Access Types
Rather than assigning individual system/access level pairs to every position one at a time, related access requirements can be bundled into an access type using the Access Types view – for example, an “Race Director access” access type might bundle together Google Workspace, MailChimp, and RunSignUp race access levels. The “Race Director access” access type can then be assigned to every position that needs that bundle of access.
A one-off access requirement that isn’t worth bundling into an access type can instead be assigned directly to a single position as direct access – see Positions view.
A position’s full set of required access is the combination of its access types and its direct access.
Access Checklist
Whenever a member’s required access changes, membertility recomputes what systems/access levels that member now needs, compares it to what they needed before the change, and adds an entry to the Access Checklist view for anything that changed:
This happens for either kind of change that can affect what a member needs:
their positions changing – using the Position Wizard or the Position Dates view
a position or access type they already hold changing what it requires – editing a position’s access types/direct access (or its Active flag) in the Positions view, or editing an access type’s own system access in the Access Types view – in which case every current holder affected by the change is checked, not just one member
If a member holds more than one position that both require the same system/access level, losing one of those positions does not add a revoke entry, since the other position still justifies the access. Only a genuine net change in what the member needs shows up on the checklist.
The Access Checklist view doesn’t grant or revoke access on its own – it’s a reminder for the systems admin to go make the actual change in the real system (MailChimp, RunSignUp, etc.). Once that’s done, edit the entry’s Resolved date to check it off the list.