Course Materials: should get an alert when associating items with a course if they are owned by a different library

[Beth Willis]

EG 3-6

When associating materials with a course, it is possible to select and attach an item owned by a different library. This should not be allowed and users should receive an error message if they attempt to this.

To replicate:

--Go to the course list
--Select (double click on) a course owned by your library
--Select the "Course Materials" tab
--On the "Associate Item" tab, input a barcode for an item owned by a different library
--Click "Add Material"
--Refresh the screen
--Notice that the item has been added to the list of course materials

See related bug: https://bugs.launchpad.net/evergreen/+bug/1909613

[Jane Sandberg (sandbergja)]

The original plan was that when somebody scanned a barcode belonging to another library, an alert would pop up. The alert would give the staff member the option to continue or cancel out. That code doesn't seem to be working properly, but I can see if I can get it running again with that model. What do you think, Beth?

[Beth Willis (willis-a)]

I cannot see a scenario in our consortium where a library would want to put another library's item on reserve for a course. But none of our academics have multiple campuses. Is this option intended for libraries from multi-campus systems? If so, and the libraries share materials, I can see how this would be useful/necessary. If you can add the pop-up alert, I think this would be OK.

[Jane Sandberg (sandbergja)]

Yes -- the idea was that in multiple-branch libraries, it could be useful to pull in an item from another branch to put on reserve.

[Jane Sandberg (sandbergja)]

Pull request here: user/sandbergja/lp1913604_course_associate_items_at_other_libraries

Link here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1913604_course_associate_items_at_other_libraries

Testing notes from the commit message:

1) Create a new course at a branch that can have items (BR3, for example).
2) Add an item with the circ_lib of BR3. Note that the item is added to the grid.
3) Add an item with a different circ_lib. Note that you get an alert showing that the item is not at the course's owning library.
4) Push the Cancel button. Notice that the item is not added to the course.
5) Repeat step 3 and push the Confirm button. Notice that the item is added to the course this time.

[Beth Willis (willis-a)]

Jane, thanks for clarifying this and for appropriately changing the description of this bug.

[Andrea Neiman (aneiman)]

Tested this on pattypan for Bug Squashing Week.

I took a BR4 item, CONC71000428, and added it to a BR1 course. As expected it presented a confirmation modal and upon confirmation, added the BR4 item to the course list and moved the items's circ library to BR1. I wasn't expecting that the owning library would also be moved to BR1 but it did that too.

However, when I removed CONC71000428 from the course, I expected to see it revert back to BR1 ownership and this did not happen, even after a checkin.

I will note that I'm not highly familiar with this interface so it might be that this is intentional, but I would argue that it's not desirable - if a "foreign" item is on reserve, it should be temporarily available to the course reserve library but once it's off the reserve list it should revert to its original library.

[Beth Willis (willis-a)]

I agree with Andrea that the owning library should not be changed when an item owned by one org unit is associated with a course owned by a different org unit.

There is a separate bug related to the failure of item fields to revert to their original values when the item is removed from a course: https://bugs.launchpad.net/evergreen/+bug/1905070

[Terran McCanna (tmccanna)]

Removing pullrequest as per comments #7-8

[Christine Burns (christine-burns)]

Tested on 3.8

I'm seeing this alert "Material exists at a different library" whenever an item is associated with a course.
Even when the item belongs to the same library the course is created for. The item is associated with the course, but the warning is confusing.

[Michele Morgan (mmorgan)]

Bug 1972919 has been opened to address the issue in Comment #10.

[Jane Sandberg (sandbergja)]

I added a second commit to that branch to address the feedback. Circ and owning libraries no longer change when being attached to a course.

For testers, note that this behavior typically only appeared when both of these are true:
* the course is at a branch-level, rather than system or consortium
* the material is getting a temporary call number when it is attached

Also a note that this branch resolves bug 1972919.

[Beth Willis (willis-a)]

Jane's latest patch works as described; neither the circ library nor owning library are edited when an item owned by one branch (e.g. BR2) is associated with a course owned by a different branch (e.g. BR1). However, I believe that the circ library should correspond to the course-owning library. It makes sense that an item would circulate from the location at which the course is offered. Additionally, if it does not, the item wants to go in transit when it is checked in. So, I think that the circ library should be updated in these instances. The circ library should revert when the item is disassociated from the course.

During testing I was logged into a BR1 workstation with a working location of BR1; my manage_reserve permission is assigned at the system level. I was able to associate an item owned by BR3 (SYSTEM2) to a course owned by BR1 (SYSTEM1). I edited the call number, the circ modifier and the shelving location. None of these edits was saved. That seems appropriate as a user with my permissions should not be able to edit a BR3 item. However, I don't think a user should be able to associate items with a course if those items are not within the depth of their permissions.

[Terran McCanna (tmccanna)]

Removed pullrequest due to testing comment #13

[Jane Sandberg (sandbergja)]

I've pushed another commit to that branch (user/sandbergja/lp1913604_course_associate_items_at_other_libraries), which does a handful of things to address Beth's feedback:
* Adds a permission check, and blocks users who are missing UPDATE_COPY at the item's circ lib.
* Adds a new field to asset.course_module_course_materials to keep track of the original circ lib for items that are being temporarily moved to a different library.
* Sets the item's circ_lib to the course's owning library (leaving the call number's owning library alone) on attach. This only happens if the course's owning library can actually have holdings (the example consortium won't cut it).
* Reverts the change on detach.
* Adds some tests.

I also based this on top of my signoff branch for bug 1940105 -- so a total of 5 commits.

Looking forward to your feedback!

[Jane Sandberg (sandbergja)]

Force pushed some small changes to the angular tests.

[Gina Monti (gmonti90)]

Feedback Fest 9/22. MOBIUS server

I, Gina Monti (<email address hidden>), sign off on this fix. A prompt does appear if the material is owned by a different library that includes a confirmation.

[Beth Willis (willis-a)]

Feedback Fest 9/27 MOBIUS Server

I concur with Gina's finding, but there is still an issue with this code. Specifically, if the user changes the item's call number when associating the item with a course, the circulation library does not revert correctly when the item is removed from the course.

Here are the steps I followed:

--I associated an item owned by BR2 (CONC51000677) to a course owned by BR1 (MUS 444): https://bugsquash.mobiusconsortium.org/eg2/en-US/staff/admin/local/asset/course_list/2

--When associating this item with the course, I edited its call number (See attached screenshot #1)

--The item’s circulating library was correctly changed to BR1, while the owning library correctly remained BR2 (See screenshot #2)

--When I removed the item from the course, however, instead of the circulation library reverting to BR2, both the circulating and owning library were now set to BR1. The shelving location has also been edited to a BR1 location. (See screenshot #3)

[Jane Sandberg (sandbergja)]

Hi Beth: thanks for your testing! I suspect that the issue you described with removing the item is fixed by Michele's patch for bug 1939730 (which was merged yesterday).

[Beth Willis (willis-a)]

Thanks, Jane. I really got side-tracked here.

[Michele Morgan (mmorgan)]

Jane, can you rebase this branch?

[Jane Sandberg (sandbergja)]

Here is a rebased version, Michele: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1913604_course_associate_items_at_other_libraries

[Michele Morgan (mmorgan)]

This works great, and takes out a couple of other bugs in the process(bug 1972919, bug 1940105)!

Pushed to master, rel_3_9 and rel_3_8

Thanks Kyle, Jane, Gina and Beth!