Time |
Nick |
Message |
00:40 |
|
sandbergja joined #evergreen |
01:28 |
|
sandbergja joined #evergreen |
01:34 |
|
sandbergja joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:28 |
|
rjackson_isl_hom joined #evergreen |
07:52 |
|
Dyrcona joined #evergreen |
08:07 |
pinesol |
[evergreen|Jason Stephenson] LP 1889628: SIP2 Patron Username Lookup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ddce1ae> |
08:07 |
pinesol |
[evergreen|Jason Stephenson] LP 1889628: Use Workstation in SIP Username Lookup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=770c882> |
08:07 |
pinesol |
[evergreen|Bill Erickson] LP1889628 SIP patron username logging config option - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=de2283a> |
08:20 |
|
rfrasur joined #evergreen |
08:32 |
|
mmorgan joined #evergreen |
08:38 |
|
mantis2 joined #evergreen |
08:50 |
|
dguarrac joined #evergreen |
09:15 |
csharp |
I'm adapting berick's quipu card branch for PINES and I'm stuck on adding a user setting. Here's my code: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Ecard.pm;h=c269e6c83e8e2d8ab2da98cae854b4e4970e2461;hb=refs/heads/user/csharp/pines-quipu-ecard-integration#l528 |
09:17 |
csharp |
In the "add_usr_settings" sub, I'm trying to pass the user's ID to open-ils.actor.patron.settings.update and it's just not coming through - I tried $user->{id} and $user->id, and now I'm just confused about what $user even contains at this point and how to access it |
09:18 |
Dyrcona |
csharp: Log the results of ref($user). It could be a hashref, an IDL object, or even and int. |
09:18 |
Dyrcona |
Fun thing about Perl and how we use it..... |
09:19 |
Dyrcona |
You'll find code sprinkled all over place that looks like: my $uid = (ref($user) ? $user->id() : $user; |
09:20 |
Dyrcona |
Well, my syntax is broken, but you get the drift... |
09:23 |
csharp |
Dyrcona: thanks - just set up logging - the vendor has to send the registration, so I have to wait, but I'll know more soon :-) |
09:24 |
Dyrcona |
csharp: That code runs on your server, no? Can't you just log it to syslog for now? |
09:26 |
Dyrcona |
Based on other code in the file, I'd say that $user is an IDL object so $user->id() (with or without parens) should work. |
10:04 |
csharp |
Fieldmapper::actor::user - yep |
10:04 |
csharp |
open-ils.actor.patron.settings.update is acting like it's undef, though, so now to figure out why |
10:09 |
Dyrcona |
Are you using "$user->id" $user->{id} should be either undef or produce an error. |
10:17 |
csharp |
[INFO:76848:Ecard.pm:534:15986237157684819] csharp: $uid = |
10:17 |
csharp |
it's undef for sure ($user->id) |
10:18 |
berick |
csharp: it will be undef until after save_user() is called |
10:19 |
Dyrcona |
Ah, you're making a new user.... |
10:19 |
berick |
the database creates the ID |
10:19 |
csharp |
https://pastebin.com/WjSQ7Ek7 |
10:19 |
Dyrcona |
I didn't read the code that thouroughly. |
10:19 |
csharp |
what I just pasted is my current sub |
10:21 |
csharp |
I see, so I just have to move that sub below save_user |
10:22 |
csharp |
(in the subroutine calls) |
10:23 |
berick |
yep |
10:23 |
csharp |
whew |
10:23 |
csharp |
this took me days |
10:24 |
csharp |
learnin' is hard, y'all |
10:25 |
csharp |
berick++ Dyrcona++ # helping |
10:29 |
|
alynn26 joined #evergreen |
10:32 |
csharp |
and it works! |
10:33 |
csharp |
jeez |
10:33 |
jeff |
happy Mon Mar 181 10:32:43 EDT 2020, y'all. |
10:33 |
csharp |
:-) |
10:33 |
csharp |
where are you seeing that? |
10:34 |
jeff |
running joke. |
10:35 |
jeff |
march never ended, and every day is a monday. |
10:36 |
csharp |
that's a quality observation :-) |
10:44 |
berick |
@quote add <janis_joplin> It's all the same [REDACTED] day, man |
10:44 |
pinesol |
berick: The operation succeeded. Quote #207 added. |
10:46 |
berick |
Dyrcona++ # been meaning to merge the SIP username stuff |
11:04 |
|
jvwoolf joined #evergreen |
15:38 |
Bmagic |
Just running this by you all. There is a library setting called "circ.hold_boundary.hard" - which during hold placement time, informs the selection_depth value. What about the hold matrix for transit_rage? Does that inform selection_ou ? |
15:43 |
|
mantis2 left #evergreen |
15:46 |
csharp |
Bmagic: I believe the hold matrix is only consulted to see if the patron is allowed to place a hold and not after the hold is placed - hard boundary would be something the hold targeter processes each time it's run |
15:47 |
Bmagic |
the hard boundary is "recorded" into the selection_depth (pretty sure) at hold time. If a library changes that setting, all of the previously-placed holds do not get updated (that's what I am dealing with - retro-actively updating holds to match the hard boundary setting) |
15:47 |
csharp |
yes that's what we saw too, even with soft boundary |
15:48 |
Bmagic |
The question I am wrestling with is: if I update the already-placed holds to match the newly changed lib setting, will that upset any of those holds that were using a hold policy where the "transit range" was something different. |
15:49 |
Bmagic |
essentially, I am not sure "where" transit range matters. The code seems to suggest that its only consulted at hold time to see whether or not a hold can be placed. But after the hold is placed using a hold policy where a transit range was specified.... is it recorded somehow? |
15:51 |
Bmagic |
when the hold targeter runs, perhaps it evaluates each copy against the hold matrix again? |
15:52 |
Bmagic |
in which case, the transit range still applied to holds (as long as it keeps hitting the same rule) |
15:59 |
Bmagic |
I'm going with that |
16:00 |
JBoyer |
Bmagic, are you talking about transit_range in config.hold_matrix_matchpoint ? |
16:00 |
Bmagic |
JBoyer: yep |
16:00 |
JBoyer |
That's not assigned anywhere, it's used as a limit when checking holds permit checks. |
16:01 |
Bmagic |
that's what I was thinking. Thanks for the confirmation! |
16:01 |
JBoyer |
If you set it to 2, say, then items can transit among branches within a system to fill holds, but not transit outside the system. |
16:02 |
|
mmorgan left #evergreen |
16:03 |
Bmagic |
right, but when is that tested. The hold targeter (every night for every hold) ? Or just once during hold placement time, to make sure that there is at least one copy that can be targeted? |
16:42 |
|
yboston joined #evergreen |
16:47 |
|
mrisher joined #evergreen |
17:02 |
JBoyer |
Sorry, I clicked away and missed your reply. I believe the hold_permit_test is called immediately when the hold is placed and for each copy the hold targeter considers each time it's run. |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:31 |
|
abowling1 joined #evergreen |
18:45 |
|
abowling joined #evergreen |
20:38 |
|
sandbergja joined #evergreen |
20:45 |
|
sandbergja joined #evergreen |
21:01 |
|
sandbergja joined #evergreen |
21:31 |
|
sandbergja joined #evergreen |
21:51 |
|
sandbergja joined #evergreen |
23:13 |
|
sandbergja joined #evergreen |
23:22 |
|
sandbergja joined #evergreen |