--- Comment #1 from John Sterbenz <[hidden email]> ---
This is still a known issue on Master as of November 2018. I note this has
been flagged as an "enhancement", but I believe it should be flagged with
something higher ("minor" seems appropriate to me based on my exploration),
since this an actual error in programming, not a convenience or a nicety.
This is the singular reason why I do not let my staff work in the Advanced
Editor despite the advantages it offers.
It would seem appropriate for the programming to consider a combination of
RecType and BibLevel (Leader bytes 6 and 7, respectively) when determining what
"option" to choose for the 008 dropdown of any record when called into the
What |Removed |Added
CC| |[hidden email]
--- Comment #2 from Donna <[hidden email]> ---
Confirming this is still an issue being reported by users, and causes a lot of
confusion and unnecessary repeated saving of a record. I agree this is not an
enhancement and have changed the importance to reflect that.
--- Comment #4 from John Sterbenz <[hidden email]> ---
This was discussed at the koha-US general meeting yesterday and I examined it
It looks as though the problem reported in this bug was corrected as observed
in the 18.11 release sequence (we're running 18.11.14). Looking for additional
verification of (unintentional?) squashing in this release sequence, 19.05,
19.11, and master.
--- Comment #5 from Heather <[hidden email]> ---
We're on 19.05.07.000 and I edited a map record and an online "computer file"
(database) record in Rancor, and neither one had their material types revert to
Book--their material types remained correct!
I got from your comments that this was a serious problem discussed in several
places, but it took me a while to understand the exact issue (and I hope I did)
I think a step by step test plan would help 'outsiders' of the discussion and
devs who are not so familiar with library workflows to grasp the actual
- Open any record in the advanced catalouging editor
- Change 008 to anything but BKS
- Save - if there is an error, for example 003 missing, it will rever to BKS
- Fix any errors
- Save to catalog again - verify it also reverted to BKS in display
It seems that this is also an issue for the normal editor:
- Open any record in cataloguing
- Switch 008 to anything but BKS
- Close the plugin
- Open it again - it shows BKS
I am not sure about the MARC standard here, it seems that the actual selection
is not part of the MARC record and I found no reference to another field this
could be pulled from. So I think this is the reason it was initially marked an
enhancement - the correct pull down value is not saved in the record, so it
cannot be determined/preselected when the record is opened again. (see
Would it help if 'none' was preselected?
Another possibility could be to save the value separately from the MARC record
in the db and pull from there.
Does someone know how other ILS solve this?
I believe the 'icon' issue noted in the Description is unrelated - for the
icons a combination of LDR, 007 and 008 are used. The value selected in the
first pull down of 008 is not part of the data, so it cannot be used for
display (and not break it)
What |Removed |Added
CC| |[hidden email]
--- Comment #7 from Elaine Bradtke <[hidden email]> ---
Even when the original record is not for a book (sound recordings for example),
when you open th 008 editor it defaults to book, and then throws up yellow
fields because the information doesn't fit the coding for books. Change it back
to 'music', and save it, open it again, and it changes back to 'book' (Normal
editor). This is disconcerting to your average cataloguer.
I think the underlying question is, why does this happen? It shouldn't change
information already in place when you open the editor.
This doesn't seem to happen in the other fields with popup editors.
--- Comment #9 from Katrin Fischer <[hidden email]> ---
Hi Elaine, I feel the problem is MARC :( As far as I can tell there is nothing
in the record that could tell Koha reliably what the value to show in the pull
down should be, so it always shows the first entry. This is not ideal, hence my
earlier question if showing an empty value would be better, as I think that
would probably be the easiest 'fix' to make it better, but certainly it would
not be great.
--- Comment #10 from Katrin Fischer <[hidden email]> ---
Some sources I found suggest that the material type in 008 could be linked to
positions 6 and 7 in the leader. I wonder what such a mapping could look like
an if it would work for all libraries?
--- Comment #11 from Heather <[hidden email]> ---
I don't think the problem is inherent in MARC because I've never worked with or
seen another ILS that has this problem.
But I also edited a DVD record in the Bywater demo 19.11.05.000 and could not
replicate the problem there, nor can I replicate the problem in our 19.05
catalog. I edited the 008 in the basic editor and the advanced editor, and it
remained, "Material type: Film." I edited another variable field, and the
material type remained "Film"--it didn't change to "Book" at all. I did the
same with two other types of records, and they didn't change to material type
So I then imported a record for Project Gutenberg into the Bywater demo and WAS
able to replicate the problem, this record:
https://catalog.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=117408 I even tried in the basic editor to change the 008 to one appropriate for a
computer file, and it reverted to BKS. I then tried in the basic editor to
change the 008 to one for Mixed Media, and it reverted to BKS. So I could
replicate the problem with this record.
So does this have something to do with the fact that Koha makes a record
conform to a particular MARC template? That a record imported as a "BK" always
reverts to that? Koha is the only system that I know of that has this
requirement for bibliographic and authority records--that they conform to
preset templates. (E.g., I can't simply change the 100 field in an authority
record to a 150.) With other systems a cataloger can type in a record without
selecting a template ahead of time, or if a template is selected, it can be
readily changed. Maybe it's something about the template that's causing the
record to revert to BKS?
--- Comment #12 from Katrin Fischer <[hidden email]> ---
Hi Heather, thx for your input!
Germany is still a bit new to MARC, so it's usually not used for cataloging
here and Koha is the only MARC bases system I know.
In order to select the right value in the pull down, when you open the record,
the information has to be drawn from somewhere. And I can't figure out where in
MARC this would be stored (008 has no position for that afaikt). I wonder if it
falls back to using the framework codes? I was testing with the Default
framework any my selection was always reset to first entry.
The other idea I had was that other ILS might store the material type in a
separate custom field.
--- Comment #13 from John Sterbenz <[hidden email]> ---
Bibliographic Level and Type of Record are both stored in the MARC record
"Leader"--the first 24 characters of any MARC (bibliographic) record. Leader
Byte 06 is Type and Leader Byte 07 is Bibliographic Level (note that counting
in the Leader starts with 0). Though they are not stored in the 008, they work
together to determine the rest of the fixed fields to be used in any given
record. Other fixed field values are also incorporated into the Leader and not
the 008 (including Encoding Level and Description).
OCLC's Bib Formats and Standards contains useful information here (Bib Formats
and Standards is free for use and is NOT restricted to OCLC member libraries):
--- Comment #14 from Katrin Fischer <[hidden email]> ---
Hi John, I think this is definitely useful. I notice that in the table there
are a lot of double ups - example: a could refer to muliple material types. I
think we'd need a more complete mapping, so that one possible combination only
leads to one material type - if that makes sense?
--- Comment #15 from Elaine Bradtke <[hidden email]> ---
After reading through the comments I decided to do a test of the leader and
I used a record for a sound recording. I went through and checked the leader,
the 006, 007 and 008 to make sure everything was as it should be.
I went back and changed the leader position 6 type of record to language
After I did that the 008 automatically switched the type of material to books.
I went back to the leader and changed the type of record back to j- Musical
The 008 switched back to type of material = MU music (without my intervention
in this field).
The leader seems to be providing the cue for the 008. Which is probably a good
thing, if this is what is happening. It means it's operator error. . . and
it's a clue to the cataloguer to check the leader.
--- Comment #16 from Elaine Bradtke <[hidden email]> ---
Further testing. It seems the Leader 06 is controlling the 008, but now I've
got a problem with the 006 reverting to books when Leader 06 and 008 are set to
Mixed materials. Is this the same problem, or is it a different bug?
--- Comment #17 from John Sterbenz <[hidden email]> ---
I just discovered the 006 matter Elaine discusses in her message of 5/29/2020.
The 006 should only reference the first byte (Byte 00) of itself when
determining what should be used in the rest of the 006 field. Currently, this
appears to always revert back to books (Byte 00 of 006 = "a"), regardless of
what it is actually set to. E-Books will have this set to "m" for computer
files, for example.
Even inserting a brand new 006 into the record, correctly coded, exhibits this
behavior just like existing 006 fields do.
Interestingly, the 007, which functions similarly to the 006 in that its first
byte determines how the rest of the field is laid out, DOES work correctly.
I view this as a separate, yet related, error to what's under discussion here
since there should be no dependence on any other value other than 006 Byte 00
to determine how the remainder of the 006 should be defined--unlike how the 008
will refer to bytes in the Leader to make this determination.