logic changes in place unfillable holds needed

[Jim Keenan]

Evergreen 2.5.5

Currently, the permission PLACE_UNFILLABLE_HOLD is granted to users and staff so that they can place holds on age protected items.

The unintended side effect is that the Place Hold will appear in the staff client for titles that can NEVER be filled by the place hold process (such as Overdrive titles or other eletronic resource titles).

The solution at the moment is basically telling staff "don't touch that button".

What I think is needed is a distinction in the logic between holds that are currently unfillable (but which will eventually be filled) and holds that will never be fillable no matter what.

[Josh Stompro (u-launchpad-stompro-org)]

I think this may be resolved by this commit [1] from 2012, which allows holds that are only blocked because of ITEM_AGE_PROTECTED to be overridden if you have the ITEM_AGE_PROTECTED.override permission set for those users.

I checked our system and we don't have PLACE_UNFILLABLE_HOLD set for anyone, and the hold button does show up for titles that have only age protected materials, and the override is offered for those that have the permission. Running EG 2.8.4.

1 - http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a663dfed41126ba4607e500ccda85dd9fa113789

I'm not sure what version that fix was released in.

Josh

[Jason Stephenson (jstephenson)]

Josh,

The commit that you cite was released in Evergreen 2.2.0.

git branch -r --contains a663dfed41126ba4607e500ccda85dd9fa113789

Is how I determined that.

Jason

[Jason Stephenson (jstephenson)]

Also, I think the original problem description is different.

I wonder if it occurred because of a "strange" workflow: i.e. adding copies to electronic resource records?

Perhaps, place unfillable hold allows holds to be placed on records with no copies?

Just some additional thoughts.

[Josh Stompro (u-launchpad-stompro-org)]

Thanks for the info Jason, I'll mark this back as New since the change I listed was already applied, and the issue is different from what I was thinking it was.
Josh