fix(userstatus): Track message timestamp too

[ChristophWurst]

• Resolves: [Bug]: User status widget shows incorrect relative timestamp #40558

Summary

Add new database column to track the message change date.

The fix requires a database schema change and data migration. I would vote against backporting.

How to test

1. Set up user A
2. Set up user B
3. Log in as A
4. Log in as B in a private window
5. Set your status to DND and the status message to "test" as user A
6. Wait 2 minutes
7. Set your status to online as user A (do not use the Save status message button. Online status change doesn't need a confirmation)
8. Open the dashboard and recent statuses as user B

master: User A shows "test, seconds ago"
this branch: User A shows "test, 2 minutes ago"

Screenshots

Before	After

TODO

• Adjust schema
• Adjust db layer
• Adjust dashboard widget
• Test
• Update branch after fix(userstatus): Sync migration version number with app version #40614

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[nickvergessen]

could skip this migration by going with default => 0 on the column

[Antreesy]

🦭

Tested with my 0-PHP-knowledge, works fine for custom statuses.
Should it also work for predefined ones, like "Commuting"?

Also noted:

• upgrade to 1.8.1 works smoothly, status is saved
• downgrade to 1.8.0 breaks the instance, but that should be expected, i guess

[nickvergessen]

downgrade to 1.8.0 breaks the instance, but that should be expected, i guess

Unfortunately yes. YOu can manually delete the column from the database table (but that will break on updating, unless you also remove the row in oc_migrations table, so I personally would prefer to reinstall)

[nickvergessen]

Should it also work for predefined ones, like "Commuting"?

When selecting them I guess yes. When they fade (because clearAt was reached) and you turn into "Away/Online" I guess also yes?

[ChristophWurst]

When they fade

Right! Forgot to test those.

When the predefined statuses are selected they should definitely update the status message timestamp.

[ChristophWurst]

When they fade

Right! Forgot to test those.

Going from a preset status (or custom status) to no status erases the database entry. There is no record of the change on the recent statuses widget. I would say this is the expected behavior, because there is no recent status to list.

[nickvergessen]

Going from a preset status (or custom status) to no status erases the database entry.

Right, then that's how it is

[nickvergessen]

Restoring from backup status (e.g. custom status > join a call for IN_CALL hardcoded one > leave call again) should also update the timestamp? Or not?

[ChristophWurst]

Phew. It's getting complicated.

If we update the status message timestamp when an automated status is entered, it should also update when that status ends and the previous status is restored from backup. Con: status shows as updated at restore when the user didn't update it themselves.

1. "Working remotely, 2h ago"
2. "In a call, 28 min ago"
3. "Working remotely, 4m ago"

Alternatively, we can not update the timestamp for entering/leaving an automated status. Pro/con: automated statuses don't show on the recent statuses widget.

1. "Working remotely, 4h ago"

@jancborchardt are you okay with the first second approach? It's easier to implement.

[ChristophWurst]

Integration test suite added so we can be sure the strange edge cases all work as expected ☺️

[ChristophWurst]

@Antreesy @nickvergessen if you are okay with the current solution we can integrate this (and unblock #40559). If we decide that automated/backup statuses should update the timestamp as well we can still change that behavior later on 👍

[nickvergessen]

if you are okay with the current solution we can integrate this (and unblock #40559). If we decide that automated/backup statuses should update the timestamp as well we can still change that behavior later on 👍

Agreed