UPC selection doesn't stick with acq ISBN identifier

[Kathy Lussier]

Evergreen version: seen on 2.4 and master

This bug occurs with records that contain both an ISBN and UPC. If the UPC is selected as the identifier to be used for the order, the selection doesn't save and reverts back to ISBN. See the screencast at http://www.screencast.com/t/XCnuL25dq0.

[Tim Spindler (tspindler-cwmars)]

This may be related but we also have reports of having to click twice to save the 13 digit ISBN when the the 10 digit has been selected on the load.

[Andrea Neiman (aneiman)]

I still see this in 3.3 -- I cannot get the UPC to stick as the order identifier on a Selection List or a Purchase Order where there is an ISBN present. It always reverts back to the ISBN.

[Josh Stompro (u-launchpad-stompro-org)]

I was just looking at this behavior.. and I noticed this error message in the logs.

2022-02-16 15:11:47 virt-egapp2 open-ils.acq: [ERR :17550:Order.pm:4263:1645045643191706] ACQ lineitem update failed to produce a matching marc att
ribute for upc => 4422333332

So the step to create the line item marc with the new UPC info fails...

I wonder if it has anything to do with the acq.lineitem_marc_attr_definition for UPC that says that the indicater 1 needs to be 1.

INSERT INTO acq.lineitem_marc_attr_definition ( code, description, xpath, remove ) VALUES ('upc', 'UPC', '//*[@tag="024" and @ind1="1"]/*[@code="a"]', $r$(?:-|\s.+$)$r$);

But the code to add in the UPC field doesn't set that?

https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Acq/Order.pm;hb=3db8047844d9cb5cb8d78fbac47d72a84808bfda#l4245

4238 my %tags = (
4239 isbn => '020',
4240 issn => '022',
4241 upc => '024'
4242 );
4243
4244 my $marc_field = MARC::Field->new(
4245 $tags{$attr_name}, '', '','a' => $attr_value);

So the newly added UPC never gets found in the lineitem marc, and the change is rolled back?

[Josh Stompro (u-launchpad-stompro-org)]

Adding the ind1 value seems to fix it on a test system.

Here is a working branch with one commit. I added some testing notes. I'm not sure how easy it is to test this out on a test system... I'm not sure how much setup is required to get acq working. I'll try it out in production tomorrow if I have a chance.

user/stompro/lp1272566_acq_lineitem_upc

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1272566_acq_lineitem_upc

[Josh Stompro (u-launchpad-stompro-org)]

I applied this fix to our production system and it seems to work fine.

I'll report back if we run into any trouble with it.

Josh

[Josh Stompro (u-launchpad-stompro-org)]

Removing the pullrequest tag. This fix doesn't help the ability to pick a UPC that already exists.. Only if you are adding a new UPC from the order identifier display.

I'll see if I can figure out that one also.
Josh

[Josh Stompro (u-launchpad-stompro-org)]

It looks to me like after the type selection is changed, and the value box is re-created, then the onchange handler is connected to the value box. But it will only try to update the value if the value box is changed after that point. And since there is only one UPC is most cases, it isn't possible to change to another one, and then back to the UPC you want.

Maybe calling updateOrderIdent() at the end would register the current selection as the official order identifier. I'll try that out.

https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/web/js/ui/default/acq/common/li_table.js;hb=7fb2ccc551797063aa2cb220a3ad33a2d9f405fb#l1117

[Josh Stompro (u-launchpad-stompro-org)]

I did poke at this for a while but wasn't able to fix the core issue. My bug fix works to allow adding UPC at order placement time... but I think that may have limited real life usefulness. Our acquisition staff member told me that the UPC usually is already in the record. So you still cannot select if it already exists, because it isn't possible to trigger setting the identifier if you cannot change from the one that gets shown initially and a second option.

[Tiffany Little (tslittle)]

Removing pullrequest based on Josh's last comment. Josh, if that's incorrect please correct me!