My Account: Add owning library to items out information

[Dan Pearl]

Wishlist

This is derived from MassLNC item: http://masslnc.org/node/3376

"It would be helpful for patrons to see which library owns the copy they have checked out.

"Library staff can easily look this up, but patrons can't easily find it (they would need to know the barcode to match it to the right copy).

"If a patron runs out of renewals they may need to follow up with the owning library. Also some libraries charge fines and some do not so it may help to know which items may accrue fines.

"It would be great if we could add the Owning Library field to the My Account - Items Out - Current Items Out screen in My Account.

"Ideally it would be a link (like the record details page in the OPAC) that takes you to contact details for that library."

[Dan Pearl (dpearl)]

I'm not in love with the column header, but I think it connects with patrons.

It's at user/dpearl/LP1753536_lib_column

To test:
Login as a patron with items out, and display the items out list. Note the library link on the right which should correspond to the circ_lib of the item.

[Jason Stephenson (jstephenson)]

I just pushed a rebased, signed off branch to working/user/dyrcona/LP1753536_lib_column-signoff:

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

I also edited the commit message a bit to make it cleaner and more clear what the new column is for.

I'm not pushing this to master so that other sites can offer feedback.

[Mike Rylander (mrylander)]

I wonder if this shouldn't use the call number owning lib, instead of the copy circ lib. Especially in the face of floating groups, the latter isn't really the owner but the "current home".

[Kathy Lussier (klussier)]

Looking at the release notes, it says:

"When a patron has run out of renewals, the owning library is the one with whom the patron will negotiate additional renewals, and clicking on the library name will provide contact information for that library."

The question, then, which library is the one responsible for the renewal. I suspect this answer to this question is related to how the circ policies are set up, which is likely to be different in different libraries.

It's not a straight answer, but more like an "it's complicated."

FWIW, as a user, I think I would interpret "Lending Library" to be the library that leant me the item, IOW the checkout library. I think "owning library" would make the most sense to the user, but it offers a bit of ambiguity for staff since we've been trained to understand the distinct difference between the cn.owning library and the copy.circulation library.

[Jason Stephenson (jstephenson)]

I can see changing the label to Owning Library and using the call number owning library as being viable. This feature could be more complicated, as the answer to whom should I call for more renewals is "it depends." This is something that we were asked to do as a local customization, but that I thought could have broader application in the community.

I wonder if the following would be in order:

1. Change the column header to "Owning Library."
2. Use the call number owning library.
3. Add an org unit setting to enable the display of this field.

Also, doing the above may complicate retrieving the URL for the link, but I will admit that I have not looked too closely at the code.

If the consensus is that this is a non-starter for community acceptance, we can always set the bug status to won't fix or invalid, and we can use it in-house.

[Kathy Lussier (klussier)]

I'm a +1 to the above proposal, with or without the org unit setting.

[Dan Pearl (dpearl)]

OK I have made the changes and pushed to user/dpearl/LP1753536_lib_column_respin

I'll need a GIT pro to clean up the commit history, as I am sure I have done something wrong.

[Remington Steed (rjs7)]

Here's a fixed git branch. It just needed a 'git rebase origin/master'. I also added Dan's sign-off to the top commit.

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

Dan, feel free to review and make sure all your intended changes are still there!

[Dan Pearl (dpearl)]

Thanks, Remington. It looks like it is all there.

On Thu, Apr 5, 2018 at 4:20 PM, Remington Steed <email address hidden> wrote:

> Here's a fixed git branch. It just needed a 'git rebase origin/master'.
> I also added Dan's sign-off to the top commit.
>
> http://git.evergreen-
> ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/
> user/rsteed/LP1753536_lib_column_respin
>
> Dan, feel free to review and make sure all your intended changes are
> still there!
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1753536
>
> Title:
> My Account: Add owning library to items out information
>
> Status in Evergreen:
> Confirmed
>
> Bug description:
> Wishlist
>
> This is derived from MassLNC item: http://masslnc.org/node/3376
>
> "It would be helpful for patrons to see which library owns the copy
> they have checked out.
>
> "Library staff can easily look this up, but patrons can't easily find
> it (they would need to know the barcode to match it to the right
> copy).
>
> "If a patron runs out of renewals they may need to follow up with the
> owning library. Also some libraries charge fines and some do not so
> it may help to know which items may accrue fines.
>
> "It would be great if we could add the Owning Library field to the My
> Account - Items Out - Current Items Out screen in My Account.
>
> "Ideally it would be a link (like the record details page in the OPAC)
> that takes you to contact details for that library."
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1753536/+subscriptions
>

[Dan Pearl (dpearl)]

This wishlist item is lonely and could use a reviewer. It's relatively easy to test.

If the community is not sure whether this should go in, well maybe we can make that decision outside of the testing/approval. We are eager to see this in our installation.

[Bill Erickson (berick)]

I have confirmed the code works as expected and pushed a new rebase/sign-off branch, including some commit message tweaks on the 2nd commit:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1753536-opac-lib-column-rebase

