Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Danielsl4/TFG_DAM_2526/llms.txt

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

FutsalLeague Manager maintains an append-only audit log of every administrative action taken across the platform. Every time an admin or referee creates, updates, or deletes data, a record is written to the audit_logs table with full context — who did what, to which entity, and when. This log is the primary accountability mechanism for the platform and cannot be modified or deleted through the UI.

​
What gets logged

The following actions produce an audit log entry automatically:
  • Matches — creation, status updates, event additions, finalization, soft deletion, restoration, permanent deletion, team assignment updates
  • Seasons — creation (with or without import), update, deletion, structure import
  • Groups — creation, update, deletion, team assignment and removal
  • Teams — creation, update, soft deletion, restoration, season registration, removal from a season or group
  • Players — creation, update, soft deletion, restoration, squad registration, transfer, season removal
  • Users — role change, account deactivation (soft delete with anonymization)
  • Images — upload via POST /admin/upload (not individually logged, but the encompassing team or player update is)

​
Log entry structure

Each row in audit_logs contains:
FieldTypeDescription
idintegerAuto-incremented primary key
user_idintegerID of the admin or referee who performed the action
usernamestringResolved from the users table via JOIN (shown in API responses)
actionstringHuman-readable description of the action
entity_typestringType of entity affected: match, team, player, season, group, or user
entity_idintegerID of the affected entity
detailsJSONBContextual data specific to the action (name, old values, season ID, etc.)
created_attimestampUTC timestamp of when the action occurred

​
Example log entry

{
  "id": 301,
  "user_id": 4,
  "username": "admin",
  "action": "Finalización de partido",
  "entity_type": "match",
  "entity_id": 88,
  "details": {
    "home_goals": 3,
    "away_goals": 1,
    "season_id": "4"
  },
  "created_at": "2026-11-08T21:15:43.000Z"
}
The details field varies by action type. Common fields you will find inside it include name (for team/player/season/group actions), season_id (to correlate entries with a season), and entity-specific data like homeTeamId, role, or imported_from.

​
Accessing the log

​
Full log with filters

GET /admin/logs
Supports the following query parameters:
ParameterTypeDescription
pageintegerPage number (default: 1)
limitintegerEntries per page (default: 20)
season_idintegerFilter to entries whose details->>'season_id' matches
usernamestringPartial, accent-insensitive match on the acting user’s username
datedateExact date filter in YYYY-MM-DD format
Example — fetch page 2 of logs by a specific user on a specific date: 
GET /admin/logs?username=daniel&date=2026-11-08&page=2&limit=20
The response includes pagination metadata: 
{
  "logs": [ ... ],
  "total": 85,
  "page": 2,
  "limit": 20
}

​
Dashboard preview

The last 5 log entries are always visible on the admin dashboard without navigating to the full log view. They are returned as the recentActivity array in GET /admin/summary. If a season_id is passed to the summary endpoint, the preview is filtered to entries that reference that season (entries without a season_id in their details are always included).

​
Background cron jobs

FutsalLeague Manager runs scheduled background tasks via node-cron to automate maintenance operations. These tasks run server-side and do not appear in the audit log, as they are automated system processes rather than user-initiated actions.
Every day at 00:00 server time, the cron job permanently deletes user accounts that have been registered for more than 24 hours without completing email verification:
DELETE FROM users
WHERE is_verified = FALSE
  AND created_at < NOW() - INTERVAL '24 hours'
This keeps the users table clean of abandoned registrations. Verified accounts are never affected.
Audit log entries are retained indefinitely in the database. There is no automated expiry or rotation for log records. If your deployment has storage constraints, manage retention directly in the database — for example, by archiving rows older than a given threshold to cold storage.
The audit log is append-only by design. There is no endpoint to delete, edit, or suppress individual log entries through the admin UI. If an action was taken in error, the corrective action (for example, restoring a deleted match) will itself produce a new log entry — maintaining a complete chain of events for accountability.

Build docs developers (and LLMs) love

Get started for freeTalk to us