| Time |
Nick |
Message |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:18 |
|
agoben joined #evergreen |
| 08:08 |
|
kmlussier joined #evergreen |
| 08:10 |
kmlussier |
Good morning #evergreen |
| 08:11 |
graced |
Good morning kmlussier |
| 08:12 |
kmlussier |
miker: Now that my head is clearer, I think I can explain what I meant by Any. If you type larry, moe, curley in the "does not contain" box, it should exclude records that just have the word larry. The records don't need all 3 words to be excluded. |
| 08:12 |
kmlussier |
graced: Happy Friday! |
| 08:12 |
kmlussier |
miker: Is that what you were thinking? |
| 08:14 |
kmlussier |
Actually, I'm not so sure how happy this particular Friday is. I have a root canal eval later today. That's not happy. |
| 08:15 |
graced |
:( |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:49 |
csharp |
mosh++ |
| 08:49 |
csharp |
comcast-- |
| 08:51 |
kmlussier |
comcast-- #Went down again last night while my son was trying to finish up his homework. |
| 08:51 |
kmlussier |
Actually, up until a week ago, we had no Internet troubles, so I suppose I should be a little more patient. |
| 08:56 |
|
bos20k joined #evergreen |
| 08:58 |
|
Dyrcona joined #evergreen |
| 08:59 |
csharp |
my problem is latency caused by some line or device in my neighborhood/area |
| 09:00 |
mmorgan |
Squirrels? |
| 09:00 |
csharp |
probably :-) |
| 09:00 |
mmorgan |
:) |
| 09:00 |
kmlussier |
@blame squirrels |
| 09:00 |
pinesol_green |
kmlussier: squirrels must eat cottage cheese! |
| 09:01 |
csharp |
@blame comcast |
| 09:01 |
pinesol_green |
csharp: comcast is really just another name for autogen |
| 09:01 |
* rhamby |
stops dropping off bads of squirrel feed at csharp's house |
| 09:01 |
* rhamby |
:%s/bads/bags/ |
| 09:01 |
csharp |
I don't think I've seen that @blame before |
| 09:01 |
csharp |
rhamby: STOP IT! |
| 09:01 |
* mmorgan |
thinks they must drive around in tiny comcast vans with hardhats on and "service" the lines. |
| 09:02 |
csharp |
mmorgan++ |
| 09:02 |
kmlussier |
mmorgan++ |
| 09:02 |
rhamby |
I ended up with comcast after the move and knock on wood they've been ok so far. |
| 09:04 |
csharp |
rhamby: I've had relatively little trouble with them over the last 9 years - this week's experience destroyed all my good feeling though :-) |
| 09:05 |
rhamby |
csharp: :( Are you in a neighborhood being targeted for Google fiber or the AT&T fiber service? |
| 09:06 |
csharp |
when your service model is to assume that all problems are inside customers' homes and the actual problem is upstream, there's pretty much no way to get them to believe you |
| 09:06 |
csharp |
not yet - I thought so before |
| 09:06 |
rhamby |
Oh, so they have the same service model as my old ISP back in SC. |
| 09:07 |
csharp |
AT&T might be coming here, but I'd only go back to them kicking and screaming |
| 09:07 |
csharp |
soulless_corporations-- |
| 09:08 |
* csharp |
actually had to explain "ping" to a customer service rep the other day |
| 09:09 |
Dyrcona |
I actually Verizon. The setup they have for FIOS, they can usually tell very quickly where the problem is. |
| 09:09 |
JBoyer |
csharp needs to learn the secret code to reach tier 1 support. ;) |
| 09:09 |
Dyrcona |
Insert like between actually and Verzion. |
| 09:09 |
csharp |
JBoyer: seriously - I've been fighting to reach someone who actually understands network infrastructure basics all week |
| 09:10 |
kmlussier |
Dyrcona: I might like Verizon too if they brought FIOS to my neighborhood. |
| 09:10 |
csharp |
Dyrcona: I can vouch for Verizon cell service - I've never had trouble with that |
| 09:11 |
csharp |
we don't have residential service from them in my area either |
| 09:11 |
Dyrcona |
Your cable company probably has a monopoly granted by your town. |
| 09:11 |
csharp |
it has been great to be able to fall back to mobile hotspot during this week's "fun" |
| 09:11 |
Dyrcona |
That's true in a few Mass. communities. |
| 09:12 |
Dyrcona |
At C/W MARS central site we've been having issues with Charter. It's apparently a neighborhood-wide thing and they hadn't figured it out last I heard. |
| 09:12 |
kmlussier |
Dyrcona: Really? I thought that was only true for cable tv service. |
| 09:13 |
Stompro |
Hello all, I'm getting ready for our 2.8->2.10 upgrade this sunday, and I just ran into an issue I've seen before and I'm wondering how you all handle it? Our app servers don't have memcached installed, but the ./configure step looks for it and errors out when it isn't there? Do you all just install then remove it? Or is there a .configure switch to skip that check? |
| 09:13 |
Dyrcona |
kmlussier: It extends to Internet in some towns. Haverhill, I think, has that kind of deal with Comcast. |
| 09:14 |
Dyrcona |
Stompro: Easiest solution is to install memcached and disable it from running. |
| 09:15 |
Stompro |
Dyrcona, thanks, I'll do that. |
| 09:16 |
Dyrcona |
On a Debian-based distro update-rc.d should work, even with systemd. |
| 09:18 |
rjackson_isl |
csharp: I found your squirrel culprits http://jokideo.com/squirrels-messing-with-the-bird-feeder-funny-cartoons/ |
| 09:19 |
|
jvwoolf joined #evergreen |
| 09:25 |
csharp |
rjackson_isl: ha! |
| 09:27 |
* Dyrcona |
just got an email that the Interent problems at Worcester Business Center should now be resolved. Guess I'll find out on Monday. ;) |
| 09:28 |
* Dyrcona |
goes back to the thrilling work of diffing configuration files and making "one configuration to rule them all." |
| 09:33 |
Dyrcona |
I should really figure out just what services SIPServer needs running and limit the config to just start those. |
| 09:35 |
Dyrcona |
Does anything actually use open-ils.justintime in a stock installation? |
| 09:36 |
JBoyer |
Dyrcona, I'm not suggesting you map it out, but a list of what services are needed for what purpose (SIP/OPAC/utility/reporting/etc.) would likely be very helpful. I've been just running fewer spare services for the ones I'm not sure about. |
| 09:36 |
tsbere |
Dyrcona: I think that only gets used for phone calling "callback to see if the call should still be made" |
| 09:38 |
Dyrcona |
JBoyer: I may just blog it for SIP. |
| 09:38 |
Dyrcona |
tsbere: Thanks. I've not seen it used anywhere, but I(we)'ve not used telephony. |
| 09:39 |
JBoyer |
That would be cool. And some of them aren't terribly mysterious. I suspect the reporter stuff could all be disabled on a SIP server for instance. |
| 09:39 |
Dyrcona |
Yeah, 90% sure it can. It can be disabled on a Syrup instance. |
| 09:39 |
Dyrcona |
A lot can be disabled on a Syrup instance. |
| 09:45 |
Dyrcona |
kmlussier++ # for mentioning something that I take for granted on a Lp bug. |
| 09:45 |
kmlussier |
Dyrcona: It's the result of my spending way too many years filing bugs without any elevated permissions. |
| 09:46 |
Dyrcona |
:) |
| 09:49 |
kmlussier |
Who has the ability to make people Bug Wranglers? |
| 09:53 |
bshum |
It's not exactly a formalized process |
| 09:53 |
tsbere |
Ben Shum, Dan Scott, Jason Stephenson |
| 09:53 |
bshum |
But there's a few admins |
| 09:54 |
* bshum |
waves Hi from Hong Kong International Airport |
| 09:54 |
Dyrcona |
People can ask to join the bug wranglers group and one of us generally approves them immediately if they're a known member of the community. |
| 09:54 |
Dyrcona |
bshum: Not through customs, yet? |
| 09:54 |
dbwells |
Dyrcona: I am curious how you folks have Syrup set up. We are using it, but we don't have a separate instance for it. What have you found to be the benefits of running it that way? |
| 09:55 |
Dyrcona |
dbwells: We have ten separate Syrup installations, one for each of the libraries using it. |
| 09:55 |
bshum |
Dyrcona: Nah we're eating dinner at one of the restaurants here first before heading out |
| 09:55 |
bshum |
Dinner? Breakfast? Something... |
| 09:56 |
Dyrcona |
heh. |
| 09:56 |
Dyrcona |
dbwells: So, we have a server dedicated to those ten instances and it has its own Evergreen services. |
| 09:56 |
kmlussier |
Yeah, Syrup wasn't built to be used by multiple institutions. |
| 09:56 |
* Dyrcona |
was going to say that next. :) |
| 09:56 |
Dyrcona |
dpearl is working on integrating Syrup into Evergreen. |
| 09:57 |
kmlussier |
Dyrcona: My recollection is that artunit told me we didn't have to run it with Evergreen, just with OpenSRF. I can't recall if NOBLE has Evergreen running on the same server as their Syrup instance. |
| 09:57 |
Dyrcona |
kmlussier: That is most definitely true. As long as the OpenSRF can talk to some other server running the Evergreen services. |
| 09:58 |
Dyrcona |
I imagine it was done this way because it was easier or to reduce load on the production bricks. |
| 09:58 |
kmlussier |
Ah |
| 09:58 |
Dyrcona |
I wasn't here when it was setup, so I'm speculating. |
| 09:59 |
Dyrcona |
We're also running services on the SIP servers, and that is not strictly necessary, either. |
| 09:59 |
Dyrcona |
And, I might change both of those conditions when we switch to VMs for production. |
| 09:59 |
dbwells |
I wondered if it was a load/isolation thing. We aren't running Evergreen on our Syrup box, as far as I can recall (it has been a while). |
| 09:59 |
Dyrcona |
Yeah... Thanks for bringing this up, I believe I will do that when we get the new servers. |
| 10:00 |
Dyrcona |
The Syrup box does only run the services that are apparently used by syrup, though I've not done a thorough audit. |
| 10:03 |
dbwells |
We do get poor performance from Syrup in certain cases, so maybe running a few services locally could help in that regard. Or maybe not :) |
| 10:05 |
Dyrcona |
Yeah, I'm not sure. Syrup has been mostly trouble free since I started here, so I've not needed to learn too much about it, yet. |
| 10:06 |
Dyrcona |
Syrup does not seem to need much RAM. |
| 10:15 |
Dyrcona |
dbwells: In case you're interested, this is what I came up with for the drones on the Syrup server: http://pastebin.com/9JUxC0BR |
| 10:16 |
Dyrcona |
The unix_config basically sets them all back to defaults, but that was based on the opensrf.xml from the server. |
| 10:26 |
|
rlefaive joined #evergreen |
| 10:28 |
Dyrcona |
There are probably some services that aren't really needed in that list. |
| 10:28 |
Dyrcona |
I'm finding the list of services needed by SIP to be rather slim. |
| 10:46 |
* dbs |
waves belatedly as well |
| 10:46 |
dbs |
current status: what the hell happened to take our nice "running with 5GB of free RAM for a full day" into an OOM situation just a few hours later in the middle of the night |
| 10:53 |
Dyrcona |
A bot? A book on an enter key? A ridiculous search query? |
| 11:04 |
Dyrcona |
JBoyer: This looks like the list of services required for SIP on a 2.9 installation: http://pastebin.com/MmVxGC9j |
| 11:04 |
Dyrcona |
NOTE: I have not tested that on a VM or anything, so something might be missing. |
| 11:05 |
Dyrcona |
That just looks like the things that could actually get used by the calls that the SIP driver makes. |
| 11:06 |
JBoyer |
Dyrcona, I'm running on tuit fumes currently, but I've got a couple places I could test that out eventually. I'll admit trigger is a surprise, but I realize there are the occasional interdependencies that aren't always clear. |
| 11:07 |
Dyrcona |
JBoyer: Well, circ could end up making a call to trigger. It probably won't but it wasn't totally clear. |
| 11:08 |
JBoyer |
Ah, that makes sense for some of the active events. |
| 11:09 |
Dyrcona |
I also could have spent more time on it. :) |
| 11:17 |
dbs |
Dyrcona: possible, I suppose, but we've been getting visited by baidu, bing, googlebot, and yahoo continously for the last two weeks and it hasn't prompted this kind of result |
| 11:17 |
dbs |
And I thought we had added guards to the "book on an enter key" basic DoS scenario over the past few releases |
| 11:18 |
* tsbere |
stares at a list of 92 patrons that are not deleted but have no barcode and wonders why we have left some of these floating around in the first place |
| 11:20 |
Dyrcona |
dbs: The guard only protects the search code. Apache still goes nuts spinning up drones to handle the multiple requests. |
| 11:21 |
JBoyer |
Disabling the form entirely with JS would likely be a good next step. |
| 11:21 |
Dyrcona |
I've done research and there are no good solutions to protect Apache. The best anyone seems to come up with is rate limiting in a firewall. |
| 11:21 |
Dyrcona |
JBoyer: The form still works without JS, though. |
| 11:22 |
JBoyer |
Something like "form.onsubmit = function() { return false; };" at the bottom of a submit handler. |
| 11:22 |
JBoyer |
without as in a browser that doesn't run it, or something else? |
| 11:23 |
Dyrcona |
JBoyer: If the user has disabled JavaScript in their browser or uses the NoScript plugin, the form still works, so disabling JS works for those situations where JS is not disabled. |
| 11:24 |
Dyrcona |
Disabling the form may be a good idea, just the same. |
| 11:24 |
JBoyer |
Sure, but that's not an issue with the opacs in the children's departments of our libraries, which is where I notice this most often. |
| 11:24 |
dbs |
We're pretty much dead in the water if anyone wants to DoS us (we still have local guards in place against searches like "a" and "the" that force the database to seqscan every record) |
| 11:24 |
JBoyer |
(well, noticed at library ips, not every search is obviously from a kids dpet.) |
| 11:25 |
JBoyer |
dbs, have much Stephen King? Is "It" popular? ;) |
| 11:25 |
Dyrcona |
Most sites are vulnerable to some sort of DoS. |
| 11:26 |
Dyrcona |
Disabling the form with JS is probably the best that we can do. There's no Apache configuration for this kind of thing. |
| 11:49 |
miker |
Dyrcona / dbs: there's a branch available for opensrf to protect against some forms of book-on-enter-key -- those where the client throws a request and then disconnects prematurely (which, I imagine, is also the MO for an intentional DoS'er) |
| 11:50 |
Dyrcona |
miker: I wasn't really noticing the problem with OpenSRF, though. It was the 100 or so Apache drones that spin up. |
| 11:51 |
miker |
Dyrcona: the modperl code uses the opensrf modules. that's where I've attempted to address it |
| 11:51 |
dbs |
the Apache drones and their 150M of memory per process :/ |
| 11:52 |
Dyrcona |
miker: I can always take a look when I get the chance, which has not been very often lately. |
| 11:53 |
* dbs |
was tempted to start working with nginx or a similar caching proxy again to try and offload some of that weight, but also doesn't want to add another layer of complexity |
| 11:53 |
Dyrcona |
I've also had a hard time reproducing this myself on a test environment. |
| 11:53 |
dbs |
miker: ah that's what I was thinking of, didn't realize it hadn't been merged yet |
| 11:54 |
miker |
in particular, a pile-up occurs when we get a spew of requests that take a long time to process. the apache backends wait for the opensrf request to finish, even if the client side has gone away. the branch attempts avoid that wait, by checking at 1s intervals for client connectedness when it's inside modperl |
| 11:54 |
miker |
dbs: well, we have had same-search guards for a long time ... 2.5, maybe? ... but that only saves the middle layer and the db |
| 11:55 |
miker |
https://bugs.launchpad.net/opensrf/+bug/1616501 |
| 11:55 |
pinesol_green |
Launchpad bug 1616501 in OpenSRF "Stop waiting for method response when browser disconnects" [Wishlist,New] |
| 11:57 |
miker |
there's an evergreen side to that patch, I think |
| 11:58 |
miker |
hrm... or I just left it incomplete? |
| 11:58 |
* miker |
looks |
| 12:01 |
miker |
there is ... I just left it at home, I think :) |
| 12:02 |
* miker |
makes a note to push that soon |
| 12:05 |
|
bmills joined #evergreen |
| 12:07 |
|
brahmina joined #evergreen |
| 12:16 |
miker |
Bmagic: not sure why, but your branch was ... wonky. maybe because we generally avoid using merge? anyway, since you didn't amend the commits with signoffs (meaning they were the same as from my branch -- no change to the commit message) I just pulled my original commits into master. treating the LP bug as your signoff |
| 12:17 |
pinesol_green |
[sipserver|Mike Rylander] LP1579144: On Login, Send Location to ILS - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=8404478> |
| 12:17 |
pinesol_green |
[sipserver|Mike Rylander] LP1579144: Let admin decide on the precedence of the location codes per institution - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=133bf03> |
| 12:17 |
pinesol_green |
[sipserver|Mike Rylander] LP1579144: Make client_location_code a hard switch, and default to original behavior - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=38369b4> |
| 12:17 |
pinesol_green |
[sipserver|Mike Rylander] LP1579144: Give Sip/MsgType.pm a copy of to_bool() from ILS.pm - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=4551a05> |
| 12:23 |
* jeff |
rebases in light of that being pushed |
| 12:34 |
dbs |
CDBI reminder: Processing of hold failed: Can't locate object method "workstation" via package "action::circulation" at OpenILS/Application/Storage/CDBI.pm line 181 suggests I need to add "workstation" to CDBI/action.pm, yeah? |
| 12:35 |
dbs |
because it's not there in rel_2_10 or master. hmm. |
| 12:35 |
* dbs |
goes back to check local code for any possible complications |
| 12:40 |
* dbs |
also half-seriously wonders if we should teach autogen.sh to generate CDBI/*.pm from fm_IDL.xml |
| 12:43 |
Stompro |
Hello, does anyone know if the OSRFTranslatorCacheServer value in the apache/eg_vhost.conf is actually used? I tried grepping for that string but the only place it shows up is in the example eg_vhost files. |
| 12:43 |
tsbere |
Stompro: That is used by OpenSRF itself, not Evergreen |
| 12:43 |
jeff |
it is indeed used. |
| 12:43 |
Stompro |
Doh, thanks |
| 12:43 |
jeff |
by the OpenSRF translator, oddly enough. ;-) |
| 13:16 |
jeffdavis |
That has caught me up before too. :) |
| 13:17 |
csharp |
what if I just don't wanna create a reports template right now? |
| 13:18 |
csharp |
@excuse |
| 13:18 |
pinesol_green |
csharp: Down time is a fact of business when you're a poor 501c3 corporation. |
| 13:19 |
tsbere |
csharp: "The nullability selector is acting up for me and I don't have time to dig into why" ;) |
| 13:21 |
csharp |
tsbere: thanks, that works! |
| 13:21 |
* csharp |
tries turning off and back on again |
| 13:24 |
Dyrcona |
csharp: Going for a short walk sometimes helps. :) |
| 13:32 |
* csharp |
just builds the damn template |
| 13:32 |
berick |
csharp++ |
| 13:44 |
|
kmlussier joined #evergreen |
| 14:06 |
csharp |
@blame comcast latency |
| 14:06 |
pinesol_green |
csharp: comcast latency wants the TRUTH?! comcast latency CAN'T HANDLE THE TRUTH!! |
| 14:17 |
dbs |
csharp: as a fellow 2.10.6 site, are you seeing those "Processing of hold failed" errors about missing "workstation" method? |
| 14:19 |
dbs |
We've had holds successfully placed by users and staff in the past couple of days, so our 3 such errors over the past 2 days seems random (but of course I know it's never random) |
| 14:25 |
csharp |
csharp: we're actually on 2.9.1-ish and don't see those errors |
| 14:27 |
|
ssieb joined #evergreen |
| 14:27 |
csharp |
we do see a lot of 'Processing of hold failed' errors resulting from the copy_once_per_hold constraint |
| 14:28 |
csharp |
which tells me that something's borked somewhere in the app layer, but at least there aren't dupes |
| 14:28 |
Dyrcona |
dbs: Have you tried the patch that went into master recently? |
| 14:28 |
Bmagic |
miker: sounds good - I didnt think I did that right |
| 14:29 |
Dyrcona |
Oh. Maybe that's something different. Never mind. |
| 14:29 |
Bmagic |
There was a merge conflict, which caused me to do a standard commit on top |
| 14:30 |
|
jihpringle joined #evergreen |
| 14:30 |
Dyrcona |
dbs: What you said while I was out to lunch around 12:35 EDT sounds right. Have you tried that? |
| 14:37 |
dbs |
Dyrcona: I'll try it, because it seems like it can't hurt, but I would have anticipated that someone else would have noticed too |
| 14:37 |
dbs |
csharp: thanks! Sorry, forgot that you're on 2.9-ish |
| 14:38 |
* dbs |
won't try generating the CDBI/*.pm from fm_IDL.xml though, not yet :) |
| 14:39 |
* dbs |
isn't sure if Dyrcona is talking about 2db335069b260 as the recent patch, but yeah we're definitely running that |
| 14:39 |
pinesol_green |
dbs: [evergreen|Dan Wells] LP#1620803 Add missing workstation passthru to AuthProxy - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2db3350> |
| 14:40 |
Dyrcona |
No, I wasn't thinking of another patch for CDBI. |
| 14:40 |
Dyrcona |
s/wasn't/was/ |
| 14:43 |
dbs |
ah the is_possible, yeah, the similarities threw me at first with that one too |
| 14:44 |
jeffdavis |
dbs: we're seeing that hold/workstation error in our logs intermittently also |
| 14:45 |
jeffdavis |
on 2.10.2 |
| 14:45 |
dbs |
jeffdavis: ah, thanks for the corroboration |
| 14:56 |
Dyrcona |
Anything in particular that I should look for in the logs? |
| 14:56 |
csharp |
collaboration++ |
| 14:56 |
Dyrcona |
We're upgrading to 2.10 next month and I should have a look at this on our training server. |
| 14:57 |
* csharp |
searched for 'Processing of hold failed' |
| 15:01 |
Dyrcona |
That simple, eh? ;) |
| 15:30 |
|
bmills joined #evergreen |
| 16:13 |
|
remingtron joined #evergreen |
| 16:22 |
mmorgan |
I know it's fairly late on a Friday afternoon, but should I be able to configure a PATRON_EXCEEDS_FINES penalty to block at a certain library when they owe, say, $10.00 in bills from any library in the consortium? |
| 16:23 |
mmorgan |
Maybe I have something configured wrong, but it's only blocking based on fines accrued at the library the penalty is set for. |
| 16:30 |
kmlussier |
mmorgan: What is depth that the penalty is set at? |
| 16:32 |
mmorgan |
I originally had it at 0, but that didn't seem to do it. |
| 16:32 |
* kmlussier |
notices that the penalties and alerts section of Evergreen in Action still has not been added to the community docs. :( |
| 16:33 |
kmlussier |
mmorgan: Yeah, that's the depth where I would have expected it to work. But, what do I know? I usually consult you when I have questions regarding penalties. |
| 16:33 |
mmorgan |
:) |
| 16:33 |
|
jvwoolf left #evergreen |
| 16:34 |
kmlussier |
Actually, I think depth would control if the block comes into play when they circulate items at other libraries. |
| 16:35 |
* kmlussier |
needs to run, but hopes mmorgan gets her answer. |
| 16:35 |
mmorgan |
Yes, that's what I was thinking. |
| 16:35 |
kmlussier |
Have a nice weekend everyone! |
| 16:35 |
mmorgan |
You too! |
| 16:38 |
* mmorgan |
is also having trouble getting penalties to recalculate. |
| 16:39 |
* mmorgan |
blames Friday, full moon, ... and squirrels. |
| 16:44 |
phasefx |
and maybe org units |
| 16:45 |
mmorgan |
Likely that, too. |
| 16:46 |
dbs |
parts, always blame parts |
| 16:47 |
mmorgan |
If I remove a PATRON_EXCEEDS_FINES penalty, I have to add another billing to the transaction to get it to apply again |
| 16:48 |
mmorgan |
Shouldn't it be reapplied if the patron is refreshed? |
| 16:53 |
csharp |
I think something has to trigger it - if that were a PINES staff person asking I would just say "don't do that" |
| 16:54 |
mmorgan |
:) |
| 16:55 |
Dyrcona |
Yeah, it's not applied by refreshing a patron. It takes a bill, etc. |
| 16:55 |
phasefx |
weird |
| 16:56 |
mmorgan |
So it works differently than, say a Lost item penalty? Those seem to reapply when refreshed. |
| 16:57 |
tsbere |
mmorgan: Lost item penalty or "they have lost items" status on the patron upper corner? |
| 16:57 |
* mmorgan |
is not having success with that now, either. |
| 16:57 |
Dyrcona |
I thought that was true of all penalties, actually. I've never removed a penalty and refreshed and expected it to do anything useful. |
| 16:58 |
Dyrcona |
A new feature might be to add a command in the staff client to recalculate penalties. |
| 16:58 |
phasefx |
the Refresh button triggers the api call for refreshing penalties |
| 16:59 |
phasefx |
checking something in or out should also do it |
| 17:01 |
mmorgan |
Hmm. On production system, 2.9, penalties are recalculating when I refresh. |
| 17:01 |
mmorgan |
On 2.10.5 test system, penalties don't recalculate when I refresh. |
| 17:01 |
phasefx |
mmorgan: are the org depths the same on the penalty definitions? |
| 17:02 |
phasefx |
between systems |
| 17:02 |
Dyrcona |
And all this time I thought that Refresh only retrieved the patron information again. |
| 17:02 |
phasefx |
wasn't really joking when I suggested org units :) |
| 17:04 |
mmorgan |
So on production system, PATRON_EXCEEDS_FINES has null org_depth |
| 17:04 |
mmorgan |
test system has 0 |
| 17:04 |
phasefx |
what I don't have a good handle on is the behavior with org depths, I just remember they can cause problems |
| 17:04 |
mmorgan |
but it's a consortium wide penalty |
| 17:05 |
* mmorgan |
guesses this won't get solved today will revisit on Monday;-) |
| 17:05 |
phasefx |
mmorgan: I bet if you make it null on the test system it'll work |
| 17:05 |
mmorgan |
Will try that next, but have to run. Have a good weekend, all! |
| 17:05 |
|
mmorgan left #evergreen |
| 17:20 |
|
Stompro joined #evergreen |
| 17:26 |
|
remingtron joined #evergreen |
| 19:12 |
|
bmills joined #evergreen |
| 20:00 |
|
bmills joined #evergreen |
| 21:06 |
|
ssieb joined #evergreen |
| 21:26 |
|
mrpeters joined #evergreen |
| 21:29 |
|
mrpeters left #evergreen |
