Bug 3013

Summary: Value builder for 006 and 008 need choices for all format types
Product: Koha Reporter: Jane Wagner <jwagner>
Component: CatalogingAssignee: Salva Zaragoza Rubio <salva>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P5 - low CC: bargioni, chagal, chris, cnighswonger, cookie.wolfrom, dgrobani, gmcharlt, katrin.fischer, koha.sekjal, mjr, mtj, paul.poulain, salva
Version: master   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5196
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: Proposed fix
Cataloguing plugin for fields 006/008, Type of Material Display and form variation with type of material selection.
follow up patch
Erase merge conflict marker left and replace XMLHttpRequest with jQuery
Value builder for 006 and 008 need choices for all format types

Description Chris Cormack 2010-05-21 01:05:23 UTC


---- Reported by jwagner@ptfs.com 2009-03-06 09:21:50 ----

I noticed this problem in the 007, but I believe the same problem exists in the 008, and in all frameworks for both.  We were trying to original catalog a DVD, with the DVDs, VHS framework selected.  If you click the ellipse after the 007 Physical Description Fixed Field, it brings up a builder screen. However, the only options available in the pulldowns are 

00 Category of material 		t-Text
01 Specific material designation 	a-Regular print
					b-Large print
					c-Braille
					d-Loose-leaf
					u-Unspecified
					z-Other

These choices are only appropriate for 007-text (books).  For DVDs, Library of Congress says the 007 choices should be

00 - Category of material		v - Videorecording
01 - Specific material designation	c - Videocartridge
					d - Videodisc
					f - Videocassette
					r - Videoreel
					u - Unspecified
					z - Other
					| - No attempt to code

Other material types of 007s have different value choices.

Following advice on the listserv, I looked at the intranet-tmpl/prog/en/modules/cataloguing/value_builder/marc21_field_007.tmpl file.  It is hardcoded to only include the above book/text values.  The marc21_field_008.tmpl file seems to be similarly hardcoded to only book values.

The 007 should conform to all Library of Congress 007 categories: 

    * 007--MAP
    * 007--ELECTRONIC RESOURCE
    * 007--GLOBE
    * 007--TACTILE MATERIAL
    * 007--PROJECTED GRAPHIC
    * 007--MICROFORM
    * 007--NONPROJECTED GRAPHIC
    * 007--MOTION PICTURE
    * 007--KIT
    * 007--NOTATED MUSIC
    * 007--REMOTE-SENSING IMAGE
    * 007--SOUND RECORDING
    * 007--TEXT
    * 007--VIDEORECORDING
    * 007--UNSPECIFIED 
 

The 008 should conform to all seven separate Library of Congress material configurations: Books (BK), Computer Files (CF), Maps (MP), Music (MU), Continuing Resources (CR), Visual Materials (VM), and Mixed Materials (MX).



---- Additional Comments From jwagner@ptfs.com 2009-03-07 05:36:20 ----

The 006 field has the same material type categories as the 008, and it looks like the builder for the 006 is also limited to books.



---- Additional Comments From jwagner@ptfs.com 2009-03-30 20:49:18 ----

I've sent a patch for the 007 value builder (expanding it to include all 15 material types).  I'm still looking at the 006 and 008 builders.



---- Additional Comments From gmcharlt@gmail.com 2009-04-18 20:35:03 ----

Patch pushed to HEAD.  Please test and close.



---- Additional Comments From gmcharlt@gmail.com 2009-04-18 20:36:32 ----

Or rather, don't close, of course - awaiting patch for 008.



---- Additional Comments From gmcharlt@gmail.com 2009-04-18 21:15:00 ----

Since you're working the templates, there's a related issue to be fixed - their output HTML should be valid XHTML, which isn't currently the case (and wasn't the case prior your patch for the 007).  The HTML Validator FireFox plugin is one way of checking the validity.



---- Additional Comments From mjr@ttllp.co.uk 2009-06-07 11:42:20 ----

This bug is described as fixed in the release notes for version 3.0.2 in the git tree.




---- Additional Comments From gmcharlt@gmail.com 2009-06-07 17:59:10 ----

Reopening.  008 plugin has not been fixed yet.



---- Additional Comments From bchurch@ptfs.com 2009-07-31 18:15:09 ----

This also applies to tag 006.



---- Additional Comments From jwagner@ptfs.com 2010-05-03 15:25:06 ----

See also http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2567 for an additional problem with the 008.  I haven't had time to work on the 006 or 008 pieces of this -- anyone else who wants to pick it up, feel free :-)



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

This bug was previously known as _bug_ 3013 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3013
This bug depended on bug(s) 2567.

Unknown operating system Linux - Debian. 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.
The original assignee of this bug does not have
   an account here. Reassigning to the default assignee
   for the component, gmcharlt@gmail.com.
   Previous assignee was jwagner@ptfs.com.
Bug reassigned, setting status to "NEW".
   Previous status was "REOPENED".
CC member adrea@moablibrary.org does not have an account here
CC member arm@hanover.ca does not have an account here
CC member bchurch@ptfs.com does not have an account here
CC member kdr@ckls.org does not have an account here

Comment 1 MJ Ray (software.coop) 2010-07-07 19:27:08 UTC
Restoring where "Previous assignee was mjr@ttllp.co.uk"
Comment 2 Nicole C. Engard 2010-09-03 11:45:06 UTC
A bug for the 006 field has been filed - basically when a selection is made in one subfield it should effect the options in the other subfields.
Comment 4 Owen Leonard 2010-09-22 15:43:30 UTC Comment hidden (obsolete)
Comment 5 Chris Cormack 2010-11-17 08:05:36 UTC
Pushed patch, please test
Comment 6 Chris Nighswonger 2010-11-18 03:15:36 UTC
This bug has a patch presently committed to HEAD and 3.2.x.

