Re: [OPEN-ILS-GENERAL] Duration Rules/Circulation Policies
Forsyth treats ILLs exactly the same way that Holly describes. We put our own barcode on a wrapper around the front cover of the book with the due date written in, check the thing out to our patron as a pre-cat, then call and let the patron know it's here. When they come to pick up, they sign a receipt for it so that we know when it actually left our hands, but the checkout date remains the day that the item arrived from the lending library and the due date is based on that. Lise Keppler On Wed, Jul 30, 2014 at 9:27 PM, Kathy Lussier kluss...@masslnc.org wrote: Hi George, As far as I know, Evergreen currently does not have the feature you describe. Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 7/30/2014 8:04 PM, George Rodgers-Clark wrote: Hello All-- I am wondering if there is a way to trigger Evergreen 2.4.4 to prompt staff to enter the due date for a specific item type. The situation is with InterLibrary Loan items (we already have a circ type for them), when the due date is set by the library we are borrowing from (usually not the same as ours, and rarely the same from case to case). We are currently relying on our staff to use the Specific Due Date check box before scanning the item for check out, and it works most of the time. I would really like it if when the item is scanned for check out, Evergreen would prompt us for the due date (which we determine while processing the item). Is this possible? If so, how? (I'm assuming it has something to do with circulation policy [we have a 30-day-0-renewal policy set], but I'm not finding any documentation on it.) Thanks in advance! George George Rodgers-Clark Library Technician La Conner Regional Library La Conner, WA grodgers-cl...@lclib.lib.wa.us -- Lise Keppler Forsyth County Public Library 660 W 5th St Winston Salem NC 27101 336-703-3070
Re: [OPEN-ILS-GENERAL] Duration Rules/Circulation Policies
We do almost the opposite. We have circ mods tied to durations such as 7DAY 14DAY 21DAY and when the item comes in we do a quick calculation of how long we're allowed to have it and subtract a week. We age out holds after a week. So, we put the hold on the item, fill it and it goes on the shelf for pickup. If they pick it up after a week, and it checks out, then it's out for the appropriate amount of time for us to return it. On Wed, Jul 30, 2014 at 8:35 PM, Holly Brennan haderh...@ci.homer.ak.us wrote: This isn't an answer related to Evergreen, but our ILL staff check the item out to the requesting patron (and set the due date) when the items arrives. Then the patron is notified. The clock starts ticking when we receive the item, not when the patron decides to pick it up. This is because the due date is really for our library to return to the lending library. If the patron picks the item up right away, great. If they don't, they get less time with the item. If they never pick it up, the item is checked in and returned. This works out well for us because only a few staff need to keep track of due dates, and front end staff simply need to grab the item and hand it over to the patron. Again, not Evergreen specific, but a simple alternative. -Holly -Original Message- From: open-ils-general-boun...@list.georgialibraries.org [mailto: open-ils-general-boun...@list.georgialibraries.org] On Behalf Of George Rodgers-Clark Sent: Wednesday, July 30, 2014 4:04 PM To: open-ils-general@list.georgialibraries.org Subject: [OPEN-ILS-GENERAL] Duration Rules/Circulation Policies Hello All-- I am wondering if there is a way to trigger Evergreen 2.4.4 to prompt staff to enter the due date for a specific item type. The situation is with InterLibrary Loan items (we already have a circ type for them), when the due date is set by the library we are borrowing from (usually not the same as ours, and rarely the same from case to case). We are currently relying on our staff to use the Specific Due Date check box before scanning the item for check out, and it works most of the time. I would really like it if when the item is scanned for check out, Evergreen would prompt us for the due date (which we determine while processing the item). Is this possible? If so, how? (I'm assuming it has something to do with circulation policy [we have a 30-day-0-renewal policy set], but I'm not finding any documentation on it.) Thanks in advance! George George Rodgers-Clark Library Technician La Conner Regional Library La Conner, WA grodgers-cl...@lclib.lib.wa.us -- Rogan Hamby, MLS, CCNP, MIA Managers Headquarters Library and Reference Services, York County Library System “You can never get a cup of tea large enough or a book long enough to suit me.” ― C.S. Lewis http://www.goodreads.com/author/show/1069006.C_S_Lewis
[OPEN-ILS-GENERAL] Auto-extending grace periods
I want to make sure I'm understanding the Library settings regarding auto-extending grace periods. Here are the settings from the Library Settings Editor: - Auto-Extend Grace Periods - When enabled, grace periods will auto-extend. By default this will be only when they are a full day or more and end on a closed date, though other options can alter this. - Auto-Extending Grace Periods extend for all closed dates - If enabled and Grace Periods auto-extending is turned on, grace periods will extend past all closed dates they intersect, within hard-coded limits. - Auto-Extending Grace Periods include trailing closed dates - If enabled and Grace Periods auto-extending is turned on, grace periods will include closed dates that directly follow the last day of the grace period. Here's the use case: An item is due on Saturday. The library is closed on Sunday. The item is checked in on Monday. The library has a 1-day grace period. My understanding is that by default, the grace period would be eaten up by the closed day on Sunday, and when the fine generator runs early Monday morning, the patron would be assessed a fine for one day overdue. So when the item is checked in, the patron would owe for 1 day. Setting only the Auto-Extend Grace Periods setting to TRUE should extend the grace period into Monday so that no fine should be charged when the fine generator runs early Monday morning. So when the item is checked in the patron would not owe any fine. Am I understanding this correctly? On our 2.5 system. I am not seeing the grace period being extended at all, even after setting the other two options, and want to make sure I'm understanding how the options are supposed to work before I open a Launchpad bug. Thanks for any feedback, Michele -- Michele Morgan, Technical Assistant North of Boston Library Exchange, Danvers Massachusetts mmor...@noblenet.org
[OPEN-ILS-GENERAL] Is 264 field indexed and visible in 2.5 version?
Are folks still utilizing the 260 for publication/distributor information or can we now use 264? Thanks Trisha -- Trisha Cantwell Keene Associate Director Thorndike Library College of the Atlantic 109 Eden St. Bar Harbor, ME 04609 (207) 801-5661 (207) 288-2328 Fax tcantw...@coa.edu Google can bring you back a hundred thousand answers. A librarian can bring you back the right one. The Guardian (London)
[OPEN-ILS-GENERAL] Questions About LC Call Numbers and Printing
All, Acquisitions has pretty much been on vacation during our migration, but it's about time to crank up the ordering machine again. This means we will soon be inundated with books that need spine labels printed. First a question about default call numbers. A bib record potentially could contain all 3 call number fields for an LC library. 099 Local Free-Text Call Number 090 Local LC-type Call Number 050 LC Assigned Call Number It would be extremely rare for a bib record to have all three numbers, but if they were present, the 099 tag should be the one chosen by the system to print. When an 090 and an 050 are present the system should choose the 090 to print. When only the 050 is present it should print. Is this protocol being followed in Evergreen? Second question. The format of spine labels in our collection for LC call numbers is, letters on line 1, numbers on line 2, cutter number on line 3, second cutter on line 4, etc. Example 050 \4 $aBX8495.2.M68$bW5 2012 displays as: BX 8495.2 .M68 W5 2012 There doesn't seem to be a way to achieve this configuration. It currently displays as BX8495.2 .M68 W5 2012 Is there a setting we have missed or is this a bug or an enhancement request? Question three. We use a roll feed Thermal Transfer Printer (CUB CB624M) to print barcodes and spine labels. The perforated label stock has a spine label on the left and a pocket label on the right. The spine/pocket label is stuck in each book while it awaits processing. Should the label fall out of the book, the pocket label has enough information on it so it can be matched up with the appropriate volume. Pocket labels are also attached to acid-free slips that are placed in books in our Archives, and they are also used for microfilm containers. So we use the pocket label a lot. In the Library Settings Editor Cataloging there are settings for Spine Label left margin, Spine label line width, and Spine label maximum lines, but there is no corollary for Pocket labels, so we cannot make those settings sticky. Is there someplace else where that formatting can be done, or do we need to make an enhancement request? Finally, would anybody else like to see a Print Label button on the Holdings Maintenance screen? (Maybe lower left next to the current Print button) One click printing instead of 4 clicks? Thanks again for your insights and your patience, Don -- Don Butterworth Faculty Associate / Librarian III B.L. Fisher Library Asbury Theological Seminary don.butterwo...@asburyseminary.edu (859) 858-2227
Re: [OPEN-ILS-GENERAL] Is 264 field indexed and visible in 2.5 version?
Trisha, As far as I know, and I could be wrong, no version of EG supports the displaying the (RDA) 264 tag. Jason Stephenson, from MVLC, wrote some code that takes care of displaying the 264 data on the OPAC for the full bib display. That code change has not been officially approved to be added to EG yet. His code inspired a nice debate on how to move forward with some related RDA and 264 issues, and I guess momentum was lost. For example, at the time he made his changes public there was a debate of how to tweak his changes or repurpose his code logic to allow non-publisher data to show up in the search results. Though Jason's code seem to perfectly handle the 264 data in the full bib view, and I have since added his code to my EG 2.5 system. Add 264 tag values to Record Summary https://bugs.launchpad.net/evergreen/+bug/1304462 Here is a link to the changes he made to make the 264 data show up in the full bib view... http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=9cf41dc26c536000dcd1cfe52fdf430accb63093 At this point I am not sure what the status is of searching (indexing) on the 264 tag. Coincidentally I was just reviewing Jason's code this week, so I can I try to help revive his code and help propose additional RDA related code changes. I hope this helps, Yamil On Thu, Jul 31, 2014 at 3:49 PM, Trisha Cantwell Keene tcantw...@coa.edu wrote: Are folks still utilizing the 260 for publication/distributor information or can we now use 264? Thanks Trisha -- Trisha Cantwell Keene Associate Director Thorndike Library College of the Atlantic 109 Eden St. Bar Harbor, ME 04609 (207) 801-5661 (207) 288-2328 Fax tcantw...@coa.edu Google can bring you back a hundred thousand answers. A librarian can bring you back the right one. The Guardian (London) -- Yamil Suarez, MCS Library System Administrator/Developer Stan Getz Library Berklee College of Music 1140 Boylston St Boston, MA 02215 ysua...@berklee.edu 617-747-2617
Re: [OPEN-ILS-GENERAL] Is 264 field indexed and visible in 2.5 version?
Hi Trisha and Yamil, For clarification, tag 264 for *publisher* data was developed and part of Evergreen 2.4 and was subsequently backported to 2.2.9 and 2.3.7 as well (see https://bugs.launchpad.net/evergreen/+bug/1071505). Indexing publisher information has not been done to my knowledge by default. We did update the reporter view to include tag 264 for pubdate (publisher date) so any reports that draw from publication info reflects either 260 or 264 for publisher data. The bug that Yamil references deals with other forms of tag 264 for Producer, Distributor, Manufacturer, and Copyright which is noted in the bug's description. Differentiating between the types of tag 264 is done through the indicator fields. The other issue Yamil mentions with https://bugs.launchpad.net/evergreen/+bug/1304462 and the search results is actually a bug that needs to be addressed as well. Right now, it's grabbing and displaying any 264 found and potentially mislabeling it as publisher in search results when in fact it could be other things. Resolving this bug and completing the work for RDA 264 is on my personal short list of code to finish for Evergreen 2.7.0-beta1 next Thursday. Good to get a nudge, thanks Yamil. ;) -- Ben On Thu, Jul 31, 2014 at 4:13 PM, Yamil Suarez ysua...@berklee.edu wrote: Trisha, As far as I know, and I could be wrong, no version of EG supports the displaying the (RDA) 264 tag. Jason Stephenson, from MVLC, wrote some code that takes care of displaying the 264 data on the OPAC for the full bib display. That code change has not been officially approved to be added to EG yet. His code inspired a nice debate on how to move forward with some related RDA and 264 issues, and I guess momentum was lost. For example, at the time he made his changes public there was a debate of how to tweak his changes or repurpose his code logic to allow non-publisher data to show up in the search results. Though Jason's code seem to perfectly handle the 264 data in the full bib view, and I have since added his code to my EG 2.5 system. Add 264 tag values to Record Summary https://bugs.launchpad.net/evergreen/+bug/1304462 Here is a link to the changes he made to make the 264 data show up in the full bib view... http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=9cf41dc26c536000dcd1cfe52fdf430accb63093 At this point I am not sure what the status is of searching (indexing) on the 264 tag. Coincidentally I was just reviewing Jason's code this week, so I can I try to help revive his code and help propose additional RDA related code changes. I hope this helps, Yamil On Thu, Jul 31, 2014 at 3:49 PM, Trisha Cantwell Keene tcantw...@coa.edu wrote: Are folks still utilizing the 260 for publication/distributor information or can we now use 264? Thanks Trisha -- Trisha Cantwell Keene Associate Director Thorndike Library College of the Atlantic 109 Eden St. Bar Harbor, ME 04609 (207) 801-5661 (207) 288-2328 Fax tcantw...@coa.edu Google can bring you back a hundred thousand answers. A librarian can bring you back the right one. The Guardian (London) -- Yamil Suarez, MCS Library System Administrator/Developer Stan Getz Library Berklee College of Music 1140 Boylston St Boston, MA 02215 ysua...@berklee.edu 617-747-2617 -- Benjamin Shum Evergreen Systems Manager Bibliomation, Inc. 24 Wooster Ave. Waterbury, CT 06708 203-577-4070, ext. 113
Re: [OPEN-ILS-GENERAL] Is 264 field indexed and visible in 2.5 version?
Hi Trisha, In terms of indexing, Evergreen by default does not index publication information, even when this information is stored the 260 tag. I think this decision was probably made so that a search for little brown bear didn't retrieve a bunch of records published by Little Brown. We have two consortia in Massachusetts that have decided to make a local configuration to index the 260 and maybe the 264 (not sure on that one). The magic spells page provides some guidance on how specific MARC tags can be indexed - http://wiki.evergreen-ils.org/doku.php?id=scratchpad:random_magic_spells#how_to_include_a_specific_marc_field_with_a_specific_search_class. Kathy Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier On 7/31/2014 4:41 PM, Ben Shum wrote: Hi Trisha and Yamil, For clarification, tag 264 for *publisher* data was developed and part of Evergreen 2.4 and was subsequently backported to 2.2.9 and 2.3.7 as well (see https://bugs.launchpad.net/evergreen/+bug/1071505). Indexing publisher information has not been done to my knowledge by default. We did update the reporter view to include tag 264 for pubdate (publisher date) so any reports that draw from publication info reflects either 260 or 264 for publisher data. The bug that Yamil references deals with other forms of tag 264 for Producer, Distributor, Manufacturer, and Copyright which is noted in the bug's description. Differentiating between the types of tag 264 is done through the indicator fields. The other issue Yamil mentions with https://bugs.launchpad.net/evergreen/+bug/1304462 and the search results is actually a bug that needs to be addressed as well. Right now, it's grabbing and displaying any 264 found and potentially mislabeling it as publisher in search results when in fact it could be other things. Resolving this bug and completing the work for RDA 264 is on my personal short list of code to finish for Evergreen 2.7.0-beta1 next Thursday. Good to get a nudge, thanks Yamil. ;) -- Ben On Thu, Jul 31, 2014 at 4:13 PM, Yamil Suarez ysua...@berklee.edu mailto:ysua...@berklee.edu wrote: Trisha, As far as I know, and I could be wrong, no version of EG supports the displaying the (RDA) 264 tag. Jason Stephenson, from MVLC, wrote some code that takes care of displaying the 264 data on the OPAC for the full bib display. That code change has not been officially approved to be added to EG yet. His code inspired a nice debate on how to move forward with some related RDA and 264 issues, and I guess momentum was lost. For example, at the time he made his changes public there was a debate of how to tweak his changes or repurpose his code logic to allow non-publisher data to show up in the search results. Though Jason's code seem to perfectly handle the 264 data in the full bib view, and I have since added his code to my EG 2.5 system. Add 264 tag values to Record Summary https://bugs.launchpad.net/evergreen/+bug/1304462 Here is a link to the changes he made to make the 264 data show up in the full bib view... http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=9cf41dc26c536000dcd1cfe52fdf430accb63093 At this point I am not sure what the status is of searching (indexing) on the 264 tag. Coincidentally I was just reviewing Jason's code this week, so I can I try to help revive his code and help propose additional RDA related code changes. I hope this helps, Yamil On Thu, Jul 31, 2014 at 3:49 PM, Trisha Cantwell Keene tcantw...@coa.edu mailto:tcantw...@coa.edu wrote: Are folks still utilizing the 260 for publication/distributor information or can we now use 264? Thanks Trisha -- Trisha Cantwell Keene Associate Director Thorndike Library College of the Atlantic 109 Eden St. Bar Harbor, ME 04609 (207) 801-5661 tel:%28207%29%20801-5661 (207) 288-2328 tel:%28207%29%20288-2328 Fax tcantw...@coa.edu mailto:tcantw...@coa.edu Google can bring you back a hundred thousand answers. A librarian can bring you back the right one. The Guardian (London) -- Yamil Suarez, MCS Library System Administrator/Developer Stan Getz Library Berklee College of Music 1140 Boylston St Boston, MA 02215 ysua...@berklee.edu mailto:ysua...@berklee.edu 617-747-2617 tel:617-747-2617 -- Benjamin Shum Evergreen Systems Manager Bibliomation, Inc. 24 Wooster Ave. Waterbury, CT 06708 203-577-4070, ext. 113
