Precat Checkout always ITEM_NOT_CATALOGED even when copy exists

Bug #1485077 reported by Jason Stephenson on 2015-08-14
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned

Bug Description

Evergreen version: 2.7+
OpenSRF version: 2.4.0
PostgreSQL version: 9.3 (but irrelevant)

When checking out a precat copy, staff are always presented with the dialog to fill in the title, etc., for the copy, even if the copy already exists with that information in the database.

If the item exists, the staff can simply close the dialog, or fill in anything at all in the fields. The information of the existing copy will be used.

The dialog opens because the back end always returns a 1202 ITEM_NOT_CATALOGED event for precat copies.

The code for https://bugs.launchpad.net/evergreen/+bug/1308239 has been included since the release of 2.7 making the use of precat copies for ILL a viable feature, the above behavior is no longer desirable. Staff should not be presented with the precat copy dialog when a precat copy already exists in the system.

It appears that the best way to fix this is to stop the back end check out and check out permit calls from returning the 1202 event when a precat copy already exists.

I am attaching a perl script to demonstrate the behavior. It creates a precat copy and then attempts to check it out to the user who created the copy. The script itself uses a couple of non-standard libraries and at least one hardcoded organizational unit, so it is a poor candidate for a test. Perhaps, I'll come up with a more generic version in the near future.

Jason Stephenson (jstephenson) wrote :
Mike Rylander (mrylander) wrote :

The code linked in bug 1308239 is specifically meant for external integration. If the desired outcome is to allow completely human-driven ILL to use the same backend mechanisms, I suggest strongly that that should be an org unit setting that uses the workstation org unit for context.

For background, the design of pre-cats is that they "disappear" from the system after check in, from the point of view of circ staff, so that each time a staff member scans a particular barcode that has not passed through cataloging they are required to fill in the "dummy" fields. IMO, staff manually "faking" ILL doesn't change the reasoning behind the human-level behavior.

In fact, based on the description, I think the bug is actually that the user can close the dialog when the pre-cat already exists and have the originally entered information persist.

Jason Stephenson (jstephenson) wrote :

Mike,

Here's the workflow that I have in mind:

The pre-cat copy is created by ILL software when it is being sent to an Evergreen library to fulfill a hold there. A hold is also created at the target location.

When the staff check that copy out, they still get the dialog about a non-cataloged item, even in the presence of the hold.

I'd like that dialog to not show up.

After looking through the circulation code a bit more in relation to this and an unrelated question about an enhancement, I think there may be a bug in the current code that it is failing to find the holds.

I have not had a lot of time to devote to that, though.

Actually, after proofreading the above, I think I know what the problem may be, and it may be in the NCIPServer software. I'll do some more testing and update this bug by either marking it invalid or adding a potential fix, if it does turn out to be a bug in Evergreen.

Jason Stephenson (jstephenson) wrote :

I am removing the milestone because I still have not determined where the "bug" actually lies, in Evergreen or in NCIPServer.

It is my understanding that if a pre-cat copy exists with a hold on it, that staff are not supposed to be prompted to enter the precat copy information.

That condition exists in my scenario, and I have not yet determined why the prompt for precat copy information still shows up. My hunch is that NCIPServer is not creating the precat copy or the copy hold (or both) in a way that the circulation code expects.

This will have to wait until after beta for more investigation.

Changed in evergreen:
milestone: 2.9-beta → none
Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers