Bug 20194 - Display both biblioitems.itemtype and items.itype in circulation screens
Summary: Display both biblioitems.itemtype and items.itype in circulation screens
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Julian Maurice
QA Contact: Martin Renvoize
URL:
Keywords:
Depends on:
Blocks: 21750 25890
  Show dependency treegraph
 
Reported: 2018-02-14 10:36 UTC by Gaetan Boisson
Modified: 2021-06-14 21:29 UTC (History)
13 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
19.11.00


Attachments
Bug 20194: Display ccode and both itemtypes in checkouts tables (8.08 KB, patch)
2018-02-14 14:56 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 20194: Display both itemtypes in checkin table (4.29 KB, patch)
2018-02-14 14:56 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 20194: Display ccode and both itemtypes in pending reserves table (4.80 KB, patch)
2018-02-14 14:56 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 20194: Display both biblioitems.itemtype and items.itype in circulation screens (12.09 KB, patch)
2018-10-25 13:29 UTC, Alex Arnaud
Details | Diff | Splinter Review
Bug 20194: Display both biblioitems.itemtype and items.itype in circulation screens (12.22 KB, patch)
2018-10-25 20:45 UTC, Alex Buckley
Details | Diff | Splinter Review
Bug 20194: Display both biblioitems.itemtype and items.itype in circulation screens (10.57 KB, patch)
2019-09-30 07:54 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 20194: Display both biblioitems.itemtype and items.itype in circulation screens (10.59 KB, patch)
2019-11-01 11:16 UTC, Martin Renvoize
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Gaetan Boisson 2018-02-14 10:36:24 UTC
At the moment in circulation screens only one "item type" is displayed, biblioitems.itemtype or items.itype, depending on the item-level_itypes system preference.

It is however possible for libraries to use both, biblioitems.itemtype to qualify the record, and items.itype to qualify the item itself. In such a scenario only one of the two will be displayed on the circulation screen.

It is also possible for libraries to use items.ccode to further refine the description of their items, but this information is not displayed on circulation screens.

This enhancement will make all this information more visible in circulation.
Comment 1 Julian Maurice 2018-02-14 14:56:00 UTC
Created attachment 71613 [details] [review]
Bug 20194: Display ccode and both itemtypes in checkouts tables

Test plan:
1. Verify that biblioitems.itemtype, items.itype and items.ccode are
   mapped to a MARC field. Otherwise create those mappings.
2. Create a biblio with an itemtype
3. Create an item with a ccode and a different itemtype for this biblio
4. Check out this item to a patron (P1)
5. Verify that both itemtypes and the ccode are displayed in the
checkouts table
6. Create a patron whose guarantor is P1 and verify that both itemtypes
and the ccode are displayed in the 'relatives checkouts' table
Comment 2 Julian Maurice 2018-02-14 14:56:03 UTC
Created attachment 71614 [details] [review]
Bug 20194: Display both itemtypes in checkin table

And move ccode in its own column

Test plan:
1. Check in an item and verify that both itemtypes are displayed in the
   table
Comment 3 Julian Maurice 2018-02-14 14:56:07 UTC
Created attachment 71615 [details] [review]
Bug 20194: Display ccode and both itemtypes in pending reserves table

Test plan:
1. Go to /cgi-bin/koha/circ/pendingreserves.pl (Holds to pull) and
   verify that ccodes and both itemtypes are displayed in the table
Comment 4 Katrin Fischer 2018-02-15 06:00:14 UTC
Looking at the code there seems no way to hide one or the other or be clear about which itemtype is from the record or the item? They will just show up next to each other. I don't think that every library will like this change, as often they are the same and it would result in a double up of information.

Can you explain what the use case is for seeing both? If you have item-level itypes and items exist, I think seeing the item itype should be the right choice.
Comment 5 Gaetan Boisson 2018-02-16 12:40:08 UTC
We had discussed it internally before submitting this, and came up with the conclusion that displaying which type is which would be redundant, because we couldn't think of a scenario where the same list would be used in both fields.The display would always be something like "book ; long loan" and be explicit for the librarians because they know the lists they are using.

I am confused about what the use case would be for having the same information in both biblioitems.itemtype and items.itype. When that is the case, why not position item-level_itypes to bibliographic level, and leave items.itype empty?

Can you enlighten us on this with more details on the use case where the information would be the same?

The use case for this enhancement is that quite a few libraries want to qualify the bibliographic record with a notion of the type of document (book, dvd, etc.) because then all items attached to this record will obviously have the same type. This notion will be useful for search. But then some want to be able to have different circulation rules for the different items attached to the record, "long loan" and "short loan" for instance. This is the use case for using both. In that scenario, biblioitems.itemtype is controlled by a separate authorized value category, not by itemtypes. Some even crazier librarians use the ccode for an extra level of categorization on the item.

