Spec §13 says the audit log should also cover auth/security events (login success/failure, permission changes), but the current spine is entity-centric: AuditAction is only created/updated/deleted and entity_type/entity_id are NOT NULL (crates/domain/src/audit.rs, crates/db/migrations/0001_audit_log.sql).
When auth lands (Plan 9), extend the model to represent auth events cleanly — e.g. an expanded action set plus a nullable or "auth"-typed entity reference, or a sibling table. Decide the shape then.
Also at that time: replace the placeholder AuditActor::User(Uuid) with the new UserId newtype (db maps to/from a raw UUID column, so it's a type-side change).
Source: Plan 1 (audit spine) final review — forward-looking, belongs with Plan 9 (auth).
Spec §13 says the audit log should also cover **auth/security events** (login success/failure, permission changes), but the current spine is entity-centric: `AuditAction` is only `created`/`updated`/`deleted` and `entity_type`/`entity_id` are `NOT NULL` (`crates/domain/src/audit.rs`, `crates/db/migrations/0001_audit_log.sql`).
When auth lands (Plan 9), extend the model to represent auth events cleanly — e.g. an expanded action set plus a nullable or `"auth"`-typed entity reference, or a sibling table. Decide the shape then.
Also at that time: replace the placeholder `AuditActor::User(Uuid)` with the new `UserId` newtype (db maps to/from a raw `UUID` column, so it's a type-side change).
_Source: Plan 1 (audit spine) final review — forward-looking, belongs with Plan 9 (auth)._
Progress/scope note from the admin-CRUD work (merged main @ c4e0c4c): admin catalogue object writes (create/update/delete/set_fields, in crates/api/src/admin_objects.rs) now correctly record AuditActor::User(<real uuid>) extracted from the authenticated session.
Still pending under this issue: set_visibility (the publish endpoint) continues to record AuditActor::System — it carries a TODO(#7) in code. Capturing the real acting user there (and login/logout/auth-event auditing) remains the scope of this issue.
Progress/scope note from the admin-CRUD work (merged `main` @ `c4e0c4c`): admin catalogue **object** writes (create/update/delete/set_fields, in `crates/api/src/admin_objects.rs`) now correctly record `AuditActor::User(<real uuid>)` extracted from the authenticated session.
Still pending under this issue: `set_visibility` (the publish endpoint) continues to record `AuditActor::System` — it carries a `TODO(#7)` in code. Capturing the real acting user there (and login/logout/auth-event auditing) remains the scope of this issue.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Spec §13 says the audit log should also cover auth/security events (login success/failure, permission changes), but the current spine is entity-centric:
AuditActionis onlycreated/updated/deletedandentity_type/entity_idareNOT NULL(crates/domain/src/audit.rs,crates/db/migrations/0001_audit_log.sql).When auth lands (Plan 9), extend the model to represent auth events cleanly — e.g. an expanded action set plus a nullable or
"auth"-typed entity reference, or a sibling table. Decide the shape then.Also at that time: replace the placeholder
AuditActor::User(Uuid)with the newUserIdnewtype (db maps to/from a rawUUIDcolumn, so it's a type-side change).Source: Plan 1 (audit spine) final review — forward-looking, belongs with Plan 9 (auth).
Progress/scope note from the admin-CRUD work (merged
main@c4e0c4c): admin catalogue object writes (create/update/delete/set_fields, incrates/api/src/admin_objects.rs) now correctly recordAuditActor::User(<real uuid>)extracted from the authenticated session.Still pending under this issue:
set_visibility(the publish endpoint) continues to recordAuditActor::System— it carries aTODO(#7)in code. Capturing the real acting user there (and login/logout/auth-event auditing) remains the scope of this issue.