Access Control Model

Related Documentation

This document explains the technical implementation of the permission system. For practical guidance on creating roles and assigning permissions, see Roles & Permissions.

How Permissions Work

Permission Checking

When a user tries to access a feature, PteroCA checks if they have the required permission:

1. User requests access to a feature (e.g., clicks "Users" menu item)

2. System retrieves user's roles from the database

3. System collects all permissions from all assigned roles

4. System checks if any permission matches what's required

5. Access granted or denied based on the check

Menu Visibility

The admin menu automatically adapts to show only items the user can access:

• Menu items are hidden if the user lacks the required permission

• Submenus use OR-logic: A submenu is visible if the user has ANY child permission

  • Example: "Shop" submenu appears if user has access_categories OR access_products

• Empty submenus are hidden completely

This provides a clean interface showing only relevant options.

Multi-layer Security

Permissions are enforced at multiple levels:

1. Menu Level: Items hidden if user lacks permission

2. Controller Level: Access denied even if user knows the URL

3. Service Level: Business logic validates permissions

4. Database Level: Foreign key constraints prevent unauthorized data changes

You Cannot Bypass Permissions

Even if you know the direct URL to a page, you cannot access it without the required permission. The system checks permissions at every level, not just in the menu.

---

Related Documentation

• Roles & Permissions Guide - Practical guide for creating and managing roles

• Access Control Overview - Introduction to the access control system

• Core Configuration - System settings (requires appropriate permissions)