| Time |
Nick |
Message |
| 04:37 |
|
gsams joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:07 |
|
TARA joined #evergreen |
| 07:11 |
|
berickm joined #evergreen |
| 07:26 |
|
rangi` joined #evergreen |
| 07:30 |
|
rjackson_isl joined #evergreen |
| 08:03 |
|
serflog joined #evergreen |
| 08:03 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 08:04 |
bshum |
@roulette |
| 08:04 |
pinesol_green |
bshum: *click* |
| 08:05 |
|
mrpeters joined #evergreen |
| 08:07 |
|
rlefaive joined #evergreen |
| 08:23 |
|
Dyrcona joined #evergreen |
| 08:25 |
|
berickm joined #evergreen |
| 08:27 |
|
TARA joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 09:07 |
kmlussier |
@coffee |
| 09:07 |
* pinesol_green |
brews and pours a cup of Hawaii Isla Kona Mauka, and sends it sliding down the bar to kmlussier |
| 09:08 |
jeff |
morning, kmlussier |
| 09:23 |
|
jvwoolf joined #evergreen |
| 09:39 |
kmlussier |
jeff: Good morning! |
| 09:48 |
|
mllewellyn joined #evergreen |
| 09:48 |
|
yboston joined #evergreen |
| 10:01 |
|
mmorgan1 joined #evergreen |
| 10:37 |
|
sandbergja joined #evergreen |
| 11:00 |
|
agent11 joined #evergreen |
| 11:02 |
|
mmorgan joined #evergreen |
| 11:18 |
|
Christineb joined #evergreen |
| 11:21 |
|
rhamby joined #evergreen |
| 11:22 |
* Dyrcona |
subclasses OpenILS::Utils::Cronscript for a special project. |
| 11:30 |
gmcharlt |
Dyrcona: so... you're Conscript'ing it them? ;) |
| 11:31 |
Dyrcona |
gmcharlt++ |
| 11:31 |
Dyrcona |
I s'pose I am. |
| 11:31 |
Dyrcona |
I'm basically doing something along the lines of what TestUtils does. |
| 11:32 |
Dyrcona |
I've got two scripts where I'll be retrieving the same objects and updating them, so I figured subclass Cronscript and add the common functions there. |
| 11:32 |
Dyrcona |
One script blocks a library's patrons from using a location and the other removes any such block. |
| 11:35 |
Dyrcona |
I've also added a login() method that might be useful in Cronscript itself. |
| 11:37 |
Dyrcona |
It's basically a wrapper around authenticate that converts a file of JSON to perl and then calls authenticate. |
| 11:42 |
|
bmills joined #evergreen |
| 11:50 |
kmlussier |
Acq question. If somebody activates and order and then cancels it before ESI pusher runs, will that order still be sent via EDI? |
| 11:51 |
kmlussier |
That would be EDI, not ESI |
| 11:53 |
csharp |
@who is the ESI pusher? |
| 11:53 |
pinesol_green |
pinesol_green is the ESI pusher. |
| 11:54 |
csharp |
kmlussier: I think it *will* still process the order unless you remove the event from the DB before the pusher runs |
| 11:54 |
csharp |
activating the order creates the A/T event |
| 11:54 |
csharp |
(PO JEDI) |
| 11:55 |
kmlussier |
csharp: Thanks, that's what I thought. |
| 11:57 |
JBoyer |
That makes 2 validators that could probably stand some additional options. You don't want to send canceled orders, and perhaps you don't want circ A/T events to fire for closed circs. (We send Damaged notices, but it's a little embarrassing if they pay for the damage upfront and then the notice goes out anyway...) |
| 12:03 |
|
vlewis joined #evergreen |
| 12:04 |
tsbere |
JBoyer: Doesn't "CircIsOpen" handle that last one? |
| 12:06 |
JBoyer |
tsbere: You're right. I might be thinking of something else, because I was thinking that even with that there was some weird wrinkle that allowed them to be processed anyway. |
| 12:06 |
JBoyer |
I need to look it over again, it's been too long. :( |
| 12:10 |
JBoyer |
Oh, there is it. CircIsOpen means "it's not checked in yet," not "this transaction hasn't been closed yet" i.e. it doesn't look at xact_finish, only checkin_time. |
| 12:12 |
JBoyer |
So open bills (the only type we want to send notices about) on returned items don't show up. Since Damage sometimes gets noted after the item is retuned (it is "here," after all) that isn't a 100% fix. |
| 12:12 |
JBoyer |
Maybe I can put something together in LP to put this to bed. |
| 12:13 |
JBoyer |
(I can add it to the pile of things I'm "working" on simultaneously today. :( ) |
| 12:20 |
mmorgan |
Quick survey: How many rows do others have? select count(*) from permission.grp_penalty_threshold |
| 12:24 |
bshum |
mmorgan: How many do you have? :) |
| 12:26 |
mmorgan |
bshum: Well originally, 2, but that number's about to grow. |
| 12:27 |
bshum |
I think we used to define fines penalty per library, so we had a lot. |
| 12:27 |
mmorgan |
I'm attempting to set up different thresholds for different libraries. |
| 12:27 |
bshum |
Same for checkouts too |
| 12:28 |
mmorgan |
Our patrons can travel around, so they could potentially be blocked in one library, but not in another. |
| 12:30 |
mmorgan |
I'm trying a consortium level penalty at a lower threshold, and a system penalty at a higher threshold. |
| 12:30 |
mmorgan |
At the library with the higher threshold, the patron isn't blocked, which is what I want. |
| 12:31 |
mmorgan |
They travel to another library and the consortium level penalty blocks them. This is ok, too. |
| 12:32 |
mmorgan |
They go back to the higher threshold library and they're still blocked by the cons level penalty. :-( |
| 12:33 |
jeff |
Is anyone here currently making use of "group" or "family" accounts, either with a special profile or with some other methods? |
| 12:34 |
|
jihpringle joined #evergreen |
| 12:35 |
bshum |
mmorgan: I have a feeling that won't work out quite as you'd like then |
| 12:35 |
bshum |
mmorgan: If the CONS level penalty is a lower threshold, that'll kick in and block them |
| 12:35 |
bshum |
It applies the penalties if the circumstances fit |
| 12:36 |
bshum |
And I don't know if Dyrcona's new feature for 2.10 will help any: https://bugs.launchpad.net/evergreen/+bug/1499123 |
| 12:36 |
pinesol_green |
Launchpad bug 1499123 in Evergreen "Ability to Ignore Certain Standing Penalties Within a Proximity to the Patron's Home Library" [Wishlist,Fix released] |
| 12:36 |
bshum |
I think the situation you're describing is a little different |
| 12:36 |
jeff |
This somewhat ties into "friends" and actor.usr.usrgroup, etc. |
| 12:36 |
jeff |
(sorry, my inquiry -- not mmorgan's) |
| 12:37 |
mmorgan |
So I really can't do a cons level penalty, I have to do specific ones for each library? |
| 12:37 |
bshum |
mmorgan: If I were building it annoyingly, I would go with a lower level penalty at all libs, and then the higher one, and forgo a CONS level penalty |
| 12:37 |
bshum |
Which I think is why we ended up with limits at each library individually. |
| 12:38 |
bshum |
I don't remember if it worked out all that well either though. |
| 12:38 |
bshum |
Cause I think penalty calculation for fines might take location into account. |
| 12:38 |
bshum |
So if a penalty is $5.00 for library X, it'll only rack up fines for library X towards that penalty |
| 12:38 |
bshum |
But maybe I'm misremembering |
| 12:39 |
mmorgan |
bshum: ok, thanks. So to specify a higher threshold at one library, I need a row for each library, so that means 28 rows for us for that one penalty. |
| 12:40 |
bshum |
mmorgan: I fear that may be the case. But perhaps others can confirm whether we were doing it wrong all this time. |
| 12:41 |
mmorgan |
jeff: We're not using patron groups at all. |
| 12:41 |
bshum |
jeff: I'm not either :P |
| 12:43 |
jeff |
and no "family" or "group" cards implemented outside of any such Evergreen feature, where there's something like a special permission group with larger-than-normal-patron limits, etc? :-) |
| 12:44 |
bshum |
Isn't there family grouping in Library ELF or whatnot? |
| 12:44 |
* bshum |
doesn't look behind the curtain or subscribe |
| 12:44 |
jeff |
don't know! i'll check! |
| 12:46 |
bshum |
That might have been only for checking on stuff already out. I don't think it ties with patron limits in any way |
| 12:47 |
jeff |
if you pay extra, library elf will store credentials for multiple accounts. |
| 12:47 |
* bshum |
finishes his lunch and disappears again |
| 12:47 |
jeff |
of course, i've no idea what would prevent you from just setting up one library elf account for each card, but... *shrug* |
| 12:48 |
* mmorgan |
sets about adding some rows to permission.grp_penalty_threshold |
| 12:48 |
mmorgan |
bshum++ |
| 12:48 |
jeff |
IMO, if library elf offers a patron of one of our libraries a compelling feature we're probably doing a poor job of serving our patrons. :-) |
| 12:49 |
Dyrcona |
mmorgan: That new feature that bshum pointed out still doesn't completely help with your situation. |
| 12:49 |
Dyrcona |
You can only apply 1 block of a type. |
| 12:50 |
Dyrcona |
What happens with the ignore proximity it the patron will be blocked everywhere but their home library. |
| 12:50 |
Dyrcona |
It would take development or possibly different org unit penalties to do what you want to do. |
| 12:51 |
Dyrcona |
And, sandbergja is interested in a similar feature, I think. |
| 12:51 |
kmlussier |
jeff: I'm a Library Elf user, and I pay for it so that I can get notifications for multiple family members. It's not a group, per se, just that I can add as many library cards, from as many systems, that I want. |
| 12:52 |
kmlussier |
jeff: Doing multiple Library Elf accounts is really no different than having multiple library accounts. They notices would each be sent to a separate email address, which was leading to the problem where overdues weren't getting returned. |
| 12:52 |
mmorgan |
Dyrcona: Thanks! |
| 12:52 |
* kmlussier |
's kids never check their email. |
| 12:52 |
* mmorgan |
runs off for a bit |
| 12:53 |
kmlussier |
Also, my local library isn't an Evergreen library, so my use of Library Elf doesn't speak to Evergreen's functionality. |
| 12:54 |
* sandbergja |
starts reading over this discussion, since penalties + ignore proximities are super interesting |
| 13:02 |
|
berickm joined #evergreen |
| 13:13 |
|
rhamby joined #evergreen |
| 13:16 |
sandbergja |
Dyrcona: I know we've chatted about this before, and that it would be a total pain, but how would you see the lower consortium-wide penalty threshold working from a staff perspective (ignoring for a moment how much of a pain it'd be to change all the circulation logic)? |
| 13:17 |
sandbergja |
I was just thinking about another column in config.standing_penalty called something like apply_automatically? |
| 13:17 |
sandbergja |
and if that is set to true, it'll apply whatever penalty automatically; otherwise staff will apply it manually? |
| 13:18 |
sandbergja |
just brainstorming/trying to wrap my head around things |
| 13:20 |
Dyrcona |
Well, the only penalties that apply automatically are ones that Evergreen knows about: overdues, lost, etc. |
| 13:20 |
Dyrcona |
Others are applied manually by staff. |
| 13:21 |
Dyrcona |
Barring difficulty of changing circulation code, the lower threshold consortium penalty would work like it does now, with ignore proximity taken into account. |
| 13:21 |
Dyrcona |
Changes would be needed to apply a second penalty at the higher threshold to block the patron again at their home library. |
| 13:22 |
Dyrcona |
I've experimented with different thresholds for the same penalty and it is only applied once at the lower penalty. |
| 13:22 |
sandbergja |
Makes sense |
| 13:22 |
Dyrcona |
That last "penalty" should be "threshold" but I think everyone understood. |
| 13:23 |
sandbergja |
So, we'd need to create a second penalty at a higher threshold, and then do some development to make it apply automatically |
| 13:23 |
sandbergja |
and the development would be a pain and very time-intensive and dependent on getting community support |
| 13:23 |
sandbergja |
does that sum it up? |
| 13:24 |
sandbergja |
(or just come up with some local script) |
| 13:25 |
sandbergja |
but if we wanted something that lived in EG, there'd have to be some way to create a custom penalty that could be applied automatically? |
| 13:26 |
JBoyer |
Development wise, one way this could be done is by "applying" every penalty that uh, applies, to the user and at the time of an attempted transaction only using the threshold of the most "specific" (think CSS) given the context OUs, etc. Then when checking an item out at home you get the higher threshold, and abroad you get the lower. Also none of this exists, so caveat reador I suppose. |
| 13:27 |
JBoyer |
That would also complicate the patron summary display as now you have to do a bunch of work to determine which of the applied penalties applies here. |
| 13:28 |
sandbergja |
That does sound complicated |
| 13:28 |
sandbergja |
But very cool! |
| 13:29 |
JBoyer |
It's much easier if everyone just agrees on all of the limits. :) |
| 13:30 |
sandbergja |
JBoyer: truer words were never spoken :-) |
| 13:30 |
Dyrcona |
But, yeah, pretty much. ;) |
| 13:31 |
JBoyer |
(BTW, we have 23 for mmorgan's query, but every one is applied at the top level, the only differences are the groups. :) ) |
| 13:32 |
sandbergja |
I also don't quite understand how the "classic" penalties (e.g. overdues, lost) get applied; is there a daemon or something that is adding and removing records to actor.usr_standing_penalty, or is it something cooler? |
| 13:32 |
Dyrcona |
sandbergja: They are added by the fine code in general. |
| 13:33 |
Dyrcona |
When fines are calculated, penalties are calculated and applied. |
| 13:33 |
Dyrcona |
There are other triggers for lost, I think. |
| 13:35 |
sandbergja |
Dyrcona: thanks; that's good to know |
| 13:56 |
|
jlitrell joined #evergreen |
| 14:22 |
|
rangi joined #evergreen |
| 15:01 |
Bmagic |
mmorgan: 93 rows in permission.grp_penalty_threshold |
| 15:04 |
mmorgan |
Bmagic: Thanks! |
| 15:08 |
|
mmorgan1 joined #evergreen |
| 15:17 |
|
mmorgan joined #evergreen |
| 15:51 |
berickm |
interesting talk on http://electron.atom.io/ at #c4l -- maybe a better way to implement Hatch |
| 15:57 |
Dyrcona |
So many frameworks....so little time. |
| 16:29 |
|
collum joined #evergreen |
| 16:44 |
* phasefx |
read "Build cross platform desktop apps with web technologies" and thought XUL <cringes> :) |
| 16:44 |
gmcharlt |
phasefx: circle of life.... ;) |
| 16:47 |
csharp |
@blame XUL |
| 16:47 |
pinesol_green |
csharp: XUL is why we can never have nice things! |
| 16:49 |
gmcharlt |
pinesol_green is wise |
| 16:49 |
pinesol_green |
gmcharlt: Ba ba ba dook Dook DOOK! |
| 16:49 |
pinesol_green |
Factoid 'is wise' not found |
| 16:49 |
gmcharlt |
or maybe not so much! ;) |
| 16:50 |
csharp |
gmcharlt++ |
| 16:54 |
dbwells |
hah |
| 16:56 |
Dyrcona |
heh |
| 17:08 |
|
mmorgan left #evergreen |
| 17:08 |
|
jvwoolf left #evergreen |
| 17:19 |
|
bmills joined #evergreen |
| 18:02 |
|
genpaku_ joined #evergreen |
| 18:21 |
|
Stompro joined #evergreen |
| 19:44 |
|
geoffsams joined #evergreen |
| 19:46 |
|
barbara joined #evergreen |
| 19:48 |
|
jeffdavi1 joined #evergreen |
| 19:48 |
|
berick_ joined #evergreen |
| 19:51 |
|
graced joined #evergreen |
| 22:02 |
|
genpaku joined #evergreen |
| 22:12 |
|
bmills joined #evergreen |
| 23:49 |
|
jeffdavis joined #evergreen |
