Problem
IK audit logs currently record an event and resource identifier, but they do not always retain enough human-readable information to identify the affected resource. This is especially problematic after a resource is deleted, because its database record is no longer available.
Audit entries should be understandable independently of the resource’s current state and should consistently identify the resource for all supported actions.
Deletion strategy investigation
Evaluate whether IK should:
- Continue hard-deleting resources while storing a metadata snapshot in the audit entry before deletion, or
- Use soft deletion by retaining the resource with a deleted status and excluding it from standard UI, API, selection, and operational flows.
The decision should consider retention requirements, referential integrity, uniqueness constraints, restore requirements, storage impact, security, and authorization.
Problem
IK audit logs currently record an event and resource identifier, but they do not always retain enough human-readable information to identify the affected resource. This is especially problematic after a resource is deleted, because its database record is no longer available.
Audit entries should be understandable independently of the resource’s current state and should consistently identify the resource for all supported actions.
Deletion strategy investigation
Evaluate whether IK should:
The decision should consider retention requirements, referential integrity, uniqueness constraints, restore requirements, storage impact, security, and authorization.