Bug 4464 - Editing a record with a 245a triggers warning about 245 is mandatory
Summary: Editing a record with a 245a triggers warning about 245 is mandatory
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: PC All
: PATCH-Sent (DO NOT USE) normal (vote)
Assignee: Galen Charlton
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-06 07:41 UTC by Jane Wagner
Modified: 2012-10-25 22:52 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
screen shot of error and record (100.78 KB, image/jpeg)
2010-05-06 19:41 UTC, Chris Cormack
Details
patch to check subfields in <textarea> elements (1.45 KB, patch)
2010-05-21 17:02 UTC, Galen Charlton
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:27:30 UTC


---- Reported by jwagner@ptfs.com 2010-05-06 19:41:55 ----

Created an attachment
screen shot of error and record

Sporadically (no pattern detected), when a record is imported from OCLC and edited, clicking save triggers a warning message:
 
Can't save this record because the following field aren't filled :
 
      * Field 245 is mandatory, at least one of its subfields must be filled.
 
The record has a title in the 245a, and that's the only subfield marked as mandatory in the framework.  The only way around this seems to be to enter a blank space in one of the yet unused subfields in the 245 (b, c, etc.).  If that is done, the record can be saved.

Any ideas?



---- Additional Comments From jwagner@ptfs.com 2010-05-06 19:44:28 ----

Sorry, meant to add the version: 3.01.00.061



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:27 UTC  ---

This bug was previously known as _bug_ 4464 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4464
Imported an attachment (id=2121)

Unknown operating system Windows 2000. Setting to default OS "All".
Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was jwagner@ptfs.com.
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
The original submitter of attachment 2121 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Jane Wagner 2010-05-21 15:49:17 UTC
One of our programmers has tracked down the cause of this problem, but we are not sure of the best way to solve it.  Briefly, it happens when a title is over 100 characters in length, and the culprit is the javascript that's controlling the text input block.  Here's our programmer's report:

-----

Here's a snippet of the HTML from a record that throws the 245 error...

<textarea cols="70"
          rows="4" 
          id="tag_245_subfield_a_834735_210982"
          name="tag_245_subfield_a_834735_210982" 
          class="input_marceditor"
          tabindex="1"
          >Orders regarding the death of George Washington and the military's funeral arrangements for their &quot;Patron and Father.&quot;</textarea>

versus a good one...


<input type="text"
       id="tag_245_subfield_a_735043_272907"
       name="tag_245_subfield_a_735043_272907"
       value="Pain is inevitable but misery is optional so, stick a geranium in your hat and be happy! /"
       tabindex="1"
       size="67"
       maxlength="9999"
       class="input_marceditor"
/>

The issue is the javascript (js) that checks for mandatory fields does not recognize the textarea.

The textarea piece comes from addbiblio.pl ($subfield_data{marc_value}), and it creates it when a title is longer than 100 characters.

A quick work around is to increment this value, but the ultimate solution would be to have the js recognize that there's something in the textarea input field.  

-----

Any ideas?
Comment 2 Galen Charlton 2010-05-21 17:02:36 UTC
Created attachment 2154 [details] [review]
patch to check subfields in <textarea> elements
Comment 3 Jane Wagner 2010-05-21 17:36:12 UTC
Some edited discussion from the IRC today about the problem, before Galen sent his patch.  Including here for background.

<owen> I tried entering a really long title and editing that, but I can't reproduce your issue
<owen> Is it only in older versions?
<jwagner> The site in production is at roughly .061, but I think my programmer's test environment is at current head.  I'll doublecheck that with him.  He reproduced the problem on his dev box.
<owen> jwagner: I did this: open existing record, edit the 245a to make it very long. Save. Open the record again for editing, save again. 
<gmcharlt> owen: issue probably lies around line 130 of addbiblio.tmpl
<gmcharlt> I was able to reproduce the issue by artificially changing the threshhold to use textareas instead of inputs to 20
<gmcharlt> that part of the mandatory field check looks for <input> elements, but ignores textareas
<gmcharlt> whole thng is a candidate for inserting jquery
<gmcharlt> but for now, patching it to also take textareas for subfields into account is the least disruptive way to change it
<owen> Am I not doing the right thing to trigger the bug?
<jwagner> owen, I just reproduced in my current head system.  The workflow is importing the bib record (he gets his records from OCLC).  Then open up in Koha to edit record.  Save it, it triggers the error.
<gmcharlt> in order to trigger the bug, you first have to save or import a record that has more than 100 characers in the 245 $a
<owen> Long enough to trigger the textarea display, right? I've got that
<gmcharlt> to artificially change the size limit, adjust line 479  of addbiblio.pl
<jwagner> That was the workaround we were using, I think -- manually changing the size limit.  Works as an immediate cure but isn't a good long-term fix.
<owen> ...but if all that's necessary to trigger the bug is a 245a textarea, I've got that. But no warning.
<jwagner> Are you creating or editing the record from scratch in Koha to be longer than 100 chars?
<jwagner> There may be a difference between importing a record, then editing, versus creating/editing in Koha.
<owen> Editing an existing record to be longer than 100chars; saving; Editing again. No warning.
<owen> Hm, a different check for new records?
<jwagner> Let me send you this record & you try to import
* owen can't duplicate the problem even if he imports a new record and tries to save it with the same long title
<owen> I see, the problem was that my tests used a record with a 245b, and the check must look for *any* subfield to be filled in (although is it possible to have a 245b with no 245a?)
<jwagner> Right, the workaround the site developed was to put a space in 245b
Comment 4 Galen Charlton 2010-05-24 11:59:20 UTC
Pushed patch to HEAD.  Please test and close.
Comment 5 Chris Cormack 2010-12-14 02:49:12 UTC
Hey look at me! Im a fixed Bug, I need some testing so I can be closed!
Comment 6 Jane Wagner 2010-12-14 14:40:44 UTC
Sorry, thought I had tested & closed a long time ago. I guess not.  It seems to be fine in latest head.  Can I mark it as signed off here?
Comment 7 Chris Cormack 2010-12-14 22:34:28 UTC
Cool, thanks for resolving it Jane