Wikipedia-style edit log for catalog records

[Jane Sandberg]

This idea has come up over and over again!

It was also the subject of a recent Cataloging and Classification Quarterly article, for those with institutional or ILL access: https://doi.org/10.1080/01639374.2019.1597005

[Lynn Floyd (lfloyd)]

I would love to know who changed what in a Marc record at a glance.

[Meg Stroup (mstroup)]

I would also like to see this feature. It would be extremely helpful when a MARC record has evolved over a long period of time and even for trying to remember how you yourself have changed/fixed/enhanced a type of record previously. It's an additional learning and teaching tool.

[Tiffany Little (tslittle)]

+1 for this feature. This would be particularly awesome in large consortia like PINES where we all own the same record and there are many catalogers with access to edit the record.

There's already auditor.biblio_record_entry_history (http://docs.evergreen-ils.org/3.1_schema/_schema_auditor.html#_biblio_record_entry_history) which pretty much has what I'd be interested in seeing. We would just have to figure out how to only show the difference in the marc column between two edits, and doing the color styling to show additions/subtractions.

[Jeff Davis (jdavis-sitka)]

I think it would be helpful to state the requirements more explicitly. Here are my suggestions of what this new feature might include, in order of importance:

1. A paged chronological display of all edits, listing the user responsible and the timestamp of the edits.

2. The ability to click on a link in the edit log and view that version of the record.

3. The ability to compare any two versions selected from the edit log. The versions are displayed side-by-side, with color highlighting to indicate the changes.

4. A filter function on the edit log, to limit the edit log to show all edits by a particular user or org unit, etc.

5. The ability for the user to provide a summary of their changes when they edit a record. This edit summary would be displayed on the edit log.

6. Discussion pages for individual records.

It seems to me that #1 and #2 are the basic requirements, #3 would be really nice, and the others are optional at best. Does that sound right?

We can use auditor.biblio_record_entry_history as the basis for an edit log, but there are a few challenges. First, that table shows the *previous* version of the record -- that is, it shows what the record looked like before it was edited, not the results of the edit; the edit log would need to take that into account, which will likely be cumbersome. Second, the table records any changes to biblio.record_entry, not just changes to the MARC; we'd need to figure out whether (and how) to display changes to quality, source, last_xact_id, and so on. Maybe we could create a new view in the database, drawing on the auditor table but smoothing out the cumbersome parts automatically, and then use that view as the data source for the edit log?

One last thought. When different institutions share the same records, this feature will allow Library A to see the changes that Library B has made to "their" record. This is a good thing and it makes sense for Evergreen to support it. However, it could lead to delicate situations depending on your consortium's politics and policies.

[Tiffany Little (tslittle)]

I guess because my mind equated this to the Acq line item history, I was thinking of this in terms of an Angular eg-grid. That would take care of points #1 and #4.

As far as the diff in point #3, my brain thought of something similar to the diff on a Git branch where it doesn't show the entire new record, but only the old (red) and the corresponding new (green) info. So I wouldn't necessarily need #2, personally, although that may appeal to others. And I don't think that's incompatible with an eg-grid, either, since you could just turn one of the columns/fields into a link that would display the previous MARC in a new tab. So for me, from your list #1, 3 and #4 would be what I would want to see. I don't think I'd be in favor of #6 simply because I wouldn't want bib records to turn into a chat/forum thing; I'd rather commentary was on a listserv or somewhere out of the ILS.

As far as seeing all of the table, not just the MARC, I *would* want to see any of those changes that are logged in that table--so like I would want to know that the record had been merged and who did it, or if the source changed, etc. I take your point about the limitations of the table not showing the most recent edit, though.

So I guess my thought was more like building out an eg-grid--which we already use--and then fiddling with the more difficult pieces, rather than a completely different kind of interface. That may not be what others want, though, so that's only my $0.02.

[Elaine Hardy (ehardy)]

For my purposes, #1 and #4 would be the basic requirements. I want to know who edited what field and I want to be able to see other changes they made to see if they made the same sort of edit on multiple records.

My purpose, by the way, would be to see where someone either made an erroneous edit or one that violated PINES cataloging policy (edited the 300 from 1 online resource to 1 volume (unpaged), for example)

I just need to see the field that was edited and don't need to see the different versions of the record as in #2 and 3.

I don't see catalogers being able to take time to provide a summary, so I don't know that that is necessary.

What would be really nice, is if the edit log could tell me what was edited by whom as the item was imported via the Z39.50 interface, but before it was saved. But I can see where that wouldn't be possible since the record doesn't exist in the logs yet.

[Ruth Frasur Davis (redavis)]

In my mind, #1 is the necessary action. Also, #4 though I'd like a date filter. From my understanding, this information is contained in audit tables that are configured very differently across Evergreen deployments. In some cases, these are retained for 3 months. In the case of Evergreen Indiana, they are retained for 9 months. I suspect there are places that retain the data in these tables for a year or longer.

As I'm thinking about all of this, I'm also thinking about the performance of equipment and the efficiency of the software. If we're talking about being able to view various versions of a record, that means that all of those versions need to exist somewhere - server space. The more "stuff" we create (directories, tables, files), the more space we need. The load on systems, etc.

If we can utilize what's already being generated and just find a way to render what's in the tables in some human readable format, we get the information we're looking for without adding a great deal of bloat in the databases.

Jeff also made a really great point. "One last thought. When different institutions share the same records, this feature will allow Library A to see the changes that Library B has made to "their" record. This is a good thing and it makes sense for Evergreen to support it. However, it could lead to delicate situations depending on your consortium's politics and policies."

Accessing this information should be reserved for those individuals identified as knowing how to hand such information in an appropriate and professional manner.

[Jason Stephenson (jstephenson)]

I set this bug to "Confirmed" because at least 5 to as many as 8 people have reported this wishlist bug as affecting them based on the heat at this time (40).