Logs changes

[uberbrady]

(This change is 'stacked' against the other PR I have open about the action_type Enum).

This is the start of the universal 'LogsChanges' trait, which we should be able to apply to things like Categories, and Status Labels, and other things like that, so we can log any changes that are made to settings or configuration.

Right now, it does successfully log creation, deletion, updates, and restores. I expect to apply it to most of the Models that we have that aren't "checkoutable".

The output you get in the action_logs looks roughly correct, but the links back to the original objects don't work yet (of course).

Does this approach make sense? Should I try to fill out just one Model (I'm using Categories for my sample case), or should I just apply it everywhere? I'm pretty sure I can also log changes to the Settings table the exact same way - the very same log_meta should be able to report back anything that changes on the table like any other.

Open Questions

• Did I miss any tables that I should be recording?
• Are there any other tables that should be in the new adminlogs table, because they are 'sensitive'?
• Do I need to put something together to be able to view the adminlogs, or are we OK with just recording those changes for now?
• Is there something else I should be doing in the Actionlog "Activity Report" - I don't know which icons I should use to represent things like "Permission Groups" or "Labels" or whatever?
• Are we OK with not adding new History tabs to the various objects that we're now recording?
• Should I be setting 'targets' on these actionlogs? I'm leaving them null for now
• I switched Location from using the Loggable trait to the new LogsChanges trait. I only saw one place where any logBlah() method was used (on 'restore' from soft-deleted) - and that use-case is at least fully subsumed by LogsChanges. Did I miss something, or are there any other reasons to stick with Loggable here?

[uberbrady]

Here's what you see when you look at the Activity Log -

[uberbrady]

I also did not add the history tab to all of those 'systems objects' - I'm just recording the changes in the action_log, is all (for now).

[snipe]

We also probably don't want Settings included in that general log.

[uberbrady]

Okay, I've made it so that Settings changes get logged to a separate table, and added a migration to create that table. Example contents:

+----+---------------------+---------------------+-------------+---------+--------------------+---------------------+------------+----------------------------------------------------------------------------+
| id | created_at          | updated_at          | action_type | item_id | item_type          | action_date         | created_by | log_meta                                                                   |
+----+---------------------+---------------------+-------------+---------+--------------------+---------------------+------------+----------------------------------------------------------------------------+
|  1 | 2025-11-05 14:46:53 | 2025-11-05 14:46:53 | update      |       1 | App\Models\Setting | 2025-11-05 14:46:53 |       1034 | {"default_eula_text":{"old":"my default eula!","new":"my default eula!!"}} |
+----+---------------------+---------------------+-------------+---------+--------------------+---------------------+------------+----------------------------------------------------------------------------+
1 row in set (0.01 sec)

[uberbrady]

Also - note - I did not build any way to actually view that new Adminlog table.