| Time |
Nick |
Message |
| 00:40 |
|
dcook joined #evergreen |
| 05:19 |
|
gsams joined #evergreen |
| 06:05 |
|
unpriviledged joined #evergreen |
| 07:22 |
|
rjackson_isl joined #evergreen |
| 07:23 |
|
agoben joined #evergreen |
| 07:37 |
|
tarac joined #evergreen |
| 08:21 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
kmlussier joined #evergreen |
| 08:42 |
|
Callender joined #evergreen |
| 09:13 |
|
bos20k joined #evergreen |
| 09:13 |
Dyrcona |
Yay! I get an OPAC on my VM. |
| 09:20 |
Dyrcona |
Hmm.. Undefined event connecting to the websockets SSL port... Self-signed certificate? |
| 09:21 |
Dyrcona |
Works in Chromium, but not in Firefox. |
| 09:34 |
Dyrcona |
Is a regular circulator account supposed to be able to reigster patrons? |
| 09:35 |
Dyrcona |
I tried with br1mtownsend and it just hangs loading the interface. |
| 09:36 |
Dyrcona |
I get this in the console: angular.js:13708 TypeError: Cannot read property 'children' of undefined |
| 09:37 |
Dyrcona |
Yes, I ran autogen.sh. |
| 09:42 |
|
jvwoolf joined #evergreen |
| 09:42 |
|
maryj joined #evergreen |
| 10:01 |
Dyrcona |
Ah, well. Gonna sign out for a bit. |
| 10:05 |
|
dteston joined #evergreen |
| 10:18 |
|
Dyrcona joined #evergreen |
| 10:19 |
Dyrcona |
I think my register patron problem is related to connectby and Pg 9.5. |
| 10:24 |
Dyrcona |
https://bugs.launchpad.net/evergreen/+bug/1568046/comments/10 |
| 10:24 |
pinesol_green |
Launchpad bug 1568046 in Evergreen "Concerto won't load because of problem with permission.grp_ancestors on PostgreSQL 9.5" [Undecided,Fix committed] |
| 10:26 |
* tsbere |
shakes his fist in the general direction of Redmond |
| 10:26 |
Dyrcona |
heh. |
| 10:41 |
|
tarac joined #evergreen |
| 10:43 |
* Dyrcona |
wishes he could edit the comment a little, just to say it is confirming what bott reported. |
| 11:00 |
berick |
@dunno add git diff origin/hamster |
| 11:00 |
pinesol_green |
berick: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
| 11:00 |
berick |
@dunno add git diff origin/hamster |
| 11:00 |
pinesol_green |
berick: The operation succeeded. Dunno #48 added. |
| 11:20 |
|
drigeny joined #evergreen |
| 11:42 |
|
bmills joined #evergreen |
| 11:56 |
* tsbere |
has just added a second SMS carrier that didn't/doesn't come stock with Evergreen and wonders if he should bother making a patch |
| 11:58 |
Dyrcona |
Which one is it? |
| 11:58 |
tsbere |
First was Republic Wireless, the new one is Google Fi |
| 11:59 |
Dyrcona |
Might be worth it. Republic is popular with AARP members, 'cause they give 'em discounts. |
| 12:00 |
* bshum |
really enjoyed Project Fi from Google for the brief months he used it |
| 12:00 |
tsbere |
Admittedly, I haven't been able to test either myself, but I imagine that technically applies to the majority of the entries in that table |
| 12:12 |
tsbere |
Not interested enough to Launchpad it, but if someone else wants to go to that effort: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/sms_carriers |
| 12:14 |
* Dyrcona |
is killing connectby with fire this time. |
| 12:32 |
* berick |
chuckles at firing up 13 parellel hold targeters and processing the concerto data set in 7 seconds. |
| 12:32 |
|
gsams_ joined #evergreen |
| 12:43 |
StomproJ |
tsbere, if you add an SMS carrier, want to remove Alltel, they seem to no longer exist. |
| 12:46 |
tsbere |
StomproJ: I add based on people telling me patrons asked about them. Removal would require research. ;) |
| 13:01 |
bos20k |
Hello. I am creating relative proximity adjustments. We are using the item_circ_lib and hold_pickup_lib when creating them. This is in a consortium. My question is, can I use the org unit ids from the system level, or do I need to use the org unit ids from the branch level? I would like to use the system level org unit ids but I am thinking it won't work right unless I use the branch level ones. |
| 13:04 |
Dyrcona |
Lots of problems with tests using Perl 5.22. |
| 13:10 |
bshum |
bos20k: If it works like most things, I would expect the more specific you are, the more exact it'll match up with the org unit for behavior. If you're specific to the branch, then it should treat it only when dealing with those branches. if system, then it ought to apply to that level and all its children. |
| 13:11 |
bshum |
If memory serves, most of the time we used system level rules, we wanted it to apply to that location and all underlying branches. |
| 13:11 |
bshum |
That being said, I don't recall exactly how relative proximity adjustments operate. |
| 13:12 |
bshum |
Custom best hold stuff wasn't my favorite area to play around in, due to the volatile nature of holds adjustments. |
| 13:13 |
bshum |
Being that it's a holiday in Canada, and maybe others are taking the day off for the pending July 4th, you might have better luck trying again next week. Or angling for an email describing what you're attempting to the list to see what bites you get |
| 13:15 |
bos20k |
bshum: Hmmm. Due to our geographically split consortium, we would like to limit hold targeting that crosses that geographical boundary unless it can't be filled any other way. So, I wanted to create relative proximities that would say if you are on the other side of the state from me, add 5 to the proximity. |
| 13:15 |
bos20k |
The easiest way to do that is at the system level. |
| 13:15 |
* bshum |
tries to remember what table all that lives in |
| 13:16 |
bshum |
This isn't lasso stuff, hmm. |
| 13:16 |
bos20k |
actor.org_unit_proximity_adjustment is where I am working |
| 13:16 |
tsbere |
bos20k: I would say that another option would be to add another level to the org tree, though that would require some adjustments elsewhere. Then copies will be most likely to stay in their "half", and you get the benefit of being able to search that way too. |
| 13:17 |
|
jvwoolf joined #evergreen |
| 13:17 |
bos20k |
tsbere: That was an option I proposed but it is not ideal. |
| 13:18 |
|
hbrennan joined #evergreen |
| 13:23 |
bshum |
So, an adjustment would be like saying, branch A and B are normally considered 5 apart (branch A -> system A -> cons -> system B -> branch B), but then you're making an adjusted entry like branch A is actually only 1 away from branch B? And thus much closer than say Branch C? |
| 13:23 |
bshum |
(5 or 4, hmm) |
| 13:24 |
bos20k |
No, I am using relative proximity. My understanding is that by using them I can add (or subtract?) from what would have been the proximity. |
| 13:25 |
bos20k |
So, I want to add 5 to what would have been the proximity between system A and system B. |
| 13:25 |
bos20k |
If need be I can do it at the branch level instead but I want it to work by adding to the proximity between the systems. |
| 13:26 |
bshum |
Gotcha, what I just described was an absolute adjustment, okay then. And it's four hops, not five. |
| 13:26 |
* bshum |
is re-reading the ESI doc on it |
| 13:26 |
bos20k |
Absolute proximity is where you just replace what would have been the proximity (what bshum seemed to be thinking I wanted) |
| 13:27 |
bshum |
So then if you're calculating at the system level of behavior, you're only two hops apart. System A to system B is two hops of proximity away from each other. Same two hops for System A and C, etc. |
| 13:28 |
bshum |
Adding a relative adjustment to specific combinations, hmm. okay. |
| 13:28 |
bos20k |
So, using your example, I want to add 5 to the proximity between system A and system B. So, if someone places a hold on an item the proximity would end up being a total of 9 between the two branches? |
| 13:28 |
bshum |
I would think that would be how it would add things up, yes. |
| 13:29 |
bos20k |
branch A and branch B would have a total proximity of 9? |
| 13:29 |
bshum |
So it would think it was farther away than something that was only 4 hops away |
| 13:29 |
bshum |
If your custom best hold sort order took proximity into consideration ahead of other things |
| 13:30 |
bshum |
If memory serves, most of yours use "traditional with holds go home" except for some systems which have custom first-in-first-out applied and special prox rules. |
| 13:30 |
bos20k |
Yes, making things seem further away. The thing that threw me is that the column in org_unit_proximity_adjustment is labeled item_circ_lib and hold_pickup_lib. |
| 13:31 |
bshum |
I would expect that to apply to children too |
| 13:31 |
bshum |
So if you specified the system level there, it would apply the rule against any child matches it finds |
| 13:31 |
bshum |
with relative though, is there an operational difference between system vs. branch then? |
| 13:31 |
bos20k |
So I enter systems IDs for item_circ_lib and hold_pickup_lib and that should apply to the branches (children) too? |
| 13:31 |
bshum |
if it still adds up to the same total due to the adjustment, if the item is held at a branch level |
| 13:32 |
bshum |
And picked up at branch |
| 13:32 |
bshum |
Like, nobody can pick up at a system level |
| 13:32 |
bos20k |
bshum: Yes, most are "traditional with holds go home" |
| 13:32 |
* jeff |
sees "total due" and "adjustment" and wondered for a moment how we had gotten on the subject of billing. |
| 13:33 |
bshum |
99% of items are held at the branch level I would expect. |
| 13:34 |
bshum |
And all holds should only happen at branches |
| 13:34 |
bos20k |
bshum: should be held at branch level |
| 13:34 |
bshum |
*pickup |
| 13:34 |
bos20k |
bshum: yes, that's the thing, the OUs generating and fulfilling the holds are branches. |
| 13:34 |
bshum |
Then why make rules at the system level instead of at the branch level? |
| 13:35 |
bshum |
Or just a curiousity? |
| 13:35 |
bos20k |
bshum: but the ideal way for me to do the rel. prox. adjustments is at the system level though. |
| 13:35 |
bos20k |
bshum: Because I have to do it for every lib on the east side of the state to every lib on the west side of the state and visa versa. |
| 13:36 |
* bshum |
isn't sure he gets it, but thinks that any rule written for a system would apply to its children, unless there was a child specifc rule. |
| 13:36 |
bshum |
Right, for every east library, you'd have to have a prox adjustment against every west library, etc. |
| 13:36 |
bos20k |
state library stuff again. We're trying to cut down on holds fulfilled by driving books across the state. |
| 13:36 |
bshum |
So you're talking a ton of adjustment entries |
| 13:37 |
bos20k |
Yup |
| 13:37 |
bshum |
But given that most of the libraries are single branch systems |
| 13:37 |
bos20k |
Writing a program to do the SQL for us. |
| 13:37 |
bos20k |
Most but not all. |
| 13:37 |
bshum |
There should be no functional difference between connecting branch vs. system |
| 13:37 |
bshum |
Oh, except for Bridgeport. Yeah okay I see what you're doing now |
| 13:37 |
bshum |
If you make the boundary of the adjustment at system, then it's easier to write it out |
| 13:38 |
bshum |
In terms of viewing each group as an independent body |
| 13:38 |
bos20k |
Yup, less rules, probably a bit less load on the system, etc. |
| 13:39 |
bos20k |
It would be totally awesome if there was a proximity group... |
| 13:39 |
bshum |
It's one of the things they tried to build once. With the lasso groups. But that dev didn't fully manifest. |
| 13:39 |
bos20k |
Or even beter, proximity calculations based on geolocation of the branches/systems! |
| 13:40 |
bshum |
Proximity isn't always 100% accurate reflection of the abiliy to transfer material though. |
| 13:40 |
tsbere |
bos20k: But what if two branches/systems are next to each other, but on different delivery routes? ;) |
| 13:40 |
bos20k |
Anyway, it sounds like we may just need to try it at the system level and your understanding is that it would probably work. |
| 13:40 |
bshum |
But yes, it would be fancy |
| 13:40 |
bshum |
bos20k: I'd say, sure try it out :D But I'd trust (blame?) the experts who wrote prox adjustments. Like miker. |
| 13:40 |
bos20k |
tsbere: Make an absolute proximity adjustment rule :) |
| 13:40 |
bshum |
j/k miker :D |
| 13:41 |
bshum |
Actually it might have been senator, hmm |
| 13:41 |
bos20k |
Ok. Thanks! |
| 13:41 |
bos20k |
bshum++ |
| 13:42 |
bshum |
bos20k: Don't forget to check your hold sort order too though |
| 13:42 |
bshum |
bos20k: Making adjustments is one thing, but if the hold sort order doesn't take prox adjustment into consideration ahead of other things, it might never apply them |
| 13:43 |
bos20k |
bshum: I will check them again to make sure. Thanks! |
| 13:52 |
bshum |
@later tell Dyrcona It might be broken perl, but curious, did you create your concerto DB with admin/demo123 as the initial user/pass? Cause without that, livetests tend to blow up too. |
| 13:52 |
pinesol_green |
bshum: The operation succeeded. |
| 13:53 |
* bshum |
is rolling a new Xenial VM to find out later |
| 14:04 |
StomproJ |
bos20k, I've got a similar setup from you, but we have two systems. Any time a hold crosses the system we add a big bump to the proximity. |
| 14:05 |
bos20k |
StomproJ: Are you doing that with relative proximity adjustments? |
| 14:05 |
StomproJ |
bos20k, Yes, I would be happy to share our settings with you. |
| 14:06 |
bos20k |
StomproJ: Ok, that would be nice. |
| 14:07 |
bshum |
StomproJ++ # real life examples ftw |
| 14:07 |
StomproJ |
bos20k, we set a relative adjustment for every branch, because we want items paged in a specific order, and then a additional bump for cross system. |
| 14:09 |
StomproJ |
bos20k, it works pretty good, but we find in annoying that every time a hold gets re-targetted, the next lowest priority item gets targeted. So the targeted copy swaps back and forth every 24 hours. bericks new hold targeter has an option to not do that. |
| 14:10 |
bos20k |
Hmmm |
| 14:13 |
StomproJ |
bos20k, Do you just want a dump of actor.org_unit_proximity_adjustment? |
| 14:14 |
bos20k |
StomproJ: That might be useful. |
| 14:16 |
StomproJ |
bos20k - /msg me your email address. |
| 14:32 |
bos20k |
StomproJ++ |
| 14:35 |
graced |
Happy Canada Day, Canadian Evergreeners! |
| 14:37 |
|
Dyrcona joined #evergreen |
| 14:38 |
Dyrcona |
@later tell bshum Yes, I did use admin demo123, unless I typoed it. |
| 14:38 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 14:41 |
Dyrcona |
Yep, I did. Just logged in to make sure. |
| 14:50 |
Dyrcona |
live_t/17-lp1579225_new_patron_passwords.t .... Dubious, test returned 25 (wstat 6400, 0x1900) |
| 14:51 |
Dyrcona |
We're also getting this with Perl 5.22 on two tets: Possible precedence issue with control flow operator at /home/opensrf/Evergreen/Open-ILS/src/perlmods/blib/lib/OpenILS/SIP/Patron.pm line 353. |
| 14:51 |
Dyrcona |
I'm guessing that is code that I wrote. |
| 14:52 |
Dyrcona |
So, with clean master on Xenial, that one test fails and two others spit out a message. |
| 14:54 |
Dyrcona |
Nope. Not my code. |
| 14:54 |
Dyrcona |
I figured it was 'cause I recently edited that file. |
| 14:58 |
bshum |
Okie dokie :( |
| 15:10 |
|
jvwoolf left #evergreen |
| 15:20 |
bshum |
Hmm, my trusty VM exploded on part of negative balances live perl test, and then utterly died with the patron password test |
| 15:20 |
bshum |
I'll reload my DB and double check |
| 15:27 |
Dyrcona |
For the benefit of the channel, I'm only failing on the patron password test after 3 or 4 times reloading the database. |
| 15:30 |
berick |
Dyrcona: does reloading the DB mean dropping and re-create the EG db, then adding concerto? |
| 15:31 |
Dyrcona |
berick: Yes, that is what it means. I used eg_db_config to recreate the database. |
| 15:31 |
Dyrcona |
There's a field in the use that is an arrayref, and that doesn't look right to me. The error is from trying to update a user. |
| 15:32 |
Dyrcona |
I'd expect a fleshed object. |
| 15:32 |
Dyrcona |
I'm going to try the pgtap tests, next. |
| 15:32 |
Dyrcona |
just have to install the extension. |
| 15:36 |
bshum |
Dyrcona: Fresh Xenial VM with concerto, etc. Neg balances works fine, but that patron password test still dies horribly |
| 15:36 |
bshum |
So that's now four attempts with fresh DBs where that test blows up consistently for me |
| 15:36 |
Dyrcona |
That's what I see, too. |
| 15:37 |
Dyrcona |
I'm going to try pgtap tests with the right db credentials, this time. :) |
| 15:39 |
Dyrcona |
not much typing the password over and over again. :) |
| 15:39 |
|
rjackson_isl_ joined #evergreen |
| 15:39 |
Dyrcona |
not much fun that is. |
| 15:41 |
|
mnsri_away joined #evergreen |
| 15:42 |
|
b_bonner joined #evergreen |
| 15:43 |
|
pastebot joined #evergreen |
| 15:43 |
Dyrcona |
pgtap tests and live tests are all successful. |
| 15:43 |
Dyrcona |
t/regress also pass. |
| 15:44 |
|
eady joined #evergreen |
| 15:44 |
|
jeff joined #evergreen |
| 15:44 |
|
jeff joined #evergreen |
| 15:44 |
Dyrcona |
Guests are here, so I'll be paying little to no attention. |
| 15:44 |
|
genpaku joined #evergreen |
| 15:44 |
|
rashma_away joined #evergreen |
| 15:49 |
|
ldw joined #evergreen |
| 15:50 |
bshum |
Well, fwiw, Dyrcona, I can't replicate yours and bott's issue with patron registration on my Xenial VM running EVG master and PG 9.5. I'll try again later and also maybe try out the working branch further to really kill connectby() stuff. It'll be good regardless. |
| 15:52 |
Dyrcona |
I haven't mentioned the branch on the LP bug, yet. I'm gonna fix it up prettier later. |
| 16:02 |
|
jlitrell joined #evergreen |
| 16:03 |
bshum |
Right, I'm just saying I can't get patron editor to break so far. |
| 16:03 |
bshum |
I did test the function call though and that is broken for sure. |
| 16:03 |
bshum |
So whatever we do to kill connectby is +1 from me :) |
| 16:03 |
bshum |
Maybe it's a browser thing |
| 16:04 |
* bshum |
uses Chrome |
| 16:11 |
StomproJ |
Can someone show me an example of a srfsh request for a service with multiple arguments please, I'm having trouble figuring it out. |
| 16:12 |
StomproJ |
I'm trying something like (test system, so not worried about the auth key) request open-ils.actor open-ils.actor.invalidate.email "ec144954b1df8f1d09894fc81ebf322c",'','','',"natcho taco.com" |
| 16:13 |
tsbere |
StomproJ: I think you can space-delimit instead of comma-delimit |
| 16:14 |
StomproJ |
Thanks, I wonder why the srfsh help screen for request says "so add commas if there is more than on param"? |
| 16:15 |
* tsbere |
isn't sure he has ever actually looked at that help screen <_< |
| 16:16 |
StomproJ |
tsbere++ thanks, that did the trick. |
| 16:48 |
* Dyrcona |
used Chrome. Firefox wouldn't even login. |
| 16:48 |
Dyrcona |
Probably didn't like the self-signed cert. on the websockets port. |
| 16:49 |
Dyrcona |
I think it's permissions. It probably works if you're admin,but not regular staff. |
| 16:49 |
Dyrcona |
I logged in as Mary Townsend. |
| 16:50 |
Dyrcona |
Well, it's definitely permissions, since it is a permissions function that fails. |
| 16:50 |
* Dyrcona |
goes back to the cook out. |
| 16:51 |
Bmagic |
Anyone heard from their consortium wanting the action.circulation and action.non_cat_in_house_use and action.in_house_use combined into a single report? |
| 16:55 |
hbrennan |
Bmagic: That would be very useful. I manually combine those reports when looking at the performance of serials |
| 16:56 |
Bmagic |
I was thinking about making a LP report if there wasn't one already |
| 17:51 |
|
tsadok joined #evergreen |
| 20:32 |
|
bmills joined #evergreen |
