Track duplication IDs

[ahankinson]

An idea, from a conversation on Slack with @jenniferward:

Since record duplication is pretty common among our users, it would be handy, even from the developer side, to know both a) whether a record originated from a duplication action and b) what record it was duplicated from.

Since we don't necessarily need this in the MARC data, I wonder if adding a NULLable origin_id (or some other name) to the database would work? Then when the record is saved, the value from the existing_title query parameter could be stored there.

I had a quick look and I couldn't see anywhere obvious that this was already being stored.

This would apply to all types where the user can create a new record by duplicating an existing one. I think this is sources, works, publications?

[lpugin]

It makes sense to track it. I am not fully convince we need this in the database, though. I would suggest storing this in a local read-only marc field.

[xhero]

I was going to say the same, why not a read-only marc field? From the Muscat side it is a bit cleaner

[ahankinson]

Well, I thought about that. It's not really part of the "record" though... Two books that originate from duplicate IDs can be completely different in content, so storing the ID in the MARC record for an otherwise unrelated source seems to be an internal Muscat thing, rather than intrinsic to the bibliographic record.

I see it more like one of the wf_ fields (published, unpublished, etc.), which we don't store in the MARC record.

[lpugin]

It is essentially a data creation process. They do not really have a relation any more once the record has been created and modified. I agree this is not directly part of the record, but I see it more like an internal notes. So something like the 599 but we probably need another one to make it read-only so cataloguers will not remove it.

[jenniferward]

Can we throw it in the version history, so when we look at the history we see it was derived from a different record?

[lpugin]

I think we can make it visible in the record preview. Wouldn't that be even simpler?

[xhero]

I'm not sure you can take an initial snapshot, ~duplication is done in the fronted and not in the backed, and the version will not be saved until you save from the editor. The duplicate record acts as a new record without an ID.~ OK no I'm wrong it is done in the backend so I imagine we could try saving it beforehand? I still prefer adding one note field...

[xhero]

Something like this? We propose a new dedicated field 981, with the origin ID and the date. Any preference on how to format the date?

[ahankinson]

Maybe "Original" instead of "Origin"?

[xhero]

Yes yes give me time to make the labels :)

[HirschSt]

Any preference on how to format the date?

Probably only date without time

[ahankinson]

Time would be a good thing to include since duplication events may happen multiple times in one day.

[jenniferward]

Catalogers shouldn't be allowed to delete this field because it would defeat the purpose:

[jenniferward]

Upon saving, the Date appears above Original record:

Can it be preserved in the same order the the Edit mode has? ID first, then date

[xhero]

Oops I forgot to make it non deletable. I will see for the show page, it is one of those easy things that are not super easy...

[xhero]

What about this?

[jenniferward]

That's great, and gives context to the date as well. Did we say unlinked though for the ID?

[xhero]

yeah but since I was making a partial anyways...

[ahankinson]

Work records can also be duplicated. It would probably make sense to do the same thing for those too?

[jenniferward]

So can Secondary Literature, while we're at it.

[xhero]

981 everywhere?

[jenniferward]

We can't duplicate the other authorities (not sure if we need to).

[xhero]

No I mean, should we use the same tag 981 in Works and Institutions ;)

[ahankinson]

Yes. (s/Institutions/Secondary Literature/g? ^^^)

[xhero]

oops yes :)