Item tags not scoped in Angular Holdings Editor in 3.8

Testing in 3.9, same problem with scoping. Also need to add other observations:

Not scoped to the library workstation; seeing all libraries' tags, not even labeled ownership. Also ignores the tag type, like finding a bookplate tag when looking for an award tag. Can't see tag until after clicking on Apply All and Save then re-opening the tag interface.

Tag will not delete from item in Holdings Editor. You can delete it from Holdings View Action menu Add/Manage Item Tags.

In 3-8, I can confirm some of what Mary reported. When applying an item tag to an item, I can view and select from item tags owned by other libraries, but only if those item tags are associated with item tag types owned at the consortium level.

When applying an item tag, I did notice that I was seeing tags that were not associated with the selected tag type. But, I think this was a caching problem. I did not see this after clearing my cache.

Here's a fix that's working in our local 3.9 installation:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jwoolford/lp1965447-scope-item-tag-by-org

I have tested Terran's proposed fix on her test server.

Note: for testing purposes, I added a number of item tag types and item tags owned at the system and branch levels.

Steps followed:

I logged in as a BR1 user
In the holdings editor, I selected "Item tags"
Only tag types owned by BR1 and its ancestors (SYS2, CONS) were displayed

I selected an item tag type owned by CONS (Digital Bookplate)
Only item tags associated with this tag type and owned by BR1 and its ancestors (CONS, SYS1) were displayed
I selected an item tag from the menu
I selected "Add Tag" and "Apply Changes"
I saved the item and exited
The item tag displayed correctly in the Patron OPAC View
Note: tags display twice in the Bootstrap catalog. I am not sure if that is the intended behavior. See https://terran-testbox.gapines.org/eg/opac/record/33 as an example

Next, I logged in as BR4 user
In the holdings editor, I selected "Item Tags"
Again, only the appropriate tag types (e.g. those owned by BR4, SYS2 and CONS) displayed on the dropdown menu

I selected an item tag type owned by BR4 (BR4 Grants)
Only item tags associated with this tag type and owned by BR4 were displayed
I chose an item tag from the menu
I selected "Add Tag" and "Apply Changes"
Apply all, Save, and Exit
The tag displayed correctly in the Patron OPAC View

Note: in order to create new item tag types and item tags, I added the needed permissions for a BR1 user (br1bbrown). Using this login I was able to create an item tag and to associate this tag with an item tag type owned by BR4. As noted above, in the holdings editor, only item tag types owned by the user's working location or its ancestors are displayed. However, I think the item tag type and item tag configuration interfaces may need some tweaking to prevent errors when adding or editing item tag types and item tags. This may warrant opening a new bug.

Hi Beth,

You mentioned that entries displayed twice in the Bootsrap catalog. That is with or without Jessica's patch right? Assuming they do it sounds like the patch worked for you. Are you signing off on it?

Hi Rogan,

Thanks for the nudge.

I tested the code on Terran's test server and I assume that it included Jessica's patch. But, I can't comment on the Bootstrap display otherwise. The duplication of tags may be related to this bug which Terran has marked as invalid: https://bugs.launchpad.net/evergreen/+bug/2002174

I have tested this code and consent to signing off on it with my name, Beth Willis and my email address, <email address hidden>.

Upon reviewing the patch, a question:

The proposed patch restricts the choice of tags to those owned by the user's workstation OU and its ancestors. However, the AngularJS holdings editor also included tags owned by the descendants of the workstation OU.

Which behavior is preferred?

Descendants sound like they would be acceptable, too. We don’t have many multi branch libraries, so we weren’t exploring that situation. As long as the library don’t see tags from other libraries that they are not related to, that is the behavior we want.

I think that the current behavior is preferable. Much like shelving locations, if a tag is specific to a particular branch, it should be available to that branch only. If that tag is relevant to multiple/all branches within a system, it should be owned at the system level and available for use by the system's descendents.

Beth, to clarify, you want workstation OU and ancestors, but not descendants?

Hi Galen,

Yes, that would be my preference. Thanks for simplifying!

I would agree with Beth that having workstation OU and ancestors is fine - we can use system-level tags for libraries with system-level cataloging.
I don't see this on a test server for bugsquashing week but I'd be happy to take a look at it if it's available.

So following the discussion, merged in its current form for the upcoming releases.