roles-permissions

First check whether an existing gate covers the need, such as CheckRole middleware, callerCanAccessFamily, or StaffRolePermissions. If a new gate is required, filter roles by slug, add whereNotNull('accepted_at') for school-context roles, and return a generic refusal message with a logged warning.

A user_roles table stores role_id, user_id, and a polymorphic roleable context of school, family, or classroom. One user can hold multiple roles simultaneously in different contexts, such as admin of one school and responsible of a family.

Always filter by slug in backend queries using whereHas on the role relation. French display names are only for UI labels, so renaming a role's name breaks nothing while changing a slug requires updates across seeders, middleware, and front-end utilities.

The membership invitation has not been accepted yet, so accepted_at is null and the school only sees the email with a pending badge. The user must accept via the set-password link or the in-app invitation banner before their name becomes visible.

The front end stores all role slugs in localStorage but computes every permission from a single active role chosen in the account menu. Use hasAnyRole with readActiveSchoolRoles from the schoolRoles utility module rather than the legacy singular key.

The is_super_admin attribute is derived by checking whether the user's email appears in the SUPER_ADMIN_EMAILS environment variable loaded through config. In production the config is cached, so changes require a config:cache run or container restart to take effect.