Granular access, tenant-scoped,end to end
Edushade ships 295 permissions out of the box, organised into 55 functional groups — every feature on the platform has its own permission set, and every API endpoint and every menu item is gated by the same RBAC engine. Build tenant-defined roles, clone an existing role to template a new one, assign roles to users or pin a single permission to a single user, and the access surface stays consistent everywhere.
A real RBAC system, not a checkbox
Roles, Permissions and the user-permission override pivot all live on the auth-service. A `middlewares.Can(name, pp)` guard wraps every protected route across every microservice — auth, learning, engagement, billing, booking, notification, website, tenant. The admin sidebar reads from the same engine to decide which menu items render. One source of truth, defended both at the menu and at the endpoint.
295 Permissions, 55 Groups
Every feature ships with its own permission group — user, rbac, role, course, lesson, assignment, cohort, event, quiz, review, billing, website (41 perms alone), e-commerce, audit and more. New features ship new groups.
Tenant-Defined Roles
Roles live per tenant — name, label, description, status (active / inactive), guard (web / API). Every tenant builds the role set that matches their org without seeing other tenants' roles.
Role Cloning for Templating
Clone any role to template a new one — the platform copies the permission set, you adjust, you save. Useful for spinning up a TA role from an instructor template, or a moderator from an admin.
Per-User Permission Overrides
The user_permissions pivot lets you grant or revoke a single permission to a single user without touching their role — one-off elevations, one-off reductions, no schema bending.
Defense in Depth
Every API endpoint is wrapped in middlewares.Can(permission_name, pp). The admin sidebar's requireRoles + requirePermissions hides items the user cannot use. The same permission name guards both — change one, the other follows.
Multi-Tenant by Default
Every roles row, every role_permissions row, every user_roles row carries a tenant_id. Hard isolation at the database level — no tenant ever sees another tenant's roles, even by accident.
Permissions that mirror every feature on the platform
The auth-service ships permissions.json with 55 groups and 295 permissions, and the seeder loads them on every fresh install. The groups read like a feature catalog — user, rbac, role, permission, tenant, organization, invitation, settings, file, notification, campaign, template, segment, notice, audit, dashboard, analytics, course, curriculum, lesson, assignment, cohort, breakpoint, holiday, grading, drip_schedule, access_rule, admin, event, speaker, quiz, discussion, comment, review, reaction, engagement, certificate, category, tag, learning_path, enrollment, entity, meeting_plan, schedule, price, purchase, bundle, subscription_plan, installment_plan, scholarship, offer, ecommerce, website, migration. Each carries a label and a description, surfaced in the admin permission picker.
55 permission groups, one per feature area
295 individual permissions out of the box
Each permission carries a name, label, description and group
Web and API guards on each — same name, two contexts
Roles that fit your organization, not the platform's defaults
Roles are tenant-defined. Each role has a name, a guard (web by default), a status (active or inactive), a permission set and a list of users assigned to it. The platform ships six bootstrap roles to seed (super_admin, admin, user_manager, developer, moderator, auditor) but the real role design happens per tenant — instructor, lead instructor, teaching assistant, content reviewer, billing operator, support agent — whatever the org actually runs. Clone a role to template the next one, and every change is auditable.
Per-tenant roles — name, label, description, status, guard
Bootstrap seeds: super_admin, admin, user_manager, developer, moderator, auditor
Clone an existing role to template a new variant in one call
Soft delete preserves the role even after retirement
Two ways to grant — role-level and user-level
Edushade resolves access in two layers. role_permissions ties a permission to a role; user_roles ties a role to a user; the union of those is the role-based grant. user_permissions is the override layer — pin a single permission to a single user without changing their role. The admin RBAC API exposes both: POST /rbac/roles/:roleID/permissions/:permissionID for role-level, POST /rbac/users/:userID/permissions/:permissionID for user-level. The middleware checks both layers when deciding access.
role_permissions: many-to-many between roles and permissions
user_roles: many-to-many between users and roles
user_permissions: per-user grant on top of role-based access
Same admin API: POST and DELETE for every assignment surface
RBAC that hides what you cannot use, not just blocks it
The admin sidebar config carries `requireRoles` and `requirePermissions` per item. Every microservice wraps every protected route in `middlewares.Can(permission_name, pp)`. The two layers share the same permission names, so a user without `notice.manage` cannot see Communication → Noticeboard in their menu and also cannot hit the noticeboard API. Nothing is greyed out for show — items that do not apply simply do not render. Defense in depth, with one source of truth.
Admin sidebar items hide when the user lacks the role + permission
Every microservice route is wrapped in middlewares.Can(name, pp)
Same permission name gates both menu and API — no drift
Audit logs capture every privileged role and permission change
From bootstrap roles to a tenant-shaped access model
The Roles & Permissions builder lives at /admin/users/roles. Clone, edit, assign — every step audits, every change propagates to the menu and to the APIs immediately.
Pick a bootstrap role or clone one
Open Admin → Platform → People → Roles & Permissions. Use one of the seeded roles (admin, user_manager, developer, moderator, auditor) as a starting point, or clone the closest match to template a new one.
Tune the permission set
Open the role detail. The permission tree groups all 295 permissions by feature area. Toggle individually, toggle a whole group, or use the search to find a specific permission name. Save — the role is live.
Assign the role and add overrides
Pick users from People and assign the role. For one-offs, open a single user and grant a per-user permission on top — no role change required. The admin sidebar updates the moment the assignment lands; APIs accept the new access immediately.
Role Permissions FAQ
How permissions, roles, overrides and the RBAC engine work inside Edushade.
Can't find what you're looking for?
Contact Sales
Start Building Learning Your Way
Set up courses, programs, and learning experiences without forcing your process into rigid software. A connected system for students, educators, and administrators.
Build Your Academy