| Time |
Nick |
Message |
| 00:49 |
|
gsams joined #evergreen |
| 04:03 |
|
unpriviledged joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:19 |
|
agoben joined #evergreen |
| 07:21 |
|
rjackson_isl joined #evergreen |
| 07:51 |
|
ericar joined #evergreen |
| 07:57 |
|
graced joined #evergreen |
| 07:58 |
|
collum joined #evergreen |
| 08:31 |
|
rlefaive joined #evergreen |
| 08:35 |
|
Dyrcona joined #evergreen |
| 08:44 |
Dyrcona |
@later tell hbrennan You can sorta do what you want by limiting a temp. patron to 3 checkouts with a penalty threshold of patron exceeds checkouts, just make sure it doesn't apply to regular patrons. |
| 08:44 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 08:48 |
|
mmorgan joined #evergreen |
| 08:50 |
|
maryj joined #evergreen |
| 08:58 |
|
Christineb joined #evergreen |
| 09:09 |
|
jvwoolf joined #evergreen |
| 09:19 |
|
bos20k joined #evergreen |
| 09:48 |
mmorgan |
@coffee |
| 09:48 |
* pinesol_green |
brews and pours a cup of Rwanda Karaba Fair Trade, and sends it sliding down the bar to mmorgan |
| 10:04 |
|
mmorgan1 joined #evergreen |
| 10:19 |
|
webmind joined #evergreen |
| 10:27 |
|
JBoyer joined #evergreen |
| 10:28 |
|
JBoyer joined #evergreen |
| 10:29 |
|
JBoyer joined #evergreen |
| 10:31 |
|
jwoodard joined #evergreen |
| 10:39 |
Dyrcona |
When testing email changes to your script, it helps to not typo the recipient email address. |
| 10:43 |
|
blake joined #evergreen |
| 10:45 |
Bmagic |
Can statistical categories be setup to "show" / "suggest" / "require" in patron registration? |
| 10:45 |
jeff |
you can require them. |
| 10:45 |
Dyrcona |
jeff beat me to it. |
| 10:45 |
jeff |
and you can show them in the summary sidebar. |
| 10:45 |
Bmagic |
oh, that's interesting |
| 10:46 |
Bmagic |
I couldn't find the setting |
| 10:46 |
jeff |
i don't think that you can "suggest" them in the same way that you can other fields. |
| 10:46 |
jeff |
it's per-stat cat. |
| 10:46 |
jeff |
so in the user stat cat editor, you can require and you can show in summary. |
| 10:46 |
jeff |
and you can expose via sip, copy when aging circs, etc. |
| 10:46 |
Bmagic |
ah! I see |
| 10:46 |
jeff |
it is also there that you can determine if they permit free-form entry or only select from a list. |
| 10:47 |
tsbere |
Most of our "expose via sip" is more "expose that they have *any* entry" because we hardcoded the output |
| 10:47 |
* tsbere |
rigged it so you could do that specifically for the "friend of the library" use case where you want a library code more than whatever they put in there |
| 10:47 |
Bmagic |
thanks you guys |
| 11:01 |
|
mmorgan joined #evergreen |
| 11:03 |
|
brahmina joined #evergreen |
| 11:54 |
|
jihpringle joined #evergreen |
| 11:56 |
jeffdavis |
Dyrcona: missed your question yesterday - Z39.50 server response times are still super slow even when zurl points at localhost rather than a separate OPAC server :( |
| 11:57 |
Dyrcona |
jeffdavis: Well, I didn't necessarily expect it to be faster. We made the move for stability. |
| 11:58 |
Dyrcona |
Also, our zurl points to a server other than the one that runs simple2zoom, now, but that may not matter much. |
| 11:59 |
Dyrcona |
jeffdavis: How are you testing response times? yaz-client? |
| 12:02 |
bshum |
jeffdavis: Also kind of curious, which version of yaz you're using with the service (the one that shipped with Ubuntu 12.04 was terribad, so we always used the yaz repo off indexdata direct to get the best of the best) |
| 12:02 |
bshum |
It's probably not related, but just call me curious :D |
| 12:05 |
jeffdavis |
I've been testing with yaz-client 4.2.18 |
| 12:06 |
Bmagic |
Anyone know of a request/wishlist item where Evergreen should automatically bill patrons on a regular bases AKA: non-resident fee ? |
| 12:06 |
jeffdavis |
the server itself is running 4.2.30 which I believe is what comes with Ubuntu 14.04 |
| 12:10 |
bshum |
jeffdavis: So you're basing slow off the "elapsed time" for a given search parameter against your zurl target, and then comparing that with timings for searches done via the catalog directly? |
| 12:10 |
jeffdavis |
bshum: correct |
| 12:12 |
JBoyer |
jeffdavis: are you including holdings information in your results? |
| 12:12 |
|
bmills joined #evergreen |
| 12:16 |
jeffdavis |
yes |
| 12:16 |
JBoyer |
(I figured, that is the most useful way to use it.) |
| 12:17 |
jeffdavis |
we are including holdings and searching at a specific org unit rather than across the consortium, both of which seem to slow things down quite a bit |
| 12:17 |
JBoyer |
That's where most of the delay is though, when only returning the records it seems much faster. That' |
| 12:17 |
JBoyer |
s great for sharing records, lousy for materials sharing groups. :( |
| 12:23 |
|
jwoodard joined #evergreen |
| 12:45 |
|
jihpringle joined #evergreen |
| 12:49 |
Dyrcona |
jeffdavis: We're using the same version of yaz. |
| 12:50 |
Dyrcona |
My experience corroborates with JBoyer's. Z searches are a lot faster when not retrieving holdings. |
| 14:08 |
Bmagic |
berick and anyone - the web based staff client doesnt seem to be respecting the "show patron statistical categories in the summary pane" setting |
| 14:09 |
berick |
Bmagic: bug it! |
| 14:09 |
Bmagic |
k, just checking |
| 14:10 |
berick |
Bmagic: do you know the org unit setting name/code offhand? |
| 14:10 |
Bmagic |
it's a property of the stat cat itself |
| 14:10 |
berick |
ah |
| 14:11 |
berick |
Bmagic: looks like the code is there to show them.. |
| 14:12 |
Bmagic |
oh? |
| 14:12 |
Bmagic |
hmmm, perhaps it's my workstation registration |
| 14:12 |
Bmagic |
I bet that is it |
| 14:13 |
Bmagic |
yep |
| 14:13 |
Bmagic |
berick++ |
| 14:14 |
berick |
cool |
| 14:14 |
Dyrcona |
Do the -commit mailing lists require administrator approval to join? |
| 14:14 |
Bmagic |
Who runs the mail list server in question? |
| 14:15 |
Dyrcona |
csharp does |
| 14:15 |
Bmagic |
that's what I thought |
| 14:15 |
Dyrcona |
I'm messing with mailing list subscriptions and the -commits lists acted strange compared to the others. |
| 14:16 |
* Dyrcona |
hopes he didn't break the server. |
| 14:16 |
Bmagic |
Anyone know of a request/wishlist item where Evergreen should automatically bill patrons on a regular bases AKA: non-resident fee ? |
| 14:16 |
Bmagic |
Dyrcona: I am sure you didn't |
| 14:17 |
Dyrcona |
That request for a recurring billing sounds familiar, but I'm not sure there is a LP bug. |
| 14:17 |
Dyrcona |
And, I don't think I did, either. |
| 14:17 |
Bmagic |
I wrote a recurring billing NOTICE but not recurring bill |
| 14:17 |
tsbere |
Bmagic: Sounds familiar, but I don't think I have seen it hit launchpad or anything |
| 14:17 |
* tsbere |
can think of multiple ways to accomplish that with a cronjob, though |
| 14:19 |
Bmagic |
tsbere: yeah, we could setup a query to run on a cron, but we would like it to be more fleshed out with library settings and action triggers |
| 14:19 |
Bmagic |
so that it's more "professional" and adoptable - unless everyone agrees that the feature wont get much traction in the community |
| 14:19 |
tsbere |
Bmagic: I was thinking more perl cronjob than SQL cronjob, which could easily pull in library settings and even fire off action/trigger notices if you wanted |
| 14:20 |
* tsbere |
isn't as sure about integrating it into A/T, but that is probably doable as well, though the entire thing seems like it would be more closely related to the fine generator code-wise |
| 14:21 |
Bmagic |
I agree, we thought of a hack where we could checkout a special book to non resident people, with a checkout period of a year, and a yearly fine of $25, lol |
| 14:22 |
Dyrcona |
The opensrf-commits list confirmation response finally came through. |
| 14:22 |
Bmagic |
Dyrcona: that feels good |
| 14:23 |
tsbere |
Bmagic: I would go with a special bill type and create grocery bills of that type, though as I said I am less certain about making it part of A/T ;) |
| 14:23 |
* tsbere |
doesn't think basing A/T event times on "the last time we billed them with this billing type" would be easily written |
| 14:23 |
Bmagic |
tsbere: what is wrong with using AT? |
| 14:24 |
Bmagic |
tsbere: I see, yeah, that does sound complex |
| 14:24 |
Bmagic |
probably a sql view would help |
| 14:24 |
tsbere |
Bmagic: Wouldn't stop code from firing off a "create events" call, though. So A/T could still be used to send notices about the billing. |
| 14:25 |
Dyrcona |
Well, could you base it on expiration date if the patrons expire at the same time the few is due. |
| 14:25 |
Dyrcona |
s/few/fee/ |
| 14:25 |
Bmagic |
Dyrcona: we thought of that, but updating the expiration date before the patron expired would spoil the billing |
| 14:26 |
Bmagic |
either we have to introduce a new datetime column in actor.usr or we base the billing on money.billing with a special billing type |
| 14:26 |
Dyrcona |
Well, make a non-resident patron type that expires in one year, but otherwise has the same privileges as a resident patron. |
| 14:27 |
Dyrcona |
We have some libraries who charge out of state patrons for a network (i.e. consortium-wide) card. |
| 14:28 |
Dyrcona |
I don't recall if they charge them every time it expires, but they manage that outside of the ILS. |
| 14:28 |
Bmagic |
I vote for money.billing {special billing type} datetime recurrence |
| 14:29 |
Dyrcona |
There was also some talk of ending the practice recently, but it ended up being so few patrons that the board decided to leave things alone. |
| 14:30 |
Dyrcona |
Bmagic: It's your feature, so do what you think works. |
| 14:31 |
Bmagic |
Dyrcona: lol, I dont mind coding it, but we would like it to be adopted of course, so I would like to code it appropriately |
| 14:31 |
JBoyer |
This sounds like the kind of thing that would be done with an Active A/T event. Rather than billing them repeatedly, it could be tied to a renewal (i.e. the expiration date changing) or some thing like that. |
| 14:32 |
JBoyer |
That way they're only charged when keeping their account current, and you don't have as many old unpaid bills arouns. |
| 14:32 |
Bmagic |
JBoyer: that's interesting, are you suggesting inserting rows into action_trigger.event upon updating the expiration date of patrons that fit the criteria? |
| 14:33 |
Dyrcona |
Bmagic: The fee could be made a field on the permission group with a default of null, but I'm not sure what others think of that. |
| 14:34 |
Bmagic |
I think you're right, repeating billing on inactive patrons (not patrons who have active unchecked but patrons that are not using the library) seems excessive, but could be coded for |
| 14:34 |
Dyrcona |
Then, when the expiration date changes or whatever, bill the patron. |
| 14:35 |
Dyrcona |
What JBoyer said sounds a lot like what I said, just different in the details. |
| 14:35 |
jeff |
you quickly run into fun with pro-rating and with patrons that are moved out of then back into a group with a "fee"... |
| 14:35 |
JBoyer |
Bmagic: Yes, that's how the active events are handled, but I haven't found many examples of how it's done (may just be in the Db, haven't looked), just the function that ends up creating them. |
| 14:35 |
Bmagic |
I don't agree with the dollar amount being apart of the permission group |
| 14:35 |
Dyrcona |
Bmagic: That's OK. It just seemed like a clean way to store and access it. Other ideas work, too. |
| 14:36 |
Bmagic |
it needs to be customizable per library, and could easily be environment variables in the action trigger (editor=1, billing_amount=$25, patron_type="nonresident") |
| 14:37 |
Dyrcona |
Right. |
| 14:37 |
Bmagic |
with environment variables, we could eliminate library setting bloat |
| 14:38 |
Dyrcona |
Well, I'm not sure I'd want to configure it in the environment when setting up the A/T. |
| 14:39 |
Dyrcona |
I'd rather it be configured elsewhere and read into the environment when the A/T runs, but I could be way off base as I don't mess with A/T that much. |
| 14:39 |
Bmagic |
I have to agree that the UI for environment variables stinks and is easily overlooked |
| 14:39 |
Dyrcona |
TBH, the few times I've messed it that sort of thing, I did it directly in the database. |
| 14:40 |
Bmagic |
haha, so your opinion doesnt count |
| 14:40 |
Bmagic |
he's a spy |
| 14:40 |
Dyrcona |
Always, even I'm not.... |
| 14:40 |
Bmagic |
@who is a spy |
| 14:40 |
pinesol_green |
wsmoak is a spy. |
| 14:40 |
Dyrcona |
"I'm the spy in the House of Love..." |
| 14:41 |
Bmagic |
LOL |
| 14:41 |
* Dyrcona |
plays some Doors. |
| 14:42 |
Bmagic |
so environment variables vs library settings... who wins |
| 14:42 |
Bmagic |
personally, I think library settings are out of control |
| 14:42 |
Dyrcona |
I don't disagree. ;) |
| 14:43 |
Dyrcona |
That said, environment variables are less accessible. |
| 14:44 |
Bmagic |
is there another option? |
| 14:44 |
Dyrcona |
New tables and IDL objects or new fields on existing ones. |
| 14:45 |
Bmagic |
seems extreme |
| 14:45 |
Bmagic |
or excessive rather |
| 14:46 |
Bmagic |
new tables, means new UI's as well? or integration in the patron editor somehow |
| 14:46 |
Dyrcona |
Yes, meaning one or the other. |
| 14:47 |
Dyrcona |
Or adjustments to existing UI if it is associated with a permission group and org. unit somehow. |
| 14:47 |
Dyrcona |
If you stick with environment only, you'd need an A/T setup for each ou that uses a different fee, right? |
| 14:48 |
Bmagic |
it's per library per permission group |
| 14:48 |
Bmagic |
yes, I am thinking an A/T for each implementing library branch/system |
| 14:48 |
Dyrcona |
So, I guess it's a tradeoff between number of A/T configurations versus how complex it would be to use A/T for everything. |
| 14:48 |
Bmagic |
it could be consortium wide if everyone agreed on the same variables |
| 14:49 |
Dyrcona |
Yeah, I'm starting to agree with environment variables. |
| 14:50 |
Bmagic |
we lost Jboyer and Jeff back there somewhere |
| 14:50 |
JBoyer |
Poof! |
| 14:50 |
Bmagic |
jeff rather |
| 14:51 |
JBoyer |
You won't hear me say this often, but I'd probably do the amount in an OUS, provided that would allow the event to apply at a higher level. If you have to have a definition for every system that uses it anyway, then I don't have as much of an opinion. |
| 14:52 |
JBoyer |
Here, it could apply consortially if the def referenced an OUS. If that's not possible with your policies then it's not as big a deal. |
| 14:54 |
JBoyer |
That said, while I certainly agree that there's an excess of OUS, I don't have a pathological aversion to them, I just think they should be for variable values more than "make feature X work like Y or N" I'd prefer that X take the best bits of Y and N and say "That's it." |
| 14:54 |
JBoyer |
/rant. |
| 15:01 |
jeff |
Sorry, I was talking about DDC. |
| 15:01 |
jeff |
I quoted a line that amused me, then walked back into the office to find that it had evolved into a discussion while I was gone. |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:10 |
|
rlefaive joined #evergreen |
| 15:20 |
Bmagic |
JBoyer: right on, well, I think leaving the library settings alone, and putting the settings in the A/T will work and might get adopted by master at some point, I'll go ahead and LP |
| 15:35 |
|
hbrennan joined #evergreen |
| 15:41 |
|
gsams_ joined #evergreen |
| 15:41 |
hbrennan |
Dyrcona: Yeah, I'm trying to avoid a lot of circ policy editing. We've experienced complete ILS meltdown in the past when settings didn't get entered the correct way. |
| 15:52 |
|
jlitrell joined #evergreen |
| 15:59 |
Dyrcona |
hbrennan: Ok. Just a thought I had this morning. |
| 16:00 |
hbrennan |
Dyrcona: It was a good thought |
| 16:01 |
tsbere |
hbrennan: You could have a check for "anyone who has circulated copies in a given patron group" and then change their group and re-calc their penalties in a nightly cronjob |
| 16:01 |
* tsbere |
doesn't think that would be all that hard to write |
| 16:02 |
hbrennan |
tsbere: hmmm. There's an idea |
| 16:02 |
hbrennan |
tsbere: Not something I have the skills to do though. |
| 16:10 |
Bmagic |
hbrennan: we have some code in place that recalculates patron penalties on a cron, otherwise the penalties are only calculated when the staff opens the patron. Our issue was SIP checkouts would allow patrons who shouldn't check something out |
| 16:11 |
tsbere |
Bmagic: How hard would it be to adjust that so that it would look up specific users (profile X and has at least one circ in action.circulation) and do an update of the user before re-calcing them? |
| 16:11 |
hbrennan |
Bmagic: You have so many spiffy cron jobs |
| 16:11 |
Bmagic |
hbrennan: https://github.com/mcoia/mobius_evergreen/tree/master/Random/recalc_penalties - could get you started anyway |
| 16:12 |
hbrennan |
Bmagic: Thanks! |
| 16:13 |
Bmagic |
tsbere: just looking at the code for the first time in years, it looks like it's a sql query |
| 16:15 |
* tsbere |
supposes that, in the context of all of this, he could actually write a single SQL statement that could find the users, update their profiles, and remove the appropriate limitation from their penalties, no perl needed |
| 16:16 |
Bmagic |
tsbere: you are probably right |
| 16:18 |
hbrennan |
So two profiles would be created? So I assign them, for example, to a 2-item limit profile group, then the query reassigns them to the larger circ limit group? |
| 16:18 |
tsbere |
hbrennan: Yes, and then probably looks for and removes any "you hit max items out" penalties in the process |
| 16:19 |
hbrennan |
tsbere: That penalty wouldn't just go away with the profile switch? |
| 16:20 |
tsbere |
Not unless you run a penalty re-calc |
| 16:21 |
jeff |
(easiest way being to click Refresh in the staff client) |
| 16:22 |
tsbere |
jeff: Not if you want it to re-calc overnight ;) |
| 16:22 |
jeff |
(recent discussion about making the web staff client run that re-calc on a patron change) |
| 16:22 |
jeff |
(which could/would impact this current hack) |
| 16:23 |
jeff |
maybe. i've not been following close enough to say for certain. |
| 16:24 |
hbrennan |
jeff: Good to know |
| 16:26 |
hbrennan |
jeff: I just went over max items with a temporary patron, switched them back to regular profile group, and still can't get the Maximum Checked Out block to go away, even with refresh |
| 16:28 |
hbrennan |
jeff: Had to actually go into Messages and remove the penalty |
| 16:28 |
jeff |
hitting the Refresh button in the staff client to the left of the Check Out and Items Out buttons? |
| 16:28 |
hbrennan |
jeff: Yep. Didn't work. |
| 16:29 |
jeff |
Heh. |
| 16:30 |
hbrennan |
jeff: And the penalty message says I can "press a navigation button above to clear this alert"... which also doesn't work |
| 16:30 |
jeff |
I just tried setting myself to a profile that is limited to 3 items out (i have >3), and upon saving my user I get the penalty and on setting my user back to Patrons I lose the penalty. No Refresh needed. |
| 16:30 |
hbrennan |
jeff: Weird... Is "sticky penalties" a thing? |
| 16:30 |
jeff |
So, it's different from what I remembered/thought, but also different from what you're experiencing. |
| 16:31 |
jeff |
Well, only certain penalties are system calculated. |
| 16:32 |
jeff |
But it seems that (at least in 2.10) the XUL / Dojo patron editor interface already has behavior similar to what I thought we were proposing anew to be added in the web staff client. |
| 16:33 |
jeff |
We likely ran into "the now-outdated penalty still remains until refresh or checkout" when doing a batch update of some patron groups in the past. |
| 16:33 |
hbrennan |
jeff: The patron_exceeds penalties for us are set up as system level |
| 16:34 |
jeff |
When I said "system calculated" above I wasn't referring to an OU depth of "system". |
| 16:34 |
tsbere |
jeff: But do you have a *larger* penalty level (100 or 1000 items out) on Patrons? It may be that having nothing set causes them to stick around. |
| 16:34 |
hbrennan |
jeff: Gotcha |
| 16:34 |
jeff |
more "internally by the system" |
| 16:35 |
jeff |
tsbere: that might explain what hbrennan is running into. |
| 16:35 |
hbrennan |
tsbere: Yep. Everyone, even staff, have limits |
| 16:35 |
jeff |
nevermind then. :-) |
| 16:35 |
hbrennan |
* instantly ruins excellent theory |
| 16:35 |
tsbere |
hbrennan: Are they at the same depth as the lower limiting? |
| 16:36 |
tsbere |
(org tree depth) |
| 16:36 |
tsbere |
Or rather, org unit in general, I guess |
| 16:37 |
hbrennan |
tsbere: We have a "User" limit of 50 items at consortium level, no one assigned to that group. Everyone is assigned to a system level group with a circ limit less that or equal to 50 |
| 16:38 |
hbrennan |
tsbere: Our temporary limited group has a limit of 2 items, and I was only using 3 items to block it |
| 16:53 |
|
mmorgan joined #evergreen |
| 17:00 |
|
jvwoolf left #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 17:28 |
|
mrpeters left #evergreen |
| 18:31 |
|
bmills joined #evergreen |
| 20:01 |
miker |
Bmagic: you'd need a new reactor to create a billing based on the environment (I prefer that to a YAOUS, personally) but I think you can do what you want with an appropriate Event Repeatability Delay, and the au.created (or similar) hook |
| 20:03 |
* miker |
notes that the docs are inaccurate re how one can create reactor (and other) a/t modules... they can live anywhere, need not be inside the core code |
