Time |
Nick |
Message |
00:16 |
|
dbwells joined #evergreen |
00:16 |
|
remingtron joined #evergreen |
00:20 |
|
dbwells_ joined #evergreen |
00:21 |
|
remingtron_ joined #evergreen |
03:15 |
|
artunit_ joined #evergreen |
05:01 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
06:56 |
|
kmlussier joined #evergreen |
06:56 |
|
wsmoak joined #evergreen |
06:56 |
|
wsmoak joined #evergreen |
07:37 |
|
mtate joined #evergreen |
07:38 |
|
eeevil joined #evergreen |
07:38 |
|
Callender joined #evergreen |
07:38 |
|
phasefx joined #evergreen |
07:39 |
|
gdunbar joined #evergreen |
07:45 |
|
jboyer-isl joined #evergreen |
07:49 |
|
collum joined #evergreen |
08:16 |
|
akilsdonk joined #evergreen |
08:16 |
|
_bott_ joined #evergreen |
08:23 |
|
Shae joined #evergreen |
08:34 |
|
ericar joined #evergreen |
08:38 |
|
krvmga joined #evergreen |
08:39 |
csharp |
it has only taken over 3 years, but I'm finally testing tsbere's fix for bug 778989 |
08:39 |
pinesol_green |
Launchpad bug 778989 in Evergreen "Owning lib of asset.copy_location not visible in Item Attributes Editor UI" (affected: 2, heat: 12) [Undecided,In progress] https://launchpad.net/bugs/778989 - Assigned to Thomas Berezansky (tsbere) |
08:40 |
kmlussier |
csharp++ |
08:43 |
|
mdriscoll joined #evergreen |
08:47 |
|
mmorgan1 left #evergreen |
08:48 |
|
mmorgan joined #evergreen |
09:00 |
|
Shae_ joined #evergreen |
09:01 |
|
rjackson-isl joined #evergreen |
09:10 |
|
Dyrcona joined #evergreen |
09:21 |
|
yboston joined #evergreen |
09:54 |
|
jwoodard joined #evergreen |
09:54 |
csharp |
@developer |
09:54 |
pinesol_green |
csharp: Communication:14, BigPicture:11, DetailOriented:10, KungFu:12, GetsStuffDone:8, FlakeFactor:12, JavaAvoidance:16 |
09:56 |
kmlussier |
@developer |
09:56 |
pinesol_green |
kmlussier: Communication:10, BigPicture:14, DetailOriented:9, KungFu:11, GetsStuffDone:12, FlakeFactor:14, JavaAvoidance:14 |
10:06 |
csharp |
tsbere: I'm looking at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/correct_copy_location and see that the trigger function only fires on updates where the copy location hasn't changed. |
10:09 |
csharp |
the issue is occurring at copy creation as well, so if I wanted to make it work on newly created copies, could I change "IF (TG_OP = 'UPDATE') THEN..." to IF (TG_OP IN ('UPDATE', 'INSERT') THEN..."? |
10:09 |
csharp |
(with the closing parens there of course ;-)) |
10:09 |
tsbere |
csharp: I think we may be reading that very differently |
10:09 |
csharp |
ok - this is why I'm asking :-) |
10:10 |
tsbere |
csharp: The IF (TG_OP = 'UPDATE') THEN block is "if this is an update, skip if the location and call number haven't changed" (though adding in circ lib may be a good potential idea) |
10:11 |
tsbere |
csharp: If the location has changed, the call number has changed, or TG_OP is not UPDATE (like, say, it is INSERT) then it should move onto the SELECT statement and beyond |
10:11 |
csharp |
ah - gotcha |
10:11 |
csharp |
okay - then let me keep testing with that in mind |
10:12 |
tsbere |
csharp: Adding in "AND NEW.circ_lib = OLD.circ_lib" into the location/call number IF check would be enough for that part. |
10:14 |
csharp |
got it |
10:15 |
jeff |
csharp: phew. i'm glad you didn't execute @developer more than twice in a row a few minutes ago. three times in a row summons either Steve Ballmer or Beetlejuice -- I'm not sure which. |
10:15 |
tsbere |
csharp: Looking over that again, I think there is the added concern of the owning_lib versus circ_lib, and the copy location can come from either....but I don't think it is checking circ lib. Possibly because I missed that circ lib could be involved at the original time of writing. |
10:15 |
csharp |
tsbere: okay, well, when I do 'select actor.org_unit_ancestors_distance(154) order by distance;', which is what appears to be what the function is doing, I get 'ERROR: column "distance" does not exist' - is that correct? |
10:16 |
jeff |
oh, and of course now i see that it was csharp and kmlussier, not both csharp. :P |
10:16 |
tsbere |
jeff: I was about to point that out to you |
10:16 |
csharp |
@developer |
10:16 |
pinesol_green |
csharp: Communication:9, BigPicture:10, DetailOriented:15, KungFu:12, GetsStuffDone:13, FlakeFactor:11, JavaAvoidance:10 |
10:16 |
csharp |
@developer |
10:16 |
pinesol_green |
csharp: Communication:14, BigPicture:8, DetailOriented:10, KungFu:12, GetsStuffDone:12, FlakeFactor:16, JavaAvoidance:8 |
10:16 |
csharp |
@developer |
10:16 |
pinesol_green |
csharp: Communication:15, BigPicture:14, DetailOriented:4, KungFu:14, GetsStuffDone:11, FlakeFactor:17, JavaAvoidance:12 |
10:16 |
* kmlussier |
chuckles |
10:16 |
ballmer |
I AM HERE jeff |
10:17 |
Dyrcona |
ballmer is not a developer. |
10:17 |
jcamins |
lol |
10:17 |
tsbere |
csharp: "select function order by blah" and "select * from function order by blah" are two different things. You need the latter. ;) |
10:18 |
Dyrcona |
:) |
10:18 |
csharp |
ah |
10:19 |
csharp |
tsbere: great - that works ;-) |
10:20 |
Dyrcona |
I also found out yesterday that you get very differently results in dbi with select function() vs. select * from function(). |
10:20 |
Dyrcona |
differently? really, dude? |
10:21 |
tsbere |
csharp: If you skip the order by portion you can probably see the difference in output. "FROM function" gives you table output. Skip the from part and you get composite types in a single column. |
10:21 |
Dyrcona |
Yep. That's what I saw. |
10:21 |
tsbere |
csharp: Well, provided the function actually returns a composite type.... |
10:27 |
csharp |
I see |
10:29 |
tsbere |
csharp/Dyrcona: For added fun, if the composite type can be used as a table, you can do things like (function(args)).column to pull out just one column, if that is all you need. And yes the extra () are needed in that case. The same goes if something else has returned a composite type, (column1).column2 |
10:31 |
Dyrcona |
Yeah, and you can also select column from function(args) or use such a function in a join. |
10:32 |
Dyrcona |
I often join on actor.org_unit_ancestors() for instance. |
11:18 |
|
mnsri joined #evergreen |
11:22 |
kmlussier |
I've been looking at bug 1271198 this morning. There's something I'm confused about with our mkurl's. The advanced search link in the search bar and button on the search results page are set to remove the expert_search_params. Those parameters should be tag, subfield, term, and _special. |
11:22 |
pinesol_green |
Launchpad bug 1271198 in Evergreen "Catalog browse search headings link self-referential" (affected: 2, heat: 12) [Medium,Confirmed] https://launchpad.net/bugs/1271198 - Assigned to Kathy Lussier (klussier) |
11:22 |
kmlussier |
Why are we also losing the query parameter there? Shouldn't it be maintained? |
11:46 |
kmlussier |
And if I add parameters to the list of general_search_parms, we lose those too when I use the advanced search links. So by virtue of using general_search_parms.merge, are we saying that general search parameters should be cleared by default? |
11:47 |
kmlussier |
I suppose it doesn't affect my work on the bug, I'm just curious as to what's happening there. |
11:50 |
|
jeffdavis joined #evergreen |
11:52 |
kmlussier |
tsbere: Any chance you might have time to rebase https://bugs.launchpad.net/evergreen/+bug/1012308? |
11:52 |
pinesol_green |
Launchpad bug 1012308 in Evergreen "Staff Client Title Sort ignores non-filing indicator information" (affected: 2, heat: 10) [Undecided,Triaged] |
11:53 |
csharp |
tsbere: I'm convinced that your function as written works for PINES' needs (thank you!) - however, you mentioned adding some logic around acp.circ_lib? |
11:53 |
tsbere |
csharp: Well, the copy location is valid under both circ lib and owning lib trees, and the function as-is only checks the owning lib. |
11:58 |
* csharp |
reads back up to this morning's exchange |
11:58 |
csharp |
tsbere: yeah, I remember you and I talking about that and at the time you were of the opinion that going by volume-owning lib was more correct |
11:59 |
tsbere |
csharp: But not always accurate. A "we didn't find volume-owning based, check for circ lib based" addition may be a good idea. |
12:01 |
tsbere |
csharp: For example, "temporarily in a branch-only display location while still owned by a higher level org unit at the volume level" could trip things up. |
12:02 |
pastebot |
"csharp" at 64.57.241.14 pasted "tsbere - adding circ_lib check" (17 lines) at http://paste.evergreen-ils.org/19 |
12:02 |
csharp |
tsbere: ^^ does that look correct? |
12:02 |
|
buzzy joined #evergreen |
12:03 |
tsbere |
csharp: For "if the circ lib changed", yes. Doesn't cover actually using the circ lib. Lemme load up the branch on my dev machine quick. |
12:03 |
csharp |
ok |
12:04 |
tsbere |
Hmmm. Really been a while. "1 and 3332 different commits each" >_> |
12:04 |
csharp |
heh |
12:04 |
csharp |
yeah, it's been like 2.5 years |
12:04 |
* csharp |
hangs head in shame |
12:08 |
bshum |
csharp: Think of it this way, at least you'll get it fixed before we freeze cataloging module for the web client rewrite? :D |
12:08 |
mmorgan |
2.5 years slips by really quickly ... |
12:08 |
|
bmills joined #evergreen |
12:09 |
tsbere |
bshum: As this is entirely backend stuff I don't think a freeze would affect it. ;) |
12:10 |
bshum |
tsbere: Heh, fair enough |
12:12 |
|
jihpringle joined #evergreen |
12:15 |
tsbere |
csharp: Force pushed a rebased branch with an added commit. You can probably just cherry-pick. Though I did mess with the CREATE TRIGGER too. |
12:45 |
|
mrpeters joined #evergreen |
12:53 |
kmlussier |
hmmm...the comments in the git commit at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=6ec8bcea7e3a1b93fd9d4627571d95483c55b635 lead me to believe that the intent wasn't to strip the general search parameters from the Advanced search links. |
12:53 |
pinesol_green |
[evergreen|Liam Whalen] LP#1037171 Removed Expert Search paramters from subject links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6ec8bce> |
12:54 |
tsbere |
kmlussier: Looks mainly like a whitespace issue. I rebased it, though I suspect my attempts at correcting the rebase whitespace issue caused a lot more whitespace changes elsewhere in the one file. |
12:54 |
|
mrpeters left #evergreen |
12:54 |
kmlussier |
tsbere: Thanks! |
12:56 |
kmlussier |
I'm tracking Bug Squashing Day activity in a Google spreadsheet at https://docs.google.com/spreadsheets/d/1w1S2p8lK7_XxD3Rv66ayGSuoK6rebBD6XJAL51kNnGM/edit?usp=sharing. |
12:57 |
* kmlussier |
thinks she should add a rebase dusty bugs column for all the rebasing tsbere has been doing. |
12:59 |
DPearl |
I'm have a "bit" of trouble. I'm attempting to use cstore to set a new bit in a circ record to TRUE. All seems OK, but the bit is just not being set! There aren't a lot of similar examples in the code, so I figure I'm doing something wrong. 1) Is the actual bit set correct for a boolean type? 2) Is there a cstore missing? 3) Typo? I'll paste code next. |
13:00 |
pastebot |
"DPearl" at 64.57.241.14 pasted "Sample code which doesn't set the bit" (27 lines) at http://paste.evergreen-ils.org/20 |
13:01 |
tsbere |
DPearl: What have you done with the IDL for the field? |
13:02 |
DPearl |
tsbere: This is the field from the circ class: <field reporter:label="Hide from User History" name="hide_from_usr_history" oils_persist:virtual="true" reporter:datatype="bool"/> |
13:02 |
tsbere |
DPearl: Er, it probably shouldn't be "virtual" at least |
13:03 |
DPearl |
tsbere: I'll admit I'm not familiar with the virtual attribute, and I haven't spotted doc on this! |
13:04 |
tsbere |
DPearl: Think "doesn't actually exist" - As such, if the column does, in fact, exist on the table it shouldn't be virtual. |
13:05 |
DPearl |
tsbere: That is definitely worth checking out! Thanks! |
13:12 |
|
dreuther joined #evergreen |
13:16 |
pinesol_green |
[evergreen|Dan Wells] LP#1078787 Fix serial scoping in TPAC - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9039c4f> |
13:16 |
pinesol_green |
[evergreen|Dan Wells] Fix currently harmless but still confusing sigil error - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a29ef8d> |
13:17 |
DPearl |
tsbere: That was indeed the problem. tsbere++ |
13:35 |
|
berick joined #evergreen |
13:57 |
remingtron |
kmlussier: is there a list of which bugs are already "claimed" and being worked on? |
13:58 |
remingtron |
I know launchpad has that ability, so I guess I'm asking for the list of sandbox branches and maybe who is working on those branches |
13:59 |
kmlussier |
remingtron: I've been asking people to add themselves to the "Assigned To" column when they are working on a bug. But the list of branches being loaded on Sandboxes is available at https://docs.google.com/spreadsheets/d/1S6X0pRuDrt5cjmro90cwFSdBxAwf39I5lrBCyLlk9AY/edit?usp=sharing |
14:00 |
remingtron |
Looks like a private document, so I'll request access. |
14:00 |
remingtron |
and I'll also check launchpad |
14:01 |
kmlussier |
Oh, I can make it public. Hold on. |
14:01 |
remingtron |
kmlussier++ #organizing everybody |
14:01 |
kmlussier |
It should work now. |
14:01 |
yboston |
kmlussier++ |
14:02 |
remingtron |
kmlussier: thanks! it's public now |
14:02 |
* kmlussier |
goes back to shaking her fist at mkurl. |
14:31 |
|
remingtron joined #evergreen |
14:35 |
|
dbwells joined #evergreen |
14:48 |
|
krvmga joined #evergreen |
14:49 |
jihpringle |
kmlussier: if the fix doesn't completely fix the bug should I be removing the pullrequest tag? |
14:53 |
tsbere |
That might depend on what it doesn't fix compared to what it does |
14:53 |
tsbere |
partial fix may still be better than nothing in some cases |
14:55 |
kmlussier |
jihpringle: I would leave it and let the developer decide if it should be removed or not. |
14:55 |
kmlussier |
jihpringle: But post a comment on the bug letting them know how it worked. |
14:55 |
jihpringle |
I'm posting the comment now |
14:56 |
kmlussier |
jihpringle++ #testing |
15:02 |
jihpringle |
kmlussier: would you load the fix for 1010027 when you have a moment? |
15:04 |
kmlussier |
jihpringle: Absolutely! |
15:04 |
jihpringle |
thanks :) |
15:05 |
|
akilsdonk joined #evergreen |
15:13 |
kmlussier |
jihpringle: It should be ready in about 15 minutes. When you see the catalog at http://mlnc4.mvlcstaff.org/, it's ready. |
15:13 |
jihpringle |
perfect, gives me time to go grab lunch :) |
15:15 |
kmlussier |
My computer is acting funky. I'll be back after a quick reboot. |
15:23 |
|
kmlussier joined #evergreen |
15:28 |
kmlussier |
MARC expert search is quite fast when you're using Concerto. :) |
15:41 |
csharp |
tsbere: thanks - I've cherry-picked your commit to my signoff branch and added a DROP TRIGGER IF EXISTS statement - if you agree with that, feel free to sign off on that ;-) |
15:41 |
* csharp |
sees that this probably should've been a collab branch now ;-) |
16:13 |
yboston |
Is Leam Whalen on IRC now by any chance? does anyone know his IRC nickname? |
16:14 |
yboston |
*Liam (sorry) |
16:14 |
kmlussier |
ldw ^ ^ |
16:14 |
yboston |
kmlussier: thanks! |
16:15 |
yboston |
ldw: do you have time for me to ask you a couple of quesiotns? |
16:15 |
yboston |
ldw: it concerns a bug I am testing today that you wrote code for https://bugs.launchpad.net/evergreen/+bug/1282286 |
16:15 |
pinesol_green |
Launchpad bug 1282286 in Evergreen 2.6 "Pressing Shift-F3 in the MARC editor results in invalid lose data warning" (affected: 2, heat: 14) [Undecided,New] |
16:19 |
tsbere |
DPearl: Your img branch seems to rename the images, but that is all it does. Did you forget to commit the changes to the references to the images? |
16:21 |
* collum |
didn't get to play in Evergreen as much as he wanted to today |
16:23 |
dbs |
tsbere: that's the same message I put in the bug :) |
16:24 |
tsbere |
dbs: I noticed when I went to add to the bug myself. |
17:02 |
kmlussier |
jihpringle: Are you ready for the next one? |
17:03 |
jihpringle |
I am, though a fix has since been committed for it |
17:03 |
jihpringle |
I'd like to test it though to see what's in master since I think we have further fixes on our system |
17:04 |
kmlussier |
Ah, I hadn't even noticed which one it was. We also had another request for that one to be loaded on a Sandbox. I'll load it now. |
17:04 |
jihpringle |
thanks |
17:09 |
kmlussier |
jihpringle: Ha ha. I clearly wasn't thinking. Since it's in master now, I didn't need to reload things. It would have been there the last time I updated your VM. Unfortunately, I didn't realize it until after I blew away your VM. It should be ready again in about 15 minutes. |
17:09 |
jihpringle |
didn't occur to me either, thanks :) |
17:13 |
kmlussier |
Just a note that we do have a handful of bugs with signedoff tags if anyone is looking for already-tested code to push into masters. http://bit.ly/1takjv9 |
17:13 |
* kmlussier |
should probably feed her children. |
17:16 |
* mmorgan |
is tired from bug squashing. |
17:17 |
mmorgan |
kmlussier: I am finished testing 1012308, if you need to know about that (before or after you feed your children) ;-) |
17:20 |
kmlussier |
mmorgan: OK, thanks for your squashing efforts today! |
17:20 |
|
mdriscoll left #evergreen |
17:21 |
mmorgan |
and thanks for yours!! |
17:24 |
|
mmorgan left #evergreen |
17:24 |
yboston |
kmlussier: I am throwing in the towel for bug squashing todaty. ON the one bug I worked on I verified that it work for most uses cases that used to fail, but found a big new bug the new code seems to have cause |
17:25 |
kmlussier |
yboston: OK. Have you added comments to the LP bug? |
17:25 |
yboston |
just did |
17:25 |
kmlussier |
yboston: Well, then, that gets you on the spreadsheet. :) |
17:25 |
yboston |
will the VMS be running tomorrow ro the rest of the week? |
17:26 |
kmlussier |
Check with Bmagic on your VMs. |
17:26 |
yboston |
OK |
17:26 |
kmlussier |
MassLNC is planning to keep theirs up for a while. |
17:27 |
kmlussier |
That is, ours. |
17:27 |
jihpringle |
kmlussier: I know the focus of today was squashing bugs but I also created a few new bug reports for minor issues I came across setting up serials testing |
17:28 |
jihpringle |
I noticed that you've reported a bunch of the serials bugs |
17:28 |
jihpringle |
when you have time could you confirm my new bugs? |
17:28 |
kmlussier |
jihpringle: Yup. Reporting bugs is good too. They can't get fixed if nobody knows about them. :) |
17:28 |
jihpringle |
https://bugs.launchpad.net/evergreen/+bug/1361786 |
17:28 |
pinesol_green |
Launchpad bug 1361786 in Evergreen "Copy Template Editor Summary Displays Database IDs Rather Than Helpful Information" (affected: 1, heat: 6) [Undecided,New] |
17:28 |
kmlussier |
jihpringle: Sure |
17:29 |
* kmlussier |
should add "Reporting New Bugs" to the spreadsheet. |
17:29 |
jihpringle |
https://bugs.launchpad.net/evergreen/+bug/1361801 |
17:29 |
pinesol_green |
Launchpad bug 1361801 in Evergreen "Serials: Issuance "Date Published" Should be Required Field" (affected: 1, heat: 6) [Undecided,New] |
17:30 |
jihpringle |
it's the perfect time to report bugs :) |
17:32 |
|
mmorgan joined #evergreen |
17:32 |
|
mmorgan left #evergreen |
17:34 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
18:50 |
|
serflog joined #evergreen |
18:50 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
20:18 |
kmlussier1 |
It would be nice to see bug 1189556 go in since it just fixes a small typo and has had a sign-off for more than a year. |
20:18 |
pinesol_green` |
Launchpad bug 1189556 in Evergreen "Typo: 'Allows a user to process and verify ULSs'" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1189556 - Assigned to Chris Sharp (chrissharp123) |
20:23 |
jihpringle |
agreed, that looks like a nice simple fix |
20:24 |
kmlussier1 |
It still works too. I just checked it. But it seemed overkill to add a second sign-off to it. :) |
20:24 |
jihpringle |
offer a prize for the person who pulls it into master first? |
20:25 |
jihpringle |
:) |
20:26 |
jihpringle |
kmlussier1: have a good night and thanks for organzing bug squashing day! |
20:26 |
jihpringle |
kmlussier++ |
20:26 |
kmlussier1 |
jihpringle: You have a nice night too. Thanks for your help! |
20:27 |
jihpringle |
:) night |
20:27 |
* kmlussier1 |
would offer cookies, but those have been set aside of MassLNC development partners. |
21:11 |
|
kmlussier joined #evergreen |
21:48 |
pinesol_green` |
[evergreen|Kyle Tomita] LP1182605 : LC call numbers sort improperly in tabular displays - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=10ccb80> |
21:48 |
pinesol_green` |
[evergreen|Victoria Lewis] lp1182605 Abstracting out common functionality from code that sorts call numbers by label_sortkey - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=59b0333> |
21:48 |
pinesol_green` |
[evergreen|Kathy Lussier] lp1182605 Add sort value for holds interfaces - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6deb8cf> |
22:01 |
|
jeff__ joined #evergreen |
22:39 |
|
shadowspar joined #evergreen |
22:48 |
|
dcook joined #evergreen |
23:36 |
|
Swift1 joined #evergreen |
23:36 |
Swift1 |
Hi |
23:36 |
Swift1 |
Anybody's here? |
23:36 |
Swift1 |
HOLAAA |
23:37 |
bshum |
Swift1: Salutations |
23:37 |
bshum |
Greetings and hello. |
23:37 |
Swift1 |
Igual... |
23:40 |
bshum |
Swift1: It's usually pretty quiet in IRC at this time. Lots of people are in east coast US time. |
23:42 |
Swift1 |
Mmm ok |
23:42 |
Swift1 |
Here in my country is at night... |
23:44 |
bshum |
Fair enough. |
23:44 |
bshum |
In any case, hello then :) |
23:46 |
bshum |
Were you just checking to see who's alive in here? Or did you have a question? (perhaps I could help out before I sign off) |
23:47 |
Swift1 |
I live in Venezuela |
23:48 |
Swift1 |
Bye |
23:48 |
|
Swift1 left #evergreen |