feat: activate @Audited AOP for declarative audit logging - #44
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8e08b8a521
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| @Audited(action = AuditActionUtil.PIN_POST, entityType = AuditActionUtil.ENTITY_FORUM_POST, entityIdFrom = "id") | ||
| public void pinPost(String id) { |
There was a problem hiding this comment.
Keep explicit audit logging for bulk forum actions
After this change, pinPost/unpinPost/lockPost/unlockPost/deletePost rely only on @Audited, but bulkAction invokes these methods from inside the same class. In Spring proxy-based AOP, that self-invocation bypasses the proxy, so the audit aspect does not run for bulk operations and those admin actions stop producing audit records.
Useful? React with 👍 / 👎.
| } | ||
|
|
||
| @Override | ||
| @Audited(action = AuditActionUtil.FLAG_COMMENT, entityType = AuditActionUtil.ENTITY_COMMENT, userIdFrom = "id") |
There was a problem hiding this comment.
Extract affected user ID from comment instead of method id
Using userIdFrom = "id" here maps the comment ID into the audit user_id field. This method already sets AuditContext.setUserId(comment.getAuthorId()/getUserId()), but the aspect prefers the annotation parameter first, so comment moderation logs will point to comment IDs rather than affected users, breaking user-centric audit queries.
Useful? React with 👍 / 👎.
| } | ||
|
|
||
| @Override | ||
| @Audited(action = AuditActionUtil.REQUEUE_SUBMISSION, entityType = AuditActionUtil.ENTITY_SUBMISSION, userIdFrom = "id") |
There was a problem hiding this comment.
Record submission ID as entityId in rejudge audits
This annotation currently sets userIdFrom = "id", so a submission ID is written as user_id, while entity_id becomes "N/A" because RejudgeResult exposes getSubmissionId() (not getId() for the aspect's reflection fallback). That regresses audit fidelity for rejudge events and makes submission-level filtering unreliable.
Useful? React with 👍 / 👎.
Summary
auditHelper.log()/auditHelper.logForUser()calls with@Auditedannotations across 8 admin servicesAuditContextThreadLocal for old/new value capture from method bodies@AuditedwithuserIdFrom/entityIdFromparam extractionAuditAspectwith exception handling,firstNonNull()fallback chainAuditHelper(forRemoval=false) — still usable for edge cases like bulk operationsTest plan
./mvnw compilepasses./mvnw test -Dtest=AuditContextTest— 11 tests pass./mvnw test -Dtest=AdminSubmissionServiceImplTest— 8 tests pass🤖 Generated with Claude Code