Rush Item update?

Is there any way we can have the 'Rush Item' function be updated to add the item to the top of the patron's service queue? Has anybody found a way around that?

We've had some caregivers and patrons that are frustrated that the 'Rush' doesn't actually rush the item at all with DOD.  Thanks!

Yes, you can have webOPAC "Rush" requests pushed to the top of patrons' Service Queues!

In the "CartDupOptions" cross reference, add web to the RushRsvSelectType list. Let us know if you need help setting this, or if it is already in place but web Rush requests are not being pushed to the top of the queue. 

Good morning! under our settings for DB we have the following "AddIssue,SerialReserve,Web,BookClub-*" Does the Web need to be all lowercase?

That sounds like it's setup correctly. I just tested it out with exactly that setup and it looks to be working.

Weird! For us it still just adds it as a reserve for the patron.

How strange! I double-checked your xRef and it sure looks correct to me... I'll report this to Customer Support and see if we can track down what's different in your system. To get the issue into our tracking system, would you please send us a brief email at ?

Craig, thank you for confirming that it works as intended in your system--that will give us a good point of comparison!

Please disregard, my information was out of date.

If the rush is just added as a reserve but not added to the queue at all, that's probably because it's the Nightly function that actually adds the book to the queue. If you manually run your nightly queue refill function from the batch manager, you should see the title appear right at the top of the queue.

The Rush will rush, but there will still be a one-day lag between when it's requested online and when it can be added to an order.

Actually, my understanding is that there should no longer be a lag--it should happen right away, instead of waiting for Nightly as it did when the option was first implemented.

In this case, we tracked the problem to a typo in the Cross Reference. It was just one of those particularly sneaky typos that takes three people to spot

It still isn't working for us.
In the cross-reference maintenance menu >CartDupOptions> KS1A/ DB> RushRsvSelectTypes> we have AddIssue,SerialReserve,Web,BookClub,* as the “Field Value”,

We were also told that the strictly Obey max is not turned on for DB's in our system.

I mainly just want to nail down what's happening so we can give patron's the right instructions and expectations with how the webopac works for them.

Strictly Obey Max shouldn't impact this; they're separate processes.

I'll dive back in and see what else I can find. Either there's a problem in your set-up somewhere, or a bug that only impacts some systems. Either way, we'll get it sorted out so you and your patrons will know that Rushes are being pushed to the service queue.

Would you please reply to the email ticket with a staff account in Live and the WebOPAC login for that account that we can use to test?

So this has been annoying me, because I thought I tested it before my previous post. I'm actually seeing different behavior for different books when I try to Rush them from the web.
Two more recent books (101429, 102760) are only on my request list after I add them as a web rush. Two older books (50549, 80283) go directly into my service queue when I add them as a web rush. I even tried this with two books from the Alex Cross series: 73951 went to the service queue, 101338 did not. (This is my patron record, LUNDBS01, if anyone at Keystone wants to look)

Interesting wrinkle! I'll take a look, thanks Sam!

Just to post a quick update on this: we've found the data inconsistency that is resulting in some Rushed titles not going onto the Service Queue as expected. Thank you all for the info to bring it to our attention and help us track it down!

We can provide a data fix that will address the problem immediately (although future eDocs may be created with the same inconsistency that blocks this function) and will implement a full correction to the underlying problem in a future version of KLAS.