Bug 41400 - Support the use of distinct values for record-level types and item-level types
Summary: Support the use of distinct values for record-level types and item-level types
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-12-07 14:56 UTC by Mathieu Saby
Modified: 2025-12-31 14:36 UTC (History)
3 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Saby 2025-12-07 14:56:49 UTC
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")
Comment 1 Katrin Fischer 2025-12-29 20:02:07 UTC
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.
Comment 2 Katrin Fischer 2025-12-29 20:49:13 UTC
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?
Comment 3 Mathieu Saby 2025-12-31 14:00:28 UTC
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.
Comment 4 Mathieu Saby 2025-12-31 14:07:43 UTC
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)
Comment 5 Katrin Fischer 2025-12-31 14:19:06 UTC
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.
Comment 6 Mathieu Saby 2025-12-31 14:29:54 UTC
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 ;-)
Comment 7 Katrin Fischer 2025-12-31 14:36:13 UTC
(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.