Evergreen ILS Website

IRC log for #evergreen, 2020-04-06

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
04:00 berick joined #evergreen
04:38 alynn26 joined #evergreen
04:41 AFloyd__ joined #evergreen
06:56 rfrasur joined #evergreen
07:18 rjackson_isl_hom joined #evergreen
07:37 Dyrcona joined #evergreen
08:07 jvwoolf joined #evergreen
08:32 mmorgan joined #evergreen
08:36 jvwoolf joined #evergreen
08:40 jvwoolf1 joined #evergreen
08:47 Stompro joined #evergreen
09:02 sandbergja joined #evergreen
10:31 mantis1 joined #evergreen
11:13 sandbergja_ joined #evergreen
11:26 Bmagic Does the matching hold rule dictate "where" the item should be sourced? I'm running into a situation where the generic consortium rule is getting matched and the copy that is filling the hold is not from the pickup branch (there is an available copy that could fill the hold at the pickup branch) - my theory is that the hold rule is the culprit?
11:26 collum joined #evergreen
11:28 csharp Bmagic: the hold rule just checks that the hold is allowed at all - it doesn't affect which copy gets targeted
11:29 Bmagic thought so!
11:29 Bmagic csharp++
11:29 csharp so many moving parts
11:29 csharp and the mechanism is far less happy with widespread closures in place
11:31 Bmagic this library is still allowing "curb-side" pickup - the library is closed in the system, however, the YAOUS "Target copies for a hold even if copy's circ lib is closed" is on for the system. Maybe it needs to be set at the branch?
11:33 csharp the setting should be inherited, I would think
11:33 csharp perhaps hold boundaries should be set just for the branch?
11:37 Bmagic I'm looking at HoldTargeter.pm
11:37 Dyrcona Is the copy on the same volume/bib as the hold?
11:37 Bmagic line 706
11:39 Bmagic it's confusing, but I think* $self->parent->get_ou_setting() climbs the tree
11:39 csharp it should
11:41 Dyrcona Bmagic: Which HoldTargeter.pm?
11:41 Bmagic Utils
11:42 Bmagic I see that it makes calls to the cache
11:42 Bmagic I wonder if the issue is temporary while the cache is old
11:43 miker Bmagic: if it's not already, you may need to set the related YAOUS that mentions the pickup library. they're orthogonal, not additive.
11:44 Bmagic miker: a setting other than "Target copies for a hold even if copy's circ lib is closed" ?
11:44 lisacarlucci joined #evergreen
11:45 miker yes. not at a computer ATM, so can't look up the exact name
11:46 Bmagic I wonder if the cache is caching that null setting for the branch and not checking the system level setting because the null setting already exists in cache?
11:46 berick Bmagic: if get_ou_setting() was busted, we'd have a lot more problems
11:47 Bmagic yeah - the implications of what I was saying would have been larger than this scenario
11:52 rfrasur joined #evergreen
11:53 Bmagic So the theory is that the cache was stale. The setting was changed 3/20. How long does it take to clear cache? It looks like the "cache" is variables in a running instance of Evergreen? my $c = $self->{ou_setting_cache};  or does that refer to memcached?
11:54 berick Bmagic: that cache is created and destroyed with every instance of the targeter.
11:54 Bmagic dang - that blows that out of the water
11:59 alynn26_away joined #evergreen
12:04 mmorgan Bmagic: I think you want this ou setting: "Target copies for a hold even if copy's circ lib is closed IF the circ lib is the hold's pickup lib"
12:04 Bmagic I saw that - wasn't sure. I'l try that
12:05 Dyrcona Bmagic: Are the hold and copy on the same bib and/or volume, depending on hold type.
12:05 Bmagic bib hold, attached copy is available at pickup library
12:05 Dyrcona Sometimes, people overlook this when it is the same title, but large print, etc., can skew things.
12:06 Dyrcona Bmagic: It shows up in the hold copy map?
12:06 Dyrcona If it's not there, nothing you do will make a difference.
12:07 * Dyrcona is wrestling with dynamic queries for a homegrown function.
12:09 jihpringle joined #evergreen
12:19 mrisher joined #evergreen
12:21 Dyrcona dow_0_open being Monday causes a slight headache with date math in the database. Since 0 is normally Sunday with EXTRACT.....
12:26 Dyrcona Bleh.... Trying to figure out if a library is open on a given day or not from pure SQL is apparently harder than it sounds, at least in a generic way.
12:36 Christineb joined #evergreen
12:39 Dyrcona OK. It turns out not to be so hard if you coerce timestamps to dates to avoid the milliseconds on the close_start and close_end fields. :)
12:58 ericar joined #evergreen
13:05 rfrasur joined #evergreen
13:13 Dyrcona For the curious, this is what I have been working on: https://pastebin.com/50ybEL9t
13:42 mmorgan Dyrcona: So you're looking at hours open and days closed to get a library's next open date?
13:44 Dyrcona mmorgan: Yes, and one of the functions needs a check to prevent an infinite loop when there are no hours of operation for the org unit.
13:44 mmorgan Dyrcona++
13:45 Dyrcona I'll update the paste later when I decide which. I'm taking my lunch and afternoon breaks to walk the dog, now.
13:45 rfrasur infinite_loop--
13:47 berick Dyrcona: I have some code in a pullrequest that does that.  in Perl, though.
13:47 * berick searches bugs
13:49 berick bug 1829295
13:49 pinesol Launchpad bug 1829295 in Evergreen "Shelf expire date doesn't respect closed dates" [Wishlist,Confirmed] https://launchpad.net/bugs/1829295
13:50 berick don't know if that helps you at all, but seemed worth mentioning
13:58 alynn26 exit
14:39 khuckins joined #evergreen
14:59 jeff berick++
15:12 rfrasur joined #evergreen
15:13 Dyrcona berick: Cool. I'm want something that I can use from SQL.
15:17 Dyrcona mmorgan: I updated the paste on pastebin with a shortcut for cases where the org_unit has no actor.hours_of_operation entry. It just returns TRUE. It could raise an error instead, but I think this works for what I want it to do.
15:20 rfrasur joined #evergreen
15:21 mmorgan Dyrcona: Great. What will you using it for?
15:22 Dyrcona mmorgan: I'm going to update due dates, patron expiration dates, and a few other dates again. I plan to use the functions to take open and closed dates into account.
15:22 mmorgan Ok, gotcha.
15:31 rfrasur_ joined #evergreen
15:56 mantis1 left #evergreen
16:23 jihpringle joined #evergreen
16:57 dbwells_ joined #evergreen
17:01 miker Dyrcona: fwiw, evergreen.find_next_open_time() from the emergency closing handler code has something that attempts to detect "hours-of-operation closed" situations, if you're just looking for inspiration
17:02 Dyrcona miker: I didn't know about that function. I can take a look tomorrow. (I'm off the clock, now, and what I have works so far.)
17:02 rjackson_isl_hom joined #evergreen
17:16 mmorgan left #evergreen
17:23 rjackson_isl_hom joined #evergreen
17:32 collum joined #evergreen
19:20 collum joined #evergreen
19:41 dbwells joined #evergreen
22:24 collum joined #evergreen
22:24 sandbergja joined #evergreen
22:56 sandbergja joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat