Time |
Nick |
Message |
01:22 |
|
mrisher joined #evergreen |
06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:55 |
|
agoben joined #evergreen |
07:14 |
|
rjackson_isl joined #evergreen |
07:29 |
|
collum joined #evergreen |
08:19 |
|
alynn26 joined #evergreen |
08:25 |
|
rfrasur joined #evergreen |
08:32 |
|
mantis1 joined #evergreen |
08:34 |
|
mmorgan joined #evergreen |
09:11 |
|
mmorgan1 joined #evergreen |
09:36 |
|
dbwells joined #evergreen |
09:40 |
|
jvwoolf joined #evergreen |
09:58 |
|
mmorgan joined #evergreen |
10:02 |
|
berick joined #evergreen |
10:20 |
|
Christineb joined #evergreen |
10:27 |
|
mrisher joined #evergreen |
10:33 |
|
mmorgan1 joined #evergreen |
10:40 |
|
sandbergja_ joined #evergreen |
11:04 |
sandbergja_ |
Emergency closing handler question: I see a hook in the action/triggers, but no event definition. Does anybody have this set up to email patrons whent their due dates get pushed back due to an emergency closure? If so, could you please share your event definition and template? |
11:34 |
|
mmorgan joined #evergreen |
11:59 |
|
BAMkubasa joined #evergreen |
12:01 |
|
jihpringle joined #evergreen |
12:04 |
|
mikerisher joined #evergreen |
12:19 |
|
StomproJ joined #evergreen |
12:26 |
|
mrisher joined #evergreen |
12:28 |
|
mmorgan left #evergreen |
12:32 |
|
Dyrcona joined #evergreen |
12:49 |
|
collum joined #evergreen |
12:54 |
|
khuckins joined #evergreen |
13:19 |
|
rfrasur joined #evergreen |
14:12 |
|
mikerisher joined #evergreen |
14:33 |
dbs |
hmm. getting reports that deleting the last callnumber on a record is resulting in the record getting deleted, even when it contains located URIs. That sounds new... (3.4 here) |
14:36 |
bshum |
Even when, hmm |
14:39 |
Dyrcona |
Are the call numbers for the located URIs deleted? |
14:47 |
|
abowling left #evergreen |
14:51 |
|
dbwells joined #evergreen |
14:51 |
dbs |
Seems fine if I just "Delete items". I'll see what happens when I try "Delete empty call numbers". |
14:52 |
dbs |
That also seems fine. "Delete items and call numbers" next |
14:55 |
Dyrcona |
This sounds familiar. I seem to recall having staff tell me this a couple of years ago, and then i couldn't reproduce it. |
14:55 |
dbs |
And fine with "Delete items and call numbers" as well. I'm using the Holdings view, I'm going to go over and see what they're doing |
14:55 |
Dyrcona |
Then, they couldn't reproduce it, either. I suspect something was up with the particular record, but I don't recall much more. |
14:56 |
dbs |
Always helpful to have another person say they've seen similar weirdness! |
14:58 |
Dyrcona |
Well, it may have been something similar but different. The mind plays tricks..... |
15:04 |
|
abowling joined #evergreen |
15:23 |
dbs |
heh, our staff couldn't reproduce the problem either. I'm wondering if there was a typo in the 856 $9 or something like that |
15:24 |
dbs |
So didn't truly have a located URI |
15:28 |
Dyrcona |
That could definitely be it. |
15:40 |
|
mmorgan joined #evergreen |
15:45 |
|
mantis1 left #evergreen |
16:20 |
|
mrisher joined #evergreen |
16:32 |
mmorgan |
For emergency library closures in a consortium, is there a sure way of preventing holds from capturing to transit to the closed libraries? |
16:35 |
jeff |
In the past we have used the technique of suspending the holds with a very specific activation date, then to "undo" it we activate all of those holds with that specific activation date, so as to try and avoid activating holds that we didn't suspend. |
16:36 |
jeff |
(a specific *future* activation date, to be clear) |
16:36 |
jeff |
some downsides: patrons editing their pickup library need to ALSO activate the holds, unless we also unsuspend any holds where the pickup library has changed and they are suspended with an activation date matching our "specific" date... |
16:37 |
jeff |
and there was at least one other potential gotcha, but it may have simply been that a patron wanting to suspend their holds will see them already suspended, but then we'll activate them potentially before they desire to. |
16:40 |
* mmorgan |
wishes lp 1740147 was a thing. |
16:40 |
mmorgan |
bug 1740147 |
16:41 |
pinesol |
Launchpad bug 1740147 in Evergreen "Wishlist: Provide functionality to bypass capturing for a hold pickup location when the org unit is closed" [Wishlist,New] https://launchpad.net/bugs/1740147 |
16:49 |
mmorgan |
Would setting Hard boundaries for closed libraries stop items from transiting to them? Haven't worked with boundaries before. |
16:58 |
jeff |
it should prevent targeting, but you'd want to test and you'd want to retarget holds |
16:58 |
jeff |
i suspect that there would also be corner cases with non-T hold types and trying to use the boundary |
16:59 |
jeff |
oh, also just changing the OU setting isn't enough there, if that's what you meant. |
16:59 |
jeff |
you need to adjust the boundaries on any outstanding holds, I believe. |
16:59 |
mmorgan |
Ah. ok. Didn't realize the boundaries were stored in the holds. |
17:00 |
mmorgan |
Might experiment with that tomorrow, might just stem the tide enough. |
17:03 |
|
b_bonner11 joined #evergreen |
17:06 |
|
mmorgan left #evergreen |
17:19 |
|
jvwoolf left #evergreen |
17:32 |
Dyrcona |
Too late.... |
17:34 |
Dyrcona |
@later tell mmorgan You can also make the library not a valid pickup location, ping me tomorrow and maybe I'll remember details. |
17:34 |
pinesol |
Dyrcona: The operation succeeded. |
17:37 |
Dyrcona |
Oh, well patches for my router require a reboot, so I'll sign out, now. |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:39 |
sandbergja |
Everyone is asking about closed libraries today. :-( :-( |
19:06 |
|
cmalm joined #evergreen |
19:19 |
csharp |
@band add Virus Squash Week |
19:19 |
pinesol |
csharp: Band 'Virus Squash Week' added to list |
19:47 |
jeff |
sandbergja: yup. :-\ |
21:51 |
|
JBoyer_ joined #evergreen |
23:05 |
|
yar joined #evergreen |