Bug 14370 - Use Restrictions in Circulation
Summary: Use Restrictions in Circulation
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Kyle M Hall
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-09 20:44 UTC by Joy Nelson
Modified: 2020-08-31 09:14 UTC (History)
6 users (show)

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


Attachments
Notforloan detail.pl (96.08 KB, image/png)
2020-08-31 09:13 UTC, delaye
Details
Notforalon detail.pl after (102.61 KB, image/png)
2020-08-31 09:14 UTC, delaye
Details
notforloan detail.pl - js (4.06 KB, application/x-javascript)
2020-08-31 09:14 UTC, delaye
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joy Nelson 2015-06-09 20:44:21 UTC
The use restrictions field runs off the 'restricted' authorised value list.  However, Koha does not restrict circulation unless the items.restricted =1.  

The code needs to be updated to allow any RESTRICTED authorised value to be used to restrict circulation.  Make this line: $item->{'restricted'} > 0 ??


Circulation.pm

    if ( $item->{'restricted'} && $item->{'restricted'} == 1 )
    {
        $issuingimpossible{RESTRICTED} = 1;
    }
Comment 1 Katrin Fischer 2015-06-09 21:02:37 UTC
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.
Comment 2 Kyle M Hall 2015-06-15 18:45:53 UTC
(In reply to Katrin Fischer from comment #1)
> 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.

I think it would be much more reasonable to say that any value less than 0 retains the current behavior. That would bring it in line with the behavior of other authorised values for items. To me that would be a much better solution than yet another system preference.

It seems to me that they are taking advantage of a bug rather than a feature. Information like that should really belong in another field, but allowing circ of negative values seems like a good compromise to me.
Comment 3 Katrin Fischer 2015-06-15 18:52:07 UTC
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
Comment 4 Joy Nelson 2015-06-15 19:46:18 UTC
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
Comment 5 Marcel de Rooy 2015-06-22 10:03:34 UTC
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?
Comment 6 Joy Nelson 2015-06-22 13:18:07 UTC
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?
Comment 7 Katrin Fischer 2015-06-22 13:21:37 UTC
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?)
Comment 8 Nicole C. Engard 2015-06-22 13:28:20 UTC
(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 ...
Comment 9 Marcel de Rooy 2015-06-25 07:20:32 UTC
(In reply to Joy Nelson from comment #6)
> 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.  

Agreed. I think we are close to reaching consensus about the restricted>0 approach.
But we need to warn libraries that added restricted values for some reason and still expect checkouts. I would not like to add a syspref on top of that.
Comment 10 Marcel de Rooy 2015-06-25 07:23:36 UTC
(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..
Comment 11 Katrin Fischer 2015-06-25 07:39:30 UTC
It does allow holds right now afaikt - so I'd like not to change that.
Comment 12 delaye 2020-08-31 09:13:14 UTC
French academic libraries have the same problems as those indicated by Marcel and Joy.

Also in search results  opac : it is indicated that the item is 'On loan' with the flag at '1' in items.restricted. (see /home/koha/src/C4/XSLT.pm).
It's not consistent.

The confusion between notforloan and restricted is also seen in the table of items (screen detail.pl) because Koha displays two contradictory information
(Notforloan => On loan and Restricticed => not communicable).
The notforloan column in this items table  display errors which requires us to do some jquery customization to harmonize the information and hide the inconsistencies.(cf attachments)


The differences between notforlan and a 'item trap' (withdrawn, lost, restricted, damaged):
-a "item trap" is stronger than notforloan in terms of display.Koha displays the trap and not notforloan

-on the return of a item, the trap is displayed , not notforloan

-notforloan is sustainable information not necessarily the value of the trap
Comment 13 delaye 2020-08-31 09:13:55 UTC
Created attachment 109346 [details]
Notforloan detail.pl
Comment 14 delaye 2020-08-31 09:14:31 UTC
Created attachment 109347 [details]
Notforalon detail.pl after
Comment 15 delaye 2020-08-31 09:14:57 UTC
Created attachment 109348 [details]
notforloan detail.pl - js