Bug 19419

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 Advanced Editor.

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.

*** Bug 16783 has been marked as a duplicate of this bug. ***

This was discussed at the koha-US general meeting yesterday and I examined it again.

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.

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 problem.

To test:
- 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  http://www.loc.gov/marc/bibliographic/bd008.html)

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)

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.

Above comment is regarding version 19.11.05

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.

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?

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 "Book."

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.

I then tried to change the 008 for this record, a DVD, to various other formats, and it always reverted to "Film"--it wouldn't let me change it's 008, and I couldn't replicate the problem with that record:
https://catalog.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=10884

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?

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.

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):

Fixed field overview (includes discussion of the Leader and 008 values that are always in the same place, regardless of format):
https://www.oclc.org/bibformats/en/fixedfield.html

Leader / 008 summary: https://www.oclc.org/bibformats/en/fixedfield/008summary.html

Type of Record (has a nice table showing the relationships between formats, Type, and Bib Level):
https://www.oclc.org/bibformats/en/fixedfield/type.html

Bibliographic Level:
https://www.oclc.org/bibformats/en/fixedfield/blvl.html

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?

After reading through the comments I decided to do a test of the leader and 008.

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 material. 
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 sound recording.
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.

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?

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.

Trying to summarize as it's been a while.

- We have discovered that the resetting of 008 happens when LDR pos. 6 is not set which is acceptable behaviour.
- We have also discovered a new problem with 006 not behaving in the same way, correct?

I suggest to close this one and file a new bug for the 006 issue, as there is a lot of discussion here already. But we could link them using the "See also".

Created attachment 140836 [details]
Screencast showing 008 defaults to BK

This screencast shows how the 008 reverts back to Material Type BK, even when changed to VM in the record creation process, using the 008 helper.

(In reply to Catrina Berka from comment #19)
> Created attachment 140836 [details]
> Screencast showing 008 defaults to BK
> 
> This screencast shows how the 008 reverts back to Material Type BK, even
> when changed to VM in the record creation process, using the 008 helper.

Hi Catrina, 

please check that your LDR pos. 6 is set correctly. In your video you left it unchanged, so it used BK which is default. Koha will determine the selection on 008 depending on the LDR setting. I just tested this and it seems to still work ok on master.

Some ideas how we can improve this for discussion:

* Add a note that the value will be pulled from LDR pos. 6 to the label of the 008 material type pull down
* Don't allow to update the material type pull down manually, make it read only.

What do you all think?

Does bug 30871 solve this?

I believe this to be fixed/resolved with the bug 30871 and bug 32325.

We have a clearer understanding now of how it should work and have taken steps to make it more visible to users. If there are other things we could do, those could still be filed as separate bugs.