Added command to fix bulk checkin action log entries

[marcusmoore]

Background

A recent PR, #16489, fixed an issue where action_logs.created_by was being recorded as null and action_logs.created_at was being recorded incorrectly when bulk checking in accessories (other bulk checkin entries recorded correctly).

This PR

This PR adds a command, snipeit:fix-bulk-accessory-action-log-entries, to fix both created_at and created_by for the entries mentioned above.

created_at was being recorded as ~1970-01-01 00:00:01 and since updated_at was recorded correctly, we can use created_at being in 1970 as a way to update created_at to the updated_at timestamp.

created_by is a little more tricky. Since other bulk checkins were being recorded correctly, this command looks to find the user_id by using each action log entry that has the 1970s issue mentioned above to find a matching log entry that has created_by populated. Put another way, if a user did a bulk checkin including accessories, where created_at and created_by would be incorrect, and the checkin also included checkins for assets, licenses, etc, we can use those entries to populate created_by.

---

Example output from a dry-run:

└─[$]› art snipeit:fix-bulk-accessory-action-log-entries --dry-run
This is a DRY RUN - no changes will be saved.

Found 5 logs with incorrect timestamps:
+-----+------------+---------------------+---------------------+
| ID  | Created By | Created At          | Updated At          |
+-----+------------+---------------------+---------------------+
| 474 |            | 1970-01-01 00:00:01 | 2025-03-11 22:47:44 |
| 478 |            | 1970-01-01 00:00:01 | 2025-03-11 22:50:32 |
| 483 |            | 1970-01-01 00:00:01 | 2025-03-11 22:56:14 |
| 501 |            | 1970-01-01 00:00:01 | 2025-03-11 23:20:03 |
| 503 |            | 1970-01-01 00:00:01 | 2025-03-11 23:21:32 |
+-----+------------+---------------------+---------------------+

DRY RUN. NOT ACTUALLY UPDATING LOGS.

Processing log id:474
Updating log id:474 created_by to 1
Updating log id:474 from 1970-01-01 00:00:01 to 2025-03-11 22:47:44

Processing log id:478
Updating log id:478 created_by to 1
Updating log id:478 from 1970-01-01 00:00:01 to 2025-03-11 22:50:32

Processing log id:483
Updating log id:483 created_by to 10
Updating log id:483 from 1970-01-01 00:00:01 to 2025-03-11 22:56:14

Processing log id:501
No created_by found for log id:501
Skipping updating this log since no similar log was found to update created_by from.

Processing log id:503
No created_by found for log id:503
Skipping updating this log since no similar log was found to update created_by from.

DRY RUN. NO CHANGES WERE ACTUALLY MADE.

[what-the-diff]

PR Summary

• A New Console Command Introduced
  A new console command has been added to the system: FixBulkAccessoryCheckinActionLogTimestamps. This is planned to rectify specific inaccuracies identified in our log timestamps and in cases where the created_by value is missing in bulk check-in entries.

• Testing Functionality Added
  An additional feature now allows users to simulate data alterations without actually applying changes in the database by using a --dryrun option. This helps to review and verify the potential changes beforehand.

• Detection of Incorrect Log Timestamps
  A logic has been incorporated to find and list logs possessing wrong timestamps, particularly ones misdated around the 1970s. This list is then presented in a structured table format for easy interpretation.

• Method to Retrieve Missing Created_by Attributes
  In cases where bulk check-in entries are missing a created_by attribute, a method has been developed to find a similar log and extract the information from there.

• Refined created_at and created_by Log Entries
  Amendments have been made to these log entries, retrieved from similar logs. This reconditions and standardizes the logs maintaining its database integrity.

• Confirmation before Updates
  Updates to the database entries will only take place once they are reviewed and confirmed by the user. There is an option to skip updates if desired, ensuring full control over data modifications.

[marcusmoore]

@snipe one question: should I include doing a backup before actually updating the logs?

[snipe]

This looks great, thank you @marcusmoore! Regarding your question, I think maybe backing up by default but allowing a --skip-backup flag might be useful.

[marcusmoore]

Sounds good. I'll add that.

[marcusmoore]

@snipe added automatic backup with option to skip via --skip-backup.