| Time |
Nick |
Message |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
agoben joined #evergreen |
| 08:02 |
|
_adb joined #evergreen |
| 08:11 |
|
jvwoolf joined #evergreen |
| 08:23 |
|
jvwoolf1 joined #evergreen |
| 08:33 |
|
jvwoolf1 left #evergreen |
| 08:58 |
|
bos20k joined #evergreen |
| 09:11 |
|
Dyrcona joined #evergreen |
| 09:18 |
|
yboston joined #evergreen |
| 09:26 |
JBoyer |
berick, I said I'd report my status on Hatch + FF and I finally got to take a good look last night. My findings are that NativeMessaging debugging on FF is garbage and I've made no real progress as yet. |
| 09:26 |
JBoyer |
Thought I should put that out there since I had mentioned thinking we were close. :/ |
| 09:59 |
berick |
JBoyer: thanks |
| 10:11 |
|
jvwoolf joined #evergreen |
| 10:54 |
jeff |
rfid+- |
| 10:55 |
Bmagic |
berick: which of the EDI attrs causes the GIR segments to be created? LINEITEM_IDENT_VENDOR_NUMBER? |
| 10:57 |
berick |
Bmagic: INCLUDE_COPIES |
| 10:57 |
Bmagic |
oh, weird. I would have thought that including copies would be fundamental for orders. But apparently we don't have an "enriched" account and therefore the GIR segments need to be omitted |
| 10:58 |
berick |
yeah, copies not required |
| 10:59 |
berick |
mostly it's just "I want 5 of this bib" |
| 11:12 |
Dyrcona |
Anyone running 2.12.8 or 3.0.2 seeing something like ARRAY(0x5593f764c788) in the search box after placing a hold for the patron in the XUL staff client? |
| 11:13 |
Dyrcona |
I'm trying to figure out if it's a general problem or just us. |
| 11:14 |
Dyrcona |
May be a customization interfering with new code. |
| 11:15 |
jeff |
the precondition doesn't apply here, but I do believe there have been cases of that in the past. I don't recall any other details without digging. |
| 11:15 |
|
littlet joined #evergreen |
| 11:16 |
Dyrcona |
jeff: Only time I've seen it happen before is when placing multiple holds at once. This is with a single hold and appears to be "new behavior." |
| 11:17 |
Dyrcona |
I've not seen it in the OPAC on 3.02, and I'm waiting on a db copy to test on a vm similar to our production system. |
| 11:18 |
Dyrcona |
I'm looking at Lp 1671635 as the possible culprit, but want to make sure it's not just our customization to place_hold.tt2. |
| 11:18 |
pinesol_green |
Launchpad bug 1671635 in Evergreen 2.12 "Place hold success page changes search scope" [Medium,Fix released] https://launchpad.net/bugs/1671635 |
| 11:23 |
jeff |
Hrm. I'm used to left-side casting on a WHERE clause giving undesirable performance without an additional index (think xact_start::DATE BETWEEN '2017-12-01'::DATE AND '2017-12-31'::DATE vs xact_start >= '2017-12-01'::DATE AND < '2018-01-01'::DATE). Now, it's possible that the performance isn't as much of a problem as it was in the past. |
| 11:23 |
jeff |
But that could just be due to a smaller dataset and running on larger hardware. |
| 11:25 |
jeff |
(and my not-quite-pseudocode has at least one error, but hopefully conveys the concept) |
| 11:25 |
|
Christineb joined #evergreen |
| 11:29 |
berick |
@band add Semi-PseudoCode |
| 11:29 |
pinesol_green |
berick: Band 'Semi-PseudoCode' added to list |
| 11:34 |
dbs |
Hrm, I'm guessing there's no easy way to add a part name to myopac/circs.tt2; if a user has both parts signed out for a given item, there's no way they can easily tell which is which (barcode, yes, but that's not "easy"--heh) |
| 11:39 |
Dyrcona |
So, my problem mentioned above does not happen in the OPAC nor the web staff client on our production 2.12.8 system (with customization), nor does it happen in the OPAC or web staff client in 3.0.2 (without customization). |
| 11:40 |
Dyrcona |
Next step build a 3.0.2 xul client to test and build a stock 2.12.8 vm to test a stock XUL client there. |
| 11:43 |
Dyrcona |
Aw. crap. That server that I messed with the networking yesterday.... I can't ssh to the non-routeable IP address and it's not listening on the other one... |
| 11:43 |
jeff |
vm console time? |
| 11:49 |
Dyrcona |
This is a physical server in another building a few miles away. |
| 11:49 |
Dyrcona |
Gonna wait until after New Year's, I think. |
| 11:49 |
Dyrcona |
And, yes, networking has definitely gotten more fussy in Linux lately. |
| 11:50 |
jeff |
ah, so no DRAC/iLO/other IPMI or similar? |
| 11:51 |
Dyrcona |
Nope. Dunno if the servers came with the option, or if it was ever set up, but I doubt it in one case or the other. |
| 11:53 |
* Dyrcona |
goes to get lunch. |
| 12:02 |
|
bos20k joined #evergreen |
| 12:27 |
Bmagic |
berick++ |
| 12:46 |
berick |
Bmagic: any word on B&T after the SAN fix? |
| 12:46 |
berick |
are we ready for an LP bug? |
| 12:46 |
Bmagic |
berick: yes, that fixed it |
| 12:47 |
Bmagic |
I believe the LP is the next step for that EDIWriter.pm change |
| 12:48 |
Dyrcona |
berick++ Bmagic++ |
| 12:48 |
|
jihpringle joined #evergreen |
| 12:48 |
berick |
k, you on it or want me to open it? |
| 12:53 |
Dyrcona |
"Time out error, please try again in a few minutes." |
| 12:53 |
Dyrcona |
Heh, the only button says "OK." It ought to say "Not OK." |
| 12:56 |
Dyrcona |
That's from Lp, btw. |
| 12:59 |
Bmagic |
berick: I can do it, sure |
| 13:02 |
Bmagic |
berick: are you in a position to push the patch to working? I coudl do it but I would need to get some things setup to do it. |
| 13:02 |
|
khuckins joined #evergreen |
| 13:02 |
Bmagic |
bug 1739465 |
| 13:03 |
pinesol_green |
Launchpad bug 1739465 in Evergreen "New EDIWriter.pm is using the wrong SAN for NAD+BY" [Undecided,New] https://launchpad.net/bugs/1739465 |
| 13:05 |
berick |
Bmagic: thanks, yes, I'll post the patch |
| 14:38 |
|
khuckins_ joined #evergreen |
| 14:42 |
|
gsams joined #evergreen |
| 14:58 |
|
sandbergja joined #evergreen |
| 15:00 |
|
khuckins__ joined #evergreen |
| 15:02 |
sandbergja |
I'm trying to get a start on the 3.0.3 and 2.12.9 release notes, but I'm not sure how I can tell what bugs will have been fixed for those releases. I don't see any new non-docs commits to the rel_2_12 or rel_3_0 branches since the last point release. |
| 15:07 |
sandbergja |
Should I wait until the rel_2_12_9 and rel_3_0_3 branches are created? If so, when will they be created? Thanks in advance. |
| 15:08 |
jeffdavis |
sandbergja: I'm not the RM, but AFAIK those branches are created (and the rel_2_12/rel_3_0 branches updated) during the release process. Yesterday gmcharlt said he was aiming for Dec 28 for a 3.0.3 release. |
| 15:09 |
gmcharlt |
correct, and with patches potentially getting merged through 26 December |
| 15:10 |
sandbergja |
Okay, great! I'll just hang off until December 26 or so, and then start checking in |
| 15:10 |
gmcharlt |
sandbergja++ |
| 15:11 |
sandbergja |
And just to check -- do those discussions of release process timing take place at the developer's meeting, or somewhere else? |
| 15:12 |
gmcharlt |
neither; it's been mostly ad hoc, with coordination taking place on #evergreen |
| 15:14 |
sandbergja |
got it. I'll just be sure to keep better tabs on the IRC channel. Thanks for your help! |
| 15:18 |
|
jvwoolf joined #evergreen |
| 15:54 |
jeff |
musing on copies with status of discard/weed and deleted = true vs those with that same status and deleted = false. |
| 15:56 |
|
bshum joined #evergreen |
| 16:03 |
jeff |
It's been practice when weeding an item to change its status from Available to Discard/Weed and then delete the item. This lets us tell the difference between an item that was deleted because it was missing/damaged/etc or an item that was actually "weeded". |
| 16:13 |
jeff |
But I do wonder about the extra step. We could either consider a deleted copy with "Available" status our clue that the copy was "weeded", or we could use some middle layer code or a DB trigger to flip status on a copy at delete time that was Available to Discard/Weed... |
| 16:14 |
jeff |
(in the first case, we could probably stop using Discard/Weed as a status) |
| 16:14 |
jeff |
Do other libraries here have workflows that involve changing status on the items to Discard/Weed but intentionally not deleting them, or not deleting them right away? |
| 16:16 |
jeff |
Another option would be to set items in Discard/Weed status to deleted=true after a period of time. We'll probably do that soon here because we *don't* have a workflow that involves Discard/Weed + NOT deleted, and it's common for the delete step to be forgotten. |
| 16:18 |
csharp |
jeff: yes, PINES libs use Discard/Weed to let circ staff mark the item so that the cataloger knows what to do with them |
| 16:19 |
csharp |
so they do exist for a time as non-deleted items |
| 16:19 |
jeff |
okay, that's good to know. |
| 16:20 |
csharp |
we actually have a req doc for fleshing out the feature so it can be used as a menu item alongside Mark Item Missing (or Damaged) |
| 16:20 |
csharp |
(not sure it's anywhere public) |
| 16:21 |
csharp |
somewhere low on the list of MassLNC dev projects, I think |
| 16:27 |
jeff |
other ideas bubbling around include a UI option to mark discard/weed and delete (could be a peer of that new menu option you describe), or a conditional prompt to ask staff to confirm the final status of the item, or a "reason" for deletion (which starts to get a bit far afield, but perhaps not TOO far). |
| 16:30 |
jeff |
we currently use edit_date to identify the "deletion time" of a copy with deleted=true, but have pondered a deleted_date field. |
| 16:30 |
csharp |
yeah we use it that way too |
| 16:30 |
csharp |
while we're at it "last_inventoried" |
| 16:31 |
* jeff |
nods |
| 16:31 |
jeff |
several of our new libraries do inventory. we never had an inventory as a priority. |
| 16:32 |
jeff |
but a simple inventory of "there is this date in the db. it is touched when items are checked in/out and is touched when items are scanned into item status with this modifier set" would go a long way. |
| 16:33 |
jeff |
but doesn't allow for the kind of inventory process which is closer to "identify all of the items that were NOT found" |
| 16:34 |
csharp |
right - baby steps :-) |
| 16:53 |
* jeff |
re-discovers the difference between Retarget Local Holds vs Retarget Local Holds + Retarget All Statuses |
| 16:53 |
jeff |
(with just Retarget Local Holds set, only items in In Process status are retargeted) |
| 17:39 |
|
jvwoolf left #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
