| Time |
Nick |
Message |
| 07:36 |
|
Shae joined #evergreen |
| 07:40 |
|
rjackson_isl joined #evergreen |
| 07:44 |
|
mrpeters joined #evergreen |
| 08:03 |
|
akilsdonk joined #evergreen |
| 08:12 |
|
Newziky joined #evergreen |
| 08:13 |
|
_bott_ joined #evergreen |
| 08:14 |
|
jboyer-isl joined #evergreen |
| 08:20 |
|
collum joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:43 |
|
RoganH joined #evergreen |
| 08:47 |
|
ericar joined #evergreen |
| 08:51 |
|
mrpeters joined #evergreen |
| 08:53 |
|
Dyrcona joined #evergreen |
| 09:13 |
|
maryj joined #evergreen |
| 09:18 |
jeff |
interesting behavior wrt Pending Patrons staff client interface. I have (at least) one machine where loading Pending Patrons stops at 64 patrons (excluding some of the most recent), but hitting Refresh loads them all. The limit is set to 300 in the staff client. |
| 09:19 |
jeff |
Oh, and now my other client (that I thought was not exhibiting this behavior) is doing the same thing. :-) |
| 09:19 |
|
pmurray joined #evergreen |
| 09:26 |
mmorgan |
Never had that many pending patrons. A few of our libraries have just begun to use self registration. |
| 09:26 |
|
sarabee joined #evergreen |
| 09:27 |
jeff |
ah. we pretty much use it exclusively, especially at our main branch. |
| 09:28 |
mmorgan |
Impressive! Do you have kiosks in the library for patrons to use to fill out the form? |
| 09:30 |
jeff |
yes. also, from home. i suspect that the in-building use case is most common. |
| 09:31 |
jeff |
i think most people filling it out from home are actually existing patrons who don't know their password/etc. |
| 09:31 |
jeff |
form is the "Register" button at the top of https://catalog.tadl.org/ -- feel free to fill it out to see how the flow works, it won't cause any issue on this end. |
| 09:32 |
jeff |
though keep in mind that if you fill in an email address and the "Stay connected! Receive news, events, and other email updates from your library" button is checked you'll get a copy of our monthly newsletter via email. :-) |
| 09:33 |
|
KiwiGeek joined #evergreen |
| 09:34 |
jeff |
I'd like to enable more things to be possible from pending patrons -- stat cats, user settings, etc. I forget which parts need backend support, and which we simply didn't wire up. |
| 09:36 |
mmorgan |
I noticed that newsletter checkbox. Great idea to put that on the form. Does that checkbox fill a field in user_stage? |
| 09:37 |
KiwiGeek |
Hi there - I'm completly out of my depth, and probably asking a mindboggingly simple question. However - we're trying to evaluate Evergreen for a small University. The Evergreen admin account that I set up on installation works fine, but I'm trying to set up other users in the system for them to be able to evaluate. I added a user, and made her a Local Administrator. Every time she logs |
| 09:37 |
KiwiGeek |
in, however, she receives a prompt about needing "VIEW_BILLING_TYPE" permissions. I checked in the user permission editor, and that permission is missing a depth. If I set it to "System" or "Branch", and hit save, nothing seems to actually save. the combo box goes back to "-- Select One --" on the page refresh, and the permissions seems to not be applied. If anyone can offer any assistance, |
| 09:37 |
KiwiGeek |
or guidance, it would be much appreciated. |
| 09:38 |
jeff |
mmorgan: Nope -- it just ensures that the supplied email address is subscribed to the proper list with the service we use for sending those mailings. Formerly we used MadMimi, now we use MailChimp. |
| 09:39 |
mmorgan |
jeff: Even better! |
| 09:39 |
jeff |
KiwiGeek: Welcome! First thing I would check is that the user in question has a "Working Location" set. |
| 09:40 |
jeff |
KiwiGeek: You can bring up the user account by searching or by barcode, then from the Other button/menu, select "User Permission Editor". |
| 09:40 |
KiwiGeek |
Yes, she does. Assuming that it's on the same page :) |
| 09:40 |
KiwiGeek |
I have her in both the System OU, and the Branch OU; neither seemed to make a difference. |
| 09:41 |
jeff |
Ah. I finished reading your description of the "missing depth" symptom. One moment. |
| 09:46 |
KiwiGeek |
jeff: certainlu - I appreciate any help you can give me |
| 09:47 |
jeff |
KiwiGeek: what version of Evergreen are you evaluating? |
| 09:47 |
KiwiGeek |
2.8.1 |
| 09:51 |
jeff |
KiwiGeek: When you're making changes to this new Local Administrator user, are you using the initial admin user that you set up during installation? |
| 09:52 |
KiwiGeek |
jeff: yes sir. |
| 10:05 |
jeff |
KiwiGeek: Do you think you've changed any of the example organizational unit structure, and/or changed any of the stock permissions? |
| 10:06 |
jeff |
KiwiGeek: I was hoping I could reproduce the issue you encountered, but no such luck. It might be something simple that I'm missing. Others may jump in with other ideas. |
| 10:06 |
kmlussier |
Good morning #evergreen |
| 10:09 |
bshum |
jeff: KiwiGeek: same idea I first thought of too. Like renamed/restructured org units and no autogen/restart |
| 10:09 |
jeff |
KiwiGeek: In the meantime, I'm going to fall back on some "usuals" -- try exiting out of the staff client, try re-running autogen, try restarting the server-side components. |
| 10:09 |
jeff |
bshum: morning! |
| 10:09 |
jeff |
kmlussier: morning! |
| 10:11 |
KiwiGeek |
I did change the OU structure, but I reran autogen.sh afterwards. Are there any limitations to the structure that I'm missing? By way of explaination, we would be a university with three campuses. So I created the name of the university as the System OU type, and then added three Branch types as children of it (one for each of the three campuses). |
| 10:12 |
KiwiGeek |
In OU types, I simply have "System", and then "Branch" |
| 10:12 |
KiwiGeek |
I guess I'll try running autogen.sh again. |
| 10:12 |
kmlussier |
KiwiGeek: I think you still need to keep that consortium level, even though you're not running on consortium. |
| 10:13 |
Dyrcona |
Anyone ever seen this in their SIP logs: Can't locate Socket/Linux.pm ? |
| 10:13 |
Bmagic |
Dyrcona: Yes! |
| 10:13 |
Bmagic |
I see that all the time |
| 10:13 |
Dyrcona |
I know what it means and how to fix it. I just wonder if we're missing a dependency. |
| 10:13 |
KiwiGeek |
kmlussier: Okay, I'll try to get that added again. Is autogen by itself enough, or do I also need to restart apache, memcached and ejabberd? |
| 10:13 |
Bmagic |
I think I ended up installing the package at some point |
| 10:15 |
Dyrcona |
Bmagic: Ubuntu 14.04? |
| 10:16 |
Bmagic |
Dyrcona: 12.04 |
| 10:16 |
|
collum joined #evergreen |
| 10:16 |
Dyrcona |
Bmagic: Thanks! |
| 10:20 |
Bmagic |
KiwiGeek: We give a single library a system all to itself for logical and circ rule reasons. It also gives them a space to grow. We name the system something similar to the branch. Changing the org tree requires autogen.sh to run and it may not be a bad idea to add the -u switch. |
| 10:22 |
bshum |
Yes restart apache after autogen. |
| 10:23 |
Dyrcona |
bshum: You don't have to do that, it turns out. |
| 10:24 |
* bshum |
shrugs |
| 10:25 |
|
collum joined #evergreen |
| 10:31 |
|
BigRig joined #evergreen |
| 10:33 |
Dyrcona |
Anyone out there have libraries with 3M self checks, and have you ever had a situation where SIP worked for PC reservation type systems but not for self checks? |
| 10:34 |
dbs |
Dyrcona: no PC reservations here, but we had to roll back to a previous version of the self-check code to make our 3M self-check work |
| 10:35 |
Dyrcona |
dbs: How recent was that, and do you have git tags handy? |
| 10:35 |
dbs |
that said, the demagnetizer on our self-check machine died and is now on mothballs until we decide it's worthwhile resurrecting it |
| 10:35 |
Bmagic |
Dyrcona: Be sure and make the return 'OK'! /usr/local/share/perl/5.14.2/OpenILS/SIP/Patron.pm sub screen_msg { return 'OK'; |
| 10:35 |
bshum |
Heh |
| 10:35 |
dbs |
Dyrcona: we upgraded January 2015, I'll check the irc logs to see where I complained about it |
| 10:36 |
Dyrcona |
What I am seeing on the server logs is they connect, logged in, and then nothing. |
| 10:36 |
Bmagic |
Is there any reason that the base.tt2 wants to include openils_dojo.js which doesnt exist? |
| 10:36 |
Dyrcona |
We never ever get a checkout attempt or anything like that. |
| 10:37 |
dbs |
http://irc.evergreen-ils.org/evergreen/2015-01-05#i_147559 is where I started IRC thought-dumping |
| 10:39 |
dbs |
more meanderings around http://irc.evergreen-ils.org/evergreen/2015-01-05#i_147559 |
| 10:39 |
jeff |
Bmagic: that's the optional bundle-o-javascript which may or may not exist -- for example, if you didn't create it. |
| 10:40 |
dbs |
http://irc.evergreen-ils.org/evergreen/2015-01-05#i_147559 -- looks like csharp was getting in on the fun too |
| 10:40 |
Bmagic |
jeff: I asked without searching launchpad. Dumb move. Here it is https://bugs.launchpad.net/evergreen/+bug/1076582 |
| 10:40 |
pinesol_green |
Launchpad bug 1076582 in Evergreen "Documentation explaining openils_dojo.js" (affected: 1, heat: 8) [Low,Confirmed] |
| 10:40 |
Dyrcona |
Bmagic: Going back to my earlier SIP question, I think this is the commit that makes Socket::Linux a requirement without possibly realizing it: 6d1ae5319e0c7ba07e20aa14805fd015dd40439e |
| 10:40 |
pinesol_green |
[sipserver|Mike Rylander] LP#1042850: Add TCP-level keepalive - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=6d1ae53> |
| 10:40 |
dbs |
http://irc.evergreen-ils.org/evergreen/2015-01-22#i_151722 |
| 10:40 |
dbs |
ARGH Chrome URL not-copy/paste I hate you |
| 10:41 |
dbs |
http://irc.evergreen-ils.org/evergreen/2015-01-06#i_147812 |
| 10:42 |
Bmagic |
Dyrcona: interesting |
| 10:42 |
|
collum joined #evergreen |
| 10:43 |
Dyrcona |
dbs Bmagic csharp: When you had trouble with the 3-M self checks did the self check have ERR_SIPBL_ILS_CAPABILITY on the screen? |
| 10:44 |
dbs |
That does not ring a bell |
| 10:44 |
Dyrcona |
I think we have something else going on. |
| 10:44 |
Bmagic |
Dyrcona: It may have but I do not recall |
| 10:45 |
Bmagic |
I get this javascript error when loading Org Unit Proximity Adjustments UI Error: Error: fieldmapper.aou.LoadOrg(): No org unit found with ID Source File: oils://remote/js/dojo/dojo/dojo.js Line: 72 |
| 10:46 |
dbs |
Dyrcona: we're at SIPServer c8e2ac5fe68961219095 running Evergreen rel-2.7 |
| 10:46 |
Bmagic |
Anyone else get this error when loading that UI (with an empty table. IE - no proximity rows yet) |
| 10:49 |
jeff |
Dyrcona: what version 3M SelfCheck units do you have? Phoenix, or QuickConnect, or something earlier? |
| 10:50 |
berick |
Bmagic: hm, you have no rows in actor.org_unit_proximity ? |
| 10:51 |
berick |
or none in _adjustment |
| 10:51 |
berick |
I have no rows in actor.org_unit_proximity_adjustment and I do not get the error in master |
| 10:51 |
Dyrcona |
jeff: I have no idea. They are not "mine." And, my various members probably have some of all the different versions. |
| 10:53 |
Bmagic |
beric: _adjustment |
| 10:54 |
Bmagic |
berick: It's tripping over loading the Org unit dropdown menu I think |
| 10:56 |
berick |
Bmagic: does it render OK if you load another UI like the Billing Types UI? |
| 10:59 |
jeff |
Dyrcona: ah. drat. and alas, there are no protocol-level headers to tell you this. :-) |
| 10:59 |
kmlussier |
dkyle1: We have some people who were interested in trying your Smart Float branch at bug 1305964. Is that something that's ready for testing or are you still working on it? |
| 10:59 |
pinesol_green |
Launchpad bug 1305964 in Evergreen "Smart Float: self balancing floating collections" (affected: 1, heat: 8) [Wishlist,Triaged] https://launchpad.net/bugs/1305964 - Assigned to Doug Kyle (dkyle) |
| 11:04 |
jeff |
rebase from 2.2 era opac templates to 2.7 era opac templates went off without complaint or catastrophe. hooray! |
| 11:09 |
dkyle1 |
kmlussier: the Smart Float branch is ready for testing, and I'm not working on it at the moment, it has been stable for GRPLs needs. Do you know if those interested have the same shelving locations across orgs that want to Smart Float? |
| 11:10 |
kmlussier |
dkyle1: I'll defer to mmorgan |
| 11:12 |
mmorgan |
dkyle1: Our shelving locs generally are not consistent, but for the items that will float, they potentially could be, if required. |
| 11:12 |
Bmagic |
berick: yes, billing types loads fine |
| 11:16 |
|
mllewellyn joined #evergreen |
| 11:21 |
dkyle1 |
mmorgan: homogeneous shelving locs would be best, but I had some stuff in my generic version to map various org/locs into single smart float configs. I think it was lightly tested working but I was not totally happy with the speed of that function. It has been a while, I need to revisit and look for any uncommited changes. |
| 11:26 |
kmlussier |
Seems to load cleanly on master. |
| 11:27 |
kmlussier |
dkyle1: I'm loading it on a server where mmorgan can take a look at it. But you might want to remove yourself as the assignee on the bug and add a pullrequest tag if you think it's ready. |
| 11:27 |
berick |
Bmagic: no idea what the problem is :( if it were me, i'd have to start digging into the code at this point |
| 11:27 |
* kmlussier |
shifts her attention to all the Sanbox requests we received. :) |
| 11:29 |
mmorgan |
kmlussier: Thanks! |
| 11:30 |
mmorgan |
dkyle1: Thanks, I'll poke at it on kmlussier's test server. |
| 11:37 |
dkyle1 |
kmlussier: I really don't know how ready a feature should be for a pullrequest tag, for example, it has no client side exposure |
| 11:37 |
berick |
dkyle1: pullrequest means you think it's done |
| 11:38 |
berick |
and ready for merging into master |
| 11:38 |
dkyle1 |
mmorgan: ok, let me know what you think, or questions you have |
| 11:38 |
|
ericar joined #evergreen |
| 11:39 |
dkyle1 |
berick: so if a new feature with no client side configuration code is ready enough for merging into master... don't know how commiters think about that |
| 11:41 |
berick |
dkyle1: what's the LP? |
| 11:41 |
berick |
the bug #, i mean |
| 11:41 |
jeff |
bug 1305964 |
| 11:41 |
pinesol_green |
Launchpad bug 1305964 in Evergreen "Smart Float: self balancing floating collections" (affected: 1, heat: 8) [Wishlist,Triaged] https://launchpad.net/bugs/1305964 - Assigned to Doug Kyle (dkyle) |
| 11:41 |
dkyle1 |
jeff: beats me to it |
| 11:44 |
Bmagic |
berick: That's where I was going to go, but I just inserted the row manually. Luckily no one uses that interface, so I can safely ignore it for now |
| 11:51 |
berick |
dkyle1: ok, so it's not done as noted in the ticket, so it's not ready for a pullrequest. however, if you see value in having the DB components without the config UI (and don't expect to create one any time soon), then I think it's fair to ask around to see if it can be merged without. |
| 11:51 |
berick |
that would be unusual though |
| 11:51 |
berick |
Bmagic: i see, so just adding a row fixes it.. odd |
| 11:51 |
jeff |
there are plenty of examples of "backend plumbing is there, no client-side support yet", but none recent that i can think of. :-) |
| 11:52 |
dkyle1 |
berick: ok, thanks |
| 11:52 |
berick |
jeff: yeah, there are, which is why think there should be some flexibility there |
| 11:53 |
jeff |
and there are/were a handful of "broken backend support is there, breakage not noticed because nothing uses it yet" |
| 11:56 |
Bmagic |
berick: No, adding the row doesn't fix the interface. I think the interface is broken around the Org unit dropdown |
| 11:56 |
Bmagic |
berick: the point is, I don't need to use the interface. |
| 11:56 |
berick |
Bmagic: oh, gotcha, you just bypasswed the interface... |
| 11:56 |
berick |
er, bypassed |
| 11:57 |
dkyle1 |
jeff: and other committers.. I would certainly like to see it merged, it adds a little more mess to the the Circulate code but is mostly pgsql code off by itself |
| 12:05 |
mmorgan |
dkyle1: You mentioned earlier that you were not happy with the speed, would that be with the checkin function? |
| 12:07 |
kmlussier |
Bmagic: On bug 1194860 , it looks like we have a signoff, but you have assigned it to yourself. Are you planning to do further work on it? |
| 12:07 |
pinesol_green |
Launchpad bug 1194860 in Evergreen ""You have permission to override some of the failed holds." appearing when it should not for patrons in the OPAC" (affected: 8, heat: 36) [Medium,Confirmed] https://launchpad.net/bugs/1194860 - Assigned to Blake GH (blake-j) |
| 12:08 |
Bmagic |
kmlussier: no, I just saw people assigning things and I figured it was protocol to have it assigned |
| 12:09 |
kmlussier |
Bmagic: Only if you're planning to work on it or test it. I can add a signedoff tag to it, which might increase its visibility the next time a core committer is looking to merge code. |
| 12:10 |
Bmagic |
kmlussier: Ok, do I need to remove myself? |
| 12:10 |
kmlussier |
Bmagic: Sure. |
| 12:17 |
dkyle1 |
mmorgan: a speed issue would be seen at checkin. the main function to time is smart_float.destination. this issue was when using the smart_float.loc_or_group function in the destination function - if I recall, have not had time to revisit yet. |
| 12:18 |
mmorgan |
dkyle1: ok, thanks. I'll keep that in mind while poking. |
| 12:28 |
kmlussier |
jeff: If you have no objections, I think I'll remove you as assignee from bug 1174498 |
| 12:28 |
pinesol_green |
Launchpad bug 1174498 in Evergreen "Payment by billing type breakdown" (affected: 7, heat: 38) [Wishlist,In progress] https://launchpad.net/bugs/1174498 - Assigned to Jeff Godin (jgodin) |
| 12:29 |
bshum |
I object, no I strenuously object... |
| 12:31 |
kmlussier |
OK, then, I guess I'm a bit confused on the status of that bug then. |
| 12:31 |
bshum |
kmlussier: Sorry, that's my poor attempt at quoting. |
| 12:31 |
bshum |
It's a line from a Few Good Men |
| 12:31 |
RoganH |
kmlussier: a few good men |
| 12:32 |
RoganH |
bshum: beat me to it |
| 12:32 |
kmlussier |
bshum: Have you not learned yet that I remember very few movie quotes? :) |
| 12:32 |
bshum |
http://quotegeek.com/quotes-from-movies/a-few-good-men/1167/ |
| 12:32 |
bshum |
Anywho |
| 12:33 |
kmlussier |
I saw that movie 23 years ago. How am I to remember these things? |
| 12:34 |
Dyrcona |
I've never seen that movie. |
| 12:34 |
bshum |
My dad watches that movie at least once a year. |
| 12:34 |
bshum |
Probably two or three times |
| 12:34 |
kmlussier |
I guess I didn't like it as much as your dad did. ;) |
| 12:35 |
* bshum |
actually reads the bug and tries to do something real for the community instead of quoting nonsense. |
| 12:36 |
kmlussier |
OK, my last question inspired by the bug squashing requests... |
| 12:37 |
kmlussier |
Bmagic: We have a request to test bug 1440148 . I was planning to load it on a MassLNC server, but it looks like the code is actually combined with bug 1331174? |
| 12:37 |
pinesol_green |
Launchpad bug 1440148 in Evergreen "Long overdue Items out TPAC OPAC display My Account" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1440148 - Assigned to Michele Morgan (mmorgan) |
| 12:37 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 4, heat: 18) [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 12:37 |
bshum |
kmlussier: Based on my read of that bug, I would set it to confirmed/triaged for status and remove jeff as the worker, since Bmagic's done some reworking at that point. |
| 12:37 |
kmlussier |
bshum: OK, thanks for your take on it. I'll do that now. |
| 12:40 |
Bmagic |
kmlussier: Those 2 bugs conflict. 1440148 is a tiny bug with a tiny fix. I prefer1331174. |
| 12:40 |
Dyrcona |
lp 1331174 |
| 12:40 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 4, heat: 18) [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 12:41 |
Dyrcona |
oops. missed it was already in the channel. |
| 12:41 |
Dyrcona |
too busy to keep up. |
| 12:41 |
Bmagic |
bshum: which bug are you referring to? Also, is mmorgan working on 1440148 ? |
| 12:41 |
kmlussier |
Bmagic: She was the one who requested the Sandbox to test it. |
| 12:43 |
bshum |
Bmagic: Oh I was referring back to kmlussier's bug she mentioned earlier in the scrollback, bug 1174498 |
| 12:43 |
pinesol_green |
Launchpad bug 1174498 in Evergreen "Payment by billing type breakdown" (affected: 7, heat: 38) [Wishlist,Triaged] https://launchpad.net/bugs/1174498 |
| 12:46 |
|
Shae joined #evergreen |
| 12:52 |
jeff |
mmpbbt needs work, i think. i can take a look at what Bmagic has found. |
| 12:52 |
jeff |
because i suspect that we're each running it in production in different versions. |
| 12:53 |
jeff |
and i know that there are issues with regard to future-dated billings (overdues) which may or may not have been addressed in Bmagic's version. |
| 12:54 |
kmlussier |
Bmagic: OK, what I'll do is load the code from working/user/blake/LP1440148_Long_overdue_Items_out_TPAC_OPAC_display_My_Account so that mmorgan can test it. However, once it goes in, I think you'll need to rebase the other branch. |
| 12:57 |
jeff |
overall, i don't know if the best approach is to teach everything to special-case future-dated billings, or to eliminate them. |
| 12:57 |
jeff |
at this point, I don't know which will be more painful. :P |
| 12:59 |
|
bmills joined #evergreen |
| 13:00 |
|
bmills left #evergreen |
| 13:04 |
Bmagic |
kmlussier: I want to add that 1331174 solves 1440148. I think that was your question |
| 13:08 |
|
sandbergja joined #evergreen |
| 13:10 |
* dbs |
tries to remember what "[type]" can be in srfsh login |
| 13:12 |
dbs |
python source to the rescue! |
| 13:12 |
dbs |
"@param login_type: one of 'opac', 'temp', or 'staff' (default: 'staff')" |
| 13:23 |
berick |
i bet 'persist' would work too |
| 13:25 |
dbs |
mmm. now trying to figure out why one of our libraries is throwing 'CIRC_PERMIT_BAD_KEY' on checkout attempts |
| 13:26 |
berick |
dbs: what version are you on? |
| 13:27 |
dbs |
berick: rel_2_7 |
| 13:27 |
berick |
odd.. checkout.full bypasses the permit-key dance |
| 13:27 |
berick |
and i thought everythign was using checkout.full now |
| 13:27 |
dbs |
and this is using checkout.full |
| 13:28 |
dbs |
request open-ils.circ open-ils.circ.checkout "session-key", {"barcode":"30012000047398","patron":132422},1 |
| 13:28 |
mmorgan |
Bmagic: kmlussier: So is there no need then to test 1440148, since 1331174 fixes it? Should 1440148 be marked as a duplicate? |
| 13:28 |
dbs |
err, no |
| 13:28 |
dbs |
heh |
| 13:29 |
dbs |
I had fallen back to trying plain .checkout because .checkout.full was failing with ye olde "*Network or server failure" in the client |
| 13:29 |
dbs |
and checkout.full from srfsh is doing the same timeout |
| 13:30 |
dbs |
OpenSRF eventually returns "<500> No active transaction to roll back" |
| 13:31 |
dbs |
switch to a different library / workstation and the same barcode + user works just fine |
| 13:32 |
berick |
ah, ok, so the call is dying on the back end |
| 13:33 |
dbs |
yeah, and trying to trace it is frustrating; nothing useful turning up in the logs, which is why I hoped srfsh might give me more of a clue |
| 13:34 |
* dbs |
sets daily reminder to GET THE HELL OVER TO in-db CIRC |
| 13:41 |
gmcharlt |
2.7.5 OS X client now available - http://evergreen-ils.org/downloads/Evergreen_2_7_5_osx.dmg |
| 13:48 |
kmlussier |
mmorgan / Bmagic: My personal opinion is that they should remain as two distinct bugs with different branches because they are addressing different issues. But others can chime in if they think it's okay to address both issues in one branch. |
| 13:49 |
kmlussier |
Also, I think one is a bug fix that we'll want to backport and another is a feature that won't be backported. We would need separate branches to make sure each is handled appropriately. |
| 13:51 |
dbs |
Figured it out. actor.hours_of_operation was set to 00:00:00 - 00:00:00 for each day of the week |
| 13:51 |
dbs |
and that, in turn, because our single source of hours information at http://laurentian.ca/library-hours was returning nothing for the library in question (checking off UofS turns nothing up) |
| 13:55 |
Bmagic |
kmlussier: That makes sense. |
| 13:55 |
|
gsams joined #evergreen |
| 13:57 |
kmlussier |
Bmagic: ugh. I thought I had sent you a link to the Sandbox requests. I'll send it to you in a pm now. Sorry about that! |
| 13:58 |
Bmagic |
kmlussier: No problem, I was at lunch anyway |
| 14:07 |
* dbs |
wonders if in-db circ would return more useful info given the same situation |
| 14:09 |
|
KiwiGeek left #evergreen |
| 14:25 |
|
drigeny joined #evergreen |
| 14:27 |
bshum |
Hmm, did we ever file an LP for web selfcheck to add something to also reset the timeout whenever a circ happens and not just when clicking around the UI |
| 14:27 |
* bshum |
can't seem to find anything, but vaguely remembers talking about it post-conference with someone. |
| 14:30 |
jeff |
does not ring any bells with me. |
| 14:30 |
jeff |
how about that wishlist bug to make the web based selfcheck use SIP2 on the backend? |
| 14:31 |
bshum |
jeff: That doesn't sound familiar to me, but no doubt someone might like that? :) |
| 14:39 |
|
bmills1 joined #evergreen |
| 14:41 |
eeevil |
jeff: SHUSH |
| 14:48 |
jboyer-isl |
jeff: that's some reddit/Something Awful level trolling right there. |
| 14:52 |
jeff |
hey, if we can do protobuf over websockets, we should be able to do SIP2 over websockets. |
| 14:53 |
jeff |
or perhaps SIP2 over protobuf over websockets. |
| 14:53 |
Dyrcona |
Can we just stick a fork in SIP2. |
| 14:53 |
mmorgan |
kmlussier: Bmagic: Yes, that makes perfect sense. |
| 14:53 |
Dyrcona |
Only 3M clients are not working. |
| 14:53 |
jboyer-isl |
Over TCP via carrier pigeon |
| 14:55 |
jeff |
Dyrcona: Can you share the relevant details of your SIP setup? I might be able to make time to test here -- where i can control both the client and the server. |
| 14:55 |
jeff |
Dyrcona: time and ability to pull a selfcheck unit from normal operation would be the only potential blockers there. |
| 14:56 |
Dyrcona |
jeff: We basically run stock on Ubunutu 14.04. We mad a profile for self checks, a profile for PC res, and a profile for a delivery application. |
| 14:56 |
Dyrcona |
jeff: The self check profile is basically the example profile. |
| 14:57 |
Dyrcona |
Here's the thing: a non-3M self check client works just fine. |
| 14:57 |
jeff |
have you isolated a particular version of sipserver that works and doesn't work, and do things behave differently between PreFork and Multiplex SIPServer personalities? |
| 14:57 |
Dyrcona |
Boopsie's check out over their cell phone app works just fine. |
| 14:58 |
jeff |
re-phrasing the first part... can you tell when things broke for you? |
| 14:58 |
Dyrcona |
No. |
| 14:58 |
Dyrcona |
Other than, it worked fine until we set up the new servers last night. |
| 14:58 |
Dyrcona |
We've only used PreFork, and we even removed the multiplex code for a bit, but it made no difference. |
| 14:59 |
Dyrcona |
I've been jumping around so much today that I haven't had time to test everything. |
| 14:59 |
bshum |
jboyer-isl: Sigh, so now CollectionHQ is asking me about adding in-house use circ to the counts. |
| 14:59 |
* jeff |
nods |
| 14:59 |
Dyrcona |
I also have 36 libraries, so I can't just up and restart it whenever I feel like it. |
| 15:00 |
jeff |
bshum: that's suspiciously similar to a ticket that we have open with CollectionHQ where their response was essentially "just add them as the last field to your extract so it's easier" |
| 15:00 |
jeff |
i wish they didn't seem to ad-hoc about things. |
| 15:01 |
jeff |
i see significant value/advantage for both libraries and them in having one format for Evergreen -> CHQ extracts. :P |
| 15:01 |
jeff |
but so far, the best information i've gotten out of them has been from not-them-at-all. |
| 15:02 |
jeff |
and it contained a document that said (paraphrased) "we intentionally are omitting the data format here because we don't want anyone to change it because it might break existing setups" |
| 15:02 |
jeff |
sorry. that's a rant for another time. |
| 15:04 |
bshum |
jeff: Yeah I'll play with it another day maybe. I figure it's mainly a matter of tweaking the collectionhq schema functions more. |
| 15:04 |
bshum |
And bringing in that additional table/data |
| 15:04 |
|
Newziky left #evergreen |
| 15:06 |
jboyer-isl |
bshum, jeff: Ugh to both counts. "Yeah, wherever you can sneak that field is sounds great." and "Oh, you would like documentation about our export format? Well, maybe don't follow too closely; no one will know what to do with a file delimited the way that document tells you to." |
| 15:06 |
jboyer-isl |
My favorite way to build software! |
| 15:06 |
* jeff |
nods |
| 15:10 |
jeff |
grr. something is breaking/hanging my ssh and/or psql connection between a wheezy and a lenny box. |
| 15:10 |
jeff |
@decide upgrade to wheezy or downgrade to lenny? |
| 15:10 |
pinesol_green |
jeff: Go away, or I'll replace you with a very small shell script! |
| 15:10 |
jeff |
good bot. |
| 16:44 |
|
mrpeters left #evergreen |
| 16:49 |
|
StomproJ joined #evergreen |
| 16:59 |
tsbere |
For reference, this appears to have been one of our major issues with SIP2 today: http://git.evergreen-ils.org/?p=working/SIPServer.git;a=shortlog;h=refs/heads/user/tsbere/server_not_self |
| 17:00 |
* tsbere |
will aim at throwing that on Launchpad tomorrow unless someone decides to just commit it to SIPServer tonight |
| 17:03 |
|
kbutler joined #evergreen |
| 17:04 |
jeff |
tsbere: can you elaborate on "one of"? which symptom did that fix? |
| 17:04 |
jeff |
(and what other symptoms did you encounter -- since I think I only saw one mentioned. :-) |
| 17:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:11 |
|
mmorgan left #evergreen |
| 17:32 |
Bmagic |
berick: Back on that web based column picker. I can have the UI load the copy ID instead of the count and it clues me in that it's "sort of working" see http://slides.mobiusconsortium.org/blake/bill.html |
| 17:36 |
berick |
Bmagic: did you try removing the oils_persist:virtual="true" from the holds_count <field> ? |
| 17:38 |
Bmagic |
berick: yea, that broke the whole thing |
| 17:38 |
Bmagic |
So, I put it back |
| 17:40 |
berick |
fair enough :) |
| 17:42 |
Bmagic |
berick: my current theory is that the web staff client needs to have real db tables, instead of a fabricated view definition inside of the IDL |
| 17:44 |
eeevil |
Bmagic: the web staff client is no different than any other client WRT the IDL |
| 17:44 |
eeevil |
for reference |
| 17:47 |
eeevil |
and virtual="true" is correct. you need that for both might_have and has_many reltype's ... they are not columns on the table, but virtual fields on the class |
| 17:47 |
Bmagic |
eeevil: I have this column working for the xul staff client, so I must be some glue missing for the WBSC that I haven't found yet |
| 17:48 |
eeevil |
it needs to be fleshed in (IIRC) 'local_flesh' ... or, that's a common name for the thing that fleshes objects that are bound for grid display |
| 17:51 |
Bmagic |
eeevil: I will look at that. |
| 17:51 |
berick |
Bmagic: in the staff client, are you using your custom API to retrieve the data or pcrud? |
| 17:51 |
eeevil |
tsbere: I think the first hunk in the patch at e905fa0e27cd54b705b0705872d36903c6b39319 is probably not what you want ... I don't think you want to change that one. but, the printing ones, maybe so... unsure |
| 17:52 |
eeevil |
Bmagic: or, rather, where exactly are you adding your eg-grid-field element? |
| 17:53 |
Bmagic |
berick: yeah, I had to invent a new opensrf call, and that is what I am using in the xul grid interface |
| 17:53 |
Bmagic |
berick: I would have expected something similar in WBSC but haven't found it yet |
| 17:53 |
Bmagic |
eeevil: t_items_out.tt2 <eg-grid-field path="target_copy.holds_count.count" hidden></eg-grid-field> |
| 17:55 |
berick |
the items out UI retrieves data via pcrud, so you'll have to add the field you want to flesh to the flesh_fields structure in items_out.js |
| 17:55 |
berick |
in fetch_circs(). |
| 17:56 |
Bmagic |
berick: ah! There we go |
| 17:56 |
eeevil |
which means you'll probably want to add pcrud as a controller, and add the appropriate <permacrud> block |
| 17:57 |
berick |
yes, what eeevil said |
| 18:03 |
* eeevil |
commutes |
| 18:03 |
tsbere |
jeff: Most of the other issues were related to a filename typo in a SSH ForceCommand file. We make our libraries SSH tunnel their SIP connections. |
| 18:05 |
tsbere |
eeevil: For clarification, the issue was "we were sending 'not logged in' status responses when actually logged in *and* the allow status before login option was not enabled" |
| 18:05 |
tsbere |
eeevil: The first hunk fixed that as the login info is on the SIPServer ($server) object, not the MsgType ($self) object. |
| 18:06 |
tsbere |
Given that no other function in MsgType.pm refers to $self->{account} I changed all the references to $server->{account}. Feel free to double-check them, though. |
| 18:44 |
Bmagic |
berick++ eeevil++ # thank you for all of your help and time! |
| 20:08 |
|
dcook joined #evergreen |
| 20:24 |
|
terminalfool_ joined #evergreen |
| 20:25 |
|
terminalfool_ left #evergreen |
| 20:27 |
|
terminalfool_ joined #evergreen |
| 20:28 |
|
terminalfool_ left #evergreen |
| 20:30 |
|
terminalfool_ joined #evergreen |
| 21:04 |
|
wongon joined #evergreen |
| 23:18 |
|
StomproJ joined #evergreen |
