Evergreen ILS Website

IRC log for #evergreen, 2017-12-20

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

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