[Bug 34128] New: Series entry in the 490 field causes the ordering of items to change in the holdings table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 Bug ID: 34128 Summary: Series entry in the 490 field causes the ordering of items to change in the holdings table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs@lists.koha-community.org Reporter: matt.blenkinsop@ptfs-europe.com QA Contact: testopia@bugs.koha-community.org CC: m.de.rooy@rijksmuseum.nl The presence of a series entry in the 490 field causes the ordering of items to change in the holdings table. The different ordering is designed to display serial/journal items correctly but it shouldn't be triggered by a 490 entry for a "Books" item type To replicate: 1) In cataloging, click on New record 2) Fill in all the required fields with generic data, ensuring that the 942c field (Koha item type) is "Books" 3) In the 490a field - fill in any string as the Series statement 4) Click save 5) You should now be on the Add item page. We need to add 3+ items, making sure that the Home and Current libraries for each item are in reverse alphabetical order. e.g. Item 1: - Home library: Midway - Current library: Midway Item 2: - Home library: Fairview - Current library: Fairview Item 1: - Home library: Centerville - Current library: Centerville 6) In the top searchbar, find your new item that you have just added 7) On the item detail page, the holdings table will be displaying the items in reverse alphabetical order by library rather than in alphabetical order as it should be by default -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 --- Comment #1 from Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com> --- Created attachment 152711 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=152711&action=edit Bug 34128: Prevent holdings table from incorrectly ordering items This patch stops the hildings table from incorrectly ordering books as serials Test plan: 1) In cataloging, click on New record 2) Fill in all the required fields with generic data, ensuring that the 942c field (Koha item type) is "Books" 3) In the 490a field - fill in any string as the Series statement 4) Click save 5) You should now be on the Add item page. We need to add 3+ items, making sure that the Home and Current libraries for each item are in reverse alphabetical order. e.g. Item 1: - Home library: Midway - Current library: Midway Item 2: - Home library: Fairview - Current library: Fairview Item 1: - Home library: Centerville - Current library: Centerville 6) In the top searchbar, find your new item that you have just added 7) On the item detail page, the holdings table will be displaying the items in reverse alphabetical order by library rather than in alphabetical order as it should be by default. 8) Apply patch 9) Refresh the item detail page - the items should now be correctly ordered. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |matt.blenkinsop@ptfs-europe |ity.org |.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hm, I believe there are some things here that are a little odd. 490 doesn't indicate if something is a serial - it only indicates it's part of a series (a volume of a series). I believe I haven't seen serial flag set in MARC21 installations, but I might be mistaken. Could a library have changed the Koha-to-MARC mappings falsely resulting in it to validate to true? Also we should not hardcode a framework code. Koha comes with some examples, but libraries can and will built their own with any code. Also: Test plan needs updating (mentions 942 set to Books) I'd suggest checking the mappings! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Note: default mapping for biblioitems.serial appears to be 942$s! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |phil@chetcolibrary.org --- Comment #4 from Phil Ringnalda <phil@chetcolibrary.org> --- Koha does try to set biblio.serial based on seriestitle, in https://git.koha-community.org/Koha-community/Koha/src/commit/532cf4ab9f5549... And from a quick sandbox test, it succeeds (had to use a sandbox, since my production install has seriestitle only mapped from 440, not 490, so I lack both seriestitle and serial). Blame says that Koha has been that way at least since "rel_3_0 moved to HEAD" 17 years ago. It's not sane, but it's a longstanding lack of sanity. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 --- Comment #5 from Phil Ringnalda <phil@chetcolibrary.org> --- Amusingly, there's also is_serial, which CheckPrevCheckout added because it wanted to know about actual serials where you don't want to warn someone checking out the current issue of People that they checked out the issue from last week, and the issue from the week before, and so on. Alas, it says something is_serial if biblio->serial, or if leader/07 is "s", rather than only checking the leader (which is also bad for it, since for people who actually have 490 mapped to seriestitle, and thus set serial for it, people who have forgotten that they already read number 34 in a series won't be warned about that). Maybe we need to add really_is_serial? Or for that matter, really_really_is_serial, since what this code actually needs to know is whether or not sorting by serialid.publisheddate makes sense, which it only does if all, or maybe at least two, of the itemnumbers exist in serialitems.itemnumber. I have plenty of biblios with leader/07="s", but since I don't use the serials module, serialid.publisheddate doesn't do anything for me. Or I guess in a less painful way to look up for every load of every items table, if the biblionumber exists in a serial.biblionumber. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I believe that mapping seriestitle probably made sense in UNIMARC as the serial flag seems to stem from there. It would be interesting to see what is mapped in UNIMARC and if that makes more sense. Can we agree that a volume in a series is not a serial? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 --- Comment #7 from Phil Ringnalda <phil@chetcolibrary.org> --- By default, UNIMARC maps biblio.serial to both 099$s and 942$s, neither one editable by default, and maps biblio.seriestitle to nothing at all. So in UNIMARC you only get biblio.serial if you either make one of the $s subfields editable, or you map biblio.seriestitle to something thinking that doing so will do you some good. I can agree that being a volume in a series has no relationship whatsoever to being a serial, if that helps. According to the first session in https://www.loc.gov/catworkshop/courses/naco-full%20series-RDA/course%20tabl... in 2013 when they last updated their numbers, 89.4% of the series headings in the LC/NACO name authority database were monograph series ("Annual report of the tin production in Moldavia"), and monograph series are serials by definition, unlike multipart monograph series ("Continents of the world") that have a fixed ending. So I can't agree that "a volume in a series is not a serial," only that "a volume in a series either is or is not a serial." I would sign off a patch that removes setting biblio.serial based on biblio.seriestitle in a heartbeat. More than a heartbeat: it's only set in AddBiblio, not ModBiblio, so you have to have a seriestitle when you first save a record to have serial set. Even better, ModBiblio actually gets rid of it. The first time you save a biblio without a seriestitle, serial is set to 0, but if you save it again it is reset to null; the first time you save a biblio with a seriestitle, serial is set to 1, but if you save it again it is set to null, making the whole seriestitle -> serial thing useless. Workaround for Matt's clients who are annoyed by unsorted items from a 490 existing: edit the biblio and save it without making any changes. Poof, no longer a serial. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 --- Comment #8 from Phil Ringnalda <phil@chetcolibrary.org> --- Oy. It hasn't been that way for over 17 years, it's been that way for 16 years, since https://git.koha-community.org/Koha-community/Koha/commit/af466ca41ab02150f4... looked at the pointless code that was my $series = 0; if ( $biblio->{'seriestitle'} ) { $series = 1 } and said "well, $series is unused, there's no biblio.series for it to set, but serial is just two letters differnt than series so they must have meant # set the series flag my $serial = 0; if ( $biblio->{'seriestitle'} ) { $serial = 1 } " so this whole stupid thing is because someone looked at dead code and instead of deleting it, made it do something very wrong instead. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 --- Comment #9 from Phil Ringnalda <phil@chetcolibrary.org> --- Filed bug 34182 for removing the bogus code, though that won't help here since the damage has already been done to existing installations. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=34182 CC| |martin.renvoize@ptfs-europe | |.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 --- Comment #10 from Phil Ringnalda <phil@chetcolibrary.org> --- I've never used the serials module. Is it reasonable to expect that there will be biblios with some items added through it which have a serialid, and other items not added through it, either from before a single library started using it, or from other libraries in a consortium not using it? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 --- Comment #11 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Should we retask this one for creating a database update that fixes any bad data found.. I'm not sure how easy it would be to identify such cases -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |ASSIGNED Summary|Series entry in the 490 |Clean up biblioitems.serial |field causes the ordering |data |of items to change in the | |holdings table | --- Comment #12 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I would love to see clean-up, but not sure how we can best do it. * Whatever we do, we want to limit to MARC21 installations. * We don't know if the library has been setting the flag manually in some cases. * We will need to access MARC data, which might make any clean-up really slow on big databases. Ideas: Would running misc/batchRebuildBiblioTables.pl.fix the issue now? Then we could add a database statement recommending to run it. Could we assume that we only if 942$s exists/is filled, we should set biblioitems.serial? I think the previously false code, didn't create that field, right or wrong? Thinking more about it... what does the alternative sorting do exactly? It seems to counteract OPACHoldingsDefaultSortField? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|matt.blenkinsop@ptfs-europe |koha-bugs@lists.koha-commun |.com |ity.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34128 --- Comment #13 from Phil Ringnalda <phil@chetcolibrary.org> --- (In reply to Katrin Fischer from comment #12)
Thinking more about it... what does the alternative sorting do exactly? It seems to counteract OPACHoldingsDefaultSortField?
More the other way around: this sorting affects how the data is ordered when the script passes it to the template, and then the template told the datatable to sort the data by OPACHoldingsDefaultSortField, which should have then resulted in a sort like 'by homebranch by publisheddate by enumchron.' But, funny story: to verify that, I'm pretty sure you would need to check in either 16.11 or 17.05, since the code that actually did something with the template var default_order_index which is set based on the setting of OPACHoldingsDefaultSortField disappeared by 17.11, and thus it hasn't done anything at all since then. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org