copy tags are being created with the a library short name in the label

[Dale Rigney]

When adding a copy tag to an item in the copy editor a new tag is being created that adds the shortname of the working location of the workstation to the tag.

To duplicate do the following:

1) Create a copy tag type and tag: Type = Bookplate, value = 'In Memory of Richard', Owned by any library. In for me it was Branch 1 (Shortname = BR1).
2) Edit any item click on the Item Tags button
3) In the Manage Item Tags window Select Tag Type = Bookplate.
4) In the Tag box start typing your Label of In - you will see a selection of tags and the owning lib of that tag in parenthesis. For me it was 'In Memory of Richard (BR1)'
5) Choose your tag and click the Add tag button.
6) in the Editor click on the Save & Exit button.

You will see the tag added was not the original tag of "In Memory of Richard" Evergreen created a new tag with the tag type = Bookplate and the Label and value both equal to "In Memory of Richard (BR1)".

If you attempt to add that tag to another copy the new tag you see the following selections: "In Memory of Richard (BR1)" and "In Memory of Richard (BR1) (BR1)" in the tag drop down box. If you select the first no new tag will be created but if you select the 2nd option a new tag will be created with "In Memory of Richard (BR1) (BR1)" as the label and value of the record. A third attempt to add that tag to another copy and your selection will be "In Memory of Richard (BR1)", "In Memory of Richard (BR1) (BR1)" and "In Memory of Richard (BR1) (BR1) (BR1)" ect...

If you add a tag owned by another branch for for example the "In Memory of Richard" owned by the System (shortname = SYS1) the new tag will be ""In Memory of Richard (SYS1)" but the owner of that tag would be the branch of the workstations. Which will show up as "In Memory of Richard (SYS1) (BR1)" when you go to add it another item.

[Lugene Shelly (lugene)]

Affecting SPARK libraries. One library reported they first noticed it happening after Feb 19 2019.

[Ron Eifert (reifert)]

This did not affect our library until April 23, 2019. The process worked fine for me until lunchtime on this date, and was not working at all after that time.

[Blake GH (bmagic)]

Some additional troubleshooting reveals that the Copy Tag management interface doesn't show all of the tags that you can see in the database.
In my example on a copy of production data, we have a copy tag defined like this:

label: "CDNFGrant"
Value: "This item purchased through the 2019 Public Library Nonfiction Collection Development Support Grant from the Missouri State Library."
staff_note: "CDNFGrant"
pub: true

And for some reason, there is another definition in the database:
label: "CDNFGrant (SKPL)"
Value: "CDNFGrant (SKPL)"
staff_note: ""
pub: true

When using the UI:
eg/staff/admin/local/asset/copy_tag
I only see the first one and not the second one

When attaching items to the copy tags and interacting with the free-type box. The suggestion dropdown menu only offers the second copy tag listed above (which is not browseable in eg/staff/admin/local/asset/copy_tag). In this example, when I type "C" into the box, the suggested dropdown menu contains a single entry for the second definition listed here.

Funny enough, if you do not choose from the suggestions and manually type the label exactly as it is in the database, it will save the copy tag to the item.

Couple of questions:

1. How did the apparent duplicate copy tag make it into the database?
2. When typing in the free-type box when assigning a copy tag: why does it not suggest all* matching tags (where label starts with "c")?

Answering these will most likely identify the bug in code.

[Mary Llewellyn (mllewell)]

I can testify that for us, copy tags worked correctly in mid-May when we were on 3.1.8. We upgraded to 3.1.11 around the end of May. I hadn't worked with copy tags after the upgrade until this week, when I found the tags displayed in the OPAC were not the values but the labels with the org unit in parentheses.

[John Merriam (jmerriam)]

It appears this is due to the change made in LP#1746769

https://bugs.launchpad.net/evergreen/+bug/1746769

The Git commit is here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/cesardv/lp1746769_add_item_tag_owner_to_label

If that change is reverted, the problem goes away.

It seems to me like the owning library was added to the actual copy tags. We do not want that. I believe the correct behavior would be to just display the owning library in the web interface and not add it to the actual tag.

[Mary Llewellyn (mllewell)]

I tested what happens when 2 libraries create tags with the same name. As long as they are properly "owned" then when adding a tag to the item, only the tag belonging to your library is available to select. For example, 2 libraries add a Friends tag, one saying "Gift of Friends of X Library" and the other saying "Donation of the Friends of Z Library." When adding an item to X library, the tag list will say "Friends" and the value displayed in the OPAC will be the note referring to X library.

The only way I could see confusion is if somehow someone were looking from a consortial view (or system view in a multi-branch system.) Otherwise, we don't see a need to have the org unit added to the tag label.

[Heather Lindskold (heatherlindskold)]

Confirming that this is still impacting PaILS not only in our current 3.1 installation but also in our updated-to-3.3 test server.

[Jason Boyer (jboyer)]

There's a patch at https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1825403-copy-tag-owner-display / working//user/jboyer/lp1825403-copy-tag-owner-display that fixes the copy editor and also adds owning location display to the Apply Tags feature of Copy Buckets.

[Mike Rylander (mrylander)]

Thanks, Jason. That all works for me, and is pushed to master back through 3.1.