app/Policies), the role → permission seed (PermissionRole::assign_permissions_to_roles), and the screens each role gets in the app.
Table of Contents
- 1. Global use case diagram: actors (with their generalization) and use cases
- 2. How permissions work
- 3. Permissions per role: Super Admin, Admin, Content Manager, Instructor, Student
- 4. Features by role
- 5. Keeping this page in sync
1. Global use case diagram
1.1 Actors
The actors and their generalization (UML inheritance: the hollow arrow points to the parent, and a child actor can do every use case of its parent). The four company roles are a Signed-in user, so they all get the My account use cases. The Super Admin is an Admin of every company, plus the platform use cases.1.2 Use cases
Actors are on the left, outside systems on the right; each arrow is one use case the actor performs. Inherited use cases (§1.1) are not drawn again: the My account ones belong to every signed-in role, and the Super Admin also has every use case of the Admin.The Admin reaches See my dashboard and sales for any instructor of the company (the “preview instructor” screen). The Super Admin inherits the Admin’s use cases (§1.1). Their own app screens are the Platform administration box plus impersonation, analytics and export; for the rest of a company’s work they go through the API or Sign in as a user.
2. How permissions work
The platform has five roles, stored inusers.role_id:
Each policy check runs in this order:
1
Super Admin
Passes every policy, in every company. The company check (
company_policy_middleware) lets them read and write another company’s data.2
Admin
Passes every policy, inside their own company. A request that names another
company_id is refused with 403.3
Content Manager, Instructor, Student
Pass only when their role holds the matching permission for their company in the
permission_role table. These rows are written when a company is created (CompanyObserver → PermissionRole::assign_permissions_to_roles), and the Super Admin can change them per company on the Roles & Permissions screen.
Two checks are open to every signed-in user: opening a training’s detail page, and listing or generating certificates.
There are 120 permissions in the
permissions table (ids 1 to 136, with gaps): nine actions for most resources (*_VIEWANY, *_CREATE, *_VIEW, *_UPDATE, *_ARCHIVE, *_UNARCHIVE, *_DELETE, *_RESTORE, *_FORCE_DELETE), plus a few special ones (certificate settings, training export, instructor dashboard, landing page). Roles and permissions themselves are only listed, read, updated, and (for roles) given their permission set: the archive / delete actions exist in the table but no endpoint uses them, so the tables mark them ·. See Roles for the endpoints and Archive, delete & restore for what each action does to a row.
3. Permissions per role
Legend: ✅ allowed · — not allowed · · the action doesn’t exist for that resource. The Content Manager, Instructor and Student tables show the default permissions a new company starts with. A Super Admin may have changed them for a given company.3.1 Super Admin
Runs the whole platform: companies, their admins, and the role permissions of every company.
Scope: every company. Super Admins are left out of the standard user lists.
3.2 Admin
Runs one company: its users, catalog, sales, discounts, notifications and platform settings.
Scope: their own company only. An Admin reads and edits their own company; creating, archiving and deleting companies is the Super Admin’s job, and the role → permission matrix is edited on the Super Admin’s Roles & Permissions screen.
3.3 Content Manager
Builds and organizes the catalog: trainings, quizzes and exams, categories and tags, classrooms.
Scope: their own company. No Restore or Force delete by default: bringing back or permanently removing a deleted row is left to the Admin.
3.4 Instructor
Teaches: writes trainings, quizzes and exams, runs classrooms and their chatrooms, and follows their own sales.
Scope: their own company. The dashboard and sales pages only show the instructor’s own figures. The default set is the Content Manager’s, minus Edit the certificate settings, plus Open the instructor dashboard.
The Instructor and Content Manager defaults are wider than their screens: the app shows neither role a user, order, coupon or voucher list. When you want a role to match its screens exactly, untick the extra permissions for that company on the Super Admin’s Roles & Permissions screen.
3.5 Student
Learns: browses and buys trainings and exams, studies, takes quizzes and exams, and earns certificates.
¹ Open to every signed-in user, not a seeded permission. ² Only their own record (see §2).
Scope: their own company’s catalog. A student applies coupons and redeems vouchers from the cart; they never see the coupon or voucher lists.
4. Features by role
Some features are not tied to apermissions row: the role itself decides, in the controller or through the screens the app gives that role. This matrix is the quick view.
³ The chatroom rules let a Content Manager manage the chatrooms of their company, but the Content Manager app has no chatroom screen yet.
For the chatroom roles inside one room (
instructor, learner, admin), see Chatrooms.
5. Keeping this page in sync
Update this page when the backend changes one of these:app/Models/PermissionRole.php(the default permission set per role) → the §3 tablesapp/Models/Permission.php(a permission added or removed) → §2 and §3app/Policies/*(a role bypass or an ownership rule) → §2 and §3- a role-only check in a controller or service, or a new screen in a role’s app → §1 and §4
Role, Permission, PermissionRole) and User roles.