---- Reported by firstname.lastname@example.org 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
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--ELECTRONIC RESOURCE
* 007--TACTILE MATERIAL
* 007--PROJECTED GRAPHIC
* 007--NONPROJECTED GRAPHIC
* 007--MOTION PICTURE
* 007--NOTATED MUSIC
* 007--REMOTE-SENSING IMAGE
* 007--SOUND RECORDING
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 email@example.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 firstname.lastname@example.org 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 email@example.com 2009-04-18 20:35:03 ----
Patch pushed to HEAD. Please test and close.
---- Additional Comments From firstname.lastname@example.org 2009-04-18 20:36:32 ----
Or rather, don't close, of course - awaiting patch for 008.
---- Additional Comments From email@example.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 firstname.lastname@example.org 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 email@example.com 2009-06-07 17:59:10 ----
Reopening. 008 plugin has not been fixed yet.
---- Additional Comments From firstname.lastname@example.org 2009-07-31 18:15:09 ----
This also applies to tag 006.
---- Additional Comments From email@example.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 firstname.lastname@example.org 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: email@example.com.
Previous reporter was firstname.lastname@example.org.
The original assignee of this bug does not have
an account here. Reassigning to the default assignee
for the component, email@example.com.
Previous assignee was firstname.lastname@example.org.
Bug reassigned, setting status to "NEW".
Previous status was "REOPENED".
CC member email@example.com does not have an account here
CC member firstname.lastname@example.org does not have an account here
CC member email@example.com does not have an account here
CC member firstname.lastname@example.org does not have an account here
Restoring where "Previous assignee was email@example.com"
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.
Original patch: http://lists.koha-community.org/pipermail/koha-patches/2009-April/008653.html
Created attachment 2641 [details] [review]
This partial fix adds a complete list of values for 006/00, "Form of material," following the list found here: http://www.loc.gov/marc/bibliographic/bd006.html
Pushed patch, please test
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.
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.
commit 6aee235e3c239fd46ffdc263bafd578d845e812b calls itself a "partial fix". Where is the fix for 008? I'm not finding it.
You are correct. Sorry. I failed to cull this one from my list.
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
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.
Created attachment 3247 [details] [review]
Cataloguing plugin for fields 006/008, Type of Material Display and form variation with type of material selection.
I've added on the cataloguing plugin for 006/008 fields the possibility to
select a type of material and to change the displayed form to view the allowed positions and enter the data accordingly.
The positions that require one char are presented as a combo, the positions with multiple chars are presented as a text field without restrinctions on value.
At the top of the plugin exists a grid-row with the current values for each position and its validity.
The allowed values are those defined on http://www.loc.gov/marc/bibliographic/bd006.html and http://www.loc.gov/marc/bibliographic/bd008.html.
I've added a new system preference "TypeOfMaterialsView_006_008" that activates this new functionality, or as default lets you to continue with the current one. So you can choose which one to use.
This functionality is implemented in the intranet -> Cataloging -> Add MARC Record
I attach proposed patch to test.
Created attachment 3248 [details] [review]
follow up patch
I have signed off on the first patch and submit this follow up for sign off. It updates the way the preference is worded in English to make more sense to users.
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.
Created attachment 3251 [details] [review]
Erase merge conflict marker left and replace XMLHttpRequest with jQuery
Erase merge conflict marker left on unimarc_standard_systemprefs.sql.
Replace XMLHttpRequest call for xml with jQuery Ajax interface.
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 :)
Ok, I'll make a new patch without the system preference.
I'll post it when finished.
Created attachment 3259 [details] [review]
Value builder for 006 and 008 need choices for all format types
Patch replacing current 006/008 plugin and without the system preference.
Signed off on new patch! Works awesome.
Pushed and merged please test and mark resolved
(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.
Pushed to 3.2.x.
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.
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"
Resetting status, as we don't have an updated patch to address the issues I've noted in comment 23
(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?
*** Bug 5196 has been marked as a duplicate of this bug. ***
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.