Yakult App enforces a three-tier role system that matches the real-world structure of a Yakult distribution operation. A Master is the administrator who oversees the whole platform — they can manage users, view every report, and perform any operation. A Promotor is a sales representative who creates orders on behalf of clients and manages the product and client catalogs. A Repartidor is a delivery driver whose interaction with the app is focused entirely on the orders assigned to them: they receive in-app notifications when an order is assigned and can update an order’s status to delivered. At registration, role assignment is automatic:Documentation Index
Fetch the complete documentation index at: https://mintlify.com/160906/Yakultt-App/llms.txt
Use this file to discover all available pages before exploring further.
@upa.edu.mx addresses become Masters and all other addresses become Promotors. The Repartidor role is never auto-assigned — a Master must promote a registered Promotor to Repartidor from the Admin screen. Any account can be suspended by a Master regardless of its role.
Role Capabilities
| Capability | Master | Promotor | Repartidor |
|---|---|---|---|
| View dashboard | ✅ | ✅ | ✅ |
| Manage products (add / edit / delete) | ✅ | ✅ | ❌ |
| Manage clients (add / edit / deactivate) | ✅ | ✅ | ❌ |
Create orders (as vendedor) | ✅ | ✅ | ❌ |
| View all orders | ✅ | ✅ | ❌ |
| Assign repartidor to an order | ✅ | ✅ | ❌ |
| Mark order as delivered | ✅ | ❌ | ✅ |
| Receive order-assignment notifications | ✅ | ❌ | ✅ |
| View own notifications | ✅ | ✅ | ✅ |
| Generate and save sales reports | ✅ | ✅ | ❌ |
| View all users’ reports | ✅ | ❌ | ❌ |
List all users (GET /api/auth/usuarios) | ✅ | ❌ | ❌ |
| Activate / deactivate user accounts | ✅ | ❌ | ❌ |
| Change a user’s role | ✅ | ❌ | ❌ |
| Delete user accounts | ✅ | ❌ | ❌ |
Access Admin screen (/(tabs)/admin) | ✅ | ❌ | ❌ |
Role Definitions
Master
Full administrative access. Manages users, views all reports across all promotors, and can perform every product, client, and order operation. Auto-assigned to
@upa.edu.mx registrations.Promotor
Standard sales representative. Creates orders as the
vendedor, manages the product catalog and client list, and generates their own sales reports. Default role for all new registrations.Repartidor
Delivery driver. Receives in-app notifications when assigned to an order. Can mark assigned orders as delivered. Has no access to product, client, or report management.
Inactive Account
Any account can be suspended by a Master by setting
activo = 0. A suspended user cannot log in regardless of their role, and is shown a clear error message.Master
The Master role is the platform administrator. Every user-management endpoint inbackend/routes/auth.js is intended exclusively for Master users:
Promotor
Promotors are the day-to-day users of the platform. When a Promotor creates an order, theirusuario.id is recorded in the vendedor_id column of the ordenes table, linking every sale to the representative who made it. This linkage powers the per-vendedor filter in the reporting system.
Repartidor
Repartidors are assigned to orders by a Master or Promotor viaPUT /api/ordenes/:id/repartidor. The moment a repartidor is assigned, the backend creates a notificaciones record pointing to that user so they see an alert in-app. Repartidors can then change the order’s estado to 'Entregado' via PUT /api/ordenes/:id/estado.
Auto-Assignment Rule
When a new user registers viaPOST /api/auth/registro, the backend checks the email domain before inserting the record:
| Email pattern | Assigned role |
|---|---|
*@upa.edu.mx | Master |
| Any other domain | Promotor |
The
Repartidor role cannot be self-assigned at registration. A Master must manually change the role to Repartidor from the Admin screen after the user has registered as a Promotor. This requirement exists because Repartidor was added to the ENUM in a later schema migration — existing databases have their usuarios.rol column automatically updated by ensureSchema() using ALTER TABLE usuarios MODIFY COLUMN rol ENUM('Master','Promotor','Repartidor') NOT NULL DEFAULT 'Promotor'.Role Storage in the Database
Roles are stored as a MySQLENUM directly on the usuarios table:
ENUM constraint means the database itself rejects any invalid role string — the application-level validation in PUT /api/auth/usuarios/:id/rol is a redundant safety net.
The full usuarios row that is returned in the JWT payload and kept in AuthContext looks like this:
Frontend Role Checks
The mobile app enforces role restrictions in two ways:1. Screen-level redirect
Screens that require Master access perform an immediate role check at the top of the component and return a<Redirect> if the check fails:
2. Tab bar visibility
Theadmin, ventas, and perfil routes are hidden from the tab bar using href: null and are only reachable via router.push() — which screens conditionally invoke based on role.
The activo Flag
Every usuarios row has an activo TINYINT(1) column (default 1). During login, the server explicitly checks this flag before issuing a token:
activo state from the Admin screen by calling AuthDB.editarUsuario(id, { activo: false }), which maps to PUT /api/auth/usuarios/:id.