User management
Information about user and role management
Introduction
The user management system controls access and permissions within the platform through three interconnected components:
- Users - Individual accounts requiring system access 
- Roles - Collections of permissions defining system capabilities 
- Permissions - Specific actions and system access rights 
The system operates on a role-based access control (RBAC) model where users receive permissions through role assignments rather than direct permission grants.
Core concepts
Users, roles, and permissions
Users represent individual accounts within the system requiring access to platform functionality.
Roles define collections of permissions that correspond to specific job functions or responsibility levels. Common role examples include:
- Supervisor 
- Fulfiller 
- Administrator 
- Read-Only Viewer 
Permissions specify individual actions that can be performed within the system, such as:
- Edit users 
- Create orders 
- View analytical data 
- Modify facility settings 
Permission assignment model
User → assigned → Role → contains → Permissions → allow access to → System FunctionsIf users with a certain role should have access to one of the following Backoffice views, the permission REMOTE_CONFIG_READ is required:
Context limitations
General
Context limitations restrict the scope of permission application within the system. When a user possesses a specific permission, context limitations define the subset of entities to which that permission applies.
Example: A user with "Edit Facilities" permission and a facility context limitation for the North Region can only edit facilities within that specific region.
Available context types
Facility context
- Restricts access to entities associated with specified facilities 
- Example: "Edit Pickjob" permission combined with Facility context for "Facility A" limits editing to pick jobs associated with Facility A exclusively 
Facility group context
- Restricts access to entities linked to specific facility groups rather than individual facilities. 
- If both Facility and Facility Group contexts are applied, access is granted when the facility belongs to either context (logical OR). 
- Example: The “Edit Pickjob” permission with a Facility Group Context for Facility Group A allows editing only for pick jobs associated with facilities within Facility Group A. 
User Role context
- Restricts user management capabilities to specified roles 
- Limits both the users that can be managed (based on their role assignments) and the roles that can be assigned to other users 
- Example: "Assign Roles" permission with User Role context for "Manager, Supervisor" restricts user management to users possessing Manager or Supervisor roles and limits role assignments to those same roles 
Context limitation implementation: Role versus user level
Context limitations can be implemented at two distinct levels within the system:
Role-level context limitation
When context limitations are defined at the role level, all users assigned to that role inherit identical limitations.
Example:
- Role: "Regional Manager" 
- Facility Context: Restricted to "North Region Facilities" 
- Result: All users assigned the Regional Manager role can access North Region facilities exclusively 
User-level context limitation
When a role contains no predefined context limitation of a given type, specific limitations of that type can be applied during individual user role assignments.
Example:
- Role: "Facility Manager" (no predefined facility context limitations) 
- User Assignment for John: Facility context restricted to "Facility A" 
- User Assignment for Sarah: Facility context restricted to "Facility B" 
- Result: John manages Facility A exclusively, Sarah manages Facility B exclusively 
Implementation rules
- Roles with defined context limitations apply those limitations to all assigned users 
- Roles without context limitations allow for customized limitations during user assignment 
- Role-level context limitations cannot be overridden at the user assignment level 
- Context limitations defined at role assignment apply only to that specific user 
Multiple role assignments
Users can be assigned multiple roles simultaneously. Each role maintains its context limitations independently, creating flexible permission structures.
Multiple Role Example
A user assigned two roles:
- "Pick Job Viewer" (no context limitations) → grants pick job viewing across all facilities 
- "Pick Job Editor" with Facility context limited to "Facility A" → grants pick job editing for Facility A exclusively 
Resulting Access: The user can view pick jobs from all facilities but can edit pick jobs in Facility A only.
Multiple role behavior
- Each role preserves its individual context limitations 
- User permissions represent the union of all assigned role permissions 
- Context limitations apply individually to each role's permission set 
- This enables sophisticated access patterns such as unrestricted read access with restricted modification rights 
Example
In the example below, the user is assigned two roles "Pick Job Viewer" and "Pick Job Editor". Additionally, each role assignment has context limitations. Thus, the user can view & edit pick jobs in facility B but only view pick jobs in facility A.

