Users & Permissions

This chapter covers everything about who can sign in to the app and what they can do once they’re in. Four built-in roles, a fine-grained permissions matrix, an Activity Log that tracks who changed what.

The four roles

Every user has exactly one role. Roles are templates of default permissions — you can override per-role from Access Control.

Role	Typical user	Default access
Admin	Owner, head of center	Everything. Full control.
Moderator	Office manager, branch lead	Everything except user management.
Teacher	Teaching staff	View academic data, take attendance, manage schedule for own groups.
Staff	Front desk, receptionist	View academic data, create bookings, see schedule (read-only).

You can’t add a new role from the UI — the four are wired into the app. But you can change what each role can and can’t do via the permissions matrix.

Inviting a new user

Users → New user (top right). Fill in:

1. Name — shown in the header dropdown and on activity log entries.
2. Email — the login identity. Must be unique per tenant.
3. Role — pick one of the four. Can be changed later.
4. Initial password — set one now, the user changes it on first login.
5. Active — toggle off to create the user but block sign-in.

Click Create. The user can sign in immediately with the email and initial password you set.

No email invite yet

EduBook doesn’t send an invitation email automatically — share credentials directly with your staff. A “send invite link” mode is on the v1.5+ roadmap.

Changing a user’s role

Open the user row → Edit → change the role dropdown → save. Effect is immediate; if the user is signed in, their next page navigation reflects the new permissions.

Avoid changing your own role to a non-admin — you’ll lose the ability to change it back. The app warns you, but only the last remaining admin can re-promote you.

Resetting a user’s password

Two paths:

As an admin (force reset)

User row → Reset password → set a new one. The user uses the new password on next login. No email is sent.

As the user (forgot password)

The login screen has a Forgot password? link. Sends a reset email — the user clicks the link and sets a new password without admin involvement.

Forgot-password emails require SMTP to be configured. Without SMTP, users can’t self-reset.

Disabling vs deleting

• Disable (active toggle off) — preserves the user record and activity-log entries. Re-enable any time. Use when staff leave temporarily or you need to revoke access in a hurry.
• Delete — permanently removes the user. Activity entries authored by them stay (with their email, not name).

When in doubt, disable. Disabled users don’t count against your plan’s max-users quota.

The Access Control page (permissions matrix)

Settings → Access Control (admin only). A grid: rows are permissions (grouped by category), columns are roles. Tick to grant; untick to revoke. Save at the top.

Categories:

• Core — dashboard view.
• Academic — teachers, subjects, groups, students, semesters, grade ladder. Each entity has separate view / create / edit / delete keys.
• Bookings — bookings, booking codes, booking requests (with their own approve/reject keys).
• Attendance — attendance + schedule, both view and manage keys.
• Exams — view, create, edit, delete, publish, grade.
• Memberships — view, create, edit, assign, sell.
• Inventory — view, create, edit, delete, sell (Pro+).
• Users — view, create, edit, delete users.
• System — branches, commissions (settle/edit/delete), billing, integrations, settings, tenant administration, and the Access Control page itself.

Actions you’ll see across categories: view, create, edit, delete, plus feature-specific ones like approve, reject, publish, grade, assign, sell, settle, and manage.

Access control gate

page.access_control.manage is the permission that gates this page itself. Whoever has it can change everyone else’s permissions. By default only Admin and the Owner role have it.

When a permission changes mid-session

The permission cache refreshes when the user navigates between pages. So if you remove bookings.delete from Staff while a staff member is on the Bookings page, the next page they click reflects the change. They won’t be kicked out, just silently restricted.

The exception: toggling a user’s Active off forces a sign-out within ~30 seconds.

The Activity Log

Activity in the sidebar. A reverse-chronological feed of significant actions:

• Bookings (created, approved, rejected, cancelled)
• Subscriptions (created, transferred, cancelled)
• Lesson overrides (cancel, reschedule, undo)
• User management (role changes, password resets, disable/delete)
• Subject / group / teacher edits
• Login events (sign-in, sign-out, failed-login)

Each row shows: who, what, when, plus a context snippet. Filter by actor or action type. Click a row to drill into the affected entity.

The log is read-only — no one can edit or delete entries, even admins. The audit trail is the audit trail.

Common questions

A teacher can see students in groups they don’t teach. Correct — the current default is “view all academic data”. Per-group teacher visibility is on the v1.5 roadmap. Workaround: tighten the role’s students.view permission, or create per-teacher staff accounts.

Two admins, one demoted the other accidentally. Re-promote — open the user, change role back to Admin. If you removed your own admin role and you’re the only admin, contact support — manual recovery requires verifying tenant ownership.

My moderator can’t see Settings → Access Control. Correct — managing access control is admin-only by default. Grant page.access_control.manage to Moderator from the matrix if you trust them with role changes.