Please take the appropriate action to update the status of this bug.

Remember, bugs which have been resolved should be tested and marked closed, preferably by the original reporter.
Comment 7 Chris Nighswonger 2010-11-30 13:49:40 UTC
This bug has a fix which was committed to the 3.2.x branch and released in 3.2.1.

Please take time to update the status of this bug and mark it RESOLVED FIXED so that it may be closed.
Comment 8 MJ Ray (software.coop) 2010-12-01 10:30:09 UTC
commit 6aee235e3c239fd46ffdc263bafd578d845e812b calls itself a "partial fix".  Where is the fix for 008?  I'm not finding it.
Comment 9 Chris Nighswonger 2010-12-01 13:14:17 UTC
You are correct. Sorry. I failed to cull this one from my list.
Comment 10 MJ Ray (software.coop) 2010-12-13 12:16:10 UTC
This bug is mentioned in:
Fix for Bug 3013,	Value builder for 006 and 008 need choices for all format types http://lists.koha-community.org/pipermail/koha-patches/2010-November/013047.html
Comment 11 Salva Zaragoza Rubio 2011-01-25 10:09:54 UTC
Hi, i would like to know if someone is currently developing the 008 choices for all format types, from what i've read the 006 one is completed but i'm not so sure about the 008 one. We were thinking on picking up this issue and using mysql tables to store the different values instead of hard coding them on the tmpl.
Let me know what you think.
Comment 12 Salva Zaragoza Rubio 2011-03-04 12:07:14 UTC Comment hidden (obsolete)
Comment 13 Nicole C. Engard 2011-03-04 12:39:56 UTC Comment hidden (obsolete)
Comment 14 Salva Zaragoza Rubio 2011-03-04 17:51:23 UTC
Nicole Engard: thanks for correcting the system preference.

Mike Hafen: didn't see that one, thanks for detecting it. I'll correct it right away.

Galen Charlton: the system preference was just for keeping the current implementation and the new one. I didn't want to impose something new over something people is using all along.
I thought jQuery.load() and jQuery.ajax() were basically front-ends for XMLHttpRequest and was indifferent which one to use, anyway I'll change the code to implement jQuery and I'll post again the patch.

Thanks for your comments and advice.

Regards

Salva
Comment 15 Salva Zaragoza Rubio 2011-03-04 19:48:26 UTC Comment hidden (obsolete)
Comment 16 Nicole C. Engard 2011-03-06 15:18:55 UTC
Should you also remove the system preference and make this the default? Sounds like that's the best way to go - especially since your way is the proper way :)
Comment 17 Salva Zaragoza Rubio 2011-03-07 07:49:06 UTC
Ok, I'll make a new patch without the system preference.

I'll post it when finished.

Thanks

Salva
Comment 18 Salva Zaragoza Rubio 2011-03-07 16:34:04 UTC Comment hidden (obsolete)
Comment 19 Nicole C. Engard 2011-03-07 16:38:06 UTC
Signed off on new patch! Works awesome.
Comment 20 Chris Cormack 2011-03-13 01:03:26 UTC
Pushed and merged please test and mark resolved
Comment 21 Stefano Bargioni 2011-06-09 13:55:24 UTC
(In reply to comment #20)
> Pushed and merged please test and mark resolved

I tested the latest patch (attachment 3259 [details] [review]) in Koha 3.2.3. It seems ok for both 006 and 008.
Comment 22 Chris Nighswonger 2011-06-11 19:59:22 UTC
Pushed to 3.2.x.
Comment 23 Ian Walls 2011-08-27 23:03:35 UTC
We've started having an intermittent problem with the 008 with non-book
materials.  When the material type is changed, it changes the data elements
correctly, but after the information is entered, and ok is clicked, sometimes
characters are dropped from the entry in the field itself.  You can go back and
reenter the data and click ok again and sometime that time and sometimes the
next it will enter correctly.

The only thing in the error log is something like:
[Fri Aug 26 09:18:55 2011] [error] [client 10.8.5.66] [Fri Aug 26 09:18:55
2011] addbiblio.pl: substr outside of string at
/usr/share/perl5/MARC/File/XML.pm line 317.
[Fri Aug 26 09:18:55 2011] [error] [client 10.8.5.66] [Fri Aug 26 09:18:55
2011] addbiblio.pl: Use of uninitialized value $original_encoding in string ne
at /usr/share/perl5/MARC/File/XML.pm line 320.
Comment 24 Paul Poulain 2011-10-06 14:15:27 UTC
QA comment:
I don't understand what is already applied an available in 3.4, what is still pending.
I feel we're waiting for one more patch, that is not here, so this bug should not be "signed off"
Comment 25 Ian Walls 2011-10-06 15:15:23 UTC
Resetting status, as we don't have an updated patch to address the issues I've noted in comment 23
Comment 26 Mason James 2014-07-03 21:46:41 UTC
(In reply to Ian Walls from comment #25)
> Resetting status, as we don't have an updated patch to address the issues
> I've noted in comment 23

some good news here...

i just searched thru 1 years worth of Koha 'production' error logs (v3.14.6), and could not find Ian's error.  perhaps this bug has been somehow resolved?

is anyone from Bywater still getting these errors?
Comment 27 Katrin Fischer 2015-06-06 20:23:38 UTC
*** Bug 5196 has been marked as a duplicate of this bug. ***
Comment 28 Katrin Fischer 2019-05-04 12:00:35 UTC
I am not sure why this was left in discussion - several patches have been pushed to really old versions of Koha here. I think if any issues remain, we'll need new bugs.