Product
Roles, permissions & invites
SoConnective controls access with a granular, per-section permission model enforced server-side on every write, and adds members to accounts through a tokenized invite-link flow.
Roles and permissions
Permissions are defined at a per-section level, with each section set to one of three access levels:
| Level | Meaning |
|---|---|
| hidden | The section is not visible to the user |
| view | The user can see the section but not change it |
| edit | The user can modify the section |
On top of section levels, roles carry action flags that gate specific operations:
- create
- delete
- export
- assign
Server-side enforcement
These permissions are not merely a UI convenience. Every write is checked server-side via canDo, so a user cannot perform an action they lack permission for — even by calling the API directly. The frontend reflects the same permissions (hiding or disabling what a user cannot do), but the authoritative check happens on the server on every write.
Invites
New members are added to an account through a tokenized invite link:
- An admin generates an invite link containing a unique token, with a role assigned for the invitee.
- The invitee opens
/invite/<token>. - They set a password.
- They become a member of that account with the assigned role, and are logged in.
The public accept endpoints (the invite-acceptance routes) are rate-limited, consistent with the platform's other sensitive endpoints (see Platform hardening). This protects token-based acceptance from abuse while keeping the flow a single, simple link for the invitee.