itemKey for merged item

qqbb

It seems to me that the behavior of the merge function changed, but I could be mistaken. Could you please confirm or deny the following change?

Previously, when merging two items, the merged item had the itemKey of the older item, irrespective of which item was selected as the master item. Now, the merged item will have the itemKey of the master item.

In my view, preserving the older itemKey irrespective of the choice of the master item would be the preferred behavior. With the current behavior, if you are using a zotero://select link e.g. for a preprint, this link will become invalid once the preprint is merged with an updated version.

bwiernik

Are you sure the links become invalid? Both keys are retained in the database during merge. The key for the item bot used as the master is stored with a ‘sameAs’ relation to the retained item. Any function relying on keys (e.g., word processor citations) then redirects from the non-retained item to the retained item.

dstillman

(Merged items are actually dc:replaces, not owl:sameAs.)

I don't think we check 'replaces' for zotero://select links. We could do that.

We do check them for word processor citations, so that should work.

dstillman

I don't think this has actually changed in the way @qqbb describes, though.

In 5.0.66, we started setting the Date Added of the oldest item on the master item, but that was simply about the date — before that, we were still retaining the selected master item and its key and marking it as replacing the non-master items.

dstillman

Redirecting zotero://select gets a little complicated. We could have zotero://select/library/items/AAAAAAAA look for a dc:replaces pointing to AAAAAAAA, but what about the new zotero://select/library/items?itemKey=AAAAAAAA,CCCCCCCC syntax? Should that also look for replacements for each key?

In the HTTP equivalent, example.com/items/AAAAAAAA would redirect to example.com/items/BBBBBBBB but example.com/search?q=AAAAAAAA probably wouldn't return BBBBBBBB in search results.

qqbb

Thanks a lot for looking into this issue! If redirecting the links causes unwanted complications or costs performance, it might not be worth it. Simply always assigning the oldest itemKey as the key for the merged item would already be very helpful and fulfill my use cases.

dstillman

No, that part isn't going to change.

qqbb

Ok, then redirecting the links would be very welcome. Otherwise many zotero://select links might become invalid when updating items.