Reference
Roles, statuses, and event access
Evorto currently uses a static section role, a section membership status, and event-specific eligibility. These controls answer different questions and are all active today.
The three access checks
- Role controls section administration. A user is either User or Admin.
- Membership status describes the user's relationship with the section and controls member-only areas.
- Event eligibility decides which membership statuses may see, join, or organize a particular event.
Changing one does not automatically change the others. For example, assigning Full status does not make someone an admin, and making someone an event organizer does not grant section-wide admin access.
Section roles
User
User is the default and correct role for participants and most event organizers. The actions they see depend on their membership status, the event's settings, and their relationship to that event.
Admin
Admin grants access to section-wide administration, including configuration, users, event organizers, event templates, and event management. Admins can also access events that ordinary users may not see.
Some participant and organizer screens still use membership-status checks. If an admin cannot see a member action such as Add Event, check their membership status as well as their role.
Use admin access sparingly
Admins can view and change sensitive section data. Grant the role only when it is needed, review the list regularly, and remove access when the responsibility ends.
Membership statuses
| Status | How the app treats it |
|---|---|
| None | Default for a user without section membership. The user can still access public events that allow this status. |
| Selected | Not treated as a member by the general member check. It can be used for event-specific visibility or registration. |
| Helper | Not treated as a member by the general member check. It can be selected in event-specific eligibility. |
| Blacklisted | Not treated as a member and excluded from the participant defaults for newly created events. Use it carefully and review existing event settings separately. |
| Trial | Treated as a section member. Newly created events allow this status to organize by default. |
| Full | Treated as a section member. Newly created events allow this status to organize by default. |
| Sponsor | Treated as a section member, but not included in the default organizer eligibility for a new event. |
| Alumni | Treated as a section member, but not included in the default organizer eligibility for a new event. |
Event templates and individual events can apply more specific rules. Always verify the event's participant and organizer eligibility instead of assuming membership alone is sufficient.
Event relationships
An event can also grant access because someone created it, is registered for it, or is one of its organizers. These relationships do not change the person's section role or membership status.
This is why two users with the same status may see different event actions: one may belong to the event team while the other does not.
Choose the right access
- Keep ordinary participants on the User role.
- Keep event organizers on the User role unless they also need section-wide administration.
- Use a membership status that reflects the person's actual relationship with the section.
- Configure participant and organizer eligibility on the event for the audience you intend.
- Reserve Admin for people responsible for section-wide data and settings.
If someone is blocked
Check these items in order:
- Confirm they are signed in to the intended section.
- Check whether their profile is complete.
- Check their section role and membership status.
- Check the event's publication state and participant or organizer eligibility.
- Check whether the action depends on being the event creator, an organizer, or a registered participant.
Tell the user which check is blocking the action. Avoid changing them to Admin merely to bypass an unexplained permissions problem.