User Rights & Role Management
Business Logic and Process Document
1. Purpose
This document defines the business logic for role-based access in the application. It
explains how administrators create roles, define permissions, assign access, and control
which modules and actions users can view or perform.
2. Overview of Access Control System
The application follows a permission-based access control model. Access is never
decided by UI labels or role names alone. It is always enforced using permission codes.
Roles
Business logic
Role is a container of permissions.
Role is stored as a master record with fields like role id, role name, status,
created by, created at.
One user can have multiple roles.
One role can have multiple permissions.
Only users with role management permission can create, edit, or disable roles.
Permissions
Business logic
Permission is a master record with fields like permission id, code, name, module,
description, status.
Permission code is the actual key used for authorization checks.
Permissions control page access, API access, feature visibility, and allowed
actions.
Backend must enforce permissions even if someone bypasses the UI.
Users
Business logic
Users receive access only through roles assigned to them.
During login, the system loads all roles for that user and fetches all permissions
mapped to those roles.
Final permission list is a union of permissions across all roles, with duplicates
removed.
Permissions are stored in session or token for quick access checks.
Menu Visibility
Business logic
Each sidebar menu item has a required permission code.
Frontend renders a menu item only if the user has that permission code.
Hiding menu items is only for UX. Real security is enforced in backend checks.
Important Note
Access level labels or display names may exist for reference only.
Actual authorization is strictly controlled using permission codes.
3. The Author Role
The Author role is a sample role used to give selected users access to author related
modules such as dashboards, content management, and editing features.
Business logic
The Author role by itself does not grant access unless permissions are mapped to
it.
Example: A user with role Author but without AUTHOR_VIEW must not see the
Author dashboard.
3. Creating the Author Role
Steps in UI
Administration → Roles → Create New Role → Enter role name Author → Save
Business logic
Only admins with ROLE_CREATE permission can create roles.
Validate role name is not empty and is unique case insensitive.
Insert role into roles table.
Record audit log entry with created by and timestamp.
4. Assigning Permissions to the Author Role
Steps in UI
Administration → Permissions ensure required permissions exist → Administration →
User Rights → Select Author role → Enable permissions → Save
Business logic
Only admins with ROLE_PERMISSION_MAP_EDIT or USER_RIGHTS_EDIT can
update role permissions.
System must confirm permission codes exist before mapping.
Save mappings in a role permissions table with role id, permission id, enabled
flag, updated by, updated at.
If role permissions are changed, user permissions must refresh either
immediately by invalidating sessions or on next login.
Example mapping logic
AUTHOR_VIEW enables viewing Author dashboard pages and related GET APIs
AUTHOR_EDIT enables create update edit actions and related POST PUT APIs
OADSMR enables dashboard access if the author needs general dashboard entry
5. Assigning the Author Role to Users
Steps in UI
Administration → Users → Select user → Assign role Author → Save
Business logic
Only admins with USER_ROLE_ASSIGN permission can assign roles.
Save mapping in user roles table with user id, role id, assigned by, assigned at.
On login or refresh, user gains union of permissions from assigned roles.
If role is removed, permissions are removed accordingly.
6. How Sidebar Access Works
Business logic flow
1. User logs in
2. System loads assigned roles from user roles mapping
3. System loads all permissions linked to those roles from role permission mapping
4. System builds a final permission code list and stores it in session or token
5. Frontend checks each sidebar item
6. Show menu item only if required permission exists in user permissions
Example logic
If menu requires AUTHOR_VIEW
o user has AUTHOR_VIEW then menu is visible
o user does not have AUTHOR_VIEW then menu is hidden
Backend enforcement
Every protected API and page must validate required permission.
If permission missing return 403 Forbidden with access denied message.
7. Adding New Sections for the Author Role
When new modules are introduced, access must be controlled through permissions.
Business logic
1. Create a new permission code for the feature
Example AUTHOR_REPORTS
2. Map that permission to Author role using User Rights
3. Link the menu item and backend route guard to AUTHOR_REPORTS
4. Default rule is deny by default until permission is assigned
Result
Only users with AUTHOR_REPORTS can see and access the new section
8. Overall Summary
Business logic
Always create permissions first for any new feature.
Assign permissions to roles, not directly to users.
User access is the combined set of permissions from all assigned roles.
Sidebar visibility is permission driven, but backend is the final security gate.
All role and permission changes should be auditable and reviewed periodically