Re: [OPEN-ILS-GENERAL] Z39.50 client query encoding issues
Hi, I have also tried the SRU search (using yaz-client) and tried some CQL queries. It seems to work fine (even for letters with diacritics) for dc.title, dc.contributor and dc.publisher. However, when trying dc.creator, no results are returned both for queries with and without diacritics. When dc.author is replaced by eg.author, it works fine. Also when searching without specifying anything (say find "matousek" or "find matoušek") it works okay: *find:* $ yaz-client http://mojzis.jabok.cuni.cz/opac/extras/sru Connecting...OK. Z> sru GET 1.1 Z> find matousek Received SRW SearchRetrieve Response Number of hits: 34 SRU server returns extra records. Skipping 10 records. Elapsed: 0.708890 Z> find matoušek Connecting...OK. Received SRW SearchRetrieve Response Number of hits: 34 SRU server returns extra records. Skipping 10 records. Elapsed: 0.675457 *find dc.creator:* Z> find dc.creator=matousek Connecting...OK. Received SRW SearchRetrieve Response Number of hits: 0 Elapsed: 0.192852 Z> find dc.creator=matoušek Connecting...OK. Received SRW SearchRetrieve Response Number of hits: 0 Elapsed: 0.238054 *find eg.author:* Z> find eg.author=matousek Connecting...OK. Received SRW SearchRetrieve Response Number of hits: 34 SRU server returns extra records. Skipping 10 records. Elapsed: 0.663780 Z> find eg.author=matoušek Connecting...OK. Received SRW SearchRetrieve Response Number of hits: 34 SRU server returns extra records. Skipping 10 records. Elapsed: 0.861588 *find dc.title:* Z> find dc.title=buh Connecting...OK. Received SRW SearchRetrieve Response Number of hits: 69 SRU server returns extra records. Skipping 10 records. Elapsed: 0.953206 Z> find dc.title=bůh Connecting...OK. Received SRW SearchRetrieve Response Number of hits: 69 SRU server returns extra records. Skipping 10 records. Elapsed: 0.509182 ** *find dc.subject:* Z> find dc.subject=buh Connecting...OK. Received SRW SearchRetrieve Response Number of hits: 243 SRU server returns extra records. Skipping 10 records. Elapsed: 2.415498 Z> find dc.subject=bůh Connecting...OK. Received SRW SearchRetrieve Response Number of hits: 243 SRU server returns extra records. Skipping 10 records. Elapsed: 1.595494 * **find dc.contributor:* Z> find dc.contributor=dvorak Connecting...OK. Received SRW SearchRetrieve Response Number of hits: 44 SRU server returns extra records. Skipping 10 records. Elapsed: 0.621795 Z> find dc.contributor=dvořák Connecting...OK. Received SRW SearchRetrieve Response Number of hits: 44 SRU server returns extra records. Skipping 10 records. Elapsed: 0.843226 *find dc.publisher:* Z> find dc.publisher=portal Connecting...OK. Received SRW SearchRetrieve Response Number of hits: 40 SRU server returns extra records. Skipping 10 records. Elapsed: 1.012238 Z> find dc.publisher=portál Connecting...OK. Received SRW SearchRetrieve Response Number of hits: 40 SRU server returns extra records. Skipping 10 records. I have also found out there is a charset command which gives the following results: yaz-client http://mojzis.jabok.cuni.cz/opac/extras/sru Connecting...OK. Z> sru GET 1.1 Z> charset Negotiation character set `none' Display character set is `UTF-8' MARC character set is `none' Query character set is `none' Do you think this could be related to our Z39.50 client query encoding issues? Should the charset be - somewhere - specifically set to utf-8? I have also found a bug reported by Jason Stephenson about a year ago (https://bugs.launchpad.net/evergreen/+bug/1346518) which seems to describe the same problem but it has probably not been looked into since then. Thank you in advance for any clues! Linda On 08/25/2015 02:51 PM, Linda Jansova wrote: Hi again, We have installed a 2.8.3 and tested the Z39.50 server output, yet the problem with diacritics remains the same. Again, when submitting a generic query with diacritics (using yaz-client), we get the expected results, but when searching specifically for author, it results in no hits. I have had a look at https://coffeecode.net/archives/217-More-granular-identifier-indexes-for-your-Evergreen-SRU-Z39.50-servers.html again and it seems to me that maybe the problem is caused by the fact that with the exception of keyword, each of the other indexes mentioned at Dan's blog (author, title, series, subject) is actually composed of more granular indexes. Maybe I am on the wrong track but it seems to me that it would be rather a strange coincidence that keyword index (which I suppose the Z39.50 client would use when no fields are specified) works fine unlike those other "composed" indexes... Do you think that this could be the reason why we are experiencing the encoding problems? And if so, do you have any idea where to look for the appropriate encoding settings and change them to utf-8? Thank you in advance for any clues to the puzzle! Linda On 08/19/2015 03:40 PM, Linda Jansova wrote: Oh, I see! In that case we shall try the upgrade and see what
Re: [OPEN-ILS-GENERAL] Another LARL member introduction
Welcome to the group, Sharon. It will be very useful to have another cataloger involved in the discussions. The cataloging sprint of the web client is nearly ready to be tested, so that would be a great way for you to participate! Terran McCanna PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, GA 30345 404-235-7138 tmcca...@georgialibraries.org - Original Message - From: "Sharon Douglas" To: open-ils-general@list.georgialibraries.org Sent: Friday, August 21, 2015 3:16:22 PM Subject: [OPEN-ILS-GENERAL] Another LARL member introduction Greetings Evergreen Community, I think I'm the last Lake Agassiz Regional Library group member to introduce herself. Have been busy answering migration questions and filling out mapping spreadsheets. What an exciting time. I'm Sharon Douglas, manage most of the settings, data cleanup, and reporting for the automation system. Have a cataloging background, which seriously helps when working out why a title isn't showing up in the web catalog. When not working, I can't help but try making basic food ingredients from scratch. Just finished trying out the idea of dehydrating sour cream, turning it into a powder, and storing it. What did I learn? While this taste great rehydrated, you really do need to get it into a fine powder form. Grainy sour cream, not so great. Sharon Douglas - Automation Coordinator - Lake Agassiz Regional Library 118 5th St S - Moorhead MN 56561 - 218-233-3757 ext 138 - www.larl.org The mission of LARL is to enrich lives and strengthen communities LARL values intellectual freedom, equal access to information, respect, tolerance, fun and welcoming atmosphere, excellent customer service, and a current community driven collection.
[OPEN-ILS-GENERAL] Hold Slip: Source of Notify By
Can anyone shed some light on the sources for the Notify By fields in the Holds Slip? There doesn't seem to be any correlation between fields populated in the patron record (including those under User Settings) and the slips produced for these patrons. Some patrons have Notify by phone unpopulated on the slip, but populated in Daytime Phone. Notify by email is similarly inconsistent. I've been unable to come up with any consistent scenarios that produce these results. Can anyone point me in the right direction with this? Thank you, Scott Thomas Lackawanna County Library System Scranton, PA
Re: [OPEN-ILS-GENERAL] Hold Slip: Source of Notify By
action.hold_request has the appropriate fields that are checked as the notification options are per-hold. Quoting Scott Thomas : Can anyone shed some light on the sources for the Notify By fields in the Holds Slip? There doesn't seem to be any correlation between fields populated in the patron record (including those under User Settings) and the slips produced for these patrons. Some patrons have Notify by phone unpopulated on the slip, but populated in Daytime Phone. Notify by email is similarly inconsistent. I've been unable to come up with any consistent scenarios that produce these results. Can anyone point me in the right direction with this? Thank you, Scott Thomas Lackawanna County Library System Scranton, PA -- Thomas Berezansky Assistant Network Administrator Merrimack Valley Library Consortium 4 High ST, Suite 175 North Andover, MA 01845 Phone: 978-557-8161
Re: [OPEN-ILS-GENERAL] Hold Slip: Source of Notify By
Hi Scott, The notify-by options for each hold placed are stored in that hold's individual record (not in the patron's record). By default, they are set to the patron's selected hold notification preferences at the time the hold is placed, but those options can be changed either at the time the hold is placed or after the fact. Changing the patron's notification preferences in the account settings will not retroactively change what is stored in the holds that have already been placed. This is the cause of confusion to many of our patrons and front-line staff, as they wonder why the patron's old phone number or email address shows up on the hold slip when it has clearly been updated in the patron account record. We recommend to our staff that when a patron requests a change to their contact information, that they ask the patron if they'd like their outstanding holds (if any) to be updated too. Also, if you have the notify by text option enabled, you may want to add that macro to the receipt template since it is not there by default. Terran McCanna PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, GA 30345 404-235-7138 tmcca...@georgialibraries.org - Original Message - From: "Scott Thomas" To: "Evergreen Discussion Group [open-ils-general@list.georgialibraries.org]" Sent: Monday, August 31, 2015 3:31:04 PM Subject: [OPEN-ILS-GENERAL] Hold Slip: Source of Notify By Can anyone shed some light on the sources for the Notify By fields in the Holds Slip? There doesn't seem to be any correlation between fields populated in the patron record (including those under User Settings) and the slips produced for these patrons. Some patrons have Notify by phone unpopulated on the slip, but populated in Daytime Phone. Notify by email is similarly inconsistent. I've been unable to come up with any consistent scenarios that produce these results. Can anyone point me in the right direction with this? Thank you, Scott Thomas Lackawanna County Library System Scranton, PA
Re: [OPEN-ILS-GENERAL] Hold Slip: Source of Notify By
Hi Scott, To expand on what Terran suggests, you may also want to turn on the following columns in the staff client hold screens when viewing those screens in the patron record or on the title: Email Notify Phone Notify Text Notify This way it's easy for staff to see the notification methods for each individual hold. Each notification method can be edited under the Actions for selected Holds menu, so if you need to change a phone number in a number of existing holds for the same patron, you can select all holds to change at once. Hope this helps, Michele -- Michele M. Morgan, Technical Assistant North of Boston Library Exchange, Danvers Massachusetts mmor...@noblenet.org On Mon, Aug 31, 2015 at 4:03 PM, McCanna, Terran < tmcca...@georgialibraries.org> wrote: > Hi Scott, > > The notify-by options for each hold placed are stored in that hold's > individual record (not in the patron's record). By default, they are set to > the patron's selected hold notification preferences at the time the hold is > placed, but those options can be changed either at the time the hold is > placed or after the fact. > > Changing the patron's notification preferences in the account settings > will not retroactively change what is stored in the holds that have already > been placed. This is the cause of confusion to many of our patrons and > front-line staff, as they wonder why the patron's old phone number or email > address shows up on the hold slip when it has clearly been updated in the > patron account record. We recommend to our staff that when a patron > requests a change to their contact information, that they ask the patron if > they'd like their outstanding holds (if any) to be updated too. > > Also, if you have the notify by text option enabled, you may want to add > that macro to the receipt template since it is not there by default. > > Terran McCanna > PINES Program Manager > Georgia Public Library Service > 1800 Century Place, Suite 150 > Atlanta, GA 30345 > 404-235-7138 > tmcca...@georgialibraries.org > > > - Original Message - > From: "Scott Thomas" > To: "Evergreen Discussion Group [ > open-ils-general@list.georgialibraries.org]" < > open-ils-general@list.georgialibraries.org> > Sent: Monday, August 31, 2015 3:31:04 PM > Subject: [OPEN-ILS-GENERAL] Hold Slip: Source of Notify By > > Can anyone shed some light on the sources for the Notify By fields in the > Holds Slip? There doesn't seem to be any correlation between fields > populated in the patron record (including those under User Settings) and > the slips produced for these patrons. Some patrons have Notify by phone > unpopulated on the slip, but populated in Daytime Phone. Notify by email is > similarly inconsistent. I've been unable to come up with any consistent > scenarios that produce these results. Can anyone point me in the right > direction with this? > > > Thank you, > Scott Thomas > Lackawanna County Library System > Scranton, PA > >
