Skip to main content
The User Role system controls access to admin features, content management, and sensitive operations across the CAFH Platform.

​
Role Hierarchy

The platform uses a tiered role system (types.ts:14-20): 
export enum UserRole {
  SUPER_ADMIN = 'SUPER_ADMIN',
  ADMIN = 'ADMIN',
  EDITOR = 'EDITOR',
  MEMBER = 'MEMBER',
  GUEST = 'GUEST'
}

​
Role Permissions

Full platform access✅ All CMS operations (create, edit, delete)✅ All CRM operations including bulk actions✅ User management (create, edit roles, delete)✅ Site settings and configuration✅ SMTP and integration settings✅ View all analytics and reports✅ Access change logs and audit trails✅ Execute automation workflows

​
User Structure

User accounts include role assignment (types.ts:22-36): 
export interface User {
  id: string;
  name: string;
  email: string;
  role: UserRole;
  avatarUrl: string;
  tenantId: string;
  interests: string[];
  joinedDate: string;
  coverUrl?: string;
  phone?: string;
  city?: string;
}

​
Admin User Management

Admin-specific user data (types.ts:585-593): 
export interface AdminUser {
  id: string;
  name: string;
  email: string;
  role: UserRole;
  isActive: boolean;
  lastLogin?: string;
  createdAt: string;
}

​
Creating Admin Users

1

Access User Management

Navigate to Settings → Users (SUPER_ADMIN only)
2

Click Add User

Open the new user creation form
3

Enter Details

  • Full name
  • Email address (must be unique)
  • Assign role from dropdown
4

Set Password

Generate secure password or let user set on first login
5

Save

User is created and can log in immediately
Only SUPER_ADMIN users can create other admin accounts. This prevents privilege escalation.

​
Authentication System

The platform uses a simple authentication system (storage.ts:303-348):

​
Login Function

db.auth.login(email, password)
// Returns User object if successful, null if failed

​
Default Accounts

For development/demo: 
// Admin account
email: '[email protected]'
password: 'admin123'
role: SUPER_ADMIN

// Member account
email: '[email protected]'
password: 'miembro123'
role: MEMBER
Change default passwords immediately in production. Use strong, unique passwords for all admin accounts.

​
Role-Based UI

The interface adapts based on user role:

​
Admin Panel Visibility

{user.role === UserRole.SUPER_ADMIN || user.role === UserRole.ADMIN ? (
  <AdminPanel />
) : null}

​
Feature Gating

{user.role === UserRole.SUPER_ADMIN && (
  <button onClick={deleteSensitiveData}>
    Delete System Data
  </button>
)}

​
CRM Access Check

const canAccessCRM = [UserRole.SUPER_ADMIN, UserRole.ADMIN].includes(user.role);

if (canAccessCRM) {
  // Show CRM features
}

​
Permission Checking

Implement permission checks before sensitive operations: 
const hasPermission = (user, requiredRole) => {
  const hierarchy = {
    GUEST: 0,
    MEMBER: 1,
    EDITOR: 2,
    ADMIN: 3,
    SUPER_ADMIN: 4
  };
  
  return hierarchy[user.role] >= hierarchy[requiredRole];
};

// Usage
if (hasPermission(currentUser, 'ADMIN')) {
  // Execute admin operation
} else {
  alert('Insufficient permissions');
}

​
Contact System Roles

Contacts can have system roles assigned (types.ts:275): 
interface Contact {
  // ...
  role: string; // Can be 'Admin', 'Tenant', 'User', 'Lead', etc.
}

​
System Role Badge

Contacts with admin/user roles show a badge (AdminViews.tsx:336-343): 
{contact.role?.toLowerCase() === 'admin' && (
  <span className="bg-cafh-indigo text-white text-[10px] px-2 py-0.5 rounded-md uppercase">
    <Shield size={10} /> Sistema
  </span>
)}

​
Session Management

User sessions are stored in localStorage (storage.ts:318-348):

​
Get Current User

const currentUser = db.auth.getCurrentUser();
// Returns User object or null if not logged in

​
Logout

db.auth.logout();
// Clears session from localStorage

​
Update Current User

db.auth.updateCurrentUser({
  name: "New Name",
  avatarUrl: "/media/new-avatar.jpg"
});

​
Security Best Practices

  • Minimum 8 characters
  • Require uppercase, lowercase, number
  • Enforce password changes every 90 days
  • Prevent password reuse (last 5)
  • Lock accounts after 5 failed attempts
  • Use principle of least privilege
  • Review permissions quarterly
  • Remove access when roles change
  • Document role assignments
  • Audit admin actions regularly
  • Implement session timeout (30 minutes)
  • Force re-authentication for sensitive ops
  • Use secure, httpOnly cookies in production
  • Log all admin actions
  • Monitor for suspicious activity
  • Enable 2FA for all admin accounts
  • Use authenticator apps (not SMS)
  • Provide backup codes
  • Require 2FA for password resets

​
Change Logging

All admin actions are logged with user attribution (types.ts:77-86): 
export interface ChangeLog {
  userId: string;
  userName: string;
  section: string;
  action: 'Create' | 'Update' | 'Delete' | 'Rollback';
  timestamp: string;
  details: string;
}
View change logs at CMS → History to audit:
  • Who made changes
  • What was changed
  • When changes occurred
  • Previous state (for rollback)

​
Multi-Tenancy

The platform supports multi-tenant deployments (types.ts:3-11): 
export interface Tenant {
  id: string;
  name: string;
  domain: string;
  theme: {
    primaryColor: string;
    logoUrl: string;
  };
}
Users are assigned to tenants via tenantId, isolating data and configurations.

​
Access Control Examples

​
CMS Access

// Only admins and editors can create content
const canCreateContent = [
  UserRole.SUPER_ADMIN,
  UserRole.ADMIN,
  UserRole.EDITOR
].includes(user.role);

​
CRM Access

// Only admins can access CRM
const canAccessCRM = [
  UserRole.SUPER_ADMIN,
  UserRole.ADMIN
].includes(user.role);

​
Settings Access

// Only SUPER_ADMIN can modify settings
const canModifySettings = user.role === UserRole.SUPER_ADMIN;

​
Deactivating Users

Safely remove user access:
1

Set Inactive Status

Change isActive to false instead of deleting
2

Preserve Data

Keep user record for audit trail and change logs
3

Revoke Sessions

Clear all active sessions for the user
4

Document Reason

Add note explaining deactivation
const deactivateUser = (userId) => {
  const user = db.auth.getAllUsers().find(u => u.id === userId);
  if (user) {
    user.isActive = false;
    db.auth.updateUser(user);
  }
};
Deactivated users cannot log in but their historical data remains intact for reporting and audit purposes.

CRM System

Contact management and permissions

CMS Overview

Content management permissions

Build docs developers (and LLMs) love

Get started for freeTalk to us