| Time |
Nick |
Message |
| 03:17 |
|
sandbergja joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
Dyrcona joined #evergreen |
| 07:26 |
|
agoben joined #evergreen |
| 07:38 |
|
Dyrcona joined #evergreen |
| 08:27 |
|
bos20k joined #evergreen |
| 08:34 |
|
jvwoolf joined #evergreen |
| 08:47 |
|
mmorgan joined #evergreen |
| 09:04 |
|
jvwoolf1 joined #evergreen |
| 09:16 |
|
dbwells joined #evergreen |
| 09:20 |
|
yboston joined #evergreen |
| 09:43 |
|
sandbergja joined #evergreen |
| 10:05 |
|
khuckins joined #evergreen |
| 10:08 |
|
sandbergja joined #evergreen |
| 10:30 |
|
seymour joined #evergreen |
| 10:43 |
|
sandbergja joined #evergreen |
| 11:02 |
|
yboston joined #evergreen |
| 11:08 |
|
Christineb joined #evergreen |
| 11:38 |
|
stephengwills joined #evergreen |
| 11:51 |
|
yboston joined #evergreen |
| 11:57 |
|
aabbee joined #evergreen |
| 12:05 |
|
stephengwills_ joined #evergreen |
| 12:08 |
|
mmorgan1 joined #evergreen |
| 12:31 |
|
stephengwills joined #evergreen |
| 12:32 |
|
yboston joined #evergreen |
| 12:36 |
|
mmorgan joined #evergreen |
| 12:36 |
|
sandbergja joined #evergreen |
| 12:40 |
|
gsams_ joined #evergreen |
| 12:46 |
|
khuckins joined #evergreen |
| 12:59 |
|
jvwoolf joined #evergreen |
| 13:15 |
|
Dyrcona joined #evergreen |
| 13:24 |
|
mmorgan left #evergreen |
| 13:57 |
pinesol |
[evergreen|Jane Sandberg] LP1828840: Option to hide grid save settings button in angular grid - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=0ab8e87> |
| 14:30 |
|
Dyrcona joined #evergreen |
| 14:50 |
|
khuckins joined #evergreen |
| 14:54 |
|
sandbergja joined #evergreen |
| 15:23 |
|
sandbergja joined #evergreen |
| 15:32 |
|
HomerPublicLibra joined #evergreen |
| 15:36 |
|
jvwoolf joined #evergreen |
| 15:40 |
|
cmalm joined #evergreen |
| 16:09 |
jeff |
Dyrcona: around? you were talking about granularity and granularity-only the other day... |
| 16:10 |
Dyrcona |
yeahp |
| 16:11 |
jeff |
around here: http://irc.evergreen-ils.org/​evergreen/2019-06-27#i_410724 |
| 16:12 |
jeff |
I think in the following lines you described seeing different behavior when specifying a granularity with --granularity=foo with and without --granularity-only |
| 16:12 |
Dyrcona |
Yes. |
| 16:13 |
Dyrcona |
--granularity foo runs that granularity and null granularity event defs. |
| 16:13 |
Dyrcona |
At lest for one stage. |
| 16:13 |
Dyrcona |
It's in the logs at some point. |
| 16:13 |
jeff |
But it looks like there's a line early in the action_trigger_runner.pl script that forces $opt_gran_only to 1 when $opt_granularity being trueish. |
| 16:13 |
Dyrcona |
It's different for --process-hooks and --run-pending, IIRC. |
| 16:13 |
jeff |
Oh! If you were basing your observations on the log output, I think those may lie about this. |
| 16:14 |
jeff |
That might explain things. |
| 16:14 |
Dyrcona |
I was basing it on a number of things, and asking me for details now is a mistake, but I'm pretty sure I saw it in the code, too. |
| 16:15 |
jeff |
I'll continue to dig. Thanks. :-) |
| 16:16 |
jeff |
The line in question overrides $opt_gran_only early enough that I don't think it gives the logs a chance to lie in the way I thought they might. |
| 16:20 |
Dyrcona |
OK. I don't remember the details, 6/27 was two lifetimes ago. |
| 16:23 |
jeff |
Yep. I started looking into something yesterday and remembered the conversation, went looking for it. |
| 16:35 |
jvwoolf |
Has anybody ever noticed that if a hold is captured and then released back into the wild (due to a canceled transit or retarget while on the hold shelf) the expiration date doesn't come back? |
| 16:36 |
jeff |
We don't use expiration on holds much, so I can't say I've noticed it, but it doesn't surprise me. |
| 16:38 |
jvwoolf |
jeff: It took us this long to notice. :) |
| 16:39 |
jeff |
action.hold_request.expire_time is cleared when a hold is suspended/frozen or when an item is captured for that hold. |
| 16:39 |
jeff |
(possibly other times, but those are the two that stand out most) |
| 16:40 |
jvwoolf |
Probably when canceled, too, from what I've seen. |
| 16:40 |
jvwoolf |
I didn't find a bug report, so I guess I'll file one. |
| 16:41 |
jeff |
I can see how it might be desirable to preserve and re-assign the previous expire_time when a hold no longer has a copy captured, but since we don't use it much to begin with (yet -- we might start), I'm not sure I'm not imagining use cases. :-) |
| 16:42 |
jeff |
If a hold's expire_time has passed when the hold is reset / transit cancelled, should the hold expire_time be set to that original time, which is now in the past? |
| 16:43 |
Dyrcona |
jeff: It's all relative. |
| 16:45 |
jeff |
Interesting quirks with expire_time and uncancel_hold... |
| 16:50 |
jvwoolf |
jeff: If the expire time has passed, the hold will be canceled anyway. |
| 16:52 |
jeff |
Well, it won't because the expire_time was cleared when the hold was captured... I guess I should have asked "if we preserve the original expire_time and try to restore it when the hold no longer has a copy captured, what should happen?" |
| 16:54 |
jeff |
probably "in that case, the hold should get whatever default expire time a newly placed hold would get"? |
| 16:55 |
Dyrcona |
Unless, of course, you're traveling at 0.99C... |
| 16:55 |
jeff |
a granularity of "0" is not recommended. |
| 17:00 |
jvwoolf |
jeff: That would be a pretty rare case. So yeah, I'd agree that it should get whatever a new hold would get. |
| 17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:28 |
|
sandbergja joined #evergreen |
| 18:11 |
|
sandbergja joined #evergreen |
| 19:03 |
|
sandbergja joined #evergreen |
| 21:20 |
|
sandbergja joined #evergreen |
| 23:18 |
|
sandbergja joined #evergreen |
| 23:28 |
|
sandbergja joined #evergreen |
| 23:32 |
|
jamesrf joined #evergreen |
