Distinguish system and user updates more precisely

[nicolasfranck]

Current situation

Currently when system updates happen, the field date_updated is affected, and therefore affects the place of the record in the index.

Examples of system updates are:

• adding handles
• clearing embargo dates

This however generates a "weird" behaviour where records that were previously pushed to the end by a user update (because sorting is set to "Updated (oldest first)"), suddenly reappear on top some time later, which may be annoying if you use this sorting option to see what records need attention.

What currently happens:

• field date_updated stores date of latest update
• on user update:
  • date_updated is set to current time
  • user_id is set to id of user
  • last_user_id is set to id of user
• on system update:
  • date_updated is set to current time
  • user_id is set to empty value
  • last_user_id is kept as a trace to the last user that updated the record

So in case of a system update, we only know:

• the time of the current update, tracked by date_updated
• the last user that made a change before that system update, tracked by last_user_id
• but not the time at which that last user made his/her change.

Proposal 1

Distinguish user and system updates more precisely. Now some fields are shared between user and system updates (which requires inspection). In a first version I would not change that, but opt for the following:

• add field like last_user_date_updated to track the time at which the latest user update was done.
• set index field date_updated to
  • last_user_date_updated when present
  • date_updated if previous field was not present

In order to reach this state the following conversion would be needed:

• user_id is empty: set last_user_date_updated to empty as we currently do not have this information anymore.
• user_id is not empty: set last_user_date_updated to current date_updated