User management operations
User creation
Required Permission: USER_WRITE
Creation requirements:
- Username must be unique across the system 
- Special characters undergo automatic conversion (ö → oe, ß → ss) 
- Password minimum length: 6 characters 
- Primary language assignment is optional 
User modification and deletion
Required Permission: USER_MODIFY
Modification Capabilities:
- Role assignment changes 
- User account property updates 
- Permission revocation through role removal 
Automatic System Responses:
- Edited Users face immediate session termination, if their password or roles were changed 
- Active tasks (such as pick jobs) are reset and returned to the available task pool 
Deletion Rules:
- Users with appropriate permissions can delete other user accounts 
Role assignment operations
Required Permission: USER_MODIFY (not restricted to administrators)
Assignment Constraints:
- Role assignments must comply with the assigning user's context limitations 
- Assigned users cannot receive broader access than the assigning user possesses 
- Facility context example: Users limited to "Facility A" can only assign roles with "Facility A" limitation or more restrictive access 
Role management operations
Custom role creation
Required permission: ROLE_WRITE
Role categories:
- Preconfigured roles: System-defined roles with fixed permissions (modification and deletion prohibited) 
- Custom roles: Administrator-defined roles with configurable permission sets 
Role management rules:
- Role names must be unique system-wide 
- Permission modifications take immediate effect for all users assigned to the role (propagation may require up to 5 minutes) 
- Role deletion is permitted only when no users are currently assigned to the role 
Role configuration best practices
- Begin with minimal required permissions 
- Test custom roles with limited user assignments before broader deployment 
- Implement descriptive naming conventions indicating role purpose 
- Maintain documentation for custom role use cases and intended applications 
Security and privilege escalation prevention
Context inheritance rule
Role assignments must maintain or increase restriction levels relative to the assigning user's context limitations.
Permitted Operations:
- User with "Facility A, Facility B" access assigns role with "Facility A, Facility B" or "Facility A" limitation 
Prohibited Operations:
- User with "Facility A" access assigns role without facility limitations or with broader facility access 
USER_MODIFY permission security considerations
The USER_MODIFY permission grants extensive role assignment capabilities, including administrator-level role assignments.
Recommended security measures:
- Implement User Role context limitations on roles containing USER_MODIFY permission 
- Define specific assignable roles through context limitations 
- Exclude administrator roles from assignable role lists when appropriate 
Security implementation example:
- Role: "Human Resources Manager" 
- Permissions: Includes USER_MODIFY 
- User Role Context: Limited to "Employee, Supervisor, Team Lead" 
- Security Result: User management capabilities without administrator creation privileges 
System reference
Permission Hierarchy Structure
System Functions
    ↑ (access controlled by)
Permissions
    ↑ (organized within)
Roles
    ↑ (assigned to)
UsersContext Limitation Processing Flow
Role Definition → Context Limitation Status Assessment
    ↓ No limitations: Individual user assignment customization available
    ↓ Limitations defined: Applied uniformly to all role assignments
User Role Assignment → Context Application
    ↓
Permission Activation → Within Defined Context BoundariesCommon issue resolution
Insufficient Access Despite Appropriate Permissions
- Verify context limitations - permissions may exist but apply to different entity subsets 
Role Assignment Failures
- Confirm context limitations match inheritance requirements 
- Verify possession of USER_MODIFY permission 
- Check User Role context limitations for target role inclusion 
Role Permission Changes Not Effective
- Allow up to 5 minutes for system-wide permission propagation 
- Consider user session refresh requirements for certain permission types 
System summary
The user management system provides comprehensive access control through:
- Role-based permission grouping for organized access management 
- Context limitation framework for granular access restriction 
- Flexible assignment options enabling role customization per user 
- Multiple role support facilitating complex permission requirements 
- Security enforcement mechanisms preventing unauthorized privilege escalation 
These components combine to create a robust access control system capable of supporting diverse organizational security requirements while maintaining operational flexibility.
The user management enables the allocation of roles to users, thereby facilitating the control of permissions for various actions and access within the platform. Users have the option of either using preconfigured roles with static rights or creating custom roles with individual rights.
Last updated
