| Time |
Nick |
Message |
| 00:06 |
|
rjackson-isl joined #evergreen |
| 01:04 |
|
stevenyvr2 joined #evergreen |
| 01:21 |
|
stevenyvr2 left #evergreen |
| 06:41 |
|
timlaptop joined #evergreen |
| 07:51 |
|
mrpeters joined #evergreen |
| 08:01 |
|
ningalls joined #evergreen |
| 08:02 |
|
collum joined #evergreen |
| 08:23 |
csharp |
~contribute |
| 08:23 |
pinesol_green |
Interested in contributing to the Evergreen project? Please see http://www.evergreen-ils.org/dokuwiki/doku.php?id=contributing and http://evergreen-ils.org/dokuwiki/doku.php?id=eg_developer_overview. |
| 08:25 |
csharp |
@later tell shubhdub_ FYI - most of our channel particpants are online 9:00 a.m. to 5:00 p.m. EST Monday - Friday, FYI. Here's what our bot has to say about contributing: "Interested in contributing to the Evergreen project? Please see http://www.evergreen-ils.org/dokuwiki/doku.php?id=contributing and http://evergreen-ils.org/dokuwiki/doku.php?id=eg_developer_overview. |
| 08:25 |
pinesol_green |
csharp: Error: No closing quotation |
| 08:25 |
csharp |
@later tell shubhdub_ FYI - most of our channel particpants are online 9:00 a.m. to 5:00 p.m. EST Monday - Friday, FYI. Here's what our bot has to say about contributing: "Interested in contributing to the Evergreen project? Please see http://www.evergreen-ils.org/dokuwiki/doku.php?id=contributing and http://evergreen-ils.org/dokuwiki/doku.php?id=eg_developer_overview." |
| 08:25 |
pinesol_green |
csharp: The operation succeeded. |
| 08:50 |
|
mmorgan1 joined #evergreen |
| 09:10 |
|
kbeswick joined #evergreen |
| 09:18 |
|
hopkinsju joined #evergreen |
| 09:41 |
|
mllewellyn joined #evergreen |
| 09:59 |
|
senator joined #evergreen |
| 10:05 |
|
hopkinsju joined #evergreen |
| 10:10 |
eeevil |
grabbing 0848 |
| 10:24 |
pinesol_green |
[evergreen|Mike Rylander] Re-apply the changes provided by 0802 for backport - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3b9e538> |
| 10:38 |
|
yboston joined #evergreen |
| 10:50 |
|
RoganH joined #evergreen |
| 10:53 |
bshum |
Oops. |
| 10:54 |
bshum |
Apparently, there must be a permission that lets people check/uncheck bills in the GUI |
| 10:54 |
bshum |
Cause now nobody can pay bills after our upgrade where we flipped on the library setting to uncheck bills by default |
| 10:56 |
* phasefx |
doesn't remember such a thing |
| 10:57 |
bshum |
Yeah that's weird |
| 10:57 |
bshum |
Maybe it's something else going on |
| 10:57 |
bshum |
Huh |
| 10:57 |
phasefx |
windows or mac? |
| 10:57 |
bshum |
Yep, you're right phasefx |
| 10:58 |
bshum |
Must be someone giving me bad intel |
| 10:58 |
bshum |
It's on Windows |
| 10:58 |
phasefx |
if mac, I wouldn't have been surprised by a widget glitch |
| 10:58 |
bshum |
As super admins, people saw the button just fine, but some library staff reported not seeing the buttons |
| 10:58 |
bshum |
I'll get some more info on this before jumping to more bad conclusions.... |
| 10:58 |
bshum |
Thanks |
| 11:01 |
csharp |
bshum: this is on master? |
| 11:01 |
bshum |
csharp: Yeah it is |
| 11:01 |
bshum |
Now I'm suspecting screen resolution |
| 11:01 |
bshum |
The person complaining is running 800x600. Maybe the buttons are sliding off the screen ara |
| 11:01 |
csharp |
lemme rebuild my test vm and try to replicate |
| 11:01 |
bshum |
*area |
| 11:01 |
csharp |
oh |
| 11:02 |
dbs |
ooh, 800x600. fun. |
| 11:02 |
bshum |
Yeah, wtf is what I said |
| 11:02 |
eeevil |
bshum: on a 30" widescreen monitor? |
| 11:03 |
bshum |
eeevil: Even *I* don't have a 30" monitor :( |
| 11:05 |
RoganH |
bshum: that's because you have a 4K 50" right? |
| 11:05 |
bshum |
RoganH: If wishes were horses :P |
| 11:08 |
bshum |
It must be some corrupted profile or something |
| 11:08 |
bshum |
I tried 800x600 and it still works |
| 11:08 |
bshum |
They're missing the checkbox column entirely in their UI |
| 11:09 |
phasefx |
does it exist in the column picker? |
| 11:10 |
bshum |
It doesn't seem to be there |
| 11:11 |
dbs |
bshum: upgraded vs fresh install client? |
| 11:11 |
bshum |
dbs: It's an upgraded client. But this isn't affecting everybody |
| 11:11 |
bshum |
Only two libraries so far |
| 11:11 |
bshum |
So it's not a consistent reproducible problem |
| 11:17 |
bshum |
We're going to try clearing the cache, or resetting the profile. And/or uninstalling/reinstalling the clients. |
| 11:19 |
* bshum |
loves the day after upgrades |
| 11:21 |
dbs |
bshum: crazy me wonders if it's a staff client upgraded from the xul 3.whatever days vs one running on xul 14, but I'm like that :) |
| 11:21 |
jboyer-isl |
bshum: Could it possibly be a training thing? With no checkmarks on Windows, the only indication that there's even a column there is the header separator at the top. Maybe request a screenshot? |
| 11:22 |
csharp |
older profile data can play havoc with newer versions sometimes |
| 11:22 |
bshum |
Huh, so the IT person troubleshooting says that when they logged in as an admin for the PC, they could see the buttons. |
| 11:22 |
bshum |
But as the other user, they couldn't see it. |
| 11:22 |
bshum |
Weird...... |
| 11:22 |
csharp |
that would be a different openils profile, right? |
| 11:22 |
bshum |
Or... wait |
| 11:23 |
bshum |
That the user is a member of admin and debugger? |
| 11:23 |
bshum |
Must be groups or something |
| 11:24 |
* bshum |
throws his hands up in the air in disgust |
| 11:24 |
bshum |
windows-- |
| 12:00 |
|
dMiller joined #evergreen |
| 12:06 |
bshum |
Hmm |
| 12:07 |
bshum |
csharp: When placing a hold in the staff client, I'm seeing that if the staff member doesn't have an email address, it populates the email field with something like "no email address configured, check account" |
| 12:07 |
bshum |
And then it doesn't update the field with the actual user's email when you key in different barcodes. |
| 12:07 |
bshum |
If the staff member does have an email, it starts with their email, and then keying in different patrons updates the field accordingly |
| 12:08 |
bshum |
My thinking is a bug since 2.4's rewrite of the code in that area |
| 12:08 |
bshum |
And maybe it's just not initializing the email variable (or refreshing it if it starts as NULL) |
| 12:09 |
bshum |
csharp: If you get a chance to test that on a 2.4/2.5/master system, let me know :D |
| 12:09 |
bshum |
I'm going to eyeball some more code |
| 12:09 |
* bshum |
loves how "upgrades" shakes loose all the bugs nobody ever saw before |
| 12:13 |
|
rfrasur joined #evergreen |
| 12:14 |
phasefx |
bshum: I think someone here said that they announce upgrades that don't actually happen for just that reason :) |
| 12:15 |
bshum |
phasefx: I've done that before :) |
| 12:15 |
phasefx |
:D |
| 12:36 |
bshum |
Well, not intentionally |
| 12:37 |
|
hopkinsju joined #evergreen |
| 12:37 |
|
dMiller_ joined #evergreen |
| 12:44 |
pastebot |
"csharp" at 64.57.241.14 pasted "failed checkin on in-transit item" (108 lines) at http://paste.evergreen-ils.org/36 |
| 12:45 |
bshum |
Some sort of timeout? |
| 12:45 |
csharp |
We're having an issue at a single library system where checkins are failing - you scan the item, and everything hangs on "Retrieving..." and ends in a network or server failure |
| 12:46 |
csharp |
yeah - I can't nail it down though |
| 12:46 |
|
DPearl joined #evergreen |
| 12:47 |
csharp |
knowing our libraries, if this were a consortium-wide problem, we'd know about it |
| 12:47 |
csharp |
only a single library is reporting |
| 12:47 |
csharp |
it's not network, since the same thing happens to me if I create a workstation for their unit |
| 12:49 |
csharp |
"No request was received in 6 seconds, exiting stateful session" - I'm assuming that's a key line |
| 12:49 |
phasefx |
csharp: anything in pg log? |
| 12:50 |
* csharp |
looks |
| 12:52 |
eeevil |
csharp: lots of holds on this title at this library? |
| 12:53 |
gmcharlt |
whee! compare https://www.googleapis.com/books/v1/volumes?q=ISBN:9781937994198 with https://www.googleapis.com/books/v1/volumes?q=isbn:9781937994198 |
| 12:53 |
eeevil |
gmcharlt: wow... different total items, just because s/ISBN/isbn/ ? |
| 12:54 |
csharp |
eeevil: just one hold at this library |
| 12:54 |
eeevil |
csharp: how about at others? |
| 12:54 |
csharp |
this item has been transited to this library to fill a hold |
| 12:54 |
csharp |
no other holds |
| 12:55 |
eeevil |
csharp: well, that kills my theory ;) |
| 12:55 |
gmcharlt |
eeevil: yep, and at present, if one of the items on the list is not embeddable, you can run into a situation where the Google preview badge gets displayed, but clicking on it doesn't display the preview becomes the wrong volume is chosen |
| 12:55 |
* gmcharlt |
is putting a patch together |
| 12:55 |
csharp |
phasefx: I don't see any UPDATE messages logged in our PG logs :_/ |
| 12:55 |
phasefx |
gmcharlt: eeevil: looks like one returns what is essentially a metarecord and the other a specific record? |
| 12:56 |
gmcharlt |
phasefx: Google's API doc is slient on the matter, alas |
| 12:56 |
mmorgan1 |
csharp: Did you try aborting the transit on that item? |
| 12:56 |
dbs |
gmcharlt: https://www.googleapis.com/books/v1/volumes?q=isbn:ebay vs. https://www.googleapis.com/books/v1/volumes?q=ISBN:ebay |
| 12:56 |
dbs |
I think ISBN: is getting quasi-ignored? |
| 12:57 |
csharp |
mmorgan1: no I haven't |
| 12:57 |
phasefx |
dbs: I think you're right. try foo:9781937994198 |
| 12:57 |
dbwells |
I agree with dbs, it looks like this is the same stuff: https://www.googleapis.com/books/v1/volumes?q=9781937994198 |
| 12:57 |
dbs |
https://www.googleapis.com/books/v1/volumes?q=ISBN: returns neat stuff :) |
| 12:57 |
gmcharlt |
keyword vs actual ISBN search, it seems |
| 12:58 |
mmorgan1 |
I think we have had it happen that is an item is in transit to fill a hold, and the hold is cancelled along the way, it's stuck til the transit it aborted. |
| 12:58 |
csharp |
mmorgan1: hmm - I'll have a look |
| 12:58 |
dbs |
someone point google at QueryParser, stat! |
| 12:59 |
dbs |
gmcharlt: and naturally we're using ISBN: in ac_google_books.tt2 eh? |
| 12:59 |
eeevil |
dbs++ |
| 13:00 |
csharp |
mmorgan1: nope this one is still an active hold for the patron :-/ |
| 13:01 |
dbwells |
It seems awfully odd that '9781937994198' would be a keyword for so many random things. Strange Google voodoo gone bad. |
| 13:02 |
* dbs |
will put a branch together, in any case |
| 13:03 |
gmcharlt |
dbs: no, changing case won't fix it |
| 13:03 |
dbs |
oh, wait, https://developers.google.com/books/docs/dynamic-links uses ISBN: examples |
| 13:03 |
gmcharlt |
dbs: wait five minutes, and I will push my branch and you can look at it |
| 13:03 |
dbs |
gmcharlt: okay |
| 13:07 |
|
dMiller joined #evergreen |
| 13:12 |
gmcharlt |
dbs: https://bugs.launchpad.net/evergreen/+bug/1254816 |
| 13:12 |
pinesol_green |
Launchpad bug 1254816 in Evergreen "embedded Google Book preview can fail to be displayed" (affected: 1, heat: 6) [Undecided,New] |
| 13:15 |
dbs |
gmcharlt: ah, nice |
| 13:42 |
csharp |
okay - looks like I figured it out - the library was not "open" today, and that was causing the closed date overlap check to take longer than it needed to |
| 13:42 |
|
dMiller joined #evergreen |
| 13:42 |
bshum |
csharp: Well that's.... special |
| 13:42 |
csharp |
looks like it timed out after 6 seconds and running that call via srfsh took (+ |
| 13:42 |
csharp |
s/(+/9+/ |
| 13:43 |
csharp |
yeah - weird |
| 13:43 |
csharp |
I set their hours to 12am - 1am and the checkin worked |
| 13:48 |
|
mjingle joined #evergreen |
| 14:08 |
eeevil |
csharp: if you can capture the full SQL I'll take a look ... maybe there's a simple tweak |
| 14:09 |
* rfrasur |
just sent her first message to someone in Google helpouts. |
| 14:16 |
|
mmorgan1 left #evergreen |
| 14:17 |
|
mmorgan joined #evergreen |
| 14:25 |
|
stevenyvr2 joined #evergreen |
| 14:29 |
dbs |
rfrasur: as a client or provider? |
| 14:29 |
* dbs |
submitted an application, but review suggested he needs to tweak his application a bit |
| 14:30 |
rfrasur |
dbs: client. I need an instructor for this summer. Somebody familiar with Scratch (beyond my 2 hours 4 years ago) and Raspberry Pi and maybe programming arduino boards. |
| 14:30 |
dbs |
rfrasur: ah, cool! good luck |
| 14:31 |
rfrasur |
ty. There's been some rumbling in library land about the service anyway, so I figured it could kill a few birds with a cheap little stone. |
| 14:37 |
|
sseng_ joined #evergreen |
| 14:38 |
bshum |
Callender: I tracked back an issue with 6707d536. Apparently, the message "No configured Email address" doesn't go away if you add a different user that actually has an email address. |
| 14:38 |
pinesol_green |
[evergreen|Steven Callender] Added in warning message when placing hold with no email address. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6707d53> |
| 14:38 |
bshum |
So it appears to the staff like it gets stuck |
| 14:39 |
phasefx |
bshum: he's on vacation |
| 14:39 |
bshum |
phasefx: Ah all good. I'll go ahead and file a bug later once I poke more on it :) |
| 14:39 |
csharp |
@summon Callender |
| 14:39 |
pinesol_green |
csharp: You probably want hard-boiled eggs. |
| 14:39 |
bshum |
For the time being, I think I'll revert that change so that libraries stop calling me about it. |
| 14:39 |
csharp |
"Mork calling Orson..." |
| 14:39 |
|
sseng joined #evergreen |
| 14:40 |
bshum |
I think it's something in staff.js that updates the ctx.user.email variable and it doesn't update because the message had already been applied and the javascript doesn't know to replace it. Or something like that. |
| 16:03 |
|
mrpeters joined #evergreen |
| 16:26 |
Bmagic |
Could someone point me in the right direction - I need to discover an opensrf command to recalc a users penalties, my start is: my $script = OpenILS::Utils::Cronscript->new; my $authtoken = $script->authenticate( |
| 16:29 |
jeff |
Bmagic: you're probably looking for open-ils.actor.user.penalties.update which takes an auth token and a user id (actor.usr.id) |
| 16:30 |
jeff |
Bmagic: were you the one last week who was trying to ensure that patrons with a single overdue item were blocked? |
| 16:31 |
Bmagic |
jeff: hello again, great! Yes, that's me |
| 16:31 |
Bmagic |
jeff: If I get this thing working, I could commit it to your github repo if you want |
| 16:32 |
jeff |
if i remember correctly, the issue was that the overdues were within the grace period, and therefore (intentionally or not) were not triggering the penalty. |
| 16:33 |
jeff |
i suppose since manually triggering a re-calc of the penalty results in the penalty being applied, the fact that it isn't being automatically applied is the bug, not intended behavior. |
| 16:33 |
jeff |
good to spell it out, though. bug + docs. :-) |
| 16:34 |
jeff |
Bmagic: what approach did you decide to use? |
| 16:34 |
Bmagic |
jeff: the command would be something like? my @results = $session->request("open-ils.user.penalties.update",$auth,$usrid); ? |
| 16:35 |
|
brent_sage joined #evergreen |
| 16:35 |
Bmagic |
jeff: I really have no idea how to code for opensrf |
| 16:35 |
jeff |
Bmagic: yes, but be sure you have the method correct: open-ils.actor.user.penalties.update |
| 17:11 |
|
mmorgan left #evergreen |
| 17:14 |
|
mllewellyn left #evergreen |
| 18:21 |
eeevil |
jeff: the fact that a recalc applies the penalty is just a side effect of the fact that it's (currently) only run from specific entry points in the code. IOW, it only runs when the middle layer logic says it should, and running it directly within grace period is "undefined" |
| 18:25 |
eeevil |
put another way, grace period is (as currently designed and defined) intended to trump penalties ... so, no bug there. but perhaps an opportunity for making penalty generation choices more granular. |
| 18:52 |
|
hopkinsju joined #evergreen |
| 18:56 |
|
stevenyvr2 left #evergreen |
| 19:14 |
|
mtcarlson joined #evergreen |
| 19:18 |
|
mtj_ joined #evergreen |
| 19:36 |
jeff |
then the bug is that refreshing the patron gets the penalty. :-) |
| 20:47 |
|
mrpeters left #evergreen |
| 21:32 |
|
stevenyvr2 joined #evergreen |
| 21:32 |
|
stevenyvr2 left #evergreen |
