Service Layer medium complexity Shared Component mobile
1
Dependencies
2
Dependents
3
Entities
0
Integrations

Description

Evaluates whether the current active role is authorized to access a specific screen, action, or data set. Used by route guards, UI conditional builders, and service layers to enforce access control at all levels.

Feature: Role-Based Access Control

permission-checker

Summaries

The Permission Checker Service is a foundational security component that protects the business by ensuring users can only access the features and data they are authorized to view or modify. By enforcing access control consistently across every screen, action, and data set, this component directly reduces the risk of unauthorized data exposure, regulatory non-compliance, and potential liability. As a shared service reused across all features, it eliminates the cost of building access control logic separately per module, reducing development time and the risk of inconsistent enforcement. This component is critical to user trust and the platform's ability to serve multiple distinct user roles with confidence.

The Permission Checker Service is a shared, medium-complexity component that underpins route guards, UI rendering logic, and service-layer operations across the entire mobile application. Because it is consumed by virtually every feature that involves role-based access, it must be completed and stabilized early in the project timeline — delays here will create downstream blockers for all feature teams. Its dependency on the Role State Manager means that component must also be delivered and tested first. Testing requirements include coverage for all role-permission combinations, edge cases such as missing or malformed roles, and regression tests whenever roles or permissions change.

Deployment risk is moderate: any regression in this component can silently break access control across multiple features.

The Permission Checker Service is a shared mobile-context service that acts as the central access control evaluator for the application. It exposes four key interfaces: `canAccess(Role, resource)` for route-level guards, `getPermissionsForRole(Role)` for UI conditional rendering decisions, `isActionAllowed(Role, action)` for service-layer enforcement, and `assertPermission(Role, resource)` for fail-fast validation that throws on unauthorized access. It depends on the Role State Manager as its source of the current active role, keeping permission evaluation stateless and pure beyond that dependency. Implementation should treat permission constants as an enumerated, centrally maintained registry to avoid magic strings.

As a shared component, changes to its interface contract will have wide blast radius — version carefully and ensure backward compatibility when extending.

Responsibilities

  • Check if a given role has permission for a specific action or route
  • Provide permission constants per role for UI conditional rendering
  • Guard service-layer operations against unauthorized role access

Interfaces

canAccess(Role role, String resource)
getPermissionsForRole(Role role)
isActionAllowed(Role role, String action)
assertPermission(Role role, String resource)

Relationships

Dependencies (1)

Components this component depends on

Dependents (2)

Components that depend on this component

Related Data Entities (3)

Data entities managed by this component

API Contract

View full contract →
REST /api/v1/permissions 5 endpoints
GET /api/v1/permissions List all permissions for all roles
GET /api/v1/permissions/:permissionId Get permissions for a specific role-resource pair
POST /api/v1/permissions Create a role-resource permission rule
PUT /api/v1/permissions/:permissionId Update allowed/denied actions for a permission rule
DELETE /api/v1/permissions/:permissionId Remove a permission rule