Evergreen

Bug #1828279
Comment #4

Comment 4 for bug 1828279

Revision history for this message

Jeff Davis (jdavis-sitka) wrote on 2019-05-24:

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.

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.