[Bug 41400] New: Support the use of distinct values for record-level types and item-level types
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41400 Bug ID: 41400 Summary: Support the use of distinct values for record-level types and item-level types Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: mathsabypro@gmail.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle@bywatersolutions.com Following the discussions under Bug 38042, I propose this enhancement : support the use of distinct values for record-level types (biblioitems.itemtype) and item-level types (items.itype). The way Koha manages item and record type is different from most ILS, and does not allow the flexibility required to manage a library network if it is not made possible to use different values in biblioitems.itemtype and item-level types. Many libraries, particularly in France, have been using different values for several decades, probably since the introduction of Koha in France. But currently this configuration can cause issues (cf Bug 38042). Use case : - Book1 and Book2 are owned by Library1 and Library2. - circulation rules are based on item-level itemtype - at the record level, the type for the 2 records is "book" - Library1 wants to apply the standard circulation rule to Book1 and Book2 (thus using the same value in item-level itemtype, eg. "NORMALLOAN") - Library2 wants to restrict the use of book1 by applying a specific circulation rule, but agree to apply the standard rule to Book2 (thus using distinct values in item-level itemtype, eg. "NORMALLOAN" and "SHORTLOAN") -- 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=41400 Donna <bwsdonna@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bwsdonna@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41400 --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I suggest to not reuse the biblioitems.itemtype, but create a new column as outline in many other bugs, bilbioitems.itemtype is already used for several features where it's expected to be a valid itemtype. Adding a new column will be a much safer change and allow to develop a good feature set on top that doens't interrupt existing behaviors. -- 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=41400 --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- If we implement your change as suggested, it will require more complex and possibly confusing code and possibly more and more such changes over time. Having a new separate database field would allow all libraries to have the best of both worlds: - All features would work as expected that rely on biblioitems.itemtype being a valid itemtype (including holds behavior, article requests etc.) - It could probably solve your circulation rules issue. - It would allow libraries who rely on those features to use the new column and the features build on top of it, without having to choose one or the other. What I am missing in the bug report is the use case of having the different biblioitems.itemtype - like what do you achieve with it currently? What are the use cases? -- 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=41400 --- Comment #3 from Mathieu Saby <mathsabypro@gmail.com> --- The use case is the one I put down in bug description. Maybe we can imagine an other one, in a 1-branch Koha. At biblio level you can have a value "multi-part document", that make no sense at item level. But I believe the real difficulties are for networks, like in my description. My previous ILS would use distinct fields at items level, for storing "material type" (book etc) and "circulation type" (21 days, 5 days, etc). And an other kind of data at biblio level (aligned with types defined in UNIMARC manual, but that's another story). In Koha we currently don't have the same precision and we "twist" the model, for example by using the collection code in a way that was probably not initially intended. -- 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=41400 --- Comment #4 from Mathieu Saby <mathsabypro@gmail.com> --- In fact, one difficulty in France stems from the fact that we have a collective catalog. Our Koha records are derived from this catalog. Koha therefore creates a document type at the record level based on these records, which imposes a significant constraint. We cannot define a "booklet" type for small books for ex. If we want to distinguish beteween books and booklets, we must do it at item level. But once again this is not the main issue (circulation rules management) -- 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=41400 --- Comment #5 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think we are going circles not quite understanding each other :( I read through your example from the first comment, but I am not quite understanding the issue. Why not have a document type on record level as a new field, with an authorised value list and ALSO have biblio and record level item types that are used for circulation? The biblioitems.itemtype is already used in some situations, even with item-level itemtypes. It should be possible to script a migration from biblioitems.itemtype to the new field. -- 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=41400 --- Comment #6 from Mathieu Saby <mathsabypro@gmail.com> --- I am well aware that this would be a major change that would require long and in-depth discussions before it could possibly come to fruition... Well, today is not the day to resolve all that, the turkey is waiting for me ;-) -- 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=41400 --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Mathieu Saby from comment #6)
I am well aware that this would be a major change that would require long and in-depth discussions before it could possibly come to fruition... Well, today is not the day to resolve all that, the turkey is waiting for me ;-)
Turkey on new year's? :) Enjoy! Please don't think I am saying we could not have a resource/document type on record level - I think it would indeed be useful. We have created one and use a custom (9xx) field for it. I also have code ready in our XSlT to display it and we will use it for search facets too. My argument is that it should be its own thing, not using a field that is also used for other purposes. -- 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