| 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 |