However, I chose not to merge the code yet. I'm concerned about showing Owning library over Lending library. If the policies may come from either location, and the patron already has an established relationship to the lending library, why not direct them there? Adding another library to the mix seems to be unnecessarily complicating things, more so since it's likely not the branch the patron usually interacts with.

I'm not saying don't merge, but would like some confirmation owning lib is really the choice we want. (Note, I would say add both, but I could also see that being confusing to patrons -- which one do I call?)

Thoughts?

[[e-mail] (tji)]

Our circ policies are mostly decided by the checkout library and the checkout library is responsible for overdue and lost issues. Patrons are supposed to contact the checkout library for renewal.

We also have libraries having floating collection. The items often have different owning and circ libraries.

Display call number's owning library is not desirable in both scenarios. A library setting controlling the display is required.

Tina Ji
BC Libraries Coop

[Jason Stephenson (jstephenson)]

Changed the target to 3.next because this is a new feature.

[Joan Kranich (jkranich)]

I agree with the suggestions in comment #5.

1. Change the column header to "Owning Library."
2. Use the call number owning library.
3. Add an org unit setting to enable the display of this field.

This would work best for C/W MARS libraries.

C/W MARS circulation policies are by owning library.
If there are no more renewals available either the patron or the staff member would call the owning library to allow the extra renewal.
If there are questions about a damaged item or lost item other than a routine payment, then the owning library would be asked.

We have floating collections and can understand the point made in comment #12. In our case it would still be fine to contact the owning library for a floating item.

To help with varying policies would it be possible for the org unit setting to offer either the owning library or the copy circ library?

[Ben Shum (bshum)]

Removing pullrequest tag while there is still ongoing discussion for this feature's future.

[Jason Stephenson (jstephenson)]

I want to add that Dan Pearl is working on adding the org. unit setting to control whether or not this field displays in the OPAC. That seems to be the last outstanding request for this feature.

It should be ready for testing soonish.

[Joan Kranich (jkranich)]

Is there a decision for the field to use the owning library or the checkout library?

[Dan Pearl (dpearl)]

After a long discussion, it seems that Owning Library (as implemented) is most useful, as long as there is an org setting to turn it off. I understand there is some justification to add a choice of which data to use if this doesn't do the job (in a future? LP).

[Joan Kranich (jkranich)]

Owning library will work well for us. Thanks.

[Dan Pearl (dpearl)]

Here is the branch that controls this feature via an org unit setting.

 working user/dpearl/LP1753536_optional_owning_lib

To test:
1. Add the org unit setting by applying the upgrade sql script
2. In the Client, turn on the org unit setting (obeys hierarchical rules).
3. In a patron's OPAC, observe that the Owning Lib column is displayed. The name of the library
   is shown, and it is a link to the library info page.
4. In the Client, turn off the org unit setting (or delete it, as the default is "not on").
5. Observe that the column does not display.

Note the "home org unit" of the patron is used to determine the (non-)appearance of the column.

[Dan Pearl (dpearl)]

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

[Jason Stephenson (jstephenson)]

It works for me, so I pushed a signoff branch to working/user/dyrcona/lp1753536_optional_owning_lib-signoff

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

[Galen Charlton (gmc)]

The release notes as written are a little misleading, as it is not universally the case that the owning library's policies control renewals.

As far as the feature is concerned, while I don't want to overly goldplate this, I wonder if there is a desire for some consortia to display the circ_lib instead (currently the lending library is not displayed at all). If so, a tweak of the new OUS to change it to a tri-value ("do nothing", "display owning library", "display lending library") may be warranted -- and be a small change on top of Dan's patch.

[Jennifer Pringle (jpringle-u)]

For Sitka we'd definitely prefer to display circ_lib over owning lib. We have a significant number of libraries doing interlibrary loan through Evergreen and showing owning library to patrons for items from other libraries that they borrowed through their home library and need to return to their home library would confuse patrons.

[Jason Stephenson (jstephenson)]

Jennifer, my understanding is that in this case, circ_lib is the circ_lib from the asset.copy. Unfortunately, both the asset.copy and action.circulation tables have columns with that name and they mean different things. If you want the action.circulation.circ_lib to display, that is not the intention of this enhancement and would complicate this setting further.

The goal of this improvement is to identify the library that the patron should contact if they run out of of renewals, etc. If that is their home library and NOT the library that owns the copy, then this field is of little to no value and should not be displayed. I likewise think this field to be of little utility if the library that the patron should contact is the library where they checked the copy out. It may serve some purpose in this case if the patron frequently uses multiple locations. There are some patrons who regularly do this.

As for copy circ_lib versus call number owning_lib, I think there was a good deal of discussion on that matter in earlier comments on this bug.

We will await clarification on what others mean by "circ_lib" before proceeding to do anything further with this branch.

[Jason Stephenson (jstephenson)]

I have rebased my signoff branch from comment #22 on master, updated the release note, and force-pushed to the same branch.

No one has clarified for me what they mean by "circ_lib" in the above comments. If it is, indeed, the checkout library, then I think that should be a separate column with a different heading: "Checkout Library." It seems to me that should be its own bug.

[Galen Charlton (gmc)]

Pushed to master for inclusion in 3.4. Thanks, Dan and Jason!