| 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/2014/03/20-simpsons-quotes-to-use-in-everyday-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/acq/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/conify/global/acq/provider.js is loaded by |
| 14:04 |
berick |
Open-ILS/src/templates/conify/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 |
