| Time |
Nick |
Message |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:20 |
|
kmlussier joined #evergreen |
| 06:20 |
* kmlussier |
yawns |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 08:22 |
|
collum joined #evergreen |
| 08:32 |
|
Callender joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:53 |
|
bos20k joined #evergreen |
| 09:18 |
|
yboston joined #evergreen |
| 09:23 |
|
maryj joined #evergreen |
| 09:37 |
|
kmlussier joined #evergreen |
| 09:58 |
_adb |
good morning. opac is showing patrons' holds with status "reserved/pending" as "ready for pickup". is there a setting to make that wait until the 'hold shelf delay status' has expired before telling people their items are available? |
| 09:59 |
|
jvwoolf joined #evergreen |
| 10:00 |
tsbere |
reserved/pending? |
| 10:01 |
_adb |
yea.. hold is captured, but before 'hold shelf delay status' time has passed |
| 10:02 |
tsbere |
aka, it is in the "on hold shelf" status with a shelf time, but within that delay period? |
| 10:03 |
jeff |
_adb: i thought that that was a known and fixed issue a while back. maybe there's still an open bug and it's not been merged. looking. |
| 10:03 |
_adb |
i think so? the hold shows up in the staff client as "reserved/pending", but i'm not sure what the item status is during this time. i'd have to test. |
| 10:04 |
|
remingtron joined #evergreen |
| 10:04 |
jeff |
bug 1195428 |
| 10:04 |
pinesol_green |
Launchpad bug 1195428 in Evergreen "TPAC reports hold "ready for pickup" before hold_shelf_status_delay expires" [Medium,Confirmed] https://launchpad.net/bugs/1195428 |
| 10:04 |
tsbere |
Well, that would indicate that the setting isn't unparsable, which was one of my thoughts. Jeff probably has the better answer as a result. |
| 10:04 |
|
mmorgan joined #evergreen |
| 10:05 |
_adb |
jeff: oh, so this has been around for a while. |
| 10:05 |
_adb |
thanks for your help |
| 10:05 |
_adb |
jeff++ tsbere++ |
| 10:06 |
jeff |
_adb: the initial description for the bug in question seems to contradict the title of the bug. i don't have time to look into it right now, and don't have a lot of direct experience with that setting, as we don't make use of it here. |
| 10:07 |
jeff |
(for things that are captured at the pickup library but are likely still sitting in the bottom of a sorter bin, we use the SIP support for "capture local holds as transits" to prevent patrons from being told that things are "ready" before they're on the hold shelf.) |
| 10:07 |
_adb |
i'll look into that, thank you! |
| 10:09 |
tsbere |
Bonus of the "capture local holds as transits" is that notifications don't get emailed/texted/called/whatever, even if third party systems are poking |
| 10:09 |
berick |
jeff: while you're here.. i was having some bugginess with declarative content on windows. after tweaking the app manifest to experiment, i found that we probably don't need declarative content to avoid the strict-hostname issues. the content_scripts option does not require strict domains. e.g. https://gist.github.com/berick/98babc4ec6d7850b4a938c2d70639b5f |
| 10:09 |
berick |
jeff: bonus, it's not prompting for any permissions. it almost seems too good to be true, though. |
| 10:10 |
jeff |
that does seem a bit too good to be true... hrm. |
| 10:10 |
_adb |
how long is the timeout before notifications sent and hold is marked as ready for pickup if it's captured as transit? |
| 10:10 |
jeff |
berick: have you tested with a fresh copy of chrome and potentially a fresh google account to confirm that there's nothing going on like "oh, you granted some permissions to this a while ago"? |
| 10:11 |
tsbere |
_adb: You still need to check it in again to end the transit, so "until staff take action, plus whatever is configured then" |
| 10:11 |
jeff |
_adb: depends on a few variables, including how often you run the action trigger script with the granularity in question, and the delay configured in the A/T definition... |
| 10:11 |
_adb |
ah, ok, thank you |
| 10:12 |
jeff |
and yes, with the "capture local holds as transit" feature, it remains in transit until you check it in somewhere where "capture local holds as transits" is NOT enabled. |
| 10:12 |
berick |
jeff: not yet, but I had the same thought. |
| 10:12 |
jeff |
in our environment, the SIP checkin bookdrops / sorters all use "capture local holds as transits", and those items are taken from the "exception" bin of the sorter and processed through a standard staff client. at that time, the hold items go from "in transit" to "available/ready for pickup" |
| 10:14 |
jeff |
berick: at first glance, this seems to go counter to the documentation and some previous experimentation. i would expect this to require a very wide/scary sounding permission of "view/change the contents of all web pages" (i forget the exact wording). |
| 10:14 |
tsbere |
I will point out that jeff's situation is why I wrote the feature in the first place, though other use cases (new material won't be made available until X date so pre-capture local holds before release date) have come up |
| 10:14 |
|
dcook__ joined #evergreen |
| 10:14 |
jeff |
berick: i might be able to spend some time looking this weekend. |
| 10:14 |
|
Dyrcona joined #evergreen |
| 10:15 |
|
bos20k joined #evergreen |
| 10:15 |
|
jvwoolf joined #evergreen |
| 10:16 |
berick |
jeff: i'm going to clean up my test code, get it into the working repo, then try it on a few other machines today. i'll update the bug. other eyes would be awesome, though |
| 10:16 |
berick |
jeff: for now, the fact that you didn't say "that's insane" is what I was looking for ;) |
| 10:17 |
jeff |
it got a raised eyebrow and a "that doesn't sound like it should work", but I'm not planning to make any further assertions without testing. :-) |
| 10:25 |
|
mmorgan1 joined #evergreen |
| 10:32 |
|
Christineb joined #evergreen |
| 10:39 |
|
Callender joined #evergreen |
| 10:51 |
|
mdriscoll joined #evergreen |
| 10:54 |
berick |
jeff: oh, i missed your earlier comment.. when viewing the details of the extension, it does say "Read and change all your data on the websites you visit" -- however, it already said that. |
| 10:55 |
berick |
first test passed, installing under a different "person" in chrome. trying on a different machine now.. |
| 11:07 |
|
sandbergja joined #evergreen |
| 11:08 |
|
dbwells joined #evergreen |
| 11:14 |
|
khuckins joined #evergreen |
| 11:17 |
|
remingtron joined #evergreen |
| 11:17 |
berick |
jeff: fyi, installed on another machine (mac) where i've never installed it before, on a different chrome "person" (not logged into google) and all is well. this is after trimming the manifest even more. http://git.evergreen-ils.org/?p=working/Hatch.git;a=blob;f=extension/app/manifest.json;hb=collab/berick/lp1646166-native-messaging-2.12-omnibus |
| 11:17 |
* berick |
updates lp |
| 11:19 |
jeff |
berick: does the extension still show "Read and change all your data on the websites you visit"? |
| 11:19 |
jeff |
and it didn't display that permission as being granted when the extension was installed? |
| 11:20 |
berick |
jeff: it does display that message when viewing the extension details. it doesn't inform me of that during install, presumably because I'm installing in developer mode. |
| 11:21 |
berick |
that and 'communicate with cooperating native applictions' for the native messaging bit |
| 11:21 |
jeff |
right, that one is expected and i think quite normal (and no way around) |
| 11:21 |
|
bmills joined #evergreen |
| 11:22 |
berick |
jeff: but like I said, it showed that permission info before I made these changes |
| 11:22 |
jeff |
hrm. |
| 11:33 |
|
rlefaive_ joined #evergreen |
| 11:36 |
|
sykeslewis joined #evergreen |
| 11:54 |
berick |
jeff: I think it boils down to the fact that EG is not connecting directly to the extension via runtime.connect. it uses the content script, which has limited capabilities, as a go-between. IIRC, externally_connectable was the fly in the ointment originally, re: hard-coded hosts. |
| 11:59 |
|
brahmina joined #evergreen |
| 12:01 |
|
bmills1 joined #evergreen |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:18 |
kmlussier |
berick++ jeff++ # Continued hatch work and testing. |
| 12:19 |
jeff |
i'm just listening today. :-) |
| 12:20 |
JBoyer |
berick++ |
| 12:21 |
JBoyer |
It sounds like hatch is coming along nicely. I've finally got a notebook running Linux so I'll be able to take part in more testing and so on. (Not putting Java on any machines I actually like, so it's been a no-go at home until now, and work doesn't like it either. :/ ) |
| 12:22 |
jeff |
berick++ indeed |
| 12:32 |
Bmagic |
Is there a way to ask SIP weather a patron can circulate without trying to circulate an item? |
| 12:33 |
Bmagic |
It looks like we are getting 'Y' in the 3rd position on the 64 responses. AKA "64 Y " - which means block right? The problem is, that 'Y' seems to shows up no matter what penalties or no penalties |
| 12:36 |
berick |
Bmagic: 3rd position is 'recall privileges' |
| 12:36 |
Bmagic |
right, is that not the right place to look for "can circulate" ? |
| 12:36 |
berick |
there's a way to configure its behavior.. |
| 12:37 |
berick |
first position is circulate |
| 12:37 |
berick |
"charge privileges" |
| 12:38 |
Bmagic |
I have a patron that should be blocked, and that column is blank |
| 12:40 |
berick |
can't explain that one. you can see the logic in OpenILS::SIP::Patron::charge_ok |
| 12:41 |
Bmagic |
I was just looking at that |
| 12:41 |
* berick |
steps away |
| 12:41 |
JBoyer |
I can't tell that it's actually looking at penalties that block CIRC, only that there are some penalties. barring the patron (the checkbox on the Edit screen) or letting them expire are the only sure-fire ways to set that to Y |
| 12:42 |
Bmagic |
thanks for the help, I will keep digging |
| 12:42 |
Bmagic |
$u->standing_penalties and @{$u->standing_penalties} |
| 12:43 |
Bmagic |
If the result of that test is true, then circ is blocked, which results in the first position 'Y' ? |
| 12:44 |
jeff |
might want to start with "why do you think the patron should be blocked?" |
| 12:44 |
JBoyer |
Yes, but I can't tell what that's actually testing. first, that there are standing penalties, but I'm not sure what @{$u->standing_penalties} is actually testing. |
| 12:44 |
Bmagic |
if the penalty they have blocks CIRC |
| 12:45 |
Bmagic |
if you look at the code for renew_ok - $renew_block_penalty = 't' if $_->standing_penalty->block_list =~ /RENEW/; |
| 12:45 |
Bmagic |
probably need something similar in charge_ok ? |
| 12:49 |
Dyrcona |
In Perl, an empty arrayref [] is true. |
| 12:50 |
Dyrcona |
That check is check that we have something, and that they arrayref has 1 or more memberes. |
| 12:50 |
Dyrcona |
@{[]} is 0 or false in scalar context |
| 12:50 |
pinesol_green |
Dyrcona: Error: "" is not a valid command. |
| 12:52 |
Bmagic |
the test is then "penalties exist and there are more than 0" ? |
| 12:55 |
Dyrcona |
Bmagic: Yeah. |
| 12:55 |
Bmagic |
I'm thinking there needs to be a penalty block check for charge_ok and hold_ok just like renew_ok, do you think? |
| 12:55 |
Dyrcona |
It's done that way to avoid warnings about undefined values. |
| 12:55 |
Dyrcona |
Yeah, probably. |
| 12:56 |
Bmagic |
it's almost a copy and paste from renew_ok - but might need to involve cache? Or is storage already caching the sql return? |
| 13:11 |
Bmagic |
That first position in the 64 response contains the answer to charge_ok which is 'Y' when it's NOT OK? That seems opposite. |
| 13:14 |
JBoyer |
Bmagic, I believe the Y's mean "Yes, they're blocked from this" as opposed to "Yes, they can do this." This is why negative logic is usually a bad idea. |
| 13:15 |
Bmagic |
alright |
| 13:19 |
Bmagic |
jeff: you reported bug 1534283 - it sounds like to me this is basically the same bug, do you agree? |
| 13:19 |
pinesol_green |
Launchpad bug 1534283 in Evergreen "SIP prevents renewal when user has any blocking standing penalties" [Undecided,Fix released] https://launchpad.net/bugs/1534283 |
| 13:22 |
jeff |
related, at a minimum. |
| 13:23 |
Bmagic |
I suppose I will create a new bug unless you can think of one that is already there ( I really don't want to make a duplicate) |
| 13:25 |
jeff |
either start with a "this might be the same thing" as a comment on that bug, or a new ticket with "this might be a duplicate" and either a new bug can be created or the new bug can be marked as a duplicate if so. |
| 13:25 |
Bmagic |
I would like to mention that our system is not setting that first position 'Y' when they have penalties. Therefore, I can conclude that "$u->standing_penalties and @{$u->standing_penalties}" doesn't seem to be returning correctly |
| 13:25 |
jeff |
i would err on the side of getting a clear explanation of what you found and how you think it should be different into launchpad over worrying about comment vs new bug too much. :-) |
| 13:26 |
jeff |
(i say this because i've let that prevent me from getting info into launchpad before) |
| 13:27 |
jeff |
also helpful is some background on what the actual practical effect of the current behavior is, as not everyone has the same SIP clients to test with, or uses SIP in the same way. |
| 13:36 |
Dyrcona |
In my experience, a number of SIP vendors treat a Y in any field as blocked for everything. |
| 13:36 |
Dyrcona |
It's rare to find one that actually checks the specific field. |
| 13:38 |
Dyrcona |
As for Bmagic's comment about it returning correctly, I'd have to look at the code in question, but when dealing with arraryrefs, that's a common way to check if it has members. |
| 13:39 |
Bmagic |
I think the issue is how that array is populated. I think it's only penalty ID 1 and 2 |
| 13:40 |
Bmagic |
yep, line 202 in Patron.pm {id => [1,2]} |
| 13:54 |
Dyrcona |
Bmagic: So, sounds like you're on the right track. |
| 13:57 |
Dyrcona |
While on the subject of SIP, it would be nice if someone could look at my fixes for the encoding issues. |
| 14:26 |
jeff |
on my todo if someone else doesn't get there first. |
| 14:29 |
Dyrcona |
mdriscoll was going to try it in production, I think. |
| 14:29 |
Dyrcona |
I should find something to look at, but I don't feel so good today. |
| 14:48 |
pinesol_green |
Showing latest 5 of 7 commits to Evergreen... |
| 14:48 |
pinesol_green |
[evergreen|Galen Charlton] LP#1485374: call tzset() after setting timezone - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8bedc56> |
| 14:48 |
pinesol_green |
[evergreen|Galen Charlton] LP#1485374: add way for C code to make TZ-aware subrequests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=28561ed> |
| 14:48 |
pinesol_green |
[evergreen|Mike Rylander] LP#1485374: Adjust TZ scope in mod_perl - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=abecff8> |
| 14:48 |
pinesol_green |
[evergreen|Mike Rylander] LP#1485374: Add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f838339> |
| 14:48 |
pinesol_green |
[evergreen|Jason Stephenson] LP#1485374: Add missing comma on line 667 of oils_auth.c. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=029deb6> |
| 15:00 |
kmlussier |
If anyone has been quietly working on web client activities, let me know so that I can include it in my report back to the community. I know there's been some hatch work going on, so no need to tell me about that. |
| 15:01 |
gmcharlt |
kmlussier: I'll have some commits later this afternoon |
| 15:01 |
kmlussier |
gmcharlt: Great, thanks! |
| 15:02 |
* kmlussier |
has spent most of her time submitting acq web client bugs to Equinox and then looking at the timezone branch. |
| 15:03 |
kmlussier |
I was hoping to get those things done by noon. Sigh... |
| 15:06 |
khuckins |
kmlussier: I've been experimenting with some ideas on bug 1528924, but nothing concrete has materialized yet. Will likely have a little bit more to add to the discussion on that issue later today, though |
| 15:06 |
pinesol_green |
Launchpad bug 1528924 in Evergreen "Web Client: Item Status List View missing column options" [Medium,Confirmed] https://launchpad.net/bugs/1528924 |
| 15:07 |
kmlussier |
khuckins: Great! Glad to hear it. |
| 15:08 |
kmlussier |
I know sometimes we end up spending an entire day on something without being able to finish it, so I just want to make sure all that activity is captured. :) |
| 15:08 |
* kmlussier |
tries to do one more thing before heading off to a late Friday afternoon conference call. |
| 15:11 |
kmlussier |
Also, I wanted to follow up on something I posted here yesterday. In looking more closely, I don't think the logs are related to the problems I've had on my web client VMs where I'm running out of hard drive space. |
| 15:39 |
Bmagic |
berick Dyrcona: looks like my issue is the sip user has a home ou of 1 and the penalties are only fleshed on matching OU's with the patron. Still only looks for penalty 1 and 2 but at least I got it to work as the coded intended |
| 15:39 |
berick |
Bmagic: mystery solved |
| 15:39 |
Bmagic |
There is a thrifty where clause when fleshing the penalties where => {id => ($here) ? $here : $user->home_ou}, |
| 15:40 |
Bmagic |
I'm not sure if that is "correct" |
| 15:41 |
Dyrcona |
Bmagic: That code rings a bell. I think it was part of a feature to ignore penalties at certain locations. |
| 15:41 |
Dyrcona |
Do a git blame and see if it blames me for it. |
| 15:41 |
Bmagic |
I suppose it makes since that a patron would be allowed to circ at a different library but not at the one where they have the penalty |
| 15:42 |
Dyrcona |
Right, but it is meant to be controlled by a setting. |
| 16:11 |
|
bmills joined #evergreen |
| 16:23 |
|
rlefaive joined #evergreen |
| 16:52 |
|
khuckins_ joined #evergreen |
| 17:00 |
|
jvwoolf left #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:10 |
|
mmorgan left #evergreen |
| 17:12 |
pinesol_green |
[evergreen|Bill Erickson] LP#1655399 webstaff: User perm editor grantable fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a2e9d7a> |
| 17:30 |
|
khuckins__ joined #evergreen |
| 17:44 |
|
kmlussier joined #evergreen |
| 17:45 |
pinesol_green |
[evergreen|Kyle Huckins] LP#1621947: webstaff address alert functionality - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5a3e0dd> |
| 17:59 |
pinesol_green |
[evergreen|Kyle Huckins] LP#1657466 - Edit Due Date Doesn't Submit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=117d164> |
| 18:03 |
* kmlussier |
just set 2.11.2 and 2.10.9 as milestones and then thought, wait, didn't we just release those? |
| 18:26 |
* kmlussier |
would love to see checkboxes on this page - https://launchpad.net/evergreen/2.11/2.11.2 - with an actions menu to perform batch updates on the bugs. |
| 19:05 |
|
rlefaive joined #evergreen |
