Roles Frontend

User Roles - Frontend Implementation Guide

1. Overview

This document outlines the frontend implementation details for user roles within the Nimbly platform. It covers how roles, permissions, and access controls should be implemented across the various frontend applications and interfaces.

2. User Role Hierarchy

The Nimbly platform implements a hierarchical user role system. Each role has specific permissions and access levels across different platform components:

graph TD
    A[Account Holder] --> B[Admin]
    A --> C[LMS Admin]
    B --> D[Supervisor]
    D --> E[Auditor]
    C --> F[Instructor]
    C --> G[Learner]

3. Role Definitions and Details

Each role has specific access rights and platform availability:

Role	Primary Functions	Access Links
Account Holder	Organization-wide management, full platform access	[Admin Web App, Mobile Apps, LMS]
Admin	Platform-wide content management, user administration	[Admin Web App, Mobile Apps]
LMS Admin	Learning content creation and management	[Admin Web App (LMS Module)]
Supervisor	Site-specific management, auditor oversight	[Admin Web App (Limited), Mobile Apps]
Auditor	Field audits and inspections	[Mobile Apps only]
Learner	Consuming educational content	[LMS Web Interface]

For detailed information about each role, click on the role name to view its dedicated documentation.

4. Permissions Matrix

The following table outlines feature access across different user roles:

Feature	Account Holder	Admin	LMS Admin	Supervisor	Auditor	Learner
Dashboard	Full	Full	Full	Limited	No Access	No Access
Reports Hub	Full	Full	Full	Limited	No Access	No Access
Issue Tracker	Full	Full	Full	Limited	Full	No Access
Gallery	Full	Full	Full	Limited	Full	No Access
File Repository	Full	Full	Full	Limited	Full	No Access
User Management	Full	Full	LMS Users	Auditors	No Access	No Access
LMS Content	Full	No Access	Full	No Access	No Access	View Only

5. Platform Specifics

5.1. Admin Web Application

• Responsive Design: The web application should be responsive and accessible on all device types
• Role-Based UI: Interface elements should dynamically adapt based on user role
• Permission Checks: Implement permission validation for all actions and UI elements

// Example permission check implementation
const hasPermission = (
  resource: string,
  action: "view" | "edit" | "delete"
): boolean => {
  const { userRole, permissions } = useUserContext();
  return permissions.some(
    (p) => p.resource === resource && p.actions.includes(action)
  );
};

5.2. Mobile Applications

• Platform: Available on iOS and Android
• Offline Support: Critical features must work offline
• Role Restriction: Some roles (Auditor) exclusively use mobile apps
• Responsive Design: Must support various screen sizes

5.3. LMS Interface

• Web-Based: Accessible through browser only, no dedicated mobile app
• Responsive: Must work on all device types
• Role Separation: Clear separation between content creators (LMS Admin) and consumers (Learners)

6. Implementation Guidelines

6.1. Permission Checking

Frontend applications should implement consistent permission checking:

// Component with permission check example
const EditButton = ({ resourceId }: { resourceId: string }) => {
  if (!hasPermission(`resource:${resourceId}`, "edit")) {
    return null;
  }
 
  return <Button onClick={handleEdit}>Edit</Button>;
};

6.2. Navigation Control

Menu items and navigation elements should be conditionally rendered based on role:

// Navigation handling example
const mainNavItems = [
  {
    path: "/dashboard",
    label: "Dashboard",
    roles: ["account_holder", "admin", "lms_admin", "supervisor"],
  },
  {
    path: "/lms",
    label: "Learning",
    roles: ["account_holder", "lms_admin", "learner"],
  },
  // More navigation items...
];
 
const NavMenu = () => {
  const { role } = useUserContext();
 
  return (
    <nav>
      {mainNavItems
        .filter((item) => item.roles.includes(role))
        .map((item) => (
          <NavLink key={item.path} to={item.path}>
            {item.label}
          </NavLink>
        ))}
    </nav>
  );
};

6.3. Error Handling

Implement appropriate error handling for unauthorized actions:

// Error handling for unauthorized access
const handleUnauthorizedAction = () => {
  toast.error("You do not have permission to perform this action");
  // Optionally log the attempt
};

7. Related Documentation

• User Roles - General overview of the role system
• Backend Implementation - Backend architecture for roles

---

role #connects/platform #connects/feature