Re: [OPEN-ILS-GENERAL] Running authority_control_fields.pl
On Fri, 2 May 2014 16:50:25 +, Kyle Tomita wrote: > I recently ran the auth to bib linking with the use of the batcher > scripts from MVLC, > http://blog.mvlcstaff.org/2012/09/howto-batch-authority-control.html. > > It took about 8 days and 8 hours to complete. > 800K bib records and 560K auth records > Ran batches of 5000 bibs and ran 3 batches at a time. > > I am wondering if others have used this batching process and how my > times match up. Last time I tried running authority_control_fields.pl, it took about 30 minutes to process a set of 1,554 bib records on a test server, i.e. about 1.2s per record. Since it was just a small test set, I didn't try running multiple processes in parallel. I didn't notice particularly high load during the test, so I suspect disk I/O was the limiting factor; I'd expect better results on a db server using SSDs, but haven't tested that so far. -- Jeff Davis Lead Evergreen Specialist BC Libraries Cooperative
Re: [OPEN-ILS-GENERAL] staff client dev 2014-05-19 / feedback requests
On 2014-05-21 23:00 +, Dan Wells wrote: > I'm not quite sure how to answer because I feel like we're not asking > the right question. Rather than ask how links should behave, we might > instead ask, what should be a link? And also perhaps the inverse; in > our interface, what should a link be? [snip] > My sense, though, is that you were not really asking about external > links which might exist in our content, but rather "internal" links > (which I will define as a link to a new context in the staff client). > These are trickier. To help our thinking, I wish to posit that on any > given screen, we have both a context and a state. The URL always > captures the context, and sometimes some aspects of the state, but we > cannot expect it to always capture every aspect of the current state. > Because of this fact, every time you switch contexts, you risk losing > some state. Therefore, we should be very careful to offer any > interface element, link or otherwise, which switches context without a > clear indication to the user of that intention. [snip] > Instead of thinking of things as 'links' and then trying to make one > rule for a bunch of disparate things, I'd propose that we should have > distinctive interface elements for which we can then define usage > appropriate behaviors. Doing so would create a tremendous opportunity > for improving the overall usability of the staff client as a whole. > > I could say more, but I've said a lot already. I'd love to hear > reactions to what I've said so far (which I know is very uneven given > the time and space limitations). Am I way off-base? Or is this the > beginning of something we can work with? Dan, I share your concern (although I would never have been able to articulate it so well!), and I think you've presented us with a good way of thinking about the issue. In general I like the idea of letting the user choose how a link opens. But I don't think that behavior is always appropriate in a web app, where context and state are richer, and user behavior more constrained, than they are on a simple web page. > P.S. Bill, I think you are doing an outstanding job, and we couldn't > even have this conversation without all the work you have done to pave > the way. Please don't take anything above as being critical of the > hundreds of decisions you've had to make to get to where we are today. > Again, thank you! This probably isn't said often enough. Thanks for all your hard work on the new client, Bill! I've been really impressed and pleased by the development so far. -- Jeff Davis Lead Evergreen Specialist BC Libraries Cooperative
Re: [OPEN-ILS-GENERAL] FW: OneClickdigital and ILS integration
On Tue, 14 Oct 2014 20:43:56 +, Elizabeth Davis wrote: > I'm new member to the list and was curious if anyone else is > interested in the OneClickDigital integration. We have both OverDrive > and OneClickDigital and I think it would be great for users to be able > to download straight from the OPAC. On a related note, a contractor for Sitka has written code to make use of OverDrive's APIs in the Evergreen OPAC: http://git.sitka.bclibraries.ca/gitweb/?p=sitka/overdrive-evergreen-opac.git;a=summary Please note that this is NOT ready to use yet (among other things, there are some hardcoded Sitka-specific URLs). We are currently reviewing and testing the code; I had been planning to do some cleanup over the next couple of weeks before inviting others to try it out. If Evergreen developers like the look of it, maybe this can also serve as a basis for OneClickDigital integration? It's not currently set up to work with multiple ebook/audiobook vendors, but there will naturally be some shared functionality between OverDrive and OneClickDigital, and it would make sense for the OPAC to reuse the same code for both. Jeff P.S. Welcome to the Evergreen community, Elizabeth!
Re: [OPEN-ILS-GENERAL] Open-ils-general Digest, Vol 105, Issue 54
On 1 Apr 2015 13:20:31 +, Deana Cunningham asked: > We use Google analytics on our website but I am curious as to how > you use it within the OPAC. Can you elaborate or put me in touch > with someone who could talk me through installing it there? Google Analytics integration is built into the Evergreen TPAC. Once you've set up an account at http://www.google.com/analytics/, you just need to edit the config.tt2 file in your TPAC, changing the google_analytics.enabled setting to 'true' and google_analytics.code to a valid Google Analytics code. I assume you can use your existing GA account and have separate codes for your website and your TPAC, but I'm not sure of the specifics there. That said, I agree with Rogan that there are some serious privacy concerns around Google Analytics (and in our case, using it might actually run afoul of provincial privacy legislation). Instead, we use a locally-hosted installation of Piwik. To enable Piwik tracking in our TPAC, we just added some extra Javascript to the TT2 file that contains Google Analytics code, as seen here: http://git.sitka.bclibraries.ca/gitweb/?p=sitka/evergreen.git;a=commitdiff;h=6eb7290 This is customized for our environment, but something similar should work for other libraries that want to run their own Piwik instance. -- Jeff Davis Lead Evergreen Specialist BC Libraries Cooperative
Re: [OPEN-ILS-GENERAL] Customizing OPAC for each library in consortium
Hi Eva, At Sitka we have separate skins for each of the libraries in our consortium, each with its own domain name. To make this work, our Apache configuration includes virtual host entries for each skin, more or less as described in the documentation here: http://docs.evergreen-ils.org/2.8/_how_to_override_templates.html See the section "Apache configuration for each virtual host (eg.conf)" at the bottom of that page. The OILSWebTemplatePath variable specifies which skin to use for each virtual host. Looking at those examples, anyone who visits http://br1.concat.ca would see the OPAC skin for BR1, which uses the template files located at /openils/var/templates_BR1. In this way, the skin you see is determined by what URL you use; it doesn't depend on whether you are logged in or not. To specify a default location for each skin, you can use the "physical_loc" environment variable in your Apache config. For example, if BR1 had a library ID of 4, you could add this line to the virtual host block for BR1: SetEnv physical_loc 4 Hope that helps! Jeff > From: Cerninakova Eva > To: Evergreen Discussion Group > > Subject: [OPEN-ILS-GENERAL] Customizing OPAC for each library in > consortium > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hi all, > > We are currently creating our first tiny Evergreen consortium, and I have a > question concerning the OPAC settings. > > Is there a possibility to customize the OPAC differently for each library > in consortium? > The desired functionality is something like this: > >1. When patron from Library1 opens the link to catalog >- the default search library on the catalog homepage is set to > "Library1" > - the OPAC homepage is customized just for Library1 (i. e. patron > sees only the information related to Library1, maybe logo of Library1 > etc.). >2. Similarly when patron from Library2 opens the link to catalog - the >default search library on the catalog homepage is set to "Library2" etc. > > I know how to create the custom TPAC templates directory and how to set the > template overriding in Apache, but as I understand it, the custom template > for each library is applied only when patron is logged in to OPAC. > > Is there a possibility to customize catalog pages without logging in? > (According to several Evergreen consortia catalogs I have examined it > seems to me that this is possible. But how?) > > Could you please give me a hit, how to do it? > > > Thanks a lot. > > Eva > > > > > > > > --- > Mgr. Eva Cerniňáková > cer...@jabok.cz > Tel. +420 211 222 409 > > Knihovna Jabok > http:/knihovna.jabok.cuni.cz <http://knihovna.jabok.cz> > Tel. +420 211 222 410 > > Jabok - Vyšší odborná škola sociálně pedagogická a teologická > Salmovská 8, 120 00 Praha 2 -- Jeff Davis Lead Evergreen Specialist BC Libraries Cooperative
Re: [OPEN-ILS-GENERAL] Evergreen 2.9 and PostgreSQL 9.4 - A Cautionary Tale
t;> Having said all that, disabling transparent huge pages is pretty much >> critical -- it's as important as disabling zone reclaim on any NUMA >> system. This was a non-issue on 9.2, became important in some >> situations on 9.3, and is a huge issue for 9.4. The reasons are >> complicated, but the cause is Postgres' change from System V to POSIX >> shared memory. Basically, just do it. :) >> >> Thanks for sharing, Chris, and again, I was glad to help when needed. >> >> -- >> Mike Rylander >> | President >> | Equinox Software, Inc. / The Open Source Experts >> | phone: 1-877-OPEN-ILS (673-6457) >> | email: mi...@esilibrary.com >> | web: http://www.esilibrary.com >> >> >> >> On Wed, Feb 10, 2016 at 2:41 PM, Chris Sharp >> wrote: >>> Hello all, >>> >>> As watchers of the Evergreen IRC channel, know, the PINES upgrade from >>> Evergreen 2.7.2/PostgreSQL 9.3 to Evergreen 2.9.1/PostgreSQL 9.4 was a bit >>> bumpy. Our system slowed to a crawl on go-live day, and we were quick to >>> determine that the culprit was the database. After consulting with Mike >>> Rylander of Equinox Software, we implemented several tweaks to our system >>> that I'll share here in hopes that they may help others in the future: >>> >>> The slowness appears to have been due to two problem areas: >>> >>> Bad Query Plans: >>> >>> - we upped the join_collapse_limit from the default value of 8 to 12 - Dan >>> Wells discusses this possibility in his bug report about slow copy load in >>> the OPAC (https://bugs.launchpad.net/evergreen/+bug/1527731). >>> - we altered the actor.org_unit_descendants, adding a realistic estimate of >>> the number of rows to be expected: >>> ALTER FUNCTION actor.org_unit_descendants(int) ROWS 300; >>> ALTER FUNCTION actor.org_unit_descendants(int,int) ROWS 300; >>> - we dropped a duplicate index on the action.hold_request table that was >>> apparently added to address an issue in the past >>> (ahr_current_copy_open_idx) >>> - we added an index to action.circulation to address an issue with slow >>> collections queries: >>> CREATE INDEX CONCURRENTLY circ_circ_lib_open_idx ON action.circulation >>> (usr,circ_lib) WHERE xact_finish IS NULL; >>> >>> PostgreSQL Memory Usage: >>> >>> - we reduced our shared_buffers size to 32GB from 128GB - we had calculated >>> the higher value from the PostgreSQL documentation >>> (http://www.postgresql.org/docs/9.4/static/runtime-config-resource.html#GUC-SHARED-BUFFERS) >>> recommendation of 1/4 of installed RAM (512GB in our case). We >>> immediately saw a reduction of resource consumption on the server. >>> - on the underlying OS, we turned off transparent huge pages (THP - see >>> http://unix.stackexchange.com/questions/99154/disable-transparent-hugepages >>> for details on how one might do this). Further research revealed that >>> turning off THP is generally recommended by Oracle and PostgreSQL. >>> >>> We also followed Mike's recommendation to run the hold targeter cron job >>> nightly rather than every 15 minutes, but that probably didn't have much >>> to do with the root cause (aside from adding queries to the pile-up when >>> slowness struck). >>> >>> Since we made the above changes, our database servers have increased speed >>> and are performing very happily. I just wanted to share our experience >>> with the Evergreen Community in hopes that others can benefit. >>> >>> -- >>> Chris Sharp >>> PINES System Administrator >>> Georgia Public Library Service >>> 1800 Century Place, Suite 150 >>> Atlanta, Georgia 30345 >>> (404) 235-7147 >>> csh...@georgialibraries.org >>> http://pines.georgialibraries.org/ >> > -- Jeff Davis Lead Evergreen Specialist BC Libraries Cooperative
[OPEN-ILS-GENERAL] Slowness/freezing with XUL staff client
Our consortium has a few libraries where the Evergreen staff client periodically becomes unusably slow or freezes up altogether. I'm curious about other libraries' experiences with this problem. 1. Does the staff client slow down or freeze up regularly at your library? How often does it happen? Are there any noticeable patterns (e.g. are only circ stations affected, not cataloguing)? 2. How do you deal with the problem? We usually recommend limiting the number of open tabs, restarting the client periodically throughout the day, and increasing RAM. 3. If you use the web client, have you noticed an improvement? We suspect that the root of the problem is the ancient version of XULrunner used by the old staff client, but we haven't had the opportunity to compare the web client in production. -- Jeff Davis BC Libraries Cooperative
Re: [OPEN-ILS-GENERAL] Limiting search options for a consortium?
Hi Jesse, I believe there are two steps you need to take: (1) Set the physical_loc environment variable in the Apache config for each of your subdomains, using a directive like this: SetEnv physical_loc 4 (2) In your library settings, set "Org Unit Hiding Depth" to the appropriate value for each library. Here's the description for that setting: This will hide certain org units in the public OPAC if the Physical Location (url param "physical_loc") for the OPAC inherits this setting. This setting specifies an org unit depth, that together with the OPAC Physical Location determines which section of the Org Hierarchy should be visible in the OPAC. For example, a stock Evergreen installation will have a 3-tier hierarchy (Consortium/System/Branch), where System has a depth of 1 and Branch has a depth of 2. If this setting contains a depth of 1 in such an installation, then every library in the System in which the Physical Location belongs will be visible, and everything else will be hidden. A depth of 0 will effectively make every org visible. The embedded OPAC in the staff client ignores this setting. Hope that helps! Jeff On 2017-02-01 09:24 AM, Jesse McCarty wrote: Hello Everyone, I was wondering if there are any configurations to restrict searches to a single library in a consortium setup? We have four libraries in our Evergreen system, all setup for access in sub-domains (Burlington.skagitcat.org, laconner.skagitcat.org etc…). Occasionally the search drop down gets switched/changed to search all the libraries instead of the local library, which causes some confusion for patrons looking for a book in our library when they don’t realize the search result is showing them a book in a different library. There any configuration to eliminate the other options from the drop down box in the web OPAC? Screenshot for reference attached, we would like to keep the searches on the Burlington Public Library, but sometimes the box gets set to Skagit Evergreen Libraries. Thanks in advance Jesse McCarty City of Burlington IT Technical Assistant
Re: [OPEN-ILS-GENERAL] Slowness/freezing with XUL staff client
I know of two sites on Windows 7 and a multibranch system with a Linux thin client setup. There may be a couple of others on one or another version of Windows. Jeff On 2017-02-02 07:14 AM, Mike Rylander wrote: Jeff, Is there an OS version that this happens on more often? I'm looking at you, Windows 10. Thanks, -- Mike Rylander | President | Equinox Open Library Initiative | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@equinoxinitiative.com | web: http://equinoxinitiative.org On Wed, Feb 1, 2017 at 4:43 PM, Jeff Davis wrote: Our consortium has a few libraries where the Evergreen staff client periodically becomes unusably slow or freezes up altogether. I'm curious about other libraries' experiences with this problem. 1. Does the staff client slow down or freeze up regularly at your library? How often does it happen? Are there any noticeable patterns (e.g. are only circ stations affected, not cataloguing)? 2. How do you deal with the problem? We usually recommend limiting the number of open tabs, restarting the client periodically throughout the day, and increasing RAM. 3. If you use the web client, have you noticed an improvement? We suspect that the root of the problem is the ancient version of XULrunner used by the old staff client, but we haven't had the opportunity to compare the web client in production. -- Jeff Davis BC Libraries Cooperative
Re: [OPEN-ILS-GENERAL] Slowness/freezing with XUL staff client
Josh, that's very interesting. One of our affected libraries makes heavy use of patron search for retrieving patrons. I found a bug report in Launchpad about patron search using up RAM: https://bugs.launchpad.net/evergreen/+bug/1110817 I did a quick test that seemed to confirm the issue; my findings have been added to the bug report. I'll need to do more testing and follow up with our other affected libraries to see if they use patron search regularly. Jeff On 2017-02-01 02:19 PM, Josh Stompro wrote: I've seen issues with using the patron search vs checkout. Patron search seems to leak memory. So I've seen issues where staff always go to patron search, even if they have a patron barcode, after a while the client will get unresponsive. Josh Stompro - LARL IT Director -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jeff Davis Sent: Wednesday, February 01, 2017 3:43 PM To: open-ils-general@list.georgialibraries.org Subject: [OPEN-ILS-GENERAL] Slowness/freezing with XUL staff client Our consortium has a few libraries where the Evergreen staff client periodically becomes unusably slow or freezes up altogether. I'm curious about other libraries' experiences with this problem. 1. Does the staff client slow down or freeze up regularly at your library? How often does it happen? Are there any noticeable patterns (e.g. are only circ stations affected, not cataloguing)? 2. How do you deal with the problem? We usually recommend limiting the number of open tabs, restarting the client periodically throughout the day, and increasing RAM. 3. If you use the web client, have you noticed an improvement? We suspect that the root of the problem is the ancient version of XULrunner used by the old staff client, but we haven't had the opportunity to compare the web client in production. -- Jeff Davis BC Libraries Cooperative
Re: [OPEN-ILS-GENERAL] change serials Holdings View from alphabetical to date order?
I believe the same problem exists with serials sorting in the OPAC: https://bugs.launchpad.net/evergreen/+bug/1429317 It would be great if we had a single solution that we could leverage for both the OPAC and the web client. Jeff On 2018-10-05 12:07 PM, Holly Brennan wrote: In the web client (well, on version 3.0.5 of webby), Holdings View shows issues in alphabetical order based on their call number. In our setup, this puts all the April issues first regardless of year, then August, etc. This is a pain when it comes to deleting issues because I have in my hands all the issues from Oct/Nov/Dec of 2017 in date order, yet I have to bounce all over the place in the list to checkbox these issues. There don’t seem to be any options for changing this view in any way… even reordering or adding columns isn’t a feature in Holdings View. I would love for this view to act like the Manage Issues interface, which defaults to a sort-by-date view, AND many of the columns can be resorted. Is this possible? Apologies if this has been covered in a newer version or if there’s an ongoing discussion already. Thanks! This sorting style is no fun to work with (current Holdings View): I would love to be able to see Holdings View like this Manage Issues view: Thanks! Holly Brennan Technology Specialist Homer Public Library Homer, Alaska hbren...@cityofhomer-ak.gov 907-435-3154 (direct) 907-235-3180 (main desk)
Re: [OPEN-ILS-GENERAL] Testing Staff client on new staging server, can't login - websockets error
Hi Jesse, It looks like your browser is trying to establish a websocket connection on port 433, not 443. Maybe there is a typo somewhere, perhaps in opensrf_ws.js or opensrf_ws_shared.js? Jeff On 2019-05-01 11:31 a.m., Jesse McCarty wrote: HI All, I am preparing to migrate our Evergreen install (3.2.5) to a new Server (Ubuntu 16.04) and have everything up and running but am having trouble with the websockets to test the web staff client before moving the current database over. The new server is configured like the production server with websocketsd and nginx to proxy everything and has the database imported from the production server’s backup. I can search catalog, login to account, just cannot get into the staff client. I get the following error in the web console using Firefox: As another test, I created a test server (complete clone of the production server, with configuration files and IP changes for internal testing) and was able to run the staff client just fine. I can see that the websocket is running on the new server. Not sure if/what I missed in setup or not, any help is greatly appreciated. Thanks! Jesse McCarty City of Burlington Information Systems Technician
Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] browser staff feedback request / integration
On 2014-04-04 09:37AM, Galen Charlton wrote: > +1 for the reasons that folks have already mentioned. My main caveat > is to try to anticipate and avoid situations where folks would not > only have to switch from browser to XUL often, but would also need to > maintain a lot of context while doing so. > > As a contrived example, if v1 of the web-based circulation interface > let you do everything except register patrons, switching to the staff > client to add a new patron, then switching back to the browser to scan > their barcode and check out their first items wouldn't be ideal, but > it wouldn't be difficult or slow to make the transition. This is > because the only thing needed to maintain the context during the > transition is scanning a patron barcode. > > Conversely, as another contrived example, if v1 of web-based circ > required that you jump to the XUL staff client during a checkout > session to add a pre-cat, that would be more disruptive, as it > scatters the overall workflow of "check out a bunch of items" across > two interfaces, and raises questions like whether the patron would end > up with two checkout receipts. I think this caveat is pretty important. Ideally, no individual workflow would require switching between the XUL client and the browser. In Galen's first example, switching isn't too much of a problem because you are also switching between conceptually distinct workflows (and indeed between different interfaces within the existing XUL client). As Dan suggested earlier, if development focuses on "fleshing out modules on a workflow-by-workflow basis as much as possible," we'll mitigate a lot of the pain in having multiple clients. Jeff
Re: [OPEN-ILS-GENERAL] Problem delete patrons
Sitka's code is here: http://github.com/twirlip/deletepatron It's not so much a patch as an external web interface that ought to be completely rewritten as a proper patch. But it works. As far as I know, the patron deletion functionality that exists in 2.0 is for completely removing patron information (specifically, it anonymizes personal information and possibly purges some stuff from other tables). Sitka's patron deletion tool just flags the patron as deleted and deletes their card; the account becomes unusable and can't be reactivated, IIRC, but the data remains in the database until you go in and purge deleted patron accounts. -- Jeff Davis Sitka Implementation Team Steve Wills wrote: Sitka has a patch for this. I'm not sure if it has been posted to contribs yet. Stev3 Sent from my iPhone On Oct 29, 2010, at 4:13 AM, "Ever Green" wrote: Hello to all user I use the program Evergreen Client 1.6, and I can not delete Patrons. How do I remove the Patrons? Please, help me solve this problem? Thanks, Ever Green.
