Evergreen ILS Website

IRC log for #evergreen, 2020-07-21

| 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
01:35 sandbergja joined #evergreen
01:40 sandbergja joined #evergreen
02:08 sandbergja joined #evergreen
02:34 mrisher joined #evergreen
02:53 book` joined #evergreen
05:49 khuckins joined #evergreen
06:02 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
06:54 agoben joined #evergreen
07:45 rfrasur joined #evergreen
07:46 mrisher_ joined #evergreen
08:21 alynn26 joined #evergreen
08:32 mantis1 joined #evergreen
08:40 mmorgan joined #evergreen
08:44 Dyrcona joined #evergreen
09:15 dbwells joined #evergreen
09:20 khuckins joined #evergreen
09:49 sandbergja joined #evergreen
09:57 sandbergja If anybody's up for some patch review, I'd really like to get a fix to bug 1845241 merged in 3.5.1.  Right now, our workaround is that everybody in my consortium just emails me when they want a bib record undeleted. It would make everyone a lot happier if they could do it for themselves again. :-)
09:57 pinesol Launchpad bug 1845241 in Evergreen 3.5 "Unable to Undelete a MARC record in MARC Edit screen" [High,Confirmed] https://launchpad.net/bugs/1845241
09:59 RFrasur_ joined #evergreen
10:03 jvwoolf joined #evergreen
10:04 Dyrcona Never blame on yourself what you can blame on others, and blaming a computer is even better!
10:04 Dyrcona @blame THE COMPUTER
10:04 pinesol Dyrcona: everything was going great until THE COMPUTER came along
10:05 sandbergja hahahaha so true
10:08 mantis1 left #evergreen
10:09 Bmagic Dyrcona: same problem here, would love to review it
10:10 Bmagic Is there a bug for holds getting filled out of order when some have an expiration date set and some are null. The null ones seem like they are getting priority over those with an expiration date (though not expired for over a year from now)
10:10 mantis1 joined #evergreen
10:15 Bmagic It might be a scenario where the library decided to lift their automatically-applied hold expiration date (probably for virus reasons) - and the older holds, those that should be filled first, are no longer at the top. The system is preferring to fill holds where expiration_date is null first
10:16 Bmagic just my theory based on one example. Bouncing it off of you all to see if it sticks
10:23 nfBurton joined #evergreen
10:23 nfBurton joined #evergreen
10:23 Dyrcona Bmagic: Holds can be created or edited to have no expiration date. I'm less sure about how the created without an expiration date happens, but editing to remove the expiration date is easy.
10:25 Dyrcona Holds regularly get filled out of order for reasons, possibly bugs and some features.
10:25 Bmagic This bib has 89 holds on it. Sorting them by request date, I see all the ones at the top having an expiration date and no capture_time. Then, starting with the holds without an expiration date, I start seeing capture times.... Very consistent. Seems hard to believe that humans would be that consistent with the expiration date removal
10:26 Dyrcona Bmagic: You could try modifying the storage function to add a sort on expire_date nulls last.
10:26 Bmagic anyway, I totally agree with you - holds are really hard to trace and unwind
10:26 Dyrcona Humans aren't that consistent, but if something is sorting a certain way, it would appear to be very consistent.
10:27 Bmagic I was thinking I would null the expiration_date in the data for a sub-set and see
10:28 Dyrcona I've seen holds created without an expiration date, but I don't remember exactly how. I think they have to be placed in one of the staff clients, either XUL or web or maybe either.
10:29 Bmagic I assumed that the expiration date was a YAOUS
10:29 berick it is
10:29 berick circ.hold_expire_interval
10:30 Bmagic bingo - I think the theory is corect. With the pandemic, the library decided they didn't want a hold expiration date. And all of the holds that were created before they changed that setting are getting put below the "new" holds post-setting change
10:30 jvwoolf1 joined #evergreen
10:35 Dyrcona Cf. what I said about blame....
10:36 Dyrcona Bmagic: So, you should look through the storage functions for holds for any strange order bys.
10:36 Bmagic yep
10:37 Bmagic probably a bug
10:37 Dyrcona If you see something with expire_date, you can add "nulls last" after the column name, and then the ones that expire will come before those that don't.
10:38 Dyrcona Not saying that is exactly the problem, but it smells like it.
10:38 Bmagic is that the right thing though? Should it even sort by expiration_time at all?
10:38 jeff neither option is good for selecting which hol... yeah, what Bmagic said.
10:38 Dyrcona Dunno. I think it depends on what "it" is.
10:38 Bmagic (speaking in theoretically having not found the query)
10:39 Dyrcona It's probably something else that coincidentally looks like a sort on expire date.
10:40 Dyrcona I'm not sure if nulls last is the default. I recently added "nulls first" to one of my own queries because that's what i wanted.....
10:41 Bmagic I'm not finding a related-function in the action schema. Whcih is where I would have assumed this logic would exist....
10:41 Dyrcona Bmagic: A lot of it is in OpenILS/Storage/Publisher/..... in Perl.
10:42 Bmagic I was thinking that it was in Perl instead
10:45 Dyrcona Could be in OpenILS/Application/Circ/Holds.pm, too.
10:45 Dyrcona Lots of holds code scattered around.
10:54 pinesol [evergreen|Jeff Davis] LP#1847680: live test for barcode completion - <http://git.evergreen-ils.org/?p=‚ÄčEvergreen.git;a=commit;h=5baf8d1>
11:57 mrisher joined #evergreen
11:57 sandbergja joined #evergreen
12:29 Bmagic There seems to be a filesize limitation when uploading files into vandelay. Where is the limit specified? Apache?
12:30 rhamby if you're using nginx I'd check there first
12:30 rhamby the nginx conf has a client_max_body_size that defaults pretty low
12:30 Bmagic yep, was about to say that :0
12:31 Bmagic rhamby++ # probably the issue
12:34 khuckins joined #evergreen
13:08 ohiojoe joined #evergreen
13:46 Bmagic rhamby++ # twas the issue :)
13:46 rhamby glad it was something simple :)
15:08 Dyrcona No code. No milestone.
15:37 mantis1 left #evergreen
15:37 jvwoolf1 left #evergreen
16:43 Bmagic Dyrcona: testing that undelete patch
17:07 jeff just spent 30 seconds trying to figure out why i was having trouble finding patterns in a file: foo.gz.bz2 :-P
17:09 Bmagic jeff: at least it wasn't an hour
17:10 Bmagic @later tell Dyrcona signed off on bug 1845241
17:10 pinesol Bmagic: The operation succeeded.
17:12 jeff Bmagic: *nod*
17:18 mmorgan left #evergreen
17:32 gmcharlt csharp: heads-up re an update to bug 1777677
17:32 pinesol Launchpad bug 1777677 in Evergreen "Test notification method" [Wishlist,Confirmed] https://launchpad.net/bugs/1777677
18:00 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
18:17 abowling1 joined #evergreen
18:43 abowling joined #evergreen
20:34 sandbergja joined #evergreen
21:21 sandbergja joined #evergreen
22:26 JBoyer joined #evergreen

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