Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ency07/B2B-import/llms.txt

Use this file to discover all available pages before exploring further.

B2B Import ERP ships with nine predefined system roles that cover every actor in a B2B industrial services operation — from platform-wide administrators down to end-clients browsing their own portal. Roles are assigned per user at the tenant level, and access is resolved at runtime through a three-stage cascade that accounts for per-user exceptions and multi-site restrictions. No user gains access to a module simply by being logged in; every action is gated by an explicit permission code tied to the user’s role.

The 9 Official Roles

SUPER_ADMIN

Platform-wide administration with no tenant affiliation. Has full bypass of all RLS policies (is_platform_user = true, tenant_id = NULL). Manages tenants, global roles, platform permissions, and cross-tenant audit logs.

ADMIN_EMPRESA

Full control within a single tenant. Can create and edit users, assign roles, manage tenant settings (including white-label), and access all operational and financial modules within their company.

GERENTE_GENERAL

Multi-site visibility across the entire tenant. Can approve quotes and jobs, view all commercial and operational data across every site, and access tenant-level audit logs. Has cross-site access by default.

DIR_COMERCIAL

Commercial pipeline management. Creates and edits clients and requirements, manages and approves quotes, and has cross-site read access to all commercial data. Cannot manage operational or financial records.

EJECUTIVO_COM

Day-to-day commercial operations. Creates clients, requirements, and quotes. Can upload documents and view inventory, but cannot approve quotes or create jobs.

DIR_OPERACIONES

Full control over the operations domain. Creates and manages jobs, manages inventory items and movements, closes jobs, and has read access to commercial records.

TECNICO_CAMPO

Field execution. Executes assigned jobs, records work activities, and logs inventory movements. Read-only access to clients and jobs assigned to them. Cannot create jobs, approve quotes, or access financial data.

AUDITOR

Read-only access to all records within the tenant, including the full audit log (audit.view_tenant). Cannot create, edit, or delete any record. Intended for compliance and internal control functions.

CLIENTE

Client portal access. Can view their own quotes, invoices, and shared documents. Can upload documents related to their own requirements. Has no access to operational, inventory, or administrative data.
GERENTE_GENERAL and DIR_COMERCIAL have cross-site visibility by default. The permission resolution engine skips the per-site site_id restriction for these two roles, so they see data from all sites within their tenant without any extra configuration.

Permission Matrix

The table below covers the key permission codes across the main modules. = granted by default for that role; No = not granted (may be added via user_permissions override).
Module / PermissionSUPER_ADMINADMIN_EMPRESAGERENTE_GENERALDIR_COMERCIALEJECUTIVO_COMDIR_OPERACIONESTECNICO_CAMPOAUDITORCLIENTE
Platform / Tenants
tenants.createNoNoNoNoNoNoNoNo
tenants.viewNoNoNoNoNoNoNoNo
tenants.settingsNoNoNoNoNoNoNo
Users & Roles
users.createNoNoNoNoNoNoNo
users.editNoNoNoNoNoNoNo
users.permissionsNoNoNoNoNoNoNo
Commercial / CRM
clients.createNoNoNoNoNo
clients.editNoNoNoNoNo
clients.viewNoNo
quotes.createNoNoNoNoNo
quotes.approveNoNoNoNoNoNoNo
quotes.viewNoNo
Operations
jobs.createNoNoNoNoNoNo
jobs.manageNoNoNoNoNo
jobs.closeNoNoNoNoNoNoNo
documents.uploadNoNo
documents.viewNo
Inventory
items.manageNoNoNoNoNoNoNo
inventory.movementNoNoNoNoNoNo
inventory.viewNoNo
Finance
invoices.createNoNoNoNoNoNoNo
payments.confirmNoNoNoNoNoNoNo
payments.viewNoNoNoNo
Audit
audit.view_globalNoNoNoNoNoNoNoNo
audit.view_tenantNoNoNoNoNoNo

Permission Resolution Cascade

At runtime, every permission check follows a deterministic three-stage cascade:
[1. Role Permissions]
     — Does the user's assigned role include this permission_code?

[2. user_permissions table (per-user overrides)]
     — Is there a row for (user_id, permission_id)?
       • granted = true  → access granted regardless of role
       • granted = false → access denied regardless of role

[3. site_id restriction (single-site users)]
     — Does the resource belong to the user's assigned site?
       • Managers / Directors → cross-site, skip this check
       • All other roles     → restricted to their own site_id

[Access Granted / Denied]
Stages are evaluated in order and the first conclusive result wins. If stage 2 produces an explicit granted = false, the cascade stops — even a role that would normally permit the action cannot override it.

User Exceptions (user_permissions)

The user_permissions table stores per-user permission overrides that augment or restrict what a role alone would grant:
CREATE TABLE user_permissions (
    id           uuid PRIMARY KEY DEFAULT gen_random_uuid(),
    tenant_id    uuid REFERENCES tenants(id) ON DELETE CASCADE,
    user_id      uuid NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    permission_id uuid NOT NULL REFERENCES permissions(id) ON DELETE CASCADE,
    granted      boolean NOT NULL DEFAULT true,
    assigned_at  timestamp NOT NULL DEFAULT NOW(),
    assigned_by  uuid REFERENCES users(id) ON DELETE SET NULL,
    CONSTRAINT unique_user_permission UNIQUE (user_id, permission_id)
);
Typical use cases:
  • Grant: give a specific EJECUTIVO_COM the quotes.approve permission without promoting them to DIR_COMERCIAL.
  • Revoke: remove inventory.view from a DIR_OPERACIONES user who should not see stock data in a particular deployment.
Only SUPER_ADMIN and ADMIN_EMPRESA can manage user_permissions rows (users.permissions gate).

Custom Roles

Tenants may create additional roles beyond the nine system defaults. Custom roles are stored with a non-NULL tenant_id in the roles table, scoping them to the creating tenant. System-level global roles carry tenant_id = NULL and are available to all tenants. Custom roles participate in the same three-stage permission resolution cascade as system roles.

Build docs developers (and LLMs) love