[OPEN-ILS-GENERAL] ***SPAM*** ***SPAM*** Re: ***SPAM*** ***SPAM*** Re: ***SPAM*** Re: Holds fulfillment enhancement
Hey Lori, I submitted a patch to the dev list with the 'Holds go Home' code back in early May, should you care to try it out. Bill Ott wrote: Here in Grand Rapids, we wrote something, which we affectionately call Holds go Home. After a designated interval (e.g. 6 weeks), if an item has not been checked in at it's shelving library, it checks back to see if there are any holds waiting at that location. If so, it sends the item home. If not, it happily fills holds in the traditional Evergreen manner. I've also talked about, but not implemented, a wild card pickup location. Here the library gas is saved, but the patron could get the item as fast as possible, if they're willing to pick it up wherever it shows up. This works well if you're as geographically dense as we are, but it's certainly not for everyone. On 6/9/10 5:09 PM, Lori Bowen Ayre wrote: This is cool. Thanks to Thompson-Nicola! I'm wondering if anyone has ever considered a related situation that comes up with holds and that is the ability to promote someone to the top of the queue because of their pick-up location. For example, let's say a patron has been waiting for PopularDVD for 5 weeks and finally the patron has risen to position #10 on the wait list. As soon as a copy is returned to that patron's pick-up location, I would like the system to behave opportunistically and allow that patron (now #10 on the wait list) to get that hold filled. I would like the setting to be flexible, meaning each library could allow for queue jumping to fill opportunistic holds at 5 or 3 or 15, their choice. I think this would address both the need to reduce as much travel for the item as possible while respecting the wait lists. We could even make the top five or ten positions (depending on your setting) be called something special like the Red Zone or something so that everyone knows that at any moment they could get the item. Any interest? Lori Ayre On Wed, Jun 9, 2010 at 1:41 PM, James Fournie jfour...@sitka.bclibraries.ca mailto:jfour...@sitka.bclibraries.ca wrote: Hi everyone, There was some discussion about problems with holds fulfillment at the holds roundtable at EG2010. I am pleased to share this patch with the community which has been thoroughly tested by the folks at Thompson-Nicola Regional District Library. (thanks guys!) Background: Evergreen's default out-of-the-box behaviour for holds fulfillment is a gas-saving method. Holds are fulfilled by proximity. In a multibranch library, holds are fulfilled at the local branch first. Many libraries, particularly single branch libraries may be ok with this, but it may be problematic for other libraries. Imagine a scenario where you have a large central branch and a small rural branch of the same library system. At the large branch, there are many copies of Popular New DVD with lots of holds. There are no copies at the rural branch. Patrons at the small rural branch who want to pick up Popular New DVD at their home branch may never get their hold fulfilled because the copies will stay at the large branch as long as there are holds for pickup there. This patch adds an org unit setting that changes the opportunistic check-in so that items checked in will be assigned to holds by request date first, rather than proximity. This setting can be applied to any level of the org tree, so in some situations you may even want to activate FIFO for large libraries, but leave the original setting for smaller libraries with less traffic who want to keep their copies more local. Also credit to Jeff Godin who thought of the same patch and contributed the setting name holds FIFO for the setting Patch is for rel_1_6_0 ~James Fournie BC SITKA
[OPEN-ILS-GENERAL] SQL Reports Wiki - Monthly Borrowers Added
FYI Just added to the SQL reports wiki: Monthly Borrowers Added by Patron Profile Group and Stat Category Check it: http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-reports:borrower_sta tistical_reports Remember, you can email me your SQL queries and I will add them to the wiki for you. Amy === Amy Terlaga Assistant Director, User Services Bibliomation 32 Crest Road Middlebury, CT 06762 (203)577-4070 x101 http://www.biblio.org Bibliomation's Open Source blog: http://biblio-os.blogspot.com/ Join us on Facebook: http://www.facebook.com/group.php?gid=171935276419
[OPEN-ILS-GENERAL] ***SPAM*** Re: ***SPAM*** Holds fulfillment enhancement
On Wed, Jun 9, 2010 at 4:41 PM, James Fournie jfour...@sitka.bclibraries.ca wrote: Hi everyone, There was some discussion about problems with holds fulfillment at the holds roundtable at EG2010. I am pleased to share this patch with the community which has been thoroughly tested by the folks at Thompson-Nicola Regional District Library. (thanks guys!) Because it's nicely protected behind an OU setting and obviously applicable to several in-use scenarios, I'll commit it as soon as I've crafted a forward-port version for rel_1_6 and trunk. I do have some thoughts and best-practice concerns below, however, that I'd like feedback on. Background: Evergreen's default out-of-the-box behaviour for holds fulfillment is a gas-saving method. Holds are fulfilled by proximity. In a multibranch library, holds are fulfilled at the local branch first. Many libraries, particularly single branch libraries may be ok with this, but it may be problematic for other libraries. Imagine a scenario where you have a large central branch and a small rural branch of the same library system. At the large branch, there are many copies of Popular New DVD with lots of holds. There are no copies at the rural branch. Patrons at the small rural branch who want to pick up Popular New DVD at their home branch may never get their hold fulfilled because the copies will stay at the large branch as long as there are holds for pickup there. This patch adds an org unit setting that changes the opportunistic check-in so that items checked in will be assigned to holds by request date first, rather than proximity. This setting can be applied to any level of the org tree, so in some situations you may even want to activate FIFO for large libraries, but leave the original setting for smaller libraries with less traffic who want to keep their copies more local. I believe, in order to make sure that the behavior is sane and expected, one would need to use hold boundaries (action.hold_request.selection_depth) to try to keep holds as local as possible. AIUI, that is indeed what SITKA is doing -- restricting holds to within geographic areas, or even to systems, because of the extreme geographic distribution (and costs of transiting therebetween) of members by using hard hold boundaries. Imagine Library A and Library B can share items. At A, they have Holds: FIFO set to true, but B does not. They both have long, equal hold lists (that keep growing) for similar sets of items. All else being equal, they have interleaved lists, where every other hold is targeting a copy at the other library. In this scenario, B will capture holds in non-fifo order and fill local holds quickly, but A will send 1/2 of it's captures to B. A will be drained or resources, and B will keep everything it can because both hold lists keep growing. There are three ways out of this configuration-cause imbalance with the code that exists today plus th attached patch, in general order of increasing bluntness of fixing instrument (IMO): 1) Soft hold boundaries at the appropriate here-ness level. Say, system. This would make holds stay local on a hold-by-hold basis if there is an available copy within the system. 2) Everyone uses FIFO 3) Hard boundaries set at the appropriate level -- what SITKA is doing (IIRC) While the most heavy-handed, option 3 is actually ideal for some situations (like SITKA, where transit costs are prohibitive, and MCLS(? ... MLC) where the goal is effectively separate mini-consortia), and actually suggests that an all-or-nothing within an effective resource-sharing OU set is the initial best-practice we should document. Thoughts on that stuff? Thanks, James! -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com
Re: [OPEN-ILS-GENERAL] ***SPAM*** Re: ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** Holds fulfillment enhancement
On 11 June 2010 10:58, Joe Atzberger jatzber...@esilibrary.com wrote: Can we please have a list administrator disable the invasive and counter-productive spam-filter that injects ***SPAM*** into the subject line, at least in cases where ***SPAM*** already appears in the subject line, or preferably in ALL cases. It's not adding anything and it breaks topic threading. The false positive rate on this list is 50%. In the case of this message, on a large browser window on a 1600-pixel wide monitor, I still see only: ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** ... as the subject in gmail. I've asked about this on channel before w/o response, but would appreciate one this time. I second this request please Chris
[OPEN-ILS-GENERAL] ***SPAM*** Re: ***SPAM*** Holds fulfillment enhancement
On Thu, Jun 10, 2010 at 2:32 PM, Mike Rylander mrylan...@gmail.com wrote: On Wed, Jun 9, 2010 at 4:41 PM, James Fournie jfour...@sitka.bclibraries.ca wrote: Hi everyone, There was some discussion about problems with holds fulfillment at the holds roundtable at EG2010. I am pleased to share this patch with the community which has been thoroughly tested by the folks at Thompson-Nicola Regional District Library. (thanks guys!) Because it's nicely protected behind an OU setting and obviously applicable to several in-use scenarios, I'll commit it as soon as I've crafted a forward-port version for rel_1_6 and trunk. Crafting complete, patches applied. Thanks again, James! -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com
[OPEN-ILS-GENERAL] ***SPAM*** Re: ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** Holds fulfillment enhancement
On Thu, Jun 10, 2010 at 5:10 PM, Georgette Rogers grog...@libertylakewa.gov wrote: Are there any issues with holds fullfiments for single branches. None at all. There aren't issues for multiple branches or consortia, either, just differing policy desires. James' patch expands the possibilities for different policies. We are looking at Evergreen and need a lot of information and have several questions that I sent in and haven't been answered, can I put them here on the list serve? If they are technical questions, you may want to copy the open-ils-dev list as well, but for general questions this list is a good place to start. -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com Thank you Georgette Rogers Circulation Supervisor Liberty Lake Municipal Library 23123 E Mission Ave Liberty Lake, WA 99019 509-435-0778 1-866-729-8507 From: open-ils-general-boun...@list.georgialibraries.org [open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Mike Rylander [mrylan...@gmail.com] Sent: Thursday, June 10, 2010 12:17 PM To: Evergreen Discussion Group Subject: [OPEN-ILS-GENERAL] ***SPAM*** Re: ***SPAM*** Holds fulfillment enhancement On Thu, Jun 10, 2010 at 2:32 PM, Mike Rylander mrylan...@gmail.com wrote: On Wed, Jun 9, 2010 at 4:41 PM, James Fournie jfour...@sitka.bclibraries.ca wrote: Hi everyone, There was some discussion about problems with holds fulfillment at the holds roundtable at EG2010. I am pleased to share this patch with the community which has been thoroughly tested by the folks at Thompson-Nicola Regional District Library. (thanks guys!) Because it's nicely protected behind an OU setting and obviously applicable to several in-use scenarios, I'll commit it as soon as I've crafted a forward-port version for rel_1_6 and trunk. Crafting complete, patches applied. Thanks again, James! -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com
[OPEN-ILS-GENERAL] ***SPAM*** Re: ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** Holds fulfillment enhancement
Georgette, yes! But start a new thread please. On Thu, Jun 10, 2010 at 2:10 PM, Georgette Rogers grog...@libertylakewa.gov wrote: Are there any issues with holds fullfiments for single branches. We are looking at Evergreen and need a lot of information and have several questions that I sent in and haven't been answered, can I put them here on the list serve? Thank you Georgette Rogers Circulation Supervisor Liberty Lake Municipal Library 23123 E Mission Ave Liberty Lake, WA 99019 509-435-0778 1-866-729-8507 From: open-ils-general-boun...@list.georgialibraries.org [ open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Mike Rylander [mrylan...@gmail.com] Sent: Thursday, June 10, 2010 12:17 PM To: Evergreen Discussion Group Subject: [OPEN-ILS-GENERAL] ***SPAM*** Re: ***SPAM*** Holds fulfillment enhancement On Thu, Jun 10, 2010 at 2:32 PM, Mike Rylander mrylan...@gmail.com wrote: On Wed, Jun 9, 2010 at 4:41 PM, James Fournie jfour...@sitka.bclibraries.ca wrote: Hi everyone, There was some discussion about problems with holds fulfillment at the holds roundtable at EG2010. I am pleased to share this patch with the community which has been thoroughly tested by the folks at Thompson-Nicola Regional District Library. (thanks guys!) Because it's nicely protected behind an OU setting and obviously applicable to several in-use scenarios, I'll commit it as soon as I've crafted a forward-port version for rel_1_6 and trunk. Crafting complete, patches applied. Thanks again, James! -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com
[OPEN-ILS-GENERAL] ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** Holds fulfillment enhancement
Thank you to all who answered. I will start a new thread. Georgette Georgette Rogers Circulation Supervisor Liberty Lake Municipal Library 23123 E Mission Ave Liberty Lake, WA 99019 509-435-0778 1-866-729-8507 From: open-ils-general-boun...@list.georgialibraries.org [open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Lori Bowen Ayre [lori.a...@galecia.com] Sent: Thursday, June 10, 2010 2:34 PM To: Evergreen Discussion Group Subject: [OPEN-ILS-GENERAL] ***SPAM*** Re: ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** Holds fulfillment enhancement Georgette, yes! But start a new thread please. On Thu, Jun 10, 2010 at 2:10 PM, Georgette Rogers grog...@libertylakewa.govmailto:grog...@libertylakewa.gov wrote: Are there any issues with holds fullfiments for single branches. We are looking at Evergreen and need a lot of information and have several questions that I sent in and haven't been answered, can I put them here on the list serve? Thank you Georgette Rogers Circulation Supervisor Liberty Lake Municipal Library 23123 E Mission Ave Liberty Lake, WA 99019 509-435-0778 1-866-729-8507 From: open-ils-general-boun...@list.georgialibraries.orgmailto:open-ils-general-boun...@list.georgialibraries.org [open-ils-general-boun...@list.georgialibraries.orgmailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Mike Rylander [mrylan...@gmail.commailto:mrylan...@gmail.com] Sent: Thursday, June 10, 2010 12:17 PM To: Evergreen Discussion Group Subject: [OPEN-ILS-GENERAL] ***SPAM*** Re: ***SPAM*** Holds fulfillment enhancement On Thu, Jun 10, 2010 at 2:32 PM, Mike Rylander mrylan...@gmail.commailto:mrylan...@gmail.com wrote: On Wed, Jun 9, 2010 at 4:41 PM, James Fournie jfour...@sitka.bclibraries.camailto:jfour...@sitka.bclibraries.ca wrote: Hi everyone, There was some discussion about problems with holds fulfillment at the holds roundtable at EG2010. I am pleased to share this patch with the community which has been thoroughly tested by the folks at Thompson-Nicola Regional District Library. (thanks guys!) Because it's nicely protected behind an OU setting and obviously applicable to several in-use scenarios, I'll commit it as soon as I've crafted a forward-port version for rel_1_6 and trunk. Crafting complete, patches applied. Thanks again, James! -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.commailto:mi...@esilibrary.com | web: http://www.esilibrary.com
Re: [OPEN-ILS-GENERAL] Holds fulfillment enhancement
Just testing to see what happens when I reply and delete the ***SPAM*** in the subject line. Chris Cormack wrote: On 11 June 2010 10:58, Joe Atzberger jatzber...@esilibrary.com wrote: Can we please have a list administrator disable the invasive and counter-productive spam-filter that injects ***SPAM*** into the subject line, at least in cases where ***SPAM*** already appears in the subject line, or preferably in ALL cases. It's not adding anything and it breaks topic threading. The false positive rate on this list is 50%. In the case of this message, on a large browser window on a 1600-pixel wide monitor, I still see only: ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** ... as the subject in gmail. I've asked about this on channel before w/o response, but would appreciate one this time. I second this request please Chris
Re: [OPEN-ILS-GENERAL] Holds fulfillment enhancement
On 11 June 2010 11:55, Debbie Hensler hens...@hslc.org wrote: Just testing to see what happens when I reply and delete the ***SPAM*** in the subject line. Breaks the threading again ... but at least the SPAM bit is gone. :) Chris
[OPEN-ILS-GENERAL] ***SPAM*** Re: Holds fulfillment enhancement
ah On Thu, Jun 10, 2010 at 4:55 PM, Debbie Hensler hens...@hslc.org wrote: Just testing to see what happens when I reply and delete the ***SPAM*** in the subject line. Chris Cormack wrote: On 11 June 2010 10:58, Joe Atzberger jatzber...@esilibrary.com wrote: Can we please have a list administrator disable the invasive and counter-productive spam-filter that injects ***SPAM*** into the subject line, at least in cases where ***SPAM*** already appears in the subject line, or preferably in ALL cases. It's not adding anything and it breaks topic threading. The false positive rate on this list is 50%. In the case of this message, on a large browser window on a 1600-pixel wide monitor, I still see only: ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** ... as the subject in gmail. I've asked about this on channel before w/o response, but would appreciate one this time. I second this request please Chris
