Skip to main content

​
Overview

Yoneily’s user management system provides comprehensive control over user accounts, vendor registration, role-based access control, and granular permissions through ACL (Access Control Lists).

​
User Types

Administrators

Full system access with ability to manage all users, vendors, and permissions

Vendors

Store owners with access to their own inventory, sales, and customer interactions

​
User Fields

The user system tracks the following information:
FieldDescription
id_usuarioUnique user identifier (primary key)
usernameLogin username (minimum 4 characters)
email_usuarioUser email address
passwordEncrypted password (SHA-1 hash)
perfil_usuarioUser’s full name/profile
groups_idgruposGroup ID (role assignment)
locale_id_localAssociated store/locale ID for vendors
fecharreg_usuarioRegistration timestamp

​
User Management Workflows

​
Creating Users

1

Access User Management

Navigate to the admin panel and select “Users” from the menu
2

Add New User

Click “Add User” and fill in the required fields:
  • Username (minimum 4 characters)
  • Email address
  • Full name/profile
  • Password
  • Assign user group (Administrator or Vendor)
3

Assign Store (Vendors Only)

For vendor accounts, select the associated store/locale from the dropdown
4

Save

Submit the form to create the user account with encrypted password storage

​
Vendor Registration

Vendors can self-register through a public registration form:
Vendors register with a unique store code that validates against existing locales in the system.
Registration Process:
  1. Vendor accesses the registration page (/users/add_vendedor)
  2. Enters store code to validate their business
  3. Fills in credentials and profile information
  4. System validates the code against the locales table
  5. Password is hashed using Security::hash() before storage
  6. Upon success, vendor is redirected to confirmation page

​
Groups & Roles

​
Available Groups

Group ID: 1Name: administradoresCapabilities:
  • Full system access
  • Manage all users and vendors
  • Configure permissions
  • Access all stores and inventory
  • View comprehensive reports

​
Access Control Lists (ACL)

​
ACL Architecture

Yoneily implements a hierarchical ACL system using CakePHP’s built-in ACL component: 
ACOs (Access Control Objects)
├── Controllers
│   ├── Galleries
│   │   ├── index
│   │   ├── add
│   │   ├── edit
│   │   └── delete
│   ├── Promos
│   ├── Ventas
│   ├── Denuncias
│   └── Users
│       ├── index
│       ├── add
│       ├── edit
│       ├── delete
│       ├── permission
│       └── ajax_load

AROs (Access Request Objects)
├── Groups
│   ├── Administrators
│   └── Vendors
└── Users (inherit from Groups)

​
Managing Permissions

1

Access Permission Manager

Navigate to Users > Permissions and select a user
2

View Permission Tree

The system displays all available controllers and actions:
  • Parent nodes represent controllers
  • Child nodes represent specific actions
  • Green checkmarks indicate granted permissions
3

Toggle Permissions

Click on any permission to toggle access:
  • Allow: User can execute the action
  • Deny: User is blocked from the action
Changes are applied immediately via AJAX
4

Inheritance

Users inherit base permissions from their group, but can have individual overrides

​
Permission AJAX System

The ajax_load action handles real-time permission changes:
  • Key Parameters:
    • key: User ID
    • key2: ACO alias (controller/action)
    • key3: Current status (0 = denied, 1 = allowed)
  • Behavior:
    • Toggles permission using $this->Acl->allow() or $this->Acl->deny()
    • Updates database immediately
    • Returns new status to update UI

​
User Operations

​
Editing Users

When changing a user’s group, the ACL hierarchy is automatically updated to maintain proper permission inheritance.
Edit Workflow:
  1. Select user from the user list
  2. Modify fields as needed
  3. If changing groups:
    • System finds user’s ARO record
    • Finds new group’s ARO record
    • Updates parent_id to maintain hierarchy
  4. Save changes

​
Password Management

Users can change their passwords through a secure workflow: 
Requirements:
- Old password verification
- New password (minimum 4 characters)
- Password confirmation match
- SHA-1 hashing using Auth component
Password Change Steps:
  1. User accesses /users/edit_pass/{id}
  2. Enters current password for verification
  3. Enters new password twice
  4. System validates:
    • Current password matches stored hash
    • New passwords match each other
    • Minimum length requirements met
  5. New password is hashed and saved

​
Deleting Users

The delete action (/users/delete/{id}) permanently removes the user record from the database.

​
Authentication System

​
Login Process

  1. User accesses /users/login
  2. Enters username and password
  3. CakePHP Auth component:
    • Hashes submitted password
    • Compares with stored hash
    • Validates group membership
    • Checks ACL permissions
  4. On success:
    • Session is created
    • User data stored in Auth.User
    • Redirected to admin home

​
Session Data

The following user data is stored in the session: 
$this->Session->read('Auth.User.id_usuario')      // User ID
$this->Session->read('Auth.User.groups_idgrupos') // Group ID
$this->Session->read('Auth.User.locale_id_local') // Store ID (vendors)
$this->Session->read('Auth.User.username')         // Username

​
Logout

Users can logout via /users/logout, which:
  • Destroys the session
  • Clears Auth data
  • Redirects to login page
  • Displays logout confirmation message

​
Reports & Exports

​
User Reports

Administrators can generate PDF reports:

Individual User Report

Generate a detailed PDF for a specific userRoute: /users/pdf/{id}

Complete User Report

Generate a comprehensive PDF of all usersRoute: /users/pdf_completo

​
Store Code Validation

The system includes an AJAX endpoint for validating vendor store codes: 
// Endpoint: /users/consulta_codigo/{code}
// Returns: locale_id or 0 if invalid
This ensures that vendors can only register with legitimate, active store codes from the locales table.

​
Best Practices

  • Enforce minimum 4-character passwords
  • All passwords are hashed with SHA-1 + salt
  • Never store plaintext passwords
  • Require old password for password changes
  • Start with group-level permissions
  • Use individual overrides sparingly
  • Regularly audit vendor permissions
  • Test permission changes before deployment
  • Validate store associations
  • Review vendor registrations regularly
  • Ensure locale_id is properly set
  • Monitor vendor activity and sales

Inventory Management

Manage products and stock levels

Sales Tracking

Monitor sales and transactions

Complaints System

Handle customer feedback

Build docs developers (and LLMs) love

Get started for freeTalk to us