Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/juescoryisus/QualityDocD/llms.txt

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

The modules system controls which features each role can access within QualityDocD. Three modules map to distinct API endpoint groups — document lifecycle management, document consultation, and advanced search. Rather than hard-coding role checks in your frontend, call GET /modules after login to receive the exact permission set for the authenticated user and render the UI accordingly.

Module definitions

Module IDNameDescription
MODULE_1Gestión de DocumentosDocument approval, rejection, and lifecycle management
MODULE_2Consulta de DocumentosViewing and searching approved documents
MODULE_3Búsqueda AvanzadaAdvanced search, metadata filtering, and autocomplete suggestions

Role access matrix

The table below shows which roles have read (canRead) and write (canWrite) access to each module. Only modules where canRead is true are returned in the API response.
RoleMODULE_1MODULE_2MODULE_3
VIEWERread
COMMENTERread
CONTRIBUTORread
OPERATORread + writereadread
COMPANY_ADMINread + writeread + writeread
SUPER_ADMINread + writeread + writeread + write
VIEWER, COMMENTER, and CONTRIBUTOR are the three standard user roles. They can only read MODULE_2 — they cannot access document management (MODULE_1) or advanced search (MODULE_3).

GET /modules

Returns the list of feature modules visible to the authenticated user, with per-module read/write flags computed from their role. Authentication: Bearer token required (requireAuth middleware).

Request headers

Authorization
string
required
Bearer <token> — JWT issued by POST /auth/login.

Response — 200 OK

role
string
The authenticated user’s role string (e.g. "OPERATOR", "COMPANY_ADMIN").
modules
array
Array of module objects. Only modules where canRead is true for the caller’s role are included.

Example

curl -X GET http://localhost:5000/modules \
  -H "Authorization: Bearer <token>"

Using modules for UI feature flags

GET /modules is designed to be called once after login and stored in your frontend application state. Use the flags to drive conditional rendering:
  • If canWrite is false for MODULE_1, hide or disable approval and rejection buttons.
  • If a module is absent from the response entirely (canRead was false), hide the corresponding navigation section.
  • If canWrite is true for MODULE_2, the user is a COMPANY_ADMIN or SUPER_ADMIN — show document management controls within the consultation view.
Cache the modules response for the duration of the user session. Permissions only change when the user’s role changes — re-fetch after any role-update operation if your app supports in-session role changes.

Build docs developers (and LLMs) love