FIXME error blocks first attempt at saving a bib record with a newly added 006/007 field

[Carrie Curie]

Evergreen 2.3.x
OpenSRF 2.1.2
PostgreSQL 9.1
Ubuntu 12.04

After using "Add/Replace 006" or "Add/Replace 007" and filling in the 006 or 007 field, a user clicks on "Save Record." A FIXME error appears saying the "record not likely updated. DATABASE_QUERY_FAILED." (see attached screenshot)

The user clicks the "Check here to confirm this message" box and "Okay." The user then has to go correct the MARC tag which has been replaced with "undefined"-usually one of the first fully editable MARC fields (i.e. 010 or later). Once corrected, then the user can "Save Record."

Ideally, the user should be able to "Add/Replace 006" or "Add/Replace 007" without having to correct another field because it's tag is replaced with "undefined."

[Pasi Kallinen (paxed)]

Fix in http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/paxed/lp1187402

[Simon Mai (simonmai)]

Hi Pasi,
I tested the fix and it looks like it's working well as expected .
Thank you.

[Carrie Curie (carrie-curie)]

Hi Pasi,

In the client I added a 2nd field and successfully saved. Then, I tried adding two 007s, saving, and then adding another one and resaving. I then tried deleting two of those four. I closed and reopened the record and the fields appeared as they were at the last save before I closed the record. So, it worked for everything I thought to throw at it.

Thanks, again!

[Carrie Curie (carrie-curie)]

Simon reminded me that he has not released his code that makes multiple 007 fields possible because he is still working on the code to make searching the multiple 007 fields possible. We've also checked it with just adding an 007 field to a record without one and it works fine.

[Dan Scott (denials)]

Committed to master through rel_2_3 (with adjustment of tabs to 4 spaces). Thanks for the patch, Pasi! And thanks for the testing, Carrie and Simon.

[Mike Rylander (mrylander)]

Carrie and Simon,

While not core to this bug, a new feature was offhandedly mentioned above: "code to make searching the multiple 007 fields possible". The guts of the record attributes infrastructure, and in particular the physical characteristics mapping, is complex and has wide-ranging effects. Have you posted any plans showing how you plan to attack this problem? This and related features have been discussed pretty extensively in the community in the past, and I'd hate to see any work you're planning or performing fail to be included due to being out of line with others' ongoing work in this and adjacent areas of the code, or the expectations of other developers working on search and ingest.

[Simon Mai (simonmai)]

@Mike: For now, I've been working on improving the OPAC filters that need to look at all 007 fields in a record when searching. This is still in development. I haven't posted any plans yet. And, yes, you're right. The multiple 007 fields will bring us other complex features and wide-ranging effects. I'm going to ask you and others about this on IRC and Evergreen hack-a-way (hopefully I can go there as planning). Thanks.

[Alex Lazar (alex-lazar)]

The summary for this bug says that the fix was released in 2.4.1, but upon examining the contents of 2.4.1 that is not the case. The fix was actually released in 2.4.2.

Similarly, for 2.3 the fix is not in 2.3.9, but I see it in 2.3.10.

[Ben Shum (bshum)]

Noted, Alexsey is right. Looks like the patch went in right after the cut was made to create 2.3.9 and 2.4.1.

Since the subsequent 2.4.2 and 2.3.10 milestones have already been closed as well, we cannot re-target them accordingly, but acknowledge the slight mis-targeting of these bugs to their final resting places.