How User Permissions and Access Control Works

Source: autosoft-workshop/app/controllers/application_controller.rb, users_controller.rb, groups_controller.rb

Permission checks happen at the controller level: system looks up the user's group_name against the GroupRightType table for the requested controller
Controllers NOT listed in the GroupRightType table are implicitly accessible to everyone — missing entries grant access, not deny it
Certain routes are whitelisted and always accessible regardless of permissions: companies-show, reports-jasper_invoice, and others
Superuser, Admin, and Demo status are validated as separate gates before group-level permission checks
Only admin users can update company settings, toggle flat rate pricing, or change Azure SSO configuration
The system prevents deactivating or demoting the last remaining admin — at least one admin must always exist
The system prevents deleting the last admin or the last user in the company
User destroy is a soft delete if the user has existing sessions (preserves audit trail); hard delete only if no sessions exist
Only superusers can create and manage permission groups — regular admins cannot modify group definitions
Mobile users are hardcoded to the USER permission group with dashboard set to F (false) — no way to change this from the mobile app

"My employee can access something they shouldn't" → that controller may not be in the GroupRightType table, making it open to everyone by default
"I can't remove admin from this user" → they're the last admin; promote someone else first
"Can't delete a user" → user has session history so they're soft-deleted (deactivated) instead; or they're the last user/admin
"Mobile user can't see the dashboard" → mobile users are hardcoded to dashboard=F, this cannot be changed
"Who can change permission groups?" → only superusers, not regular admins