| Time |
Nick |
Message |
| 02:47 |
|
jyorio_ joined #evergreen |
| 02:48 |
|
StomproJ joined #evergreen |
| 02:48 |
|
bwicksall_ joined #evergreen |
| 02:48 |
|
dbwells_ joined #evergreen |
| 02:49 |
|
csharp_ joined #evergreen |
| 02:52 |
|
ejk_ joined #evergreen |
| 02:56 |
|
ldw joined #evergreen |
| 03:05 |
|
_adb joined #evergreen |
| 07:56 |
|
gsams_ joined #evergreen |
| 11:10 |
|
jwoodard joined #evergreen |
| 11:37 |
|
Dyrcona joined #evergreen |
| 11:38 |
Dyrcona |
Heh. Didn't mean to open Pidgin, but since I did guess I'll stick around. |
| 12:19 |
Dyrcona |
Heh. I use a different password for my evergreen db user on my vms from the one used at work, and I keep typing the one from work, first. :) |
| 12:30 |
Dyrcona |
Well, I can't figure out why my copy that is "Reshelving" status won't fill the hold when I check it in. Does Reshelving not fill holds? I thought it did. |
| 12:34 |
Dyrcona |
Hmm. Even after getting to Available status, it no longer fills the hold.... |
| 12:35 |
Dyrcona |
Ah, looks like it says it is captured for the hold, but checking it in does not recreate the transit. |
| 12:35 |
Dyrcona |
I swear that this did not used to happen. |
| 12:37 |
Dyrcona |
Setting the hold's capture time to null fixed that.... |
| 12:38 |
Dyrcona |
This doesn't seem right to me, but if anyone is around or wants to chime in later, feel free. :) |
| 12:39 |
Dyrcona |
I'll revert miker's commit on my branch if the behavior changes any. |
| 12:39 |
Dyrcona |
"And check" should go between branch and if. |
| 12:44 |
|
bmills joined #evergreen |
| 12:48 |
Dyrcona |
Yep. Reverted miker's changes and the copy traps again after the transit is aborted. I'll take a closer look later and see if I can do something about that. |
| 12:50 |
miker |
Dyrcona: I think I noted that behavior change in the commit message... |
| 12:51 |
Dyrcona |
Right. But even after multiple check ins and getting the status back to available, the copy still would not generate a transit. |
| 12:51 |
|
gsams joined #evergreen |
| 12:51 |
Dyrcona |
Not until after I changed the capture time on the hold, which puzzles me. |
| 12:54 |
Dyrcona |
I'll do some more experimentation later. I'd like to see the real differences in what's going on for myself. |
| 12:54 |
miker |
the change that let it work was the hold getting retargeted |
| 12:55 |
miker |
after the copy became available or equivalent |
| 12:59 |
miker |
if the problem to solve is "don't break circs" then the first "if" test in my branch is enough. if the problem is "staff are confused" the the status dance is needed. but the status dance kills immediate recapture via op-capture because the hold gets retargeted after the copy becomes untargetable |
| 13:01 |
miker |
if we add the canceled-transit status, per csharp, and allow it to be holdable, op-capture will work as before |
| 13:01 |
miker |
on top of my branch, I mean |
| 13:03 |
miker |
I think we'll really want berick's is_available branch, too, and make the new status true for that flag |
| 13:03 |
miker |
otherwise we'll get warnings at the eventual hold dest |
| 13:03 |
Dyrcona |
Hmm. What you're saying makes sense, but I'm not sure that it completely supports what I think I saw. :) |
| 13:04 |
Dyrcona |
I'll do some looking later. |
| 13:04 |
miker |
k |
| 13:05 |
Dyrcona |
berikc has an is_available branch? I don't recall seeing that before, but sometimes there are so many branches when you fetch... ;) |
| 13:05 |
Dyrcona |
I'll look at the timezone branch, next. I thinks some other bugs are waiting on that one. |
| 13:07 |
Dyrcona |
Oh. lp 1464709 |
| 13:07 |
pinesol_green |
Launchpad bug 1464709 in Evergreen "Seamless checkout of non-standard copy status AKA single-use copy statuses" [Wishlist,New] https://launchpad.net/bugs/1464709 |
| 13:07 |
Dyrcona |
I didn't mentally associate that with is_available, but of course. |
| 13:44 |
|
jwoodard joined #evergreen |
| 13:45 |
jwoodard |
@librarian |
| 13:45 |
pinesol_green |
jwoodard: Management:16, Cataloging:10, Acquisitions:12, Reference:16, Circulation:14, Systems:11, Research:5, Custodial:14 |
| 13:45 |
* Dyrcona |
pushed a compile error fix to collab/miker/lp1485374-always-use-client-tz-rebase |
| 13:45 |
Dyrcona |
Missing comma on line 667 of oils_auth.c. |
| 13:46 |
miker |
huh. must have missed that in a conflict on rebase. soory :) |
| 13:47 |
Dyrcona |
NP. |
| 14:28 |
Dyrcona |
Hmm. I'm not really certain how to test that branch. I tried placing holds from the OPAC, but the times are in UTC. |
| 14:29 |
Dyrcona |
I tried a SetENV TZ America/New_York in the Apache config for the /opac location and restarted, but that didn't seem to do anything either. |
| 14:48 |
|
bmills joined #evergreen |
| 15:10 |
csharp_ |
I was just going to finally comment out the PINES reporting views by default in fm_IDL.xml, but I can see that other non-PINES tables have been added to the PINES section |
| 15:10 |
csharp_ |
looks like my work is cut out for me :-/ |
| 15:18 |
|
csharp joined #evergreen |
| 16:05 |
|
bmills joined #evergreen |
| 18:03 |
|
b_bonner joined #evergreen |
| 18:04 |
|
jeff joined #evergreen |
| 18:04 |
|
jeff joined #evergreen |
| 18:05 |
|
jeffdavis joined #evergreen |
| 18:07 |
|
mnsri joined #evergreen |
| 18:17 |
|
_adb joined #evergreen |
| 18:17 |
|
_bott_ joined #evergreen |
| 18:22 |
miker |
@later tell Dyrcona just to be sure, you have the master branch of opensrf installed? that has some required js |
| 18:22 |
pinesol_green |
miker: The operation succeeded. |
| 18:44 |
|
jeffdavis joined #evergreen |
