refactor: separate activity occurrence dates from creation dates

[anonymoususer72041]

This PR separates the functional occurrence timestamp of activity records from their technical creation timestamp.

PR #758 made it possible to log activities with a manual date and time, but the manually selected activity timestamp was stored in activity.date_created. That made the activity timeline behave as intended, but it also changed the meaning of date_created: instead of always representing when the database row was created, it could represent when the activity occurred.

This PR adds a dedicated activity.date_occurred column and backfills it from the existing date_created values so that existing activity timelines keep their current ordering and displayed timestamps after migration.

Manual activity dates are now stored in date_occurred, while date_created is always set to NOW() when a new activity row is inserted. Editing an activity date also updates date_occurred instead of overwriting date_created.

Activity timelines, activity grids, date filters, activity statistics, and latest-activity lookups now use date_occurred as the functional activity timestamp. Existing output aliases such as dateCreated, dateCreatedSort and lastActivity are intentionally kept unchanged to avoid unnecessary template and JavaScript changes.

This restores date_created as the technical record creation timestamp while preserving the user-facing behavior introduced by manual activity dates.

[anonymoususer72041]

@RussH do you want to add merging this PR on our #736 to-do list?

[anonymoususer72041]

@RussH I highly suggest to review this PR before creating the v0.9.8.0 release otherwise the database migration might result in unexpected results.

[RussH]

Thanks — as always this is a good PR. Separating date_occurred from date_created makes sense, and backfilling it from date_created during migration will work.

I think there is one functional issue to fix before merge: in ActivityEntries::add(), $dateOccurredSQL is calculated and passed into sprintf(), but the new date_occurred value appears to be hardcoded as NOW() in the INSERT values list. That means a user-selected activity date may be ignored and stored as the current timestamp instead?

Suggest you update the INSERT so date_occurred uses $dateOccurredSQL, while date_created and date_modified remain NOW().

One other small migration question: is ALTER IGNORE TABLE needed here? Since this is adding a new column rather than resolving duplicate rows, plain ALTER TABLE would be preferable and would be more future-safe for any newer MySQL/MariaDB versions.

=> Otherwise, can you rebase against master so it'll merge without conflicts?

[anonymoususer72041]

I think there is one functional issue to fix before merge: in ActivityEntries::add(), $dateOccurredSQL is calculated and passed into sprintf(), but the new date_occurred value appears to be hardcoded as NOW() in the INSERT values list. That means a user-selected activity date may be ignored and stored as the current timestamp instead?

Suggest you update the INSERT so date_occurred uses $dateOccurredSQL, while date_created and date_modified remain NOW().

I double-checked the current branch and date_occurred should already be using $dateOccurredSQL. The INSERT column order is date_occurred, date_created, date_modified and the corresponding values are %s, NOW(), NOW(), with $dateOccurredSQL passed into that %s.

So the manually selected activity date should be stored in date_occurred, while date_created and date_modified remain technical timestamps.

That said, a manual test would probably be helpful here to make sure the behavior is clear end-to-end: create an activity with a manually selected past/future date and verify that the timeline displays/sorts by that selected date, while date_created remains the actual row creation time.

One other small migration question: is ALTER IGNORE TABLE needed here? Since this is adding a new column rather than resolving duplicate rows, plain ALTER TABLE would be preferable and would be more future-safe for any newer MySQL/MariaDB versions.

Good point on the migration. I think the ALTER IGNORE TABLE was mostly me following the existing migration style a bit too rigidly. Since this migration only adds a new column and does not need to resolve duplicate rows, I agree that plain ALTER TABLE is preferable here. I will update that.

[RussH]

Thanks — this looks good to me now.

Looks like you’ve made the requested changes. Assuming CI passes, I’m happy to merge this.