Also since some hooks use the Composr API to delete content, such actions could cause additional records to get added into action log. It's likely we already purged the action log by that point though, so that's a problem. Let's make action log the last table purged.
EDIT: Actually, can't do that as log_it could be a shutdown function. We will have to re-run purge again in another task, but only on action log.
EDIT 2: Action logs doesn't define user privacy data; maybe it should?
EDIT 3: It does... in core. A bit confusing it's there and not actionlog.
EDIT 4: I thought about using push/pop methods instead of making it more confusing with another task run for just actionlogs, but actionlogs allow anonymisation or deletion. So this won't work; we really do need to run it as a separate purge task.
EDIT 5: Actually we probably could use push/pop to force log_it to log immediately instead of during shut-down. Then, we can just make actionlogs the last table purged instead of using another task.
EDIT: Actually, can't do that as log_it could be a shutdown function. We will have to re-run purge again in another task, but only on action log.
EDIT 2: Action logs doesn't define user privacy data; maybe it should?
EDIT 3: It does... in core. A bit confusing it's there and not actionlog.
EDIT 4: I thought about using push/pop methods instead of making it more confusing with another task run for just actionlogs, but actionlogs allow anonymisation or deletion. So this won't work; we really do need to run it as a separate purge task.
EDIT 5: Actually we probably could use push/pop to force log_it to log immediately instead of during shut-down. Then, we can just make actionlogs the last table purged instead of using another task.
Same for allowing null on points_ledger sender_id and recipient_id