| Time |
Nick |
Message |
| 00:08 |
bshum |
And added all the 2.8 links to the Code Museum page for long term reference, once we nix the 2.8 final off the main downloads areas. |
| 00:24 |
pinesol_green |
[evergreen|Dan Wells] LP#1578716 Fix Responsive Items Out - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e56780c> |
| 00:32 |
|
bmills joined #evergreen |
| 00:34 |
|
bmills left #evergreen |
| 02:09 |
|
dcook joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:12 |
|
TARA joined #evergreen |
| 07:26 |
|
agoben joined #evergreen |
| 07:40 |
|
kmlussier joined #evergreen |
| 07:40 |
kmlussier |
Good morning #evergreen! |
| 07:40 |
|
rjackson_isl joined #evergreen |
| 07:45 |
rhamby_ |
Good morning |
| 07:45 |
|
collum joined #evergreen |
| 07:49 |
|
Callender joined #evergreen |
| 07:51 |
|
ericar joined #evergreen |
| 08:16 |
|
mrpeters joined #evergreen |
| 08:24 |
|
TARA joined #evergreen |
| 08:27 |
kmlussier |
@dessert |
| 08:27 |
* pinesol_green |
grabs some Coconut Cream Cake for kmlussier |
| 08:35 |
|
geoffsams joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:57 |
|
bos20k joined #evergreen |
| 09:11 |
|
yboston joined #evergreen |
| 09:11 |
|
jvwoolf joined #evergreen |
| 09:24 |
|
maryj joined #evergreen |
| 09:39 |
* dbs |
waves at csharp from F24-beta |
| 09:39 |
dbs |
bshum++ |
| 09:52 |
kmlussier |
Did a bug ever get filed for the issues with web client installation since the upgrade to AngularJS 1.5? |
| 09:53 |
bshum |
kmlussier: Dyrcona and I talked about it and decided to reopen the original bug since master isn't a release (yet) |
| 09:53 |
bshum |
But then I didn't get to actually do it yet |
| 09:54 |
bshum |
I figured to reopen since it would have more of the history that way, and maybe gmcharlt and berick could figure out what we're missing that they had when it got pushed in |
| 09:55 |
kmlussier |
OK, I'm just trying to track down an issue I see on webby with unsaved data prompts in the patron editor that I'm 99% sure I didn't see on our local server. But I don't have another system to check it against. |
| 09:55 |
kmlussier |
Of course, the problem could have developed with changes that were added to the web client since then, so I probably should just file the bug. |
| 09:56 |
bshum |
For fun, I did revert the commits for angular 1.5 from one of my master test systems and successfully built the webstaff afterwards using the old version. |
| 09:57 |
* bshum |
wanders off to meetings |
| 10:01 |
|
rlefaive joined #evergreen |
| 10:06 |
|
terran joined #evergreen |
| 10:11 |
kmlussier |
Hmmm, actually, the problem is not seen on the ESI community demo server. |
| 10:13 |
kmlussier |
gmcharlt: Is webby running master or 2.10? I'm just wondering if an issue I see there might be related to the angular 1.5 upgrade since I'm not seeing it on your community demo server. |
| 10:17 |
graced |
kmlussier: expect webby to be "down" for the next 3 days |
| 10:18 |
kmlussier |
graced: OK. I'll hold off on filing any bugs then. :) |
| 10:18 |
graced |
We are actively pushing a ton of Sprint 3 development so things will be in flux and/or broken |
| 10:19 |
graced |
Webby is currently running our most recent branch, not master or 2.10 |
| 10:29 |
|
mrpeters joined #evergreen |
| 11:34 |
|
bmills joined #evergreen |
| 11:34 |
|
bmills left #evergreen |
| 11:50 |
|
bmills joined #evergreen |
| 11:54 |
|
Christineb joined #evergreen |
| 12:45 |
|
brahmina joined #evergreen |
| 12:58 |
|
bmills joined #evergreen |
| 12:58 |
|
jvwoolf joined #evergreen |
| 13:02 |
|
brahmina joined #evergreen |
| 13:03 |
|
jihpringle joined #evergreen |
| 13:05 |
bshum |
@dessert |
| 13:05 |
* pinesol_green |
grabs some Shamrock Shakes for bshum |
| 13:05 |
bshum |
Figures |
| 13:06 |
bshum |
And I did try to order a milkshake today, only to be told that the machine was "broken" |
| 13:06 |
bshum |
:( |
| 13:11 |
|
gsams joined #evergreen |
| 13:12 |
|
bmills joined #evergreen |
| 13:17 |
|
gsams joined #evergreen |
| 13:20 |
|
TARA joined #evergreen |
| 13:34 |
terran |
bshum: I had the same (milkshake) problem yesterday :( |
| 13:36 |
bshum |
@love milkshakes |
| 13:36 |
pinesol_green |
bshum: The operation succeeded. bshum loves milkshakes. |
| 13:53 |
|
Callender joined #evergreen |
| 15:21 |
|
jvwoolf joined #evergreen |
| 15:42 |
|
jlitrell joined #evergreen |
| 15:47 |
kmlussier |
It's a quiet day in #evergreen land |
| 15:49 |
* mmorgan |
was thinking the same thing, and was debating whether to break the silence with some hold targeter questions :) |
| 15:49 |
terran |
Hold targeter? Sounds like a good time for me to log off! :) |
| 15:50 |
* mmorgan |
watches as folks scurry away ;-) |
| 15:51 |
mmorgan |
Ok, here goes. |
| 15:51 |
bshum |
Yes, in theory. |
| 15:51 |
kmlussier |
There are other topics out there that are more likely to make me scurry than holds targeting *cough* billing *cough* |
| 15:52 |
* jeff |
grins |
| 15:52 |
mmorgan |
When the hold targeter runs, does it only act on hold that have a prev_check_time that's 24 hours old? |
| 15:53 |
mmorgan |
s/hold/holds |
| 15:53 |
bshum |
mmorgan: I think it'll act on any holds with prev_check_time outside the limit specified in the hold_targeter script (which is by default, 24 hours) |
| 15:54 |
bshum |
So , yes :0 |
| 15:54 |
kmlussier |
mmorgan: That's my understanding, as long as you didn't change that hardcoded value in hold_targeter.pl. But my understanding my be wrong. |
| 15:54 |
kmlussier |
Or *may* be wrong |
| 15:55 |
mmorgan |
Ok, the hardcoded value is the default 24 hours. |
| 15:56 |
mmorgan |
And the targeter also runs when a request is made, right? |
| 15:57 |
tsbere |
mmorgan: Generally when the request is made or edited, or when staff tell it to with find another target |
| 15:59 |
mmorgan |
tsbere: ok, makes sense. |
| 16:00 |
mmorgan |
And there's curently no way for one library to have a different retargeting interval than another, right? It's all hardcoded in the script? |
| 16:00 |
tsbere |
Interestingly, if you don't specify the 24h in those calls I think it defaults to 12h in the background |
| 16:00 |
tsbere |
mmorgan: That would be correct at this point in time |
| 16:01 |
* tsbere |
can think of multiple ways to change that, but hasn't ever had a good reason to change it |
| 16:03 |
mmorgan |
I'm looking at the situation where a chosen pickup library is closed for the weekend. A patron places a hold on something on Saturday evening. |
| 16:03 |
mmorgan |
We have the ou setting set to true to target libs when they are closed if the copy is at the pickup lib. |
| 16:05 |
mmorgan |
The hold retargets on Sunday evening and another library captures the hold on Monday morning when they process their pull list and sets the item in transit |
| 16:06 |
mmorgan |
The patron could have had it ready for pickup on Monday morning from the pickup lib if the hold hadn't moved on. |
| 16:06 |
tsbere |
Yea, that can be annoying. |
| 16:07 |
mmorgan |
Yes. :-( |
| 16:09 |
bshum |
That's the kind of thing where we kind of wish hold stalling wasn't so soft :) |
| 16:09 |
bshum |
And applied to targeted holds for a period of time too. |
| 16:09 |
bshum |
Or you know, magic. |
| 16:09 |
* bshum |
wonders if custom hold sort order would help in any of these situations. |
| 16:10 |
tsbere |
mmorgan: I can think of some other "tricks" to help alleviate that. A nightly cron job that looks for new holds and bumps the prev_check_time up by a day when the current_copy's circ_lib = pickup_lib could help fix that without major code changes anywhere. |
| 16:10 |
bshum |
Probably not enough, it'll always move on during a retarget I guess. |
| 16:10 |
jeff |
bshum++ "Or you know, magic." |
| 16:10 |
tsbere |
You could even run it only on the specific days you care about, so it doesn't change during the week behavior. |
| 16:11 |
mmorgan |
tsbere: interesting. |
| 16:11 |
|
brahmina joined #evergreen |
| 16:12 |
tsbere |
mmorgan: Want me to see if I can whip up a quick SQL query for you? |
| 16:12 |
mmorgan |
The magic sounds good, too. :) |
| 16:13 |
bshum |
SQL is magic. |
| 16:13 |
mmorgan |
tsbere: thanks for the offer, but I can work one up to try. |
| 16:14 |
tsbere |
mmorgan: I recommend comparing request_time to prev_check_time, if they are <24 hours apart and the circ_lib/pickup_lib match then bump prev_check_time |
| 16:15 |
mmorgan |
So just updating the prev_check_time in the holds will fool the hold targeter. Sounds almost simple! |
| 16:15 |
tsbere |
only so much as "to prevent the cron job targeter from finding the holds" - Other things that trip it will still cause it to run |
| 16:16 |
mmorgan |
gotcha. |
| 16:17 |
mmorgan |
tsbere++ bshum++ |
| 16:18 |
mmorgan |
Anyone want to talk about billing now? |
| 16:18 |
* mmorgan |
ducks. |
| 16:18 |
* tsbere |
throws rotten fruit aimed at mmorgan's knees ;) |
| 16:19 |
* kmlussier |
scurries away |
| 16:22 |
tsbere |
mmorgan: I can also think of ways to just plain make that check part of the backend code, with or without an OU setting, so... |
| 16:24 |
mmorgan |
It would be useful to have it as part of the code to accommodate libraries with different opening schedules. |
| 16:25 |
mmorgan |
If a library is open every day, we wouldn't want to delay retargeting. |
| 16:25 |
tsbere |
Well, with the "run sql as a cron job" you could also embed the library ids to do the check for and only run it on the days that matter |
| 16:26 |
mmorgan |
Yes, that was what I was thinking. |
| 16:26 |
tsbere |
With changing the base code it would be more complicated. I would likely implement this kind of thing as an "extension" to the normal check time for new holds targeting copies at the pickup library... |
| 16:27 |
tsbere |
Then let each library have a different extension time, defaulting to 0 |
| 16:27 |
tsbere |
But that doesn't cover per-day headaches, such as "only do this on saturday and sunday", so... |
| 16:28 |
|
jvwoolf joined #evergreen |
| 16:29 |
jeff |
Are you looking for "has this library been open at least X hours since this hold was requested," or are you needing to base it off of the last target time and not the request time? |
| 16:30 |
mmorgan |
It would be great if the check time would take closings into account library closings as part of the calculation. |
| 16:30 |
mmorgan |
Boy, that didn't make any sense at all :-( |
| 16:30 |
tsbere |
jeff: There are a lot of potential ways to handle things. All have good and bad things going for them. |
| 16:35 |
kmlussier |
My concern is that if it became too complex, it might add even more time that it takes for the holds targeter to run. |
| 16:35 |
tsbere |
kmlussier: Provided that all the checks are part of the "which holds are we targeting" chunk it shouldn't make things too much worse as that runs *once* per cron job invocation |
| 16:37 |
mmorgan |
How often do others run the hold targeter? |
| 16:38 |
tsbere |
We run it every 15 minutes, if we were to run it nightly I would probably change the 24h to 12h or something. |
| 16:38 |
tsbere |
Just to ensure it actually targeted things |
| 16:40 |
mmorgan |
We run it every 15 minutes also. Is the time it takes to run a concern only if it's run once a day? |
| 16:41 |
tsbere |
Well, it can be problematic if it takes more than the time between runs to run, as then you get "ALREADY RUNNING!" messages. |
| 16:41 |
tsbere |
But that applies to quite a few cron jobs |
| 16:44 |
kmlussier |
I'm curious. If holds are targeted as soon as they are placed or edited, and the individual holds only retarget every 24 hours, what is the benefit of running the holds targeter every 15 minutes? |
| 16:44 |
kmlussier |
Instead of doing it every night. |
| 16:46 |
tsbere |
Cycles holds during the day, prevents a single "target for several hours every night" session. And with a stock hold targeter script allows daily retargeting instead of every other day retargeting. |
| 16:47 |
mmorgan |
Running it every 15 minutes would always retarget those that were placed 24 hours + 15 minutes ago. In smaller chunks than retargeting everything once a day. |
| 16:49 |
kmlussier |
mmorgan: My concern with the time it take to run comes from previous releases where slow holds targeting seemed to be a problem. A few of those issues were identified in bug 1272316. |
| 16:49 |
pinesol_green |
Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" [High,Fix released] https://launchpad.net/bugs/1272316 |
| 16:49 |
jeffdavis |
mrpeters: are you around? |
| 16:53 |
mmorgan |
kmlussier: Thanks for the reference. Good to keep all that in mind. |
| 16:59 |
mrpeters |
i am jeff |
| 16:59 |
kmlussier |
Ha ha. For a minute, I though mrpeters was claiming to be jeff. :) |
| 17:00 |
mrpeters |
haha ooops :P |
| 17:00 |
berick |
hear me roar |
| 17:00 |
mrpeters |
jeffdavis: i am here :) |
| 17:02 |
|
jvwoolf left #evergreen |
| 17:02 |
jeffdavis |
mrpeters: I'm pushing a few small changes to overdrive-eg-opac which should make it play more nicely with 2.10 (although still need those Sitka commits for now) |
| 17:03 |
mrpeters |
sweet! |
| 17:03 |
mrpeters |
ill be taking a close look at that next month when i get ready to upgrade one of our customers who is using it |
| 17:03 |
jeffdavis |
cool |
| 17:04 |
jeffdavis |
I was concerned that one change would break compatibility with EG < 2.9, but I think I've found a way around that |
| 17:06 |
|
mmorgan left #evergreen |
| 18:46 |
|
berick joined #evergreen |
| 19:55 |
|
geoffsams joined #evergreen |
| 20:04 |
|
hopkinsju joined #evergreen |
| 22:00 |
|
artunit_away joined #evergreen |
| 22:27 |
|
bmills joined #evergreen |
| 22:43 |
|
bmills left #evergreen |
