activity logging

Initial pass at activity logging was confined to ‘shift’ activity, and was handled with a ShiftActivity class, related to a shift, and updated with various information during different shift activities (creation, updates, clockin, etc).

The ‘shift activity’ code is still in place, but is being superseded by the general ‘activity’ log - using a package from Spatie - https://docs.spatie.be/laravel-activitylog

The default migration was modified to use ‘string’ for the target id fields, because we currently have a mix of ID field types for different tables (integers, strings, ulid, uuid). That may get normalized over time, but the activity log table may need to remain firmly in the ‘generic string id’ camp for historical purposes.

concerns

size

The activitylog package config will prune entries over 1 year old - we may want to configure this in future to hold more, or, look at migrating the data to an archival table. We could, when showing ‘regular activity’, show a note indicating that ‘activity shown only goes back 6 months’ (or 12 or whatever we decide to keep).

migration

docker-compose exec app artisan migrate:shiftactivity

A ‘MigrateShiftActivity’ command was put in place to migrate existing ShiftActivity entries to the generic activity log. This is to accommodate new ‘activity view’ code which now uses the activity_log table (and Activity model from the spatie package).

Initially this was going to be run as an automatic ‘migration’, but… the time it will take to convert 40000+ shift activity entries is close to an hour. This command will need to be run after a push to production, and may take an hour or so to complete.

The data is in place, and still being collected, but may not show up on production until after the migration is run. It may still not show up ‘correctly’, and may require another round of format/code to rectify.

The data formats between the logs are slightly different, so some of the data format/display may necessarily end up looking slightly different from before, but the core data should all still be in place.

After migration/acceptance, the ‘ShiftActivity’ code will be removed altogether. It’s currently left in place as a redundant logging backup.