Two new fields: wf_edited_by and wf_event?

[fjorba]

Most of Muscat main tables have workflow (wf_*) fields like:

• wf_owner, integer, stores the user id who created the record.
• wf_stage, integer, stores the record status (published, unpublished, deleted).
• wf_audit, integer, stores other values like minimal, full, basic, imported, etc.

I tried to understand how paper_trail works, and how it fits into Muscat (as like any other Rails application), and I learned that paper_trail "stores the pre-change version of the model" (https://github.com/paper-trail-gem/paper_trail?tab=readme-ov-file#1c-basic-usage), but not the current one, that lives in standard Rails table. Paper_trail uses two fields to keep who did the last change (whodunnit) and which event created this last change (event).

With this knowledge, many months ago we were able to create an export and import procedure to migrate all our record history from Invenio into Muscat (currently 4,601,595 versions for our largest database).

However, as we are testing our Muscat instances, we noticed that there is no fields to store the equivalent of the the whodunnit or event fields into the current version of the record. Those fields should be the ones that would mutate into paper_trail versions table when a new version of a record is updated (whodunnit probably should store the text identification of the user). Otherwise, we cannot know who and how the record was last modified, and audit it.

So, we are interested in two new fields, and I'd like to ask whether this need could be shared, and part of standard Muscat:

• wf_edited_by, integer, should store the user id of the last person who edited the record. I propose this name as whodunnit is quite ugly and the meaning not obvious (at least it was not obvious to me!).
• wf_event, text, would be the equivalence of the event field of the versions table. One clear value would be "Muscat editor" if the record was manually edited by a person, and some identification of the program o procedure if the update was done by a program (we do many updates via automated procedures). Unless I've messed up our instances (which I cannot discard), now it always says "update".

During the last weeks I have done some ugly hacks to overcome this limitation without altering Muscat database schema, but the more it goes, the more I feel that this is fragile and probably the solution could be solved in Muscat itself.

Would you accept patches and migrations to initially create the fields? Updating them (should be automatic) and displaying them would be a second phase.

[fjorba]

Let me make ask it in another way: in your Muscat instance at RISM, can you know who did the last modification of a record? (Or which program, if it was an automatic correction or update.) And the list of all people who modified it (and when and what, of course)? Would you be interested in this information?

[xhero]

@jenniferward @lpugin What do you think? In theory we can use the versions to know who made a snapshot, but not all events are always snapshotted.

[ahankinson]

wf_event is similar to the "commit message" idea we've been throwing around...

[xhero]

true, it could have a default value or some message users can add

[lpugin]

Yes, I think this is a similar idea. It should be also in the version history, maybe simply be using it int the versions.event column?

I agree we need a default message, because otherwise people just put subjective information (e.g., "minor changes")

[fjorba]

Not really, the wf_event should be automatic and, as we have been using are, for example:

• Muscat editor
• Modified via person authority
• Modified via person merge
• fix773g (or any other automated program)

Except for the last one, all they also have the person (user id) who has edited or merged the records. It is not needed to explain it, like a git commit message, it is automatic.

I have it working in my instances, but reusing unused db fields. I'd prefer to have them right.

[lpugin]

A problem we had when storing the user as id in versions was when a user would eventually be deleted. That might be an issue with wf_edited_by too.

[fjorba]

That's why I proposed that in the versions table the whodunnit field should mutate into a text version of this user. We store the email address.

However, probably a better policy would be to never delete users, just mark them as deleted.

[fjorba]

OTOH, the problem of deleted users also happens now with wf_owner, that keeps the user id.

[lpugin]

Yes, but it makes sense to require for the owner of a record to be changed before you can deleted a user.