http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14370 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- This would be a change of behaviour - could we please make it optional? Maybe we can specify the values in a pref that should also block circulation. I know a library using this to indicate on-site checkouts - restricted being the reading room with a value != 0. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14370 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |kyle@bywatersolutions.com |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14370 --- Comment #4 from Joy Nelson <joy@bywatersolutions.com> --- Not for loan items can be overridden at the time of checkout, if needed. Restricted items cannot be checked out ever (if value=1). So the intention seems clear from the code that if you are restricting an item, you are setting it to be 'circulation impossible'. I like the option of allowing for negative numbers that could be circulated, but positive numbers that actually do restrict. If you look at withdrawn, you can have multiple withdrawn values and ALL of them will prohibit circulation. Why allow an authorised value list to be used for restricted if you do not allow for additional values to work? . joy (In reply to Katrin Fischer from comment #3)

I'd not call it a bug if we never implemented it differently :)

For me restricted doesn't imply 'no checkout' - then it would be the same as 'not for loan'. I think there should be a clear difference between the two fields, so we actually win something here.

Be able to place on hold, but only checkout on-site maybe? With the difference between negative and positive values maybe?

There is also another bug about this: bug 10591

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

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14370 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|3.18 |master -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14370 --- Comment #6 from Joy Nelson <joy@bywatersolutions.com> --- Marcel- You are right. The difference between notforloan and restricted is vague. I am all for using negative numbers in restricted as is in not for loan. background: The situation I ran into was for a consortium of academic libraries where each library had a 'different reason' for something to be restricted. They came from another system and we struggled to find places to put all the item data they required to be associated with an item. They opted to simply create a few additional 'restricted' values to contain the 'why' of restriction. Finding that the additional 'authorised_values' in the RESTRICTED list did not actually restrict was an unpleasant surprise. If additional values are not allowed (i.e. not functional as '1') for RESTRICTED, then it probably should not be a field that runs off an 'authorised_value' list. Either hard code it like the 942$n suppress value or allow additional values. joy (In reply to Marcel de Rooy from comment #5)

The difference between notforloan and restricted is not very clear. Notforloan for instance could be/have been a subvalue of restricted; changing this now is not very obvious.

If we add values to the RESTRICTED list, I would opt for better descriptions. That restricted access now means no checkout is not very clear.

Making a difference between positive and negative values could be a compromise similar to notforloan<0 in current code.

I am only wondering now what the difference between various positive restricted values would be? "The code needs to be updated to allow.." But why exactly? If they would do exactly the same, why are you using multiple values? Could this be a property that actually belongs somewhere else?

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

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14370 Nicole C. Engard <nengard@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nengard@gmail.com --- Comment #8 from Nicole C. Engard <nengard@gmail.com> --- (In reply to Katrin Fischer from comment #7)

Hi Joy and Marcel,

still pondering this too - I think for me "Restricted" means that there are 'limits' to its use - like only allowing it to be used on-site. While I would use a 'notforloan' if I didn't want a checkout. I am still wondering what would make the most sense here.

Suggestion: - Block positive values from 'normal' checkout (can add exception for on-site later) - Don't block negative values from checkout - Always allow holds? (in difference from notforloan?)

I'm in agreement with a lot of you here. I always taught libraries not to use the restricted access values because it was so very very unclear what it did. That said, having it only block access with 1 value seems contrary to other authorized values. I like Katrin's suggestions: - Block positive values from checkout - Don't block negative values from checkout As for holds though - I'm really not sure. Basically it sounds to like restricted is no different from not for loan in this scenario. Before this I thought restricted just put a label on items that were restricted and did nothing - while that too seems strange, it at least was different from not for loan. I don't now if I helped at all here ... -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14370 --- Comment #10 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #7)

- Always allow holds? (in difference from notforloan?)

If we would not allow holds, what would still be the difference? On the other hand, it feels like offering a feature without associated code.. -- You are receiving this mail because: You are watching all bug changes.