[Bug 38042] New: Wrong values in Item type form on acqui/neworderempty.pl
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38042 Bug ID: 38042 Summary: Wrong values in Item type form on acqui/neworderempty.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs@lists.koha-community.org Reporter: mathsabypro@gmail.com QA Contact: testopia@bugs.koha-community.org Not sure of the right component for this problem, but it has an impact on our acquisition workflow. The problem seems to have been introduced by https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29554 When entering a manual order, the form on acqui/neworderempty.pl imposes a "Item type" field with a drop-down menu containing wrong values. Our configuration (defined with our vendor 2 years ago, and everything was fine in 21.11) : - UNIMARC - item-level_itypes : specific item - record level item type defined in 099$t : mapped with biblioitems.itemtype ; using TYPEDOC authorized values - item item type defined in 995$r : mapped with items.itype ; using value:itemtypes authorized values When you create a record in acqui/neworderempty.pl, the "Item type" fills the 099$t, so the form must display the TYPEDOC values. It was the (logical) behavior before the change introduced by https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29554 Now, the form display the "itemtypes" values. That's not good, it creates a data coherence issue -- 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=38042 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |29554 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29554 [Bug 29554] neworderempty.pl may create records with biblioitems.itemtype NULL -- 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=38042 --- Comment #1 from Mathieu Saby <mathsabypro@gmail.com> --- Add on : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30373 has added TYPEDOC value in default UNIMARC configuration, and make use of it in 099$t, while 995$r uses itemtypes So it seems our configuration follows this default behavior -- 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=38042 --- Comment #2 from Mathieu Saby <mathsabypro@gmail.com> --- Our vendor had to make a local patch to fix the issue -- 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=38042 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I had a long discussion about the problems caused by the different mapping with Julian on some bug I believe. I don't think we should support it in core, because it is causing you problems you might not notice as it's breaking features, like the max count of holds for record level holds, circulation conditions for article requests without items, searchability of item type on record level in the advanced search etc. The ultimate solution is to have a separate field for the document type instead or re-using the itemtype that should be linked to itemtypes independent of MARC flavor. -- 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=38042 --- Comment #4 from Mathieu Saby <mathsabypro@gmail.com> --- Although this mode of operation was developed in the UNIMARC "community", strictly speaking, this is not a MARC flavor issue. Is there really nobody in the MARC21 community that would be interested in a differentiated record/item type management? In fact, I don't understand the purpose of the "standard" behavior. What's the interest of copying the same value at biblio and item level ? What's certain is that our configuration worked well in the past for us, and has been used by other libraries in France for years. I'd even go so far as to say that if Koha hadn't enabled us to have different types for record and items, we would have been forced to choose an other ILS. -- 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=38042 --- Comment #5 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Mathieu Saby from comment #4)
Although this mode of operation was developed in the UNIMARC "community", strictly speaking, this is not a MARC flavor issue. Is there really nobody in the MARC21 community that would be interested in a differentiated record/item type management? In fact, I don't understand the purpose of the "standard" behavior. What's the interest of copying the same value at biblio and item level ?
What's certain is that our configuration worked well in the past for us, and has been used by other libraries in France for years. I'd even go so far as to say that if Koha hadn't enabled us to have different types for record and items, we would have been forced to choose an other ILS.
The UNIMARC community never communicated this to the MARC21 community, so on side was not aware of the others change. Now we are in a non-good situation. I haven't said that there should not be a document type field, just that it should have been added as a separate field from the beginning. And I woudl be really interested to hear why it is so important to your libraries and how it is used. With the current setup, UNIMARC users are losing features and we will keep encounter situations where things break. In a MARC21 installation, if you set the itemtype at record level, it will be used for: 1) Search: Records without items (electronic resources, serials, set records) will be searchable with this item type from the advanced search, as both fields are indexed as item type (942$c and 952$y) 2) Cataloguing help: the record level itype will be suggested as itemtype when adding a new item. 3) Article requests for records without items: article requests can work both on item level and biblio level. The item type on record level will be used to determine if an article request on a record is allowed by circulation rules if you chose "biblio level" 4) Hold requests: If you want to enforce a max of 4 record level hold requests on a certain item type, the record level one will be used to check the rule (item types in the items might be mixed item types) ... It did work for you, but it will keep breaking as long as both MARC and UNIMARC work in different directions here. The best solution would be to introduce a new field for your record/document type and restore itype to be the same as MARC21. But I am not a UNIMARC user. I have been pointing out the diverting behavior for years in order to help. -- 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=38042 --- Comment #6 from Mathieu Saby <mathsabypro@gmail.com> --- Thanks for these explanations. Maybe Biblibre would present things differently, but from my point of view, here is how it works for us and why : We use items.itype as a "type of loan". I believe this is pretty common in other libraries in France. Perhaps not all of them. It gives the ability to define specific rules for for items attached to the same record. Frequent situation if the items belong to different libraries, but it can happen if they belong to different sections of the same library. - item A : can be checked out with standard loan period => in items.itype we choose a value like "NORMALLOAN" - item B : must have a shorter loan period => in items.itype we choose a value like "SHORTLOAN" - item C : cannot be checked out (but staff can override) => in items.itype we choose a value like "NOLOAN" In my library we also items.ccode as a "type of material". I believe it is less common. We had a "material type" at item level in our previous ILS and wanted to keep this information. Our biblioitems.itemtype is calculated from the coded fields of the record, which is imported from our national union catalog. So the item level material type gives us more flexibility to define custom specific types. Something like "object" at record level and "chessboard" at item level. It is especially useful when the record level item type is something like "multisupport document" : if the document is a CD with a book, we can assign the type "CD" to one item ccode, and the type "book" to the other item, and know for example if the book or the CD was lost by a reader. -- 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=38042 --- Comment #7 from Mathieu Saby <mathsabypro@gmail.com> --- For information and comparison, I have just taken a look to the open source FOLIO ILS for other reasons, and I note that their standard implementation makes the distinction between : - at record level : "ressource type" - at item level "material type" and "permanent loan type" with 3 different sets of values for filling those fields -- 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=38042 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@bigballofwax.co.nz --- Comment #8 from Chris Cormack <chris@bigballofwax.co.nz> --- As the original person who created the bibliotems table I can tell you itemtype there was never meant to map to anything other than the Koha itemtype. So if you a column ton mean something else you either needed to rename it after consulting the wider community. Or better create another column named after you mean it to be, perhaps loan type. Having a column called something that doesn't represent what is stored in it is a bad idea. -- 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=38042 --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Mathieu, what are you fighting for? I am not advocating against having a resource type field. I am advocating to have feature parity again for UNIMARC and MARC21 users. The easiest way to get there in my opinion is to have a new separate field for the resource type and re-map to itemtypes for the other field. I think this would be code-wise the easiest fix to have the best of both worlds and stop the current situation where MARC21 and UNIMARC pull in different directions in development, which leads to broken features for users of one MARC flavors and an ongoing need to fix bugs like this. -- 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=38042 --- Comment #10 from Mathieu Saby <mathsabypro@gmail.com> --- Well, I am not in a fighting mode... But there seems to be long-standing disagreement within the developer and vendors community on this point, which has not been the subject of an easy-to-follow discussion involving all stakeholders. All this is detrimental to libraries... This should not be my role as a librarian to discuss technically those matters. I thought it would be possible to harmonise practices by ‘officially’ approving the use observed in France, and I tried to show that it was sensible and useful from a user perspective. If it is not possible for technical reasons, does the community agree that it could be an enhancement, in order to give libraries more flexibility, and to support for example the use cases pointed in my comment https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38042#c6 ? -- 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=38042 --- Comment #11 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I am not sure what our misunderstanding is based on. :( All I want IS to harmonize. But we can't just establish the UNIMARC behavior for both MARC flavors as it would break all the features I listed for MARC21 and vice versa. We need to find a technical solution that keeps both feature sets available and makes the feature set of one flavor available to the other. -- 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=38042 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |victor@tuxayo.net -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38042 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38336 -- 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=38042 --- Comment #12 from Mathieu Saby <mathsabypro@gmail.com> --- Note that it may be affected by https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 => When 38336 is pushed it will be usefull to try to replicate this bug -- 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=38042 Sonia Bouis <sonia.bouis@univ-lyon3.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sonia.bouis@univ-lyon3.fr --- Comment #13 from Sonia Bouis <sonia.bouis@univ-lyon3.fr> --- Hello, I must admit that I don't understand all the points of your debate. What I can confirm is that as almost all libraries supported by Biblibre, our library is using item-level_itypes = specific item As Mathieu explained, when adding a new biblio record from acquistion module, it is asked to fill an item type on a the biblio level and that is a nonsense. Biblibre provided a correction for Koha 24.11 but it seems to be only for their users. I don't really understand why it is not possible to check the item-level_itypes and to hide the drop-down menu if the preference systeme is on item. As I know that all the acquisition module is going to be refactoring/enhancing, I'm wondering now if it is planned to managed that a lot of koha users don't want to choose a value liked to items on a biblio record. I'm not sure I'm really clear, but I hope this comment could help the mutual understanding. Sonia -- 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=38042 --- Comment #14 from Sonia Bouis <sonia.bouis@univ-lyon3.fr> --- Created attachment 187836 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=187836&action=edit acquisition - biblio part with item values -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org