[Koha-bugs] [Bug 20194] Display items.ccode as well as both biblioitems.itemtype and items.itype in circulation screens

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20194

Katrin Fischer <katrin.fischer at bsz-bw.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Needs Signoff               |In Discussion
                 CC|                            |gmc at esilibrary.com,
                   |                            |jonathan.druart at bugs.koha-c
                   |                            |ommunity.org,
                   |                            |m.de.rooy at rijksmuseum.nl,
                   |                            |nick at bywatersolutions.com,
                   |                            |tomascohen at gmail.com

--- Comment #6 from Katrin Fischer <katrin.fischer at bsz-bw.de> ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.