Angular Holdings Editor does not allow you to edit the owning library

[Christine Burns]

3.8 / 3.9

The new Angular Holdings Editor does not allow you to edit the owning library.

The Owning library field on the Holdings tab is grey and cannot be edited.

[Jennifer Pringle (jpringle-u)]

There is a workaround which is not ideal.
1. Click Add Holdings
2. Click the Plus beside the owning library (BR1)
3. Select the owning library (BR2) you actually want to add a holding to. A second line will appear for that library.
4. On the original line (BR1) click the Minus in-between Suffix and Barcode
5. The original line (BR1) will disappear and you are left with the new one (BR2) and can now catalogue the item.

This is particularly problematic for multi-branch libraries that do centralized cataloguing.

[Elaine Hardy (ehardy)]

We don't typically use add holdings because it has been buggy in the past and makes adding all branches more time consuming.

We use holdings view with empty libs displayed and check the libraries to add holdings, so that is another work around

In holdings view, select library/system and check "display empty libs"

Check branches/libraries for holdings

From actions menu, select add call numbers and items

[Elaine Hardy (ehardy)]

Sorry -- show empty libs not display!

[Bill Erickson (berick)]

When changing the owning lib for call number, how should the attached copies be affected? Change their circ libs? What if it's a mixed batch of circ libs?

[Bill Erickson (berick)]

I suppose it should just honor the "Change Circ Lib When Owning Lib Changes" preference?

[Bill Erickson (berick)]

3 Possibilities for handling copies attached to a calll number when modifying the call number's owning library:

1. Ignore the copies and just update the call number.

2. Update the circ lib on the copies loaded into the same edit session, ignore other copies.

3. Update the circ lib for all copies linked to the call number, regardless of whether they are loaded into the edit session.

There may be sub-variations of some of these, but I'm curious if there is any consensus toward any of these options?

[Galen Charlton (gmc)]

As near as I can tell, the AngularJS holdings editor did not propagate owning library changes to the circ library. Consequently, as a least-impact fix unless there's a clear consensus expressed by the Cat IG, I suggest running with option 1 if the "Change Circ Lib When Owning Lib Changes" is not set, otherwise option 2 if it is set.

[Bill Erickson (berick)]

Here's a branch that uses the logic from Galen's previous comment:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1975879-volcopy-edit-callnum-owner

In the holdings editor, you will now see an edit (pencil) icon to the right of the owning lib, one per call number.

[Galen Charlton (gmc)]

I've pushed a signoff branch to user/gmcharlt/lp1975879_signoff / https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1975879_signoff

I think this one definitely warrants additional eyes, so I'm not pushing this one directly.

[Jennifer Weston (jweston)]

Discussed in July Cat IG meeting: Consensus is that when the owning library of the call number is changed, then the circ library should be changed to match owning library for all copies attached to the call number -- without consideration of the "Change Circ Lib When Owning Lib Changes" setting.

Add Holdings functionality is straightforward. The ability to change the owning library when adding will definitely be beneficial and time-saving.

Editing the owning library for a call number is not a typical workflow but, if it should happen, it was agreed that the expected behavior would be that all copies attached would be changed (both circ and owning library) to match.

[Galen Charlton (gmc)]

Thanks. From the point of view of the Cat IG consensus, would I be correct in inferring that the "Change Circ Lib When Owning Lib Changes" preference is therefore superfluous?

[Elaine Hardy (ehardy)]

In this narrow instance of editing the owning library at the call number level, yes.

[Jennifer Weston (jweston)]

I believe the "Change Circ Lib When Owning Lib Changes" preference came from KCLS to prevent mismatches. I don't believe it has been widely used enough (as it was new in 3.8.1) to get a sense of how it will be used widely but it received a positive response.

Today's discussion was limited to changing owning lib on call number; there are potential scenarios for editing items where the optional new preference would be utilized.

[Kate Coleman (katecoleman)]

Absolute +1 for the "Change circ lib when owning lib changes" option. Not superfluous at all. This is an excellent addition to Evergreen for most (if not all) multi-branch systems.

[Bill Erickson (berick)]

"Consensus is that when the owning library of the call number is changed, then the circ library should be changed to match owning library for all copies attached to the call number -- without consideration of the "Change Circ Lib When Owning Lib Changes" setting."

