https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16260
Andrew Fuerste-Henry <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #11 from Andrew Fuerste-Henry <[email protected]> --- We've got a general consensus here that there should be a way to have AllowHoldsOnPatronsPossessions enabled for biblios on which the items are distinct (multi-volume works) but disabled for biblios on which the items are identical (multiple copies). So then the question is how to distinguish these two types of biblios from each other. We just discussed this at a meeting of the koha-US development committee and came up with a few options, but none of them feel perfect. Itemtype: We could set this at the itemtype level. This broadly makes sense when imagining something like a PERIODICAL itemtype (enable AllowHoldsOnPatronsPossessions) and a BOOK itemtype (disable AllowHoldsOnPatronsPossessions). But a nonfiction section will often contain a mix of multi-volume titles and multi-copy records all of the same itemtype. Basing this behavior on itemtype would require libraries to create more itemtypes, which means more circulation rules and other setup. Item-level serial/volume info: We could make AllowHoldsOnPatronsPossessions look at the items.enumchron value and only allow holds where the enumchron value of the item to be held does not match the enumchron value of the item already checked out. But not every library sets enumchron values in their item records, so using this option would force a cataloging practice that might not otherwise be used. Item groups: We could make AllowHoldsOnPatronsPossessions look at item groups and only allow a hold on an item that's not in the same item group as the item already checked out. This assumes libraries would be making distinct item groups for each volume on a multi-volume bib. But this would require setting up item groups of one item each on a lot of bibs and not all libraries use item groups anyway. Some other/new value on the bib: We could make this a new value attached to each individual biblio record, stored in the biblio table. That's very flexible, but feels inefficient. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
