StockManager maintains a persistent audit log of every meaningful action taken through the application. Every time a product is created, a user is updated, a sale is approved, or a session is started, a structured record is written to theDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/InnoDev69/StockManager/llms.txt
Use this file to discover all available pages before exploring further.
audit_log table — capturing who did it, what changed, when it happened, and whether the operation succeeded. The three endpoints below let you query that log by user, filter it system-wide, or trace the full change trail for a single entity.
How actions are recorded
Audit entries are written automatically by the@audit_action decorator defined in tools/audit_decorator.py. Any Flask route handler decorated with it will have its execution wrapped: the actor’s session user ID and the client IP are captured, pre/post snapshots are diffed for updates, and the resulting entry is written to the database regardless of whether the underlying operation succeeded or raised an exception.
| Parameter | Values | Description |
|---|---|---|
entity_type | product, sale, user, application | The kind of object being acted upon |
action_name | create, update, delete, activate, login, register, reset_password, change_password, approve, reject | The action being performed. Defaults to the HTTP method if omitted |
id_param | e.g. product_id, user_id | Name of the URL keyword argument that holds the entity’s primary key |
user_id from session and entity_id from the route’s URL kwargs using id_param. For update actions it fetches the entity’s current state both before and after the handler runs and stores a human-readable diff in the description field. For create actions it captures the request body (excluding password). For delete it records the entity’s last known state.
An audit entry is not written if there is no
actor_id in the session at the time of the call. Requests that fail authentication before reaching a decorated handler therefore produce no audit record.Endpoints
GET /api/user/:user_id
Returns the paginated audit history for a single user. A logged-in user may query their own history. Only users with theroot role may query another user’s history.
Authentication: RequiredAccess: Own history (any role) or any user (root only)
Query parameters
Filter entries to a specific action name, for example
login, create, or delete. Case-insensitive — the query is uppercased internally before matching.Return only entries with a
timestamp on or after this date. Format: YYYY-MM-DD.Return only entries with a
timestamp on or before this date. Format: YYYY-MM-DD.Maximum number of records to return. Defaults to
50.Number of records to skip before returning results. Defaults to
0. Use together with limit to paginate.Example response
GET /api/all
Returns the full system-wide audit log, spanning every user and entity type. Authentication: RequiredAccess: Root only
This endpoint is restricted to the
root role. Any authenticated request from a user with admin or vendedor role will receive a 403 Forbidden response.Query parameters
Accepts the sameaction, from, to, limit, and offset parameters as GET /api/user/:user_id.
Example response
GET /api/entity/:entity_type/:entity_id
Returns the complete ordered change trail for a single entity — every audit entry that references it, sorted oldest-first. This is useful for reconstructing the full lifecycle of a product, sale, or user account. Authentication: RequiredAccess: Admin or root
| Path parameter | Description |
|---|---|
entity_type | One of product, sale, user, application |
entity_id | Integer primary key of the entity |
Example response
Audit entry fields
The following fields appear in each record returned by/api/user/:user_id and /api/all.
Auto-incremented primary key of the audit log entry.
The ID of the user who performed the action (the actor).
The username of the actor, joined from the
users table at query time.The action that was performed, stored in uppercase:
CREATE, UPDATE, DELETE, LOGIN, etc.The type of entity affected:
product, sale, user, or application.The primary key of the affected entity.
null for actions that do not target a specific record (for example, a bulk query).A human-readable summary of the change. For updates, this contains a field-by-field diff (e.g.
Cambios: Precio: '$9.99' → '$11.49'). For creates it lists the initial field values; for deletes it identifies the entity by name.ISO 8601 datetime string (
YYYY-MM-DDTHH:MM:SS.ffffff) recorded at write time in local server time."success" if the operation completed without an exception; "error" if the handler threw before returning a response.Examples
Retrieve all recorded changes to product ID 3:delete actions system-wide between two dates (root only):