Skip to content

feat(audit): implement comprehensive audit logging system#72

Open
wellCh4n wants to merge 1 commit into
mainfrom
feature/audit-log
Open

feat(audit): implement comprehensive audit logging system#72
wellCh4n wants to merge 1 commit into
mainfrom
feature/audit-log

Conversation

@wellCh4n

Copy link
Copy Markdown
Owner

Add a complete audit logging system to track all critical operations in the platform.

Core Components

Domain Layer

  • AuditLog entity with full operation metadata (user, source, resource, timestamp, success/failure)
  • OperationSource enum (USER, OPENAPI, SCHEDULED, SYSTEM) to distinguish operation origins

Application Layer

  • AuditService with async logging to avoid impacting main operations
  • Query methods using JpaSpecificationExecutor for flexible dynamic filtering
  • AuditLogRepository with Specification support for any combination of filters

Infrastructure Layer

  • AuditAspect using AOP to automatically intercept @Auditable methods
  • Determines operation source by inspecting request URI (/api/** vs /openapi/**)
  • Extracts user info, resource details, and client IP automatically

Interface Layer

  • @Auditable annotation for declarative audit marking
  • AuditLogController with admin query endpoint and per-application audit view
  • Applied audit annotations to all key operations:
    • Application: CREATE_APP, UPDATE_APP, DELETE_APP, MIGRATE_NAMESPACE
    • Deployment: DEPLOY
    • Pipeline: STOP_PIPELINE, DEPLOY_PIPELINE, ROLLBACK
    • Environment: CREATE_ENV, UPDATE_ENV, DELETE_ENV
    • User: CREATE_USER, UPDATE_USER, DELETE_USER
    • Config: UPDATE_CONFIG

Database

  • V19 migration creates audit_log table with indexes on resource, user, namespace, timestamp, source

Key Features

  • Asynchronous logging: Uses @async with REQUIRES_NEW propagation to ensure audit logs are saved even if main transaction fails
  • Non-invasive: AOP-based approach requires only @Auditable annotation on methods
  • Source tracking: Automatically distinguishes USER (Web UI) vs OPENAPI (CLI/skill) operations
  • Failure tolerance: Audit logging failures never impact main business operations
  • Flexible queries: Specification-based queries support any combination of filters without adding repository methods

API Endpoints

  • GET /api/audit-logs (admin only) - query with filters (resourceType, resourceId, userId, namespace, source)
  • GET /api/audit-logs/namespaces/{ns}/applications/{name} - per-app audit log

@wellCh4n
wellCh4n force-pushed the feature/audit-log branch from 879dc61 to a422f58 Compare July 20, 2026 08:47
Record user, OpenAPI, and system operations across applications,
pipelines, environments, configs, and users. Operations are captured
via a @loggable aspect and persisted to the operation_log table, then
surfaced through a global /logs page and a per-application logs tab.

Both list views follow the standard ContentPage + TableForm layout with
icon pagination and i18n column factories, consistent with the other
list pages. Naming is uniformly 'operation log' / 'log' with no audit
terminology anywhere in the codebase.

Co-authored-by: Claude <noreply@anthropic.com>
@wellCh4n
wellCh4n force-pushed the feature/audit-log branch from a422f58 to 36dcec2 Compare July 20, 2026 15:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant