Zzzz
1.8 KiB
Logging Guidelines
Logging and system-log conventions for the library-management backend.
Overview
The project requires system maintenance/log support for key operation logs, data
backup support, and exception tracing. MySQL should include a system log table,
illustratively system_logs, for durable audit and troubleshooting records.
What to Log
Record key operations that affect security, data integrity, or inventory:
- Login success/failure and logout for administrator, librarian, and reader roles when applicable.
- Permission changes, role changes, and denied protected operations.
- Book create, update, delete, category maintenance, and warehousing/intake.
- Borrow, return, renew, overdue handling, and automatic inventory status updates.
- Reader profile, eligibility, and contact information changes.
- Data backup events and restore-related maintenance actions.
- Unhandled exceptions and failed database operations with safe context.
System Log Fields
When the schema is introduced, system_logs should preserve enough information
to trace actions without exposing sensitive data. Useful fields include an ID,
operator ID, operator role, operation type, target entity/table, target ID,
result status, message, timestamp, and request IP when available.
Sensitive Data
Do not log passwords, raw credentials, full request bodies, database connection strings, or unnecessary personal data. Prefer IDs and operation summaries over large before/after payloads.
Exception Tracing
Server logs may contain technical stack traces for developers. User-facing JSP pages should receive concise messages. Durable system logs should record the operation, actor, failure category, and correlation details needed to locate the server-side exception.