Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ytabeloved/ordervista/llms.txt

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

The Operator is the frontline role in Ordervista, responsible for the day-to-day running of the restaurant floor. Accounts with id_rol: 2 can see all active and historical orders across the system, create in-person orders on behalf of walk-in customers, advance orders through their lifecycle by updating their status, monitor the kitchen commands view to coordinate preparation, and generate printed or on-screen receipts when an order is completed. Operators do not have access to catalog management, user administration, or analytics reports — those surfaces belong exclusively to the Administrator.

Accessible Frontend Routes

After logging in, an Operator is directed to the operational layout. The following frontend routes are available to this role.
RoutePagePurpose
/operatorOrder ManagementView and manage all active and historical orders.
/operator/new-orderCreate In-Person OrderBuild and submit an in-person order for a walk-in customer.
/kitchenKitchen CommandsReview kitchen commands associated with active orders.
/receiptsReceiptsGenerate and view operational receipts for completed orders.

API Endpoints Accessible

All routes below require a valid JWT (Authorization: Bearer <token>) with id_rol: 2. Routes that also accept id_rol: 1 are shared with the Administrator role.

Orders (managed view) — authorizeRoles(1, 2)

MethodEndpointAction
GET/api/orders/manageList all orders in the managed view.
GET/api/orders/manage/:idGet full detail of a specific order.
PATCH/api/orders/manage/:id/statusUpdate the status of a specific order.
POST/api/orders/in-personCreate a new in-person (walk-in) order.

Commands — authorizeRoles(1, 2)

MethodEndpointAction
GET/api/commandsList all kitchen commands.
GET/api/commands/:idGet the detail of a single command.

Workflow

1

Log in

Navigate to /login and authenticate with an Operator account. The backend issues a JWT containing id_rol: 2 and the frontend stores it in localStorage, granting access to all operational routes.
2

View active orders

Go to /operator to see the full order list. The managed order view shows every order in the system along with its current status, creation time, total, and customer details — giving the operator a live picture of what needs attention.
3

Create an in-person order (optional)

If a walk-in customer arrives and places an order at the counter, navigate to /operator/new-order. Select products from the catalog, set quantities, choose the order type, and submit. The order is created via POST /api/orders/in-person and immediately appears in the order list.
4

Update order status

From the order management view, advance each order through its lifecycle by updating its status via PATCH /api/orders/manage/:id/status. Valid status transitions follow the five status IDs defined in the system.
5

Review kitchen commands

Navigate to /kitchen to consult the COMANDAS table. Each command corresponds to an order sent to the kitchen, showing the items to be prepared. This view helps operators and kitchen staff stay coordinated without paper tickets.
6

Generate receipts

Go to /receipts to generate operational receipts for completed orders. Receipts serve as a record of what was ordered and delivered, and can be referenced in case of disputes or handover verification.

Order Status Values

Every order in Ordervista carries an id_estado field that references the ESTADOS_PEDIDO table. The Operator advances orders through the following statuses by sending the corresponding ID to PATCH /api/orders/manage/:id/status.
Status IDStatus NameDescription
1PendienteOrder has been registered and is awaiting preparation.
2En preparaciónOrder is actively being prepared in the kitchen.
3ListoOrder is prepared and ready for pickup, delivery, or service.
4EntregadoOrder has been finalised and delivered to the customer.
The backend validates that the incoming id_estado value is one of [1, 2, 3, 4, 5]. Any value outside that range is rejected with a 400 Bad Request response before the database is touched. Status IDs 1–4 map to the named statuses in the ESTADOS_PEDIDO table above.

Build docs developers (and LLMs) love