Evergreen ILS Website

IRC log for #evergreen, 2015-07-27

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:36 eady joined #evergreen
04:38 bshum kmlussier: Going to test https://bugs.launchpad.net/evergreen/+bug/1198465 later today, got it put together on our test server.
04:38 pinesol_green Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 17, heat: 80) [Wishlist,Confirmed] - Assigned to Dan Wells (dbw2)
04:38 bshum Just one minor note though, one of the library settings in the upgrade script has a typo in it.  "overde" instead of "overdue"
05:04 pinesol_green Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
06:19 Bmagic_ joined #evergreen
07:47 ericar joined #evergreen
07:59 rjackson_isl joined #evergreen
07:59 jboyer-isl joined #evergreen
08:23 TaraC joined #evergreen
08:41 mmorgan joined #evergreen
08:52 akilsdonk joined #evergreen
08:59 RoganH joined #evergreen
09:04 Shae joined #evergreen
09:18 dbwells joined #evergreen
09:33 kmlussier bshum: Fixed and force pushed to my working branch.
09:33 kmlussier bshum: Also, 4:30 a.m.? Really?
09:35 csharp @praise 10 bshum
09:35 * pinesol_green You don't want to get mixed up with someone like bshum. bshum is a loner, Dottie. A rebel.
09:36 mmorgan 4:30am is either way too early or way too late, not really sure which.
09:36 csharp it's both!
09:37 csharp http://www.complex.com/pop-culture/20​14/03/20-simpsons-quotes-to-use-in-ev​eryday-situations/430-in-the-morning
09:37 maryj joined #evergreen
09:37 yboston joined #evergreen
09:38 mmorgan :)
10:04 mrpeters joined #evergreen
10:39 collum joined #evergreen
10:46 Christineb joined #evergreen
11:19 mllewellyn joined #evergreen
11:26 Dyrcona joined #evergreen
11:35 mtj_- joined #evergreen
11:37 * Dyrcona yawns.
11:45 * Bmagic_ yawns reactively
11:48 mmorgan @coffee Dyrcona and Bmagic
11:48 * pinesol_green brews and pours a cup of Kenya AA Wagamuga Auction Lot, and sends it sliding down the bar to Dyrcona and Bmagic
11:48 Dyrcona Thankies.
11:49 * mmorgan attempts to derail reactive yawning :)
11:51 jihpringle joined #evergreen
12:09 sandbergja joined #evergreen
12:16 Shae joined #evergreen
12:47 bshum So, what's this MARC "breaker" thing all about in the web client?
12:57 jeff it's a representation of MARC -- similar (identical?) to the "text editor" view in the staff client
13:00 bshum Well it just seems to be some sort of popup notification when I click on it in Chrome.
13:00 bshum So i wasn't sure how we were meant to interact with it.  Or not.
13:07 jeff ah.
13:20 jeff git tags are handy for a number of things: recently i've been using them to tag deployments of templates. i can then use "git diff --name-only deploy_DATE_TICKET.." to get a list of files that have changed since the last deploy.
13:20 jeff since we're not using git to actually deploy, i then have a handy list of files that need to be uploaded.
13:40 csharp hmm - having an acq issue where my "acq admin" user can't see/interact with the list of providers (Admin -> Server Administration -> Acquisitions -> Providers)
13:40 csharp as admin, I'm able to see them
13:41 kmlussier csharp: Has your acq admin user been able to see them in the past?
13:41 * csharp continues to look in the postgres logs for clues
13:41 csharp kmlussier: I don't think so
13:42 csharp the user in question has all of the *_PROVIDER perms assigned at the System level, and the providers are owned by the library system in question
13:42 csharp (system, not branch)
13:44 csharp I can also see that the SQL queries are being performed for the providers, but they aren't displaying
13:44 csharp the user passes all the permission tests I can see being performed in the logs
13:44 kmlussier This reminds me of an old bug that was fixed a long time ago.
13:45 kmlussier bug 731510
13:45 pinesol_green Launchpad bug 731510 in Evergreen master "Acquisitions - Unable to view providers" (affected: 2, heat: 12) [Medium,Fix released] https://launchpad.net/bugs/731510 - Assigned to Mike Rylander (mrylander)
13:45 kmlussier csharp: I can't imagine it's the same thing, but if you page through the interface, do you see the providers?
13:48 csharp kmlussier: nope :-(
13:49 kmlussier csharp: And the library selector on that page is the same as the OU that owns the providers? Sorry to ask obvious questions.
13:50 csharp yes, that's right
13:51 csharp one possible clue (that could be a red herring), the JS console shows "TypeError: item is null"
13:52 csharp when I look at Open-ILS/web/js/ui/default/ac​q/financial/view_provider.js, I see the term "item" used - I'm assuming that's what's being referred to in the JS error
13:57 csharp also 'request open-ils.acq open-ils.acq.provider.org.retrieve <authtoken>' shows the expected list via srfsh
13:57 csharp which is what is called by that JS library
13:58 csharp again, if I'm admin, I can see everything as expected, so it *seems* like this should be perms, but I'm not seeing any messages in the logs
13:59 csharp and all the perms I do see checked appear to be assigned at the appropriate levels (or I wouldn't expect the srfsh test to work)
14:03 berick csharp: the JS error mentions view_provider.js specifially?
14:03 berick i think that file might actually be deprecated
14:04 berick Open-ILS/web/js/ui/default/c​onify/global/acq/provider.js is loaded by
14:04 berick Open-ILS/src/templates/coni​fy/global/acq/provider.tt2
14:04 berick don't see anything loading view_provider.js
14:05 berick looks like user needs one of [ADMIN|MANAGE|VIEW]_PROVIDER permission
14:09 pdot2 joined #evergreen
14:10 csharp berick: actually, it's dojo.js - thanks for the direction
14:11 pdot2 a question for those with knowledge, is anyone using evergreen with code 128 barcodes?
14:11 csharp the user in question has all three _PROVIDER perms
14:12 jeff pdot2: in some cases, yes. do you have a more specific question?
14:14 pdot2 jeff: This may be a case of not knowing what questions to ask, as I'm attempting to evaluate label printers, and scanner compatibility, is there a set number of digits that evergreen requires / limits in a barcode?
14:14 jlitrell joined #evergreen
14:15 pdot2 10000028
14:17 jeff pdot2: in my experience, 14 digit numeric barcode values with the 14th digit being a luhn/mod10 check digit are what I have encountered most often. if you have the "strict barcode" option enabled, that will require a valid check digit. beyond that, there are very few constraints that evergreen cares about.
14:18 jeff pdot2: it may also be useful to compare with your peers in terms of similar geographic area and similar library type.
14:20 jeff pdot2: i.e., you may care more about being the same as nearby libraries, especially since in the case of Evergreen there are very few constraints. If your neghbors all use codabar you may regret a decision to use Code128 later.
14:39 jeffdavis I have a question about OpenSRF routing, but my understanding is a little sketchy so I'm not quite sure how to frame it.
14:40 jeffdavis Our EG traffic is load-balanced between two servers. We are seeing cases where osrf_http_translator on server A attempts to send a pcrud request to server B.
14:40 jeffdavis Is that expected behavior? If not, how would you normally expect to prevent it in a load-balanced environment?
14:41 bshum berick: gmcharlt: For https://bugs.launchpad.net/evergreen/+bug/1394989, we're looking to try implementing the solution that you suggested alternative to mrpeters' patch.  If it passes, should we rework that to be a proper git branch and get it submitted towards review and inclusion in a future release?
14:41 pinesol_green Launchpad bug 1394989 in Evergreen "Collections API users_of_interest can crash on users with null card values" (affected: 1, heat: 6) [Low,Confirmed] - Assigned to Michael Peters (mrpeters)
14:41 csharp ooh - another point of interest - the problem is *not* happening on our production server, just our acq testing server :-/
14:41 bshum mceraso's been poking around at this at Unique's behest and we just found the LP
14:42 gmcharlt bshum: yes please
14:43 mrpeters sorry guys, i never caught those comments
14:43 bshum From the comment, I think we can just grab berick's approach and copy it in, but we'll test and see what blows up :P
14:48 miker jeffdavis: that load balancing is probably expected, and you probably don't want to prevent it.  if the translator is what's initiating it, it's almost certainly because of a stateful connection from the client side, which is required for several interfaces to work correctly. they have to be able to send several messages, possibly through different apache servers, to one opensrf backend. the translator knows how to coordinate that via a memcache blob
14:56 jeffdavis What we are seeing is that the translator on server A sends an XMPP request to opensrf@private.localhost/open-ils.pcrud_drone_server_B, and gets a 503 error in response
15:01 miker ah, yeah... you'll need to set up real (if internal-only) names and addresses and cross-register services, and set up the <trusted_domains> stuff ... I'll see if there are pointer docs
15:02 jeffdavis our opensrf.xml does include a full list of services on all servers in the <hosts> block
15:02 miker this'll all be in the opensrf_core.xml
15:03 jeffdavis ah ok
15:03 miker instead of public.localhost you'll want a public.server_a and public.server_b as appropriate, and /etc/hosts entries for IPs
15:10 jeffdavis hm, looks like our old setup used public.localhost on both servers, and mapped that to the current server's IP in /etc/hosts
15:19 jeffdavis miker: thanks for that, that points me at a possible solution that I'll try overnight
16:40 jeffdavis Rather than adding entries for IPs to /etc/hosts, is there any reason you couldn't use DNS for public.server_a and public.server_b (etc)?
16:55 jeff How common is it to have MARC records that claim "Laserdisc" in the 007 but are actually DVDs?
16:56 jeff Is this something that's common in older records before a value for DVD was defined, or is it just poor cataloging in general?
16:56 jeff We seem to have... many. I'm wondering what the likely source is (OCLC, vendor, bad local template, etc).
16:56 jeff I suspect it'll be a matter of "the bad records come from everywhere!"
17:00 dbwells jeff: Looking at the LoC page, it looks like pre-2001, 007/04 code 'g' was "Laser optical (Reflective) videodisc", so basically both disc types.  In 2001 it was split into g/v.
17:02 dbwells jeff: gory details here: https://www.loc.gov/marc/marbi/2001/2001-08.html
17:03 Dyrcona jeff: It is common. We wrote a program to fix it. Hit me up tomorrow and I can share it with you.
17:15 mmorgan left #evergreen
17:47 gsams joined #evergreen
19:13 bmills joined #evergreen
19:13 bmills left #evergreen
20:57 eady joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat