Staff management

1. Overview

This document outlines the requirements for staff management for partner portal that manages multiple branches and user roles with varying permissions.

Platform :

• Admin Dashboard Setting

2. Role Definitions

2.1 Admin Role (Owner)

• Superadmin level.
• Can manage all system settings.
• Can create, modify, and delete users and roles.
  • First Name
  • Last Name
  • Email
  • Password
  • Confirm Password
• Can assign and modify permissions for other roles.
• Can delete other Admins and Staff under specific conditions (detailed in 4.1 Deletion Rules).
• Can add a custom role and save it.
• Can edit the existing staff role and make it as default.

2.2 Staff Role

• Default role for non-admin users.
• Permissions include Read, View, Delete access per feature.
• Customizable permissions based on Admin settings.
• Cannot delete or edit Admins.
• Can edit other staff roles if customization is allowed.

2.3 Temporary Staff Role (HH internal purposes)

• Identical to Admin in terms of permissions and capabilities.

3. Role and Permission Settings

• Role management should be done on a dedicated page (not via pop-up).
• Each role should have a table defining Read, View, Delete permissions per feature.
• Staff role permissions should be configurable by Admin.
• Default roles (Admin, Staff, Temporary Staff) should be pre-defined.

4. Role Deletion Rules

4.1 Admin Role Deletion

• Admin can delete other Admins and Staff.
• An Admin cannot be deleted if there is the only 1 Admin left.
• Error handling must prevent deletion of the last Admin.

4.2 Staff Role Deletion

• Staff cannot delete or edit Admin roles.
• Staff role customization should include an option to allow/disallow editing of other staff roles.

5. Login Types and Branch Management

Users must select whether they are logging in as Individual or Group on the login page.

5.1 Individual Login

• Users logging in under Individual Login can manage only a specific branch.
• Example :
  • Staff A has access to 2 restaurants (Restaurant A and Restaurant B)
    • Staff A can login (using Individual Login) into restaurant A and can manage restaurant A, but can't manage restaurant B at the same time (individual login behavior).
    • Staff A can login (using Individual Login) into restaurant B and can manage restaurant B, but can't manage restaurant A at the same time (individual login behavior).

5.2 Group Login

• Users logging in under Group Login can manage all branches.
• Only Admins can assign users to multiple branches.
• Example :
  • Staff A has access to a restaurant group Z that contains Restaurant A and Restaurant B
    • Staff A can login (using Group Login) into restaurant group Z and manage all of the restaurant branches, those are Restaurant A and Restaurant B at the same time (Group login behavior).

6. Role Assignment per Branch

• Admin can assign roles to one or all branches.
• Role assignment should follow these rules:
  • Individual Login Role: Can access specific branches (one or more selected branches).
  • Group Login Role: Must have all branches selected.
  • Users can log in under multiple Individual Logins but cannot log into Group Login if assigned to only some branches.

7. System Validation and Error Handling

• Prevent last Admin from being deleted.
• Prevent Staff from modifying Admin roles.
• Ensure correct role assignment logic when assigning user to branches.

8. UI/UX Considerations

• Dedicated page for role and permission management.
• Clear distinction between Individual and Group login options.
• Role assignment interface should allow multi-selection of branches where applicable.
• Proper validation and error messages when role constraints are violated.

9. Future Enhancements (Optional Considerations)

• Audit logs to track role changes (history changes?).

Example

Admin

By default, admin has the superadmin role.

Suggestions for Implementation

1. Role-Based Filtering: Implement role-based filtering in the UI to ensure users only see actions they are allowed to perform.
2. Granular Permissions: If needed, allow different access levels per role (e.g., Admin can update Profile, Staff can only read).
3. Custom Roles: If staff roles can be customized, allow toggling permissions dynamically based on the above template.

Staff (Default)

The only difference for staff is access right, they only have read access for this. but doable if want to customize the access (by admin)