circ.holds.usr_not_requestor considered harmful

[Mike Rylander]

Many moons ago, before all living memory, hold rules (in the scripted sense) were chosen based on the group of the user that would eventually get the item. One could customize these scripts so that the group of the requesting user, who might be a staff member, would be used instead.

Then came in-db circ. All else being equal, it starts with the requestor, which is required. The user can be added, optionally, and used instead. And, there is a global flag called circ.holds.usr_not_requestor that will swap the user and requestor groups. It attempts to make "user is more important" easy to set, rather than touching all the rules.

However, in-db circ is too subtle for that flag in all but the most trivial cases. In the end, it just makes understanding the rules harder and more complicated, because it is effectively a hidden variable.

I propose that we remove this flag entirely, and the code that looks at it. For upgrades, we can swap requestor and user groups on rules, which will have the effect of leaving configurations unchanged, but they will act the way they look at that point.

Additionally, we could make requestor group optional on hold matchpoints, which would make the system more flexible.

[Jason Boyer (jboyer)]

I'm all for stripping it out and making requestor_grp nullable (Not much point in requiring it if a lot of installations only ever set it to "Users"). Not all installations afford any special preference to staff-placed holds over user-placed holds. In the past it was a source of confusion for quite some time because staff-placed holds would be able to transit before the item's age protection was up. (I seem to remember some old code specifically ignoring age protection when requestor != usr for script based holds.)

[Lindsay Stratton (lstratton)]

Version 3.10.4

At some point - in 2021 I think? I would have been using 3.6? - I was told to enable this setting in order to correctly test and apply (?) hold policies that used requestor to determine if a hold can be placed or not.

Our use case -

LIB-A only allows staff users to place holds on streaming devices, patrons can't place holds on them.

"Suddenly" - i.e. noticed last week, mid-January 2024 - these 2 year old hold policies were no longer working, and previously valid holds were failing.

I unset this flag and now holds are testing (using action.find_hold_matrix_matchpoint) and being manually placed as expected.

I don't know what has changed since in the last 9-3 years or last few months, but something has. Maybe this will help sombody else.