Evergreen ILS Website

IRC log for #evergreen, 2016-08-22

| 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
05:19 kmlussier joined #evergreen
06:40 rlefaive joined #evergreen
07:07 kmlussier @coffee
07:07 * pinesol_green brews and pours a cup of Aricha Selection Seven Ethiopia Yirgacheffe, and sends it sliding down the bar to kmlussier
07:14 tsbere_ joined #evergreen
07:18 rjackson_isl joined #evergreen
07:48 kmlussier miker / gmcharlt: In your spare time, I would be interested in your thoughts on bug 1615600
07:48 pinesol_green Launchpad bug 1615600 in Evergreen "One popularity ranking method should be used by default" [Wishlist,New] https://launchpad.net/bugs/1615600
07:49 kmlussier I know I had previously talked to one of you about moving to just one of these sort methods by default, but I don't think we ever discussed which one should be used.
07:57 ericar joined #evergreen
07:59 mrpeters joined #evergreen
07:59 gsams_ joined #evergreen
08:01 pinesol_green [evergreen|Chris Sharp] LP#1586221 - Remove "no spaces" message from login form. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c597e8f>
08:05 rhamby joined #evergreen
08:52 krvmga joined #evergreen
08:59 mmorgan joined #evergreen
09:03 tsbere Huh, amazing what you find in your database when you are looking for things. I kindof expected Canadian addresses, but apparently we have at least one French one too.
09:07 csharp tsbere: you would have so much fun with our database :-)
09:08 csharp ten years of manual data entry!
09:09 tsbere csharp: Most of what I am looking for are addresses so badly entered that they can't be parsed as addresses. Some of which are migrated manual data entry issues. <_<
09:09 * csharp considers adding that fact to future PINES employment position ads
09:09 csharp ah
09:09 bos20k joined #evergreen
09:10 * tsbere is also working on "bulk cleanup" commands, such as standardizing states to their uppercase abbreviations. Or at least the most common ones in our DB.
09:10 * csharp finally buckles down to test Dyrcona's and miker's fix to bug 1306666 since it's probably a dependency for his fix to bug 1613374
09:10 pinesol_green Launchpad bug 1306666 in Evergreen 2.9 "When Aborting a Transit, items should not automatically get a status change." [Low,Confirmed] https://launchpad.net/bugs/1306666
09:10 pinesol_green Launchpad bug 1613374 in Evergreen "Feature Request: "Canceled Transit" Item Status" [Wishlist,Confirmed] https://launchpad.net/bugs/1613374 - Assigned to Chris Sharp (chrissharp123)
09:13 * tsbere isn't sure if he should include misspellings of states in his corrections <_<
09:14 tsbere And sometimes I look at the info and wonder "how did you screw that up in that way?"
09:14 tsbere Like seeing '0A' where I think it is supposed to be 'MA'
09:19 jeff perhaps they were indicating that there was no change from the previous state that they had entered? :-)
09:19 jeff oh, wait. that would be 0E0.
09:20 tsbere We have thousands of states entered as 'N/A', which I think was migration-speak for "we can't figure it out from the previous ILS". >_>
09:20 jeff failed Perl puns are the best failed puns.
09:21 tsbere Huh, an East Timor address. I am half tempted to look up that user now.
09:34 * tsbere stares at what appears to be "lets put two addresses in one address field, but don't double the post code"
09:37 maryj joined #evergreen
09:39 StomproJ We had a UK address when I was cleaning up stuff, so our postal code regex has to cover US zips, Canadian postal codes, and one form of UK postal code.  The Canadian postal codes really trip staff up, so many o's entered for zeros.
09:44 tsbere We have so few non-US addresses that I am not excessively concerned about them in this case, we can safely ignore them in reports.
09:49 collum joined #evergreen
09:52 yboston joined #evergreen
10:03 mmorgan1 joined #evergreen
10:08 mrpeters joined #evergreen
10:15 barbara joined #evergreen
10:47 Dyrcona joined #evergreen
10:48 Dyrcona Bit late, but...
10:49 Dyrcona miker: Yeah, I updated and installed OpenSRF, too. I'll check that the JS files are up to date, though, and get back to you.
11:05 Christineb joined #evergreen
11:08 mmorgan joined #evergreen
11:10 ericar_ joined #evergreen
11:27 Dyrcona miker: The /openils/lib/javascript files were updated on Aug 20. I'll compare them with the ones from the source directory.
11:31 Dyrcona miker: diff says that they are the same, so maybe my OpenSRF branch was out of date....
11:34 Dyrcona Nope. Looks good.
12:05 book` joined #evergreen
12:36 mllewellyn joined #evergreen
12:49 tsbere Hmmm
12:49 tsbere Looks like evergreen-ils.org's https certificate expired over the weekend
12:51 bshum Hmmm, go figure
12:51 * bshum goes to fix that
12:52 bshum if I can remember how... heh
12:53 tsbere I feel I have done my part by noticing *and* speaking up about it. ;)
12:53 * tsbere wouldn't have noticed if he hadn't hit the wrong bookmark, though
12:54 bshum Should be good now
12:54 bshum For 3 more months anyways
12:55 bshum tsbere++ # thanks for letting us know :)
13:05 csharp okay, regarding bug 1613374 and how it relates to the fix on bug 1306666, I'm not convinced we need to reclaim the stored copy status (action.transit_copy.copy_status) when the transit is aborted
13:05 pinesol_green Launchpad bug 1613374 in Evergreen "Feature Request: "Canceled Transit" Item Status" [Wishlist,Confirmed] https://launchpad.net/bugs/1613374 - Assigned to Chris Sharp (chrissharp123)
13:05 pinesol_green Launchpad bug 1306666 in Evergreen 2.9 "When Aborting a Transit, items should not automatically get a status change." [Low,Confirmed] https://launchpad.net/bugs/1306666
13:06 csharp I think if the transited copy is not at "home", is should be set to 'Canceled Transit' no matter what the stored status is - can someone please explain why we wouldn't want that?
13:07 * csharp glances at miker or Dyrcona for input but all are welcome ;-)
13:07 csharp or mmorgan
13:09 Dyrcona csharp: I have no problem with that. I would kind of assume that the person aborting the transit has the copy in hand.
13:09 Dyrcona Of course, we know what happens when we assume... ;)
13:09 * mmorgan is having trouble thinking of why restoring the last status is useful on transit abort, err. cancel.
13:09 Dyrcona If it's in transit because it is damaged, it would make sense.
13:10 csharp we were also unsure how a damaged or bindery copy would be sent in transit too
13:10 mmorgan Recovering the status may have made more sense when we didn't have a Canceled transit status.
13:10 csharp is the assumption that cataloging staff place holds on the damaged/bindery items?
13:12 tsbere Marked as damaged by circ staff to prevent hold capture, checked in to send back home?
13:13 csharp ah - that makes sense
13:14 csharp we were thinking of "I'm at a branch library and HQ does our cataloging, and I have a damaged copy in hand that I want to send to HQ, which is not the circ library"
13:14 mmorgan Yes, that makes sense. If the transit concludes normally, restoring the status makes sense there, but is the same true given the Canceled transit status?
13:14 tsbere I would see that as a possible use for a recall hold, though that wouldn't keep it flagged as damaged
13:15 csharp if my "cancel_time" branch gets accepted, it's even possible to get the status from a canceled transit ;-)
13:15 csharp right now the rows are deleted
13:17 csharp okay then, I'll build my branch with the assumption that we don't care about the stored status on a canceled transit
13:18 mmorgan FWIW, here are a few of the statuses in the transit_copy table in our production system: Lost and Paid, Lost, Cataloging, Damaged, Mending, IN Process...
13:21 jeff didn't the discussion over the past week focus on the copy in an aborted transit getting a new cancelled transit status if it was in a normal available/reshelving status when going into transit, and getting the original status if it was in any other status?
13:22 jeff maybe i interpolated incorrectly based on my skimming.
13:23 csharp jeff: in my recollection, we didn't go deeper than checking that the copy was in "In transit" status at the time of the abort/cancel
13:23 jeff ah.
13:23 csharp we can definitely check the stored status, though
13:23 * csharp wants this to work for everybody ;-)
13:24 tsbere I think the "only if it is to go into the available/reshelving status" would be the better way to go, personally. Although "on hold shelf" would be another to consider the implications of...
13:24 kmlussier csharp: Sounds like an unattainable goal to me. ;)
13:24 csharp yeah :-(
13:25 csharp well we're pretty sure we're going to implement something like this locally if it isn't accepted into master, but I'd really like to avoid doing that
13:26 csharp the status quo is confusing for staff and time-consuming for sys admins
13:26 mmorgan csharp: Are you working on a branch that incorporates your two bugs as well as lp 1306666?
13:26 pinesol_green Launchpad bug 1306666 in Evergreen 2.9 "When Aborting a Transit, items should not automatically get a status change." [Low,Confirmed] https://launchpad.net/bugs/1306666
13:26 csharp mmorgan: right now I'm building a branch on top of the fix for 1306666
13:27 csharp my other thought was YAOUS that says "do you want to use the canceled transit status?" and if not, revert to the status quo behavior
13:28 mmorgan Ok, makes sense. I'd like to see this get in, too.
13:29 * csharp wishes the hackaway was scheduled before a major release instead of right after
13:29 csharp if we were all in a room, this could get knocked out in a matter of hours
13:43 jeff csharp: we would more easily convince ourselves that we've gotten it right, while at the same time increased our chances of having it completely wrong. ;-)
13:44 jeff that said, i was wondering about the idea of a developer gathering where zero code is written.
13:44 Dyrcona csharp: The branch on 130666 as it stands doesn't do quite what I want. I've had a hard time getting the copy to go into transit after aborting the transit, even after multiple check ins.
13:46 kmlussier joined #evergreen
13:47 * mmorgan needs to run out for a bit, but just had a thought regarding the saved copy status. Maybe it makes sense to apply that status when the Canceled transit is resolved?
13:52 kmlussier I haven't been following this discussion as closely as I should over the past week, but since Dyrcona is having trouble with the code at bug 1306666 and the feature freeze is pending, would it make sense for csharp to not do his code on top of bug 1306666, but to introduce it on its own as a new feature?
13:52 pinesol_green Launchpad bug 1306666 in Evergreen 2.9 "When Aborting a Transit, items should not automatically get a status change." [Low,Confirmed] https://launchpad.net/bugs/1306666
13:52 kmlussier The bug fix could come at a later time.
13:52 csharp kmlussier: that's fine with me - my original branch is pretty simple
13:54 csharp I may check the stored status and only change the status for items with certain stored statuses
13:54 Dyrcona I don't know, really, what miker's intended behavior with this was, but with his commit applied, I can't get the copy to go back into transit after aborting a hold transit remotely, i.e. at the destination library.
13:54 Dyrcona csharp: I'd prefer for the stored status to not matter. When we get into checking statuses, we have to keep that list up to date when new statuses are added.
13:54 csharp ok - then I'll work separately from that - it's easier working from the code in current master
13:55 csharp Dyrcona: good point
13:56 ericar joined #evergreen
13:59 kmlussier Calling 0990
14:08 csharp okay my branch is up-to-date with current changes at http://git.evergreen-ils.org/?p=working/Eve​rgreen.git;a=shortlog;h=refs/heads/user/csh​arp/lp1613374_canceled_transit_item_status (which mmorgan helpfully added to bug 1613374)
14:08 pinesol_green Launchpad bug 1613374 in Evergreen "Feature Request: "Canceled Transit" Item Status" [Wishlist,Confirmed] https://launchpad.net/bugs/1613374 - Assigned to Chris Sharp (chrissharp123)
14:10 kmlussier csharp++
14:12 pinesol_green [evergreen|Mike Rylander] LP#1613730: Add a "Copy Count" rating function for badges - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=da240e7>
14:12 pinesol_green [evergreen|Kathy Lussier] LP#1613730: Stamping upgrade script for copy count badge - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=2888b40>
14:52 mmorgan csharp++
15:26 kmlussier Nice! I just got my first look at the new webby search box.
15:26 kmlussier berick++
15:32 berick kmlussier: yay
15:39 miker Dyrcona: I'm happy to go over my intent again
15:42 miker here's a recap of the situation, as I see it: http://irc.evergreen-ils.org/​evergreen/2016-08-20#i_262591
15:48 Dyrcona miker: Thanks. I'll read the logs again. I have some other things going on right now.
16:55 * tsbere hopes he was clear enough in explaining his view on bug 1464709
16:55 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
17:16 mmorgan left #evergreen
18:06 gsams joined #evergreen
18:54 gsams_ joined #evergreen
19:17 sandbergja joined #evergreen
19:59 mllewellyn left #evergreen
21:30 genpaku joined #evergreen

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