| Time |
Nick |
Message |
| 01:04 |
|
StomproJ joined #evergreen |
| 02:29 |
|
mrisher joined #evergreen |
| 03:16 |
|
cmalm joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:24 |
|
agoben joined #evergreen |
| 06:57 |
|
rjackson_isl joined #evergreen |
| 07:19 |
|
rlefaive joined #evergreen |
| 07:33 |
rlefaive |
hey folks, has anyone used evergreen’s Emergency Closing feature before? |
| 07:34 |
agoben |
We're using it a lot right now |
| 07:34 |
agoben |
(And have occasionally in the past) |
| 07:35 |
rlefaive |
we want to push all due dates of existing loans to April 27, but we’re still “open” and signing stuff out (to be due april 27). Is that a reasonable use for this tool? |
| 07:42 |
agoben |
That's how we've done it. If the library chooses to stay open, the only difference is that any new due dates get pushed to the 27th then, and no OD fines are assessed if you charge them. |
| 07:44 |
agoben |
And for the libraries that close to the public then, everything is already in place and it's one less thing they have to worry about. |
| 07:44 |
agoben |
We'll be re-evaluating for a further extension later in April. |
| 07:47 |
rlefaive |
thanks agoben! that’s awesome. |
| 07:48 |
agoben |
Good luck!!! |
| 08:01 |
csharp |
also know that closed dates mean that hold requests are not assigned to the closed unit |
| 08:04 |
agoben |
Only if the one library setting is set to skip for targeting when closed. Otherwise, you should still be able to target when closed. |
| 08:11 |
rhamby |
one thing I'm seeing a lot of libraies want that the emergency closing handler doesn't do is push out patron expirations so that they don't get stuck unable to use electronic resources |
| 08:12 |
rhamby |
I've been pushing those out a lot recently but thinking about an LP for that as an optional feature for it |
| 08:19 |
agoben |
We're doing that too, within the limits still in force by law. |
| 08:19 |
|
sandbergja joined #evergreen |
| 08:20 |
agoben |
I'm pretty sure some sort of tool for that would work. I know you can do it with patron buckets, but it's a pain. |
| 08:21 |
rhamby |
yeah, I'm thinking another checkbox in the emergency closing handler that says "also push out expirations for patrons in this time" |
| 08:22 |
rhamby |
not a big deal but a nice quality of life thing for extended closings, which hopefully will be a far end of the bell curve concern |
| 08:26 |
|
mantis1 joined #evergreen |
| 08:29 |
agoben |
Sounds like a nice option to me. |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:44 |
|
Dyrcona joined #evergreen |
| 08:55 |
alynn26 |
Rhamby++ |
| 08:56 |
* Dyrcona |
missed something? |
| 08:56 |
Dyrcona |
To the logs! |
| 08:57 |
Dyrcona |
Ah, yeah. We're using emergency closings and I'm updating patron expiration dates via SQL tonight. |
| 08:58 |
Dyrcona |
Some of our bigger members have trouble with emergency closing. It takes a while to update 100,000 open circs. |
| 08:59 |
Dyrcona |
rhamby: +1 to the Lp on extending patron expiration via emergency closing. |
| 09:00 |
rhamby |
I'll add the LP today. It sounds like we're all having to do it. It's minor but could be useful even for short closings. |
| 09:05 |
|
terranm joined #evergreen |
| 09:10 |
terranm |
rhamby++ for the idea to include pushing patron expiration dates back too |
| 09:14 |
rhamby |
submitted as wishlist |
| 09:16 |
|
sandbergja_ joined #evergreen |
| 09:23 |
|
jvwoolf joined #evergreen |
| 09:32 |
|
mdriscoll joined #evergreen |
| 09:33 |
|
mantis2 joined #evergreen |
| 09:48 |
mmorgan |
rhamby++ |
| 09:55 |
|
jvwoolf1 joined #evergreen |
| 10:21 |
|
collum joined #evergreen |
| 10:35 |
|
sandbergja joined #evergreen |
| 11:02 |
mmorgan |
Anyone using Emergency Closing Handler to update past due dates? That is, add a closed date that's in the past and mark it as an emergency closing? |
| 11:03 |
terranm |
Yes, we use it |
| 11:03 |
Dyrcona |
Not that I'm aware of. We let the libraries enter the dates themselves (Local Admin can do it). We help them if they need assistance, and that's not me. |
| 11:06 |
terranm |
Our libraries usually do it themselves, but we help them as needed. It takes forever to process the closures and update the fines/due dates, but as far as I've seen it's working well. |
| 11:07 |
jeff |
our approach was to use SQL to bump due dates on most items not already 45 days overdue, and to update expiry dates on patrons not more than one year expired. |
| 11:08 |
jeff |
some various exclusions for certain things |
| 11:08 |
jeff |
at this point in time, we left existing fines on those circs that were already overdue before our closure. |
| 11:10 |
Dyrcona |
I am doing a SQL update tonight for circulations that are still checked out, not LOST nor CLAIMSRETURNED. |
| 11:11 |
Dyrcona |
Also, not messing with fines, because it's to messy in my opinion. We're recommending that libraries use amnesty mode if they want to skip fines, etc. |
| 11:20 |
|
mrisher joined #evergreen |
| 11:23 |
mmorgan |
terranm: For overdue items, does it remove (i.e. void or adjust) fines? |
| 11:23 |
* mmorgan |
has never tried it for past due dates. |
| 11:23 |
agoben |
It's supposed to void them. |
| 11:24 |
agoben |
It's been a while since I had a reason to do it though. |
| 11:35 |
mmorgan |
Ok, so if we extend due dates for overdue items using an sql query, fines will remain, if we use the emergency closing, fines will be removed. |
| 11:39 |
jeff |
If you're only doing an UPDATE on action.circulation and the transactions already have fines, then there will be no change to the already billed fines. |
| 11:42 |
jeff |
emergency closing functions seem to void fines but also seem to do it in a way different from backdating/amnesty checkin, which is interesting. |
| 12:01 |
|
Christineb joined #evergreen |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:06 |
Dyrcona |
Regarding bug 1867789, we're discussing do that via SQL locally. It will probably be done Thursday night at the rate things are going. |
| 12:07 |
pinesol |
Launchpad bug 1867789 in Evergreen "Emergency Closing Handler Should Push Back Hold Expirations" [Wishlist,New] https://launchpad.net/bugs/1867789 |
| 12:07 |
|
mmorgan1 joined #evergreen |
| 12:08 |
jeff |
also, one library's SHOULD is another library's MUST NOT |
| 12:10 |
Dyrcona |
Well, yeah. That goes without saying. :) |
| 12:10 |
collum |
Yep. That's why I chose wishlist instead of bug. This would be a nice option. |
| 12:11 |
Dyrcona |
Guess we'll get even more dials to spin. |
| 12:11 |
Dyrcona |
:) |
| 12:15 |
collum |
Oops! That was referencing Rogan's similar but different bug. :) |
| 12:16 |
Dyrcona |
S'allright. Yours is a good idea, too. |
| 12:22 |
|
rlefaive joined #evergreen |
| 12:30 |
csharp |
quote add <jeff> one library's SHOULD is another library's MUST NOT |
| 12:30 |
csharp |
@quote add <jeff> one library's SHOULD is another library's MUST NOT |
| 12:30 |
pinesol |
csharp: The operation succeeded. Quote #201 added. |
| 12:32 |
Dyrcona |
@quote get 200 |
| 12:32 |
pinesol |
Dyrcona: Quote #200: "<Dyrcona> Chasing NULL pointers is worse than chasing rabbits." (added by csharp at 04:38 PM, July 12, 2019) |
| 12:32 |
* Dyrcona |
had no idea, honestly. |
| 12:34 |
Dyrcona |
@quote random |
| 12:34 |
pinesol |
Dyrcona: Quote #51: "< dbwells> As I mentioned last night, though, it is easy to reach these brick wall moments with search. You index, it's really fast, you get excited, you realize it isn't doing some important thing, you try to add it, it gets slow, you cry. That is my experience with evaluating search." (added by csharp at 01:35 PM, April 12, 2013) |
| 12:53 |
|
jvwoolf joined #evergreen |
| 13:10 |
|
sandbergja joined #evergreen |
| 13:28 |
|
mmorgan left #evergreen |
| 13:32 |
|
khuckins joined #evergreen |
| 13:34 |
|
rfrasur joined #evergreen |
| 13:49 |
|
sandbergja joined #evergreen |
| 14:10 |
|
mmorgan joined #evergreen |
| 14:21 |
|
sandbergja joined #evergreen |
| 14:29 |
|
rlefaive joined #evergreen |
| 15:19 |
Dyrcona |
Anyone remember what's wrong when you get a list of blank search results? You get like 1. through 10 with a blank space where the brief description should be? It's happening on my dev VM. I'm going to do an ingest, but thought I'd ask if anyone remembers something else being wrong. |
| 15:21 |
Bmagic |
reingest |
| 15:34 |
StomproJ |
Anyone have a good way of stopping hold pickup notices for one system, but allowing for another when one system is closed, one is open, share the same event def. Staff are checking things in even when we are closed for a few weeks, generating hold pickup notices. |
| 15:35 |
StomproJ |
Change the context org of the event def? |
| 15:36 |
jihpringle |
StomproJ: staff doing checkin at the closed branch could use the "Supress Holds and Transits" check in modifier than the holds won't be captured and should show up on the pull list when the library re-opens |
| 15:37 |
jeff |
change the A/T defs around? use a json filter? use capture local holds as transits? |
| 15:37 |
StomproJ |
Thank you for the ideas. |
| 15:38 |
jeff |
jihpringle: when using suppress holds and transits, do you encounter issues with items that should have transited elsewhere and are now "nowhere" in certain ways? |
| 15:39 |
jihpringle |
I don't think we've had any libraries use it for long periods so we haven't run into that as far as I'm aware |
| 16:19 |
|
rlefaive joined #evergreen |
| 16:28 |
|
mantis2 left #evergreen |
| 16:51 |
Dyrcona |
Stomproj: Use a filter, or we're updating holds to remove email_notify and sms_notify at libraries' request. |
| 16:52 |
Dyrcona |
I'm keeping the original values in a separate table so I can put them back later, if necessary. |
| 16:58 |
StomproJ |
I just changed the owner of the event def so the system that is staying open longer owns it. I think that should only generate events for that org now. |
| 17:05 |
mmorgan |
StomproJ: Maybe a custom a/t filter that limits to just the pickup libraries that want them? |
| 17:05 |
mmorgan |
suppress holds and transits leaves items in Reshelving status that should be in transit. We've had problems with that in the past. |
| 17:06 |
* mmorgan |
will likely be looking at these issues tomorrow. |
| 17:06 |
mmorgan |
Stay healthy, everyone! |
| 17:06 |
|
mmorgan left #evergreen |
| 17:35 |
|
jvwoolf left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:44 |
|
mrisher joined #evergreen |
| 19:09 |
|
cmalm joined #evergreen |
| 19:21 |
|
cmalm joined #evergreen |
| 20:25 |
|
sandbergja joined #evergreen |
| 20:57 |
|
mantis1 joined #evergreen |
| 20:58 |
|
mantis1 left #evergreen |
| 21:11 |
|
Dyrcona joined #evergreen |
