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/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/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 |