pages.updated_at should only be updated when a revision is made, or the page "Updated by" date should use the latest revision

[stephen-hill-safe-uk]

Describe the bug
When a user changes the sort order of a page within a book or chapter, the pages.updated_at field is updated (the updated_by field is not updated).

When viewing the page in the browser, the pages.updated_at field is used to display when the page was last updates. After a sort, this will give the wrong impression of who and when the page was last updated.

In the below image, no page content was modified, and the displayed user "Stephen Hill" did not perform the sort.

Steps To Reproduce

1. User "Abby" creates a new book with two pages.
2. User "Bobby" sort/re-orders the pages within the book.
3. The page displays that it was updated by Abby, on the datetime Bobby sorted the book.

Expected behavior

• The entity-meta.blade.php and entity-export-meta.blade.php templates should be updated to use the datetime and user of the latest page revision for rendering the "entities.meta_updated_name" string. This would give a clear indication of who actually performed a meaningful update to the page.
• Performing a sort should not update the pages.updated_at field.

Screenshots
entity-meta.blade.php output after the page was sorted. The last revision was over a year ago.

Your Configuration (please complete the following information):

• BookStack v0.26.2
• PHP 7.2.4
• Hosting Method: FreeBSD Jail, Nginx, PHP-FPM

Many Thanks
Stephen

[ssddanbrown]

Thanks for the request @stephen-hill-safe-uk.

I'd prefer not to base any dates off the revisions system, since there are options to prune and disable those. I can see why the current change to updated_at can cause confusion. I think it would be best to still have some indicator on the page-level of a order/location change, Maybe log activities against each item that's moved in a sort operation but leave the updated_at fields untouched?

[watschi]

Hi @ssddanbrown,
I'm using the BookStack API to generate weekly digests and send mails with updates on what sites where changed or created to users.
Re-ordering a book causes the page api filter (updated_at > last week) to return all pages within that book, preventing me from creating useful summaries.

I would appreciate if there was a way to log re-ordering pages in a different way and not touch the updated_at column.

Thank you,
Fabian

[c0shea]

I'm having this same issue. An employee who has since retired is showing as having last updated pages a couple weeks ago when his last revision to the page was months ago. As it turns out, all the pages in question are part of books that were recently sorted, which changed the updated_at timestamp and is now misleading.

At a minimum, I think the updated_at column shouldn't be updated when a book is sorted (or any non-user driven action to the page happens). If you still want an additional audit outside of the activities table to indicate when the page record was last modified, perhaps there should be a system_updated_at column or similar that can track any system-driven changes like sorting?

[amartinz]

This is still reproducable with v23.10.4.

To reproduce:

1. Login as user A
2. Edit a page as user A
3. Login as user B
4. Sort the book, move the page

See that last updated got refreshed, showing last edited by user A and set to the time user B sorted the book.

This caused confusion, as collegues assumed they work on the same page at the same time.

[c0shea]

We've continued to have this issue cause confusion with users. We store our scheduled job runbooks in BookStack, and someone thought that the instructions were recently modified because it had a new updated date in the sidebar. But, when looking at the page revisions (and we store all revisions with no purging), the page hadn't been modified in two years.

I think it makes sense to log the sort as an activity in the audit log and update the updated at date on the book itself when sorted, but all of the pages and chapters updated at should be left alone.

[WyattBest]

I also noticed and was confused by this. As I understand, the timestamp from a sort operation and the user from an edit operation are being munged together, resulting in an output like "Updated 2 hours ago by So and So" that isn't accurate.

Personally, I'd prefer the "Updated" label ignore sort updates and show the last revision, but it sounds like it may be a lot of work. An easy fix might be simply dropping the user, like "Updated 2 hours ago," when updated_at doesn't match the last revision timestamp.

[ssddanbrown]

It seems that sorting is the primary issue here relating to the timestamps.
With the merge of #5457, basic sort/priority changes (automatic or manual) will no longer affect timestamps.
Note, that any more substantial changes, even via the sort interface (for example, location changes) can still affect timestamps.
These changes will be part of the next feature release.

I think this should address the most common issue expressed here, so I'm going to therefore close this off, but new specific issues can be raised if remaining scenarios are particular problematic.