Web client: branch library shelving locations not visible to HQ workstation

Bug #1739460 reported by Elaine Hardy on 2017-12-20
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Evergreen
High
Unassigned
3.0
Undecided
Unassigned

Bug Description

In the copy editor and vol/copy template editor, CAT1s, when logged into headquarters workstation in order to catalog for all branches in a system, see only the shelving locations for the headquarters library in the drop down menu. Templates created for branches other than the workstation library are not correctly applying the shelving locations for other branches.

You must login separately, with each branch library workstation, when creating templates to see shelving locations for that branch in the copy editor and in the vol/copy template editor.

When logged into the headquarters workstation for centralized cataloging, templates created for branch libraries as circ library with that library’s shelving location, do not apply branch library (circ library) shelving locations. CAT1s can only see shelving locations in copy editor for the workstation library in the drop down, even though circ library is set for branch library. This means catalogers must log in separately to add vols/copies to each branch for the same title.

As a supercat, I can sometimes see branch library shelving locations and sometimes not. I have not been able to find a pattern. CAT1s never see the branch locations.

PINES catalogers cannot migrate to the Web Client until this bug is fixed.

Chris Sharp (chrissharp123) wrote :

I can confirm the behavior.

Changed in evergreen:
importance: Undecided → High
status: New → Confirmed
Mike Rylander (mrylander) wrote :
tags: added: pullrequest
Elaine Hardy (ehardy) wrote :

Chris applied the patch and I tested today and it does not work. While logged in on a STATELIB-L workstation as a supercat or cat1, I can sometimes see the shelving locations in the item editor for STATELIB-B and sometimes not, even after applying a STATELIB-B template.

I cannot see the STATELIB-B shelving locations in the Vol/Copy template editor while logged into a STATELIB-L workstations as a supercat or cat1

Mike Rylander (mrylander) wrote :

That's unfortunate. I can't replicate that on the system where I'm testing. I'm loading up a set of copies from different branches, and I can see the shelving locations from all the copy circ (and owning) libs just fine.

Something to check would be whether you are getting any errors in the javascript console.

Thanks!

Andrea Neiman (aneiman) wrote :

Tested this as well, with different workstations and both regular cataloger and cataloger admin logins.

I consistently see a set of shelving locations owned by OUs at, above, or below my workstation OU and at, above, or below the item's owning library OU.

I see this selecting single items or a batch of items to edit -- if it is a batch, the shelving location dropdown will pull in locations owned by all OUs (and their parents/children) who have owned copies in the set, as well as locations in the WS heirarchy.

Elaine Hardy (ehardy) wrote :

We are getting inconsistent results. Am trying to nail down why, however, our upgrade is this weekend so it may be next week before Chris and I can really delve into the console logs. My suspicion at this point is around templates and whether they are created in an early version of the XUL client or the Web client, I will need to test more to confirm or not.

I still was also unable to see the branch library in Vol/Copy template editor from a HQ workstation.

Mike Rylander (mrylander) wrote :

Elaine,

The patch as it stands only addresses the editor, not the template UI. The way the code knows what libraries to pull locations for is by looking at the set of copies that the user has chosen.

With that in mind, I'm struggling to find a clean way to choose which library or libraries to use in the template context. Certainly we don't want to simply load all locations globally. Perhaps a "Context Location" option lets the user of the template UI specify, say, the system-level org unit to gather locations for. This would gather locations from ancestor and descendent org units, of course. This would be a new feature, however.

Can you confirm that you are getting the appropriate set of locations in the editor proper, given a set of copies from different branches?

Thanks!

Kathy Lussier (klussier) wrote :

Mike,
Could the list of copy locations be based on the permission for the logged-in user? For example, if the user has permission to update copies at the system level, they would see all of the copy locations owned by all of the branches, the system or a parent of that consortium. If they only have the update copy permission set at the branch level, they would only see the copy locations owned by that specific branch or a parent of the branch.

Elaine Hardy (ehardy) wrote :

Mike,

The results in the editor proper are inconsistent. Sometimes, with the owning/circ library is a branch, I see the locations for that branch. Other times, I see the locations for the HQ library. Sometimes, when I apply a template in the editor proper the template is applied correctly for circ library and shelving locations and sometimes it does not. We will try to see if we can pin down why this happens after we upgrade on our live servers.

As to the vol/copy editor in local admin. In the XUL client, when I am logged into an HQ workstation and am in the item attribute editor in local admin, if I choose a branch library as the circulation library, the shelving locations for that branch (including system wide locations) are available in the drop down menu. locations for other branches are not. I can successfully create a template for that branch.