Just to be super clear, this means all copies regardless of a) whether they are currently being edited in the holdings editor and b) whether they have a different circ lib entirely from, for example, floating.

[Galen Charlton (gmc)]

Apologies for the "Change circ lib when owning lib changes" noise; I had missed that the owning library is _also_ editable as a copy attribute, and that's where that preference was initially effective.

[Elaine Hardy (ehardy)]

Yes, all copies regardless of a or b.

Discussion in CIG was that catalogers would most likely edit the owning library at the item level (where we would want the preference "change circ library" to be honored.

The discussion also was that when the cataloger chooses to edit at the call number level, they are probably transferring all copies to a different owning and circ library, regardless of whether they have indicated a preference for the circ library to change. (This also would take into account that the default for the preference is not to change the circ library. Since many catalogers might be unaware they need to check that box.)

[Jennifer Weston (jweston)]

+1 to Elaine's comments and affirmative response to Bill's clarification request

[Bill Erickson (berick)]

Here's a new branch:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1975879-volcopy-edit-callnum-owner-v2

The top commit implements the logic requested by the Cataloging team. When changing the owing library of a call number from within the Holdings tab, propagate the value to the circ lib of all attached copies, period.

[Gina Monti (gmonti90)]

I, Gina Monti, sign off on this bug ticket. The fix shows an edit option for the owning library under Holdings in the Angular catalog.

[Jane Sandberg (sandbergja)]

This works well for me, but I found one aspect of the UI potentially misleading.

Steps to recreate on a box with Bill's patch applied:
1) Open some item in the holdings editor
2) Open up the holdings tab
3) Press the pencil icon
4) Change the owning library.
5) Open up the item attributes tab.
6) Note that the Circulating Library is still listed as the original library.
7) Click "Apply all and save"
8) Note that the circulating library is now changed to reflect the new owning library.

I would have expected that Step 6 would reflect the new library, so that a user can get a reliable "preview" of what will happen when they click Save.

But, also, I don't want to block this if that is the behavior that CWG is looking for. Elaine and Jennifer, what do you think?

[Jeff Davis (jdavis-sitka)]

We've run into an interesting bug with Bill's fix.

In our environment, with the fix applied, if you are adding a new item at a multi-branch library and use the Edit icon to change the owning library to a different branch, it fails. The reason is that Bill's fix attempts to propagate the owning library change to all copies belonging to the call number -- but when you're adding a new item and call number together, the call number has a dummy ID of -1, which is actually the UNCATALOGED call number. In our environment, call number -1 has 37,000 copies attached, and EG basically times out when it tries to look them up. But even if there were 0 attached items, it would be incorrect to propagate the change in this case.

I haven't tested this yet, but I believe the solution is to only propagate the owning lib change if the call number ID >= 0.

[Jeff Davis (jdavis-sitka)]

Working branch user/jeffdavis/lp1975879-volcopy-edit-callnum-owner-v2.5 has a fix based on my previous comment:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp1975879-volcopy-edit-callnum-owner-v2.5

Note that this does not address the display issue identified by Jane in comment #21.

[Jennifer Pringle (jpringle-u)]

+1 to Jane's comment in #21.

When creating a new item if you edit the owning library the circ library should update in the item attributes to match so you see the values that are going to be used when the item is actually created.

[Elaine Hardy (ehardy)]

+1 to Jane's comment in #21.

[Shannon Dineen (sdineen)]

We have this fix on production in 3.9.0 .

The holdings editor now works better for Sitka libraries but there is a problem with depth of editing permissions/access.

Library staff can now change the owning library of holdings they do not own. They should not be able to do so and should receive an override advising them of such. We think this is a bug.

Testing confirms they can only change the owning library to their own library (or libraries) , which is expected and correct, and once changed and saved they cannot change it back to the original owning library , i.e. they are correctly restricted to their own org units as expected.

We think the grant depth of UPDATE_VOLUMN is ignored. There should be an override blocking access to non-owned holdings.

Co-op Support reverts the record for the site when this is reported to us.

[Terran McCanna (tmccanna)]

Removing pullrequest due to comments #21-26

[Terran McCanna (tmccanna)]

Removing milestones as it needs additional work.