I think this is linked to a terminology issue in Koha that doesn't seem to bother everyone: what the system calls "item types" can be positioned at the bibliographic level, in which case it is not about *items* any longer.
Comment 6 Katrin Fischer 2018-02-16 13:53:40 UTC
(In reply to Gaetan Boisson from comment #5)
> We had discussed it internally before submitting this, and came up with the
> conclusion that displaying which type is which would be redundant, because
> we couldn't think of a scenario where the same list would be used in both
> fields. The display would always be something like "book ; long loan" and be
> explicit for the librarians because they know the lists they are using.

It sounds, like you have a different list of values for each? I think that we might encounter here is a main difference in use/understanding of the different itemtype fields (between MARC21/UNIMARC(?))

For MARC21 the default mapping for biblioitems.itype was (I think) never changed and is itemtypes. The same as for items. So the values will match in a lot of cases. The record level itemtype is used in some cases, even when you are using item-level itypes:

- When editing an item, the itemtype from the record will be preselected when adding an item.
- When using article requests, you can use the itemtype on record level to allow article requests for records without items (serials, articles)
- For some scenarios with holds, I think the record level itemtype is used when there is more than one itemtype on the record (Kyle might know, I seem to remember a dev of his did that)
- For advanced search itemtypes both item and record level are (for MARC21) indexed equally. One possible use case here is having an itemtype for electronic resources without the need to add items to the records.

> I am confused about what the use case would be for having the same
> information in both biblioitems.itemtype and items.itype. When that is the
> case, why not position item-level_itypes to bibliographic level, and leave
> items.itype empty?

Because item-level_itypes lets you decide which one will be the primary for your circulation conditions. 

> Can you enlighten us on this with more details on the use case where the
> information would be the same?

For example when you are using the "preselect" functionality above or for the holds scenaro - it might match with some items, but not with all of them.

> The use case for this enhancement is that quite a few libraries want to
> qualify the bibliographic record with a notion of the type of document
> (book, dvd, etc.) because then all items attached to this record will
> obviously have the same type. This notion will be useful for search. But
> then some want to be able to have different circulation rules for the
> different items attached to the record, "long loan" and "short loan" for
> instance. This is the use case for using both. In that scenario,
> biblioitems.itemtype is controlled by a separate authorized value category,
> not by itemtypes. Some even crazier librarians use the ccode for an extra
> level of categorization on the item.

I honestly don't think this was not a good idea. It appears to me like misusing a field that was meant to have a different meaning in Koha, but it will prevent you from using some features (examples given above) as it doesn't match with what Koha expects in that field.
 
> I think this is linked to a terminology issue in Koha that doesn't seem to
> bother everyone: what the system calls "item types" can be positioned at the
> bibliographic level, in which case it is not about *items* any longer.

There has been discussion about that on the mailing list and especially about the use of item-level_itypes and the idea of removing it.

As always... I might be completely wrong :) Setting this to "In Discussion" and CC'ing a few people that might have some more insight also in history.
Comment 7 Nick Clemens 2018-02-16 14:45:11 UTC
I think the idea is sound, but I would say only show 1 if the values are the same  and say label the types if they differ. 

ideally maybe a column for each? If in the same column they should have classes so the record level can be hidden for libraries who don't use this feature in the way you are describing

it is standard practice at many US libraries to assign both - the record level itype is needed to correctly limit record level holds per itemtype, and you need both if you offer specific item holds as well
Comment 8 Gaetan Boisson 2018-02-16 16:56:22 UTC
Ok i guess i'm not really clear about the marc21 use cases.

But it seems to me that it is then possible in the marc21 setup to have both fields filled with different information, in which case it is certainly of interest to show it to the users.

I like Nick suggestion of adding labels and css classes to allow hiding them easily.

Would that work out for everyone then?
Comment 9 Katrin Fischer 2018-02-16 21:35:26 UTC
IDs and classes will still require some knowledge to set appropriately. Maybe separate columns and use the column visibility tools turning them invisible by default for new installations?
Comment 10 Alex Arnaud 2018-10-25 13:29:51 UTC
Created attachment 81161 [details] [review]
Bug 20194: Display both biblioitems.itemtype and items.itype in circulation screens

Test plan:
1. Verify that biblioitems.itemtype, items.itype are
   mapped to a MARC field. Otherwise create those mappings.
2. Create a biblio with an itemtype
3. Create an item with a different itemtype for this biblio
4. Check out this item to a patron (P1)
5. Verify that both itemtypes are displayed in the
checkouts table (moremember.pl, circulation.pl, returns.pl)
6. Create a patron whose guarantor is P1 and verify that both itemtypes
and the ccode are displayed in the 'relatives checkouts' table
Comment 11 Alex Buckley 2018-10-25 20:45:38 UTC
Created attachment 81202 [details] [review]
Bug 20194: Display both biblioitems.itemtype and items.itype in circulation screens

Test plan:
1. Verify that biblioitems.itemtype, items.itype are
   mapped to a MARC field. Otherwise create those mappings.
2. Create a biblio with an itemtype
3. Create an item with a different itemtype for this biblio
4. Check out this item to a patron (P1)
5. Verify that both itemtypes are displayed in the
checkouts table (moremember.pl, circulation.pl, returns.pl)
6. Create a patron whose guarantor is P1 and verify that both itemtypes
and the ccode are displayed in the 'relatives checkouts' table

Followed test plan, patch worked as described, also passes QA test tool
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Comment 12 Katrin Fischer 2018-11-14 20:28:17 UTC
I am not sure about the terminology of using Record type - this is still an itemtype, just from a different level. I think it gives a wrong idea of the usage.
Comment 13 Jonathan Druart 2018-12-13 20:32:51 UTC
So far "record type" is used to make the difference between biblio and authority. I am not sure it is a good idea to reuse it for a different need.

English native speakers around?
Comment 14 Jonathan Druart 2018-12-13 20:33:36 UTC
(In reply to Katrin Fischer from comment #12)
> I am not sure about the terminology of using Record type - this is still an
> itemtype, just from a different level. I think it gives a wrong idea of the
> usage.

Ha! I did not see your comment! We are at least two then :)
Comment 15 Julian Maurice 2019-02-25 11:16:07 UTC
(In reply to Katrin Fischer from comment #12)
> I am not sure about the terminology of using Record type - this is still an
> itemtype, just from a different level. I think it gives a wrong idea of the
> usage.

Is "Record-level item type" better ?
Comment 16 Katrin Fischer 2019-02-25 12:47:46 UTC
(In reply to Julian Maurice from comment #15)
> (In reply to Katrin Fischer from comment #12)
> > I am not sure about the terminology of using Record type - this is still an
> > itemtype, just from a different level. I think it gives a wrong idea of the
> > usage.
> 
> Is "Record-level item type" better ?

I like it better, but a native speaker would probably be helpful :)
Comment 17 Nick Clemens 2019-02-25 13:35:24 UTC
(In reply to Katrin Fischer from comment #16)
> (In reply to Julian Maurice from comment #15)
> > (In reply to Katrin Fischer from comment #12)
> > > I am not sure about the terminology of using Record type - this is still an
> > > itemtype, just from a different level. I think it gives a wrong idea of the
> > > usage.
> > 
> > Is "Record-level item type" better ?
> 
> I like it better, but a native speaker would probably be helpful :)

That makes sense to me, that is how we refer to it
Comment 18 Nick Clemens 2019-09-30 07:54:04 UTC
Created attachment 93221 [details] [review]
Bug 20194: Display both biblioitems.itemtype and items.itype in circulation screens

Test plan:
1. Verify that biblioitems.itemtype, items.itype are
   mapped to a MARC field. Otherwise create those mappings.
2. Create a biblio with an itemtype
3. Create an item with a different itemtype for this biblio
4. Check out this item to a patron (P1)
5. Verify that both itemtypes are displayed in the
checkouts table (moremember.pl, circulation.pl, returns.pl)
6. Create a patron whose guarantor is P1 and verify that both itemtypes
and the ccode are displayed in the 'relatives checkouts' table

Followed test plan, patch worked as described, also passes QA test tool
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Comment 19 Nick Clemens 2019-09-30 07:54:46 UTC
Rebased, updated the wording, signed off
Comment 20 David Cook 2019-09-30 08:14:51 UTC
(In reply to Nick Clemens from comment #17)
> (In reply to Katrin Fischer from comment #16)
> > (In reply to Julian Maurice from comment #15)
> > > (In reply to Katrin Fischer from comment #12)
> > > > I am not sure about the terminology of using Record type - this is still an
> > > > itemtype, just from a different level. I think it gives a wrong idea of the
> > > > usage.
> > > 
> > > Is "Record-level item type" better ?
> > 
> > I like it better, but a native speaker would probably be helpful :)
> 
> That makes sense to me, that is how we refer to it

As a native English-speaking librarian, biblioitems.itemtype makes me crazy. 

I usually say "Bib-level item type" or "Bibliographic-level item type", and then wish that biblioitems.itemtype will be removed from Koha, since "Bib-level item type" is a paradox. The concept makes no sense in a library, and I've had a lot of confused librarians ask me about it over the years.

But... I'm sure that it's not going away any time soon. 

"Record-level item type" doesn't make sense in libraries, but I think it's probably a good enough technical description.
Comment 21 Martin Renvoize 2019-11-01 11:16:04 UTC
Created attachment 94947 [details] [review]
Bug 20194: Display both biblioitems.itemtype and items.itype in circulation screens

Test plan:
1. Verify that biblioitems.itemtype, items.itype are
   mapped to a MARC field. Otherwise create those mappings.
2. Create a biblio with an itemtype
3. Create an item with a different itemtype for this biblio
4. Check out this item to a patron (P1)
5. Verify that both itemtypes are displayed in the
checkouts table (moremember.pl, circulation.pl, returns.pl)
6. Create a patron whose guarantor is P1 and verify that both itemtypes
and the ccode are displayed in the 'relatives checkouts' table

Followed test plan, patch worked as described, also passes QA test tool
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 22 Martin Renvoize 2019-11-01 11:16:53 UTC
Works well and I think clarifies things to the end user.. Passes QA scripts, Passing QA
Comment 23 Martin Renvoize 2019-11-03 07:52:53 UTC
Nice work!

Pushed to master for 19.11.00