In the web client, while in the vol/copy editor in local admin, logged into a HQ workstation, choosing a branch library as circ library, the shelving locations available are for the HQ library and not for that specific branch. In order to successfully create a template for that branch, I must log into a workstation for that branch. We need to have feature parity between the XUL and web client.

Elaine

Elaine Hardy (ehardy) wrote :

Kathy,

Yes -- a person with system wide permissions should be able to see all shelving locations for that system. Then, choosing the owning/circ library, whether in editor proper or template editor, should make the locations visible for that specific owning/circ library.

In other words, as supercat for PINES, I can see any PINES library shelving locations. As CAT1, etc for STATELIB, I can see only those locations for STATELIB, and branches. As CAT1, etc for STATELIB-L, I can only see locations for STATELIB-L (this latter case would not exist in PINES since we catalog at the system level)

Elaine Hardy (ehardy) wrote :

We are still testing this -- I continue to find it is intermittent and am trying to see if I can determine why it is.

Kathy Lussier (klussier) on 2018-03-22
Changed in evergreen:
assignee: nobody → Kathy Lussier (klussier)
Andrea Neiman (aneiman) on 2018-04-24
tags: added: cataloging
Kathy Lussier (klussier) on 2018-05-15
Changed in evergreen:
assignee: Kathy Lussier (klussier) → nobody
Bill Erickson (berick) wrote :

Testing on current master, logged in as 'admin' at workstation BR1.

From the holdings maintenance view, clicking on "Add Volumes", the availability of copy locations appears to be affected by what rows in the holdings maintenance grid are selected prior to clicking the "Add Volumes" button.

If I select the 'SYS1' row, I see copy locations for SYS1, BR1, BR2 in the copy editor. If I first choose a BR1 row, then I'm shown copy locations for BR1 only. If I select the CONS row, I get all copy locations in the copy editor.

Not sure if this is intentional, but might explain Elaine's comment about it being inconsistent.

Mike Rylander (mrylander) wrote :

That behavior is intentional, Bill. The intended improvement to the UI is to provide the set of shelving locations that actually make sense for the copies being edited, rather than every location the staff user might possibly have access to.

More precisely, it offers locations that belong to the set of circ lib, owning lib, and ancestors of both (for shared shelving locations), for all selected (have a check mark by them in the bottom grid) copies.

If staff have a workflow where they use shelving locations from libraries other than where the copies live, then we could bring back the "show me everything, even if it's not relevant" behavior.

Bill Erickson (berick) wrote :

Thanks for the explanation, Mike. I can certainly understand not wanting to load all copy locations in all contexts. That can be a big list.

Elaine Hardy (ehardy) wrote :

Bill -- that wasn't what was happening. It was occurring when we were trying to either add multiple branches at one time or a single non-workstation branch.

Chris and I tested this morning to see if we could make it happen again. I tried a variety of ways to add volumes across libraries, including on our test server where the omnibus fix for https://bugs.launchpad.net/evergreen/+bug/1715697, etc. was applied, and we consistently saw the shelving locations for expected branches on both the live and test servers. If I added vols for all branches, I saw locations for all branches. If I added a subset, I saw locations for that subset.

I even tried added to several branches that included one with no shelving locations assigned just to it but the locations for the other branches were in the dropdown, as one would expect. (Also included is a legacy PINES location)

There was only one occasion where the shelving locations did not display as expected: When adding volumes/copies for branch A, if after assigning barcodes, I then changed the library to branch B, the shelving locations for branch B do not appear, only those for Branch A and the workstation library, if it differs. I think this is an outlier and probably should have a separate ticket.

Basically, we are seeing all shelving locations for all branches for the workstation system within the copy editor. I was not able to replicate the problems we were having earlier

The copy template editor displays only the workstation locations, which is still a major issue for PINES libraries.

Chris Sharp (chrissharp123) wrote :

So since we don't seem to be able to reproduce the originally-reported issue, is there a benefit in applying Mike's fixes in Comment #2? Or should we mark the bug invalid and move on?

Andrea Neiman (aneiman) wrote :
Bill Erickson (berick) on 2018-08-08
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Bill Erickson (berick) wrote :

Signed off and merged Mike's belt+suspenders patch to 3.0, 3.1, and master.

Marking bug as closed since no other issues are pending on this bug. We can open new bugs as needed.

Thanks, All!

Changed in evergreen:
milestone: none → 3.1.5
status: Confirmed → Fix Committed
assignee: Bill Erickson (berick) → nobody
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers