LOGGING

What is this for?

The LOGGING plugin collects audit logs for the tenant:

• Who logged in?
• Who edited a contract?
• Which AUTOMATE task ran, and with what result?
• Which critical actions (deletion, permission change, backup) took place?

This gives you traceability, so you can look back when problems or disputes arise.

---

Typical day-to-day tasks

• Quickly check the log after an incident
• Apply filters (time range, user, plugin, action)
• Export / archive

---

Step by step

1) View logs

1. Admin → Logging (/settings/admin/logging).
2. Browse / filter the list.
3. Open an entry → see details (user, time, action, affected record).

2) Retain / clean up logs

• Depending on the configuration, old logs end up:
• in the tenant database (table for audit logs)
• and/or in the tenant's log directory (<tenant-root>/logs)
• Cleanup can run via an AUTOMATE task (for example, "delete logs older than X days").

3) Day-to-day: a quick overview

• At the start or end of the day, take one look at the log to spot unusual activity.
• For tickets/escalations: check the log first, then ask.

---

Common questions / problems

"Logs are empty"

• Is the LOGGING plugin actually enabled?
• Are write permissions set on the log directory?

"Logs are getting too large"

• Set up cleanup via AUTOMATE.
• Check the storage location (<tenant-root>/logs).

"I can't find a specific action"

• Reset the filters.
• Some actions are only logged at a coarse level (for example, "tenant changed" instead of every single field) – the focus is on important events.

---

Technical URLs / paths (quick reference)

Admin:

• GET /settings/admin/logging – logs overview

Directory:

• <tenant-root>/logs – file logs (when enabled)
• DB table: audit_log (internal)

Notes

• LOGGING is primarily a read / audit tool. It does not change any business data.
• Mind data privacy: logs can contain personal data – set retention periods accordingly.