|
Description
Gaetan Boisson
2018-02-14 10:36:24 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 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 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 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. 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. (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. 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 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? 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? 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 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> 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. 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? (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 :) (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 ? (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 :) (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 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> Rebased, updated the wording, signed off (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. 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> Works well and I think clarifies things to the end user.. Passes QA scripts, Passing QA Nice work! Pushed to master for 19.11.00 |