"cut in line" not restricted by permissions, open to any staff

[Michael Peters]

Hi all,

Recently, while staff were familiarizing themselves with 2.0.1 via our test environment, a few crafty users discovered the ability to “cut in line” with their own hold requests. Obviously, this set off major alarms here in Indiana. While we would certainly expect staff members to not abuse such a privilege, we feel there should be some discussion about putting some code in place to prevent staff from updating their own holds and placing them at the top of the holds queue.

Additionally, it may be wise to prevent any staff member from updating the hold of another staff member to prevent the “hey, I’ll update your holds if you update mine” scenario that could occur.

Another scenario is that some libraries may want to prevent some users with lesser permissions from being able to place users at the top of the holds queue. For example, here in Indiana we often utilize the limited Circ4 staff profile for people who may volunteer in the library and do simple things like scan books for check-in , etc. Preventing these users from essentially, reordering the holds queue, would be a good idea in my eyes.

With a little pushing from some of the IRC crew, I was able to get a very small portion of this working with my extremely limited knowledge of Perl. Essentially, all this does is prevent a user that does not have the “UPDATE_HOLD_REQUEST_TIME” permission from using the “cut in line” feature. Previously, there were no checks on this so any level of staff could place a hold at the top of the queue. This small patch now allows you to grant/restrict the UPDATE_HOLD_REQUEST_TIME permission as it applies to the “cut in line” feature, but it does open another loophole as anyone with this permission can still update their own hold, to place it at the top of the queue.

I’m putting this out there in hopes that someone with a bit more knowledge of Perl can run with this and assist in improving this great feature, while working to make it a bit more secure.

[Mike Rylander (mrylander)]

Applied as-is to trunk through 2.0. Marking the bug as in progress so we can come back to it, but the attack surface has been reduced. Thanks, Mike!

[Jason Stephenson (jstephenson)]

Setting this to fix released to diminish the number of perceived open bugs.

If someone wants to come back to this, they can open a new bug.