| Time |
Nick |
Message |
| 02:27 |
|
annagoben joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:44 |
|
bdljohn joined #evergreen |
| 08:23 |
|
rlefaive joined #evergreen |
| 08:32 |
JBoyer |
sandbergja++ # Finding tuits for bug 1772444 where I had none |
| 08:32 |
pinesol_green |
Launchpad bug 1772444 in Evergreen 3.0 "User information missing from billing receipts" [Undecided,Confirmed] https://launchpad.net/bugs/1772444 |
| 08:34 |
|
stephengwills joined #evergreen |
| 08:41 |
|
idjit joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:49 |
|
rlefaive joined #evergreen |
| 08:52 |
|
rlefaive joined #evergreen |
| 08:59 |
|
rlefaive joined #evergreen |
| 09:02 |
|
lsach joined #evergreen |
| 09:12 |
|
kmlussier joined #evergreen |
| 09:30 |
|
jvwoolf joined #evergreen |
| 09:38 |
JBoyer |
acl_support++ # /me learns that non-Windows/non-VMS/etc. filesystems have come a long way since last paying attention to them. |
| 09:51 |
kmlussier |
Good morning #evergreen! |
| 09:52 |
kmlussier |
@coffee [someone] |
| 09:52 |
* pinesol_green |
brews and pours a cup of Aricha Selection Seven Ethiopia Yirgacheffe, and sends it sliding down the bar to abneiman |
| 09:52 |
kmlussier |
@tea [someone] |
| 09:52 |
* pinesol_green |
brews and pours a pot of Holy Basil Purple Leaf, and sends it sliding down the bar to cesardv (http://ratetea.com/tea/upton/holy-basil-purple-leaf-organic/1937/) |
| 09:52 |
abneiman |
kmlussier++ # much-needed caffeine :) |
| 09:53 |
kmlussier |
Poor cesardv didn't get any caffeine in his pot of tea. :( |
| 09:55 |
abneiman |
yeah, but that tea sounds delicious though |
| 09:58 |
idjit |
does anyone happen to have a test server with concerto data handy? i've got an oddity. |
| 09:58 |
idjit |
and i'm not sure if it's just me or not |
| 09:59 |
kmlussier |
idjit: https://mlnc4.noblenet.org |
| 09:59 |
kmlussier |
Admin login is admin / evergreen123 |
| 10:00 |
idjit |
kmlussier++ # thanks! |
| 10:02 |
idjit |
ok, my adventure started at bug 1775216. but i'm not sure if this is the same or different. |
| 10:02 |
pinesol_green |
Launchpad bug 1775216 in Evergreen "Inconsistency between client and opac availability counts for statuses with is available flag" [Medium,Confirmed] https://launchpad.net/bugs/1775216 |
| 10:03 |
idjit |
https://mlnc4.noblenet.org/eg/opac/record/30?copy_limit=50;copy_offset=0 says there are 25 of 29 copies available, but only lists 24 copies. and i haven't yet figured out where the other 5 copies went. |
| 10:03 |
idjit |
and the staff client view (https://mlnc4.noblenet.org/eg/staff/cat/catalog/record/30) says that there are only 24 copies. |
| 10:08 |
kmlussier |
mlnc2 has 2.12 and shows the correct count - https://mlnc2.noblenet.org/eg/opac/record/30?copy_limit=50;copy_offset=0 |
| 10:08 |
|
Christineb joined #evergreen |
| 10:09 |
kmlussier |
I should start up a 3.0 VM and see what happens there. I suspect it broke in 3.0, which is what we saw with bug 1775216 |
| 10:09 |
pinesol_green |
Launchpad bug 1775216 in Evergreen "Inconsistency between client and opac availability counts for statuses with is available flag" [Medium,Confirmed] https://launchpad.net/bugs/1775216 |
| 10:10 |
kmlussier |
I guess it's not just the availability counts that are off. |
| 10:11 |
idjit |
correct or consistent? i fear that the 24 might be wrong. copy id 31 (barcode CONC4000066) for example doesn't show up in any of the lists, but it looks normal enough in copy status. compare to copy id 431 (barcode CONC90000466). |
| 10:12 |
idjit |
hrm.. location "reserves" instead of "stacks"... i wonder if the others are there too. i'll get back to you if i learn something. i'm just glad to confirm behavior is consistent on other instances. |
| 10:16 |
|
Dyrcona joined #evergreen |
| 10:17 |
kmlussier |
Reserves is OPAC visible for BR1, so it should be showing. I don't see anything else on that record that says it's not opac visible. Also, it's not displaying in the client either, which will show things that are not opac visible. hmmm |
| 10:18 |
idjit |
fwiw, that's my patch on 1775216. i found this trying to write a pgtap test for it. the test fails since counts are still inconsistent, but for reasons other than the availability. should i add the test to the branch anyway, or wait until its passing? |
| 10:23 |
kmlussier |
idjit: Well, it appears that the test is probably working, so you could add it. But there may be another bug that needs fixing. |
| 10:24 |
kmlussier |
Also, idjit++ # Adding tests |
| 10:27 |
kmlussier |
Nothing from BR1 is displaying on that record. That seems odd. |
| 10:28 |
idjit |
in case it helps, the wayward copy ids for record 30 are 31, 531, 1031, 1531, and 2031 |
| 10:28 |
idjit |
and other records with similar situations include ids 24, 40, 93, 97, and 100. they all look to be in the same boat. |
| 10:30 |
kmlussier |
I think the call numbers may be deleted? |
| 10:30 |
idjit |
i hadn't thought of that. checking... |
| 10:31 |
kmlussier |
But the copies are not deleted. |
| 10:31 |
* mmorgan |
thinks kmlussier may be on to something |
| 10:31 |
kmlussier |
There are two call numbers owned by BR1 on that record. Both are deleted. |
| 10:37 |
idjit |
looks like it. i still get a mismatched count for records 24, 93, 97, and 100, but at least #93 lists the right number of items in the opac. |
| 10:40 |
kmlussier |
It appears, then, as if the pre-3.0 method of counting copies appropriately excluded copies attached to a deleted call number, but, as of 3.0, those aren't being excluded from the count. Does that sound right? |
| 10:40 |
idjit |
are you asking me if that sounds like the correct behavior (i have no idea), a reasonable theory for what we're seeing (that sounds about right), or asking someone else if they know what's going on? :-) |
| 10:42 |
|
yboston joined #evergreen |
| 10:42 |
kmlussier |
The 2nd. Is the a reasonable theory for what we're seeing. |
| 10:42 |
mmorgan |
kmlussier: I'm not sure that's exactly what I'm seeing on another test system. |
| 10:43 |
kmlussier |
mmorgan: Are you not seeing those types of copies being counted or are you seeing something totally different affecting the counts? |
| 10:44 |
idjit |
deleted call numbers are certainly a part of it. that accounts for all of the missing copies on record #30. |
| 10:44 |
mmorgan |
Well, first it's a 3.1 beta system, so not sure what that throws into the mix. |
| 10:44 |
kmlussier |
mmorgan: I'm looking at 3.1.1 |
| 10:45 |
mmorgan |
Ok. |
| 10:46 |
mmorgan |
I have 24 copies, not deleted, their call numbers aren't deleted either. In the public catalog, I see total copy count as 22 |
| 10:46 |
mmorgan |
I also have 7 undeleted copies on 2 deleted call numbers. |
| 10:47 |
kmlussier |
mmorgan: It's possible there are multiple issues affecting copy counts. |
| 10:47 |
mmorgan |
Yes, making it harder to pin down! |
| 10:47 |
kmlussier |
mmorgan: What record id is it? I think I know which server it is. |
| 10:48 |
mmorgan |
It's record 30. I'll paste a query that I used to see exactly what's on the record. |
| 10:49 |
pastebot |
"mmorgan" at 64.57.241.14 pasted "Copy query" (9 lines) at http://paste.evergreen-ils.org/9703 |
| 10:57 |
|
beanjammin joined #evergreen |
| 10:59 |
pastebot |
"mmorgan" at 64.57.241.14 pasted "Copy query results on mlnc4 - with status" (32 lines) at http://paste.evergreen-ils.org/9708 |
| 11:00 |
miker |
hrm... deleted CNs with extant copies is Bad Data (tm) ... is that consistently happening across concerto instances? that data is side loaded, so... |
| 11:01 |
kmlussier |
miker: Yes, it's bad data and, unfortunately, bad data sometimes happens in the wild too. It appears to be happening across concerto instances. |
| 11:01 |
kmlussier |
Actually, bad data is probably more likely to happen in the wild. :) |
| 11:02 |
|
gsams joined #evergreen |
| 11:02 |
mmorgan |
Indeed it is! |
| 11:03 |
miker |
kmlussier: bad data does happen in the wild, sure. I think the fix is to stop the bad data from creeping in, and provide ways to detect/repair it, rather than making accommodations for it, though. (however, idjit's patch is a fix for a bug separate from bad data. I'll be looking at it later today, tuits willing) |
| 11:05 |
kmlussier |
miker: But the pre-3.0 code apparently handled this potential scenario appropriately? Shouldn't the 3.0 plus code do the same? |
| 11:05 |
mmorgan |
I undeleted the two deleted call numbers on my test system, and the copy counts are correct now. |
| 11:05 |
kmlussier |
Actually, I should verify that the 2.12 system has the same bad data before I say that with certainty. |
| 11:06 |
* mmorgan |
runs off to check for undeleted copies on delete call numbers in the wild (production server, that is) |
| 11:06 |
miker |
I think "appropriately" may be open to question. but differently, it seems. It didn't explicitly check for the deleted flag on an intervening table, but I'd argue that's a deficiency in the previous code, and checking deleted=f is more correct |
| 11:07 |
miker |
but if the effect of the old code is desirable (ignore deletedness of CNs with live copies) then I think the fix is to provide an upgrade that undeletes call numbers that have live copies. does that sound reasonable? |
| 11:08 |
miker |
and, we should be looking for how CNs might be deleted with live copies (or copies added to deleted CNs, perhaps) |
| 11:08 |
miker |
but if we're only seeing this on concerto data, I'd make the side-loading scripts suspect number one... |
| 11:10 |
kmlussier |
I don't know. Is anyone seeing this kind of data on production systems? I don't have a production system to check. |
| 11:10 |
Dyrcona |
Deleted call numbers with not deleted copies? |
| 11:10 |
kmlussier |
yes |
| 11:10 |
miker |
kmlussier: I'm looking at one big data set right now |
| 11:10 |
* kmlussier |
suspects that, if it did happen, it would occur through direct database updates. |
| 11:10 |
Dyrcona |
Probably. I'll check. |
| 11:10 |
miker |
select count(*) from asset.call_number cn where deleted and exists (select 1 from asset.copy where call_number = cn.id); |
| 11:10 |
miker |
er, that's not complete |
| 11:10 |
* mmorgan |
found 63 undeleted copies on deleted call numbers (live bibs) |
| 11:11 |
miker |
select count(*) from asset.call_number cn where deleted and exists (select 1 from asset.copy where call_number = cn.id and not deleted); |
| 11:12 |
mmorgan |
Here's what I used... |
| 11:12 |
pastebot |
"mmorgan" at 64.57.241.14 pasted "query for copies on deleted call numbers" (6 lines) at http://paste.evergreen-ils.org/9714 |
| 11:13 |
Dyrcona |
I have 4. Didn't check if the bibs were deleted or not. |
| 11:14 |
dbs |
Maybe the concerto data deliberately sets up the acn/acp situation? |
| 11:14 |
Dyrcona |
One of these call numbers has id -1. |
| 11:14 |
mmorgan |
miker's query gave me 102 |
| 11:15 |
miker |
Dyrcona: heh ... I've seen CN -1 get deleted before. it shouldn't be, but it doesn't actually create problems, I think. |
| 11:15 |
Dyrcona |
I did a select cound(distinct acn.id) .... |
| 11:15 |
Dyrcona |
s/cound/count/ |
| 11:15 |
Dyrcona |
miker: I've seen it before, too, but don't recall the problems. |
| 11:16 |
Dyrcona |
I'll undelete it in a sec. |
| 11:16 |
kmlussier |
miker: I might be misunderstanding what you said above, but I think your description above of the old code ignoring the deletedness of CNs with live copies isn't what was happening. |
| 11:16 |
miker |
I have a theory I'm testing... I wonder if the copies were accidentally deleted and then someone undeleted them in the DB directly without undeleting the CN (which was auto-deleted with the last copy) |
| 11:16 |
kmlussier |
Undeleted copies that are attached to a deleted CN do not display in the holdings list. This seems correct to me. |
| 11:17 |
Dyrcona |
select count(distinct acn.id) from asset.call_number acn join asset.copy acp on acp.call_number = acn.id and not acp.deleted where acn.deleted; |
| 11:17 |
dbs |
120 instances of acn=deleted acp=not deleted in production here |
| 11:17 |
miker |
and, for me at least, that theory seems to hold water. |
| 11:17 |
kmlussier |
Prior to 3.0, the count also did not count those holdings, making it consistent with the catalog display. That also seems correct to me. |
| 11:17 |
miker |
I looked at the auditor table for asset.copy and see the copies were deleted in the past |
| 11:17 |
miker |
only direct db access can undelete copies, so... |
| 11:18 |
|
yboston joined #evergreen |
| 11:18 |
miker |
(that is, my 3 instances in the wild) |
| 11:20 |
idjit |
completely unrelated, should https://mlnc4.noblenet.org/eg/opac/record/24?copy_limit=50;copy_offset=0 have a green header bar, like https://mlnc2.noblenet.org/eg/opac/record/24?copy_limit=50;copy_offset=0 does? |
| 11:20 |
kmlussier |
Whatever we for those specific copies, I think the logic used to determine what displays in the holdings table should match the logic of what is counted above. |
| 11:21 |
kmlussier |
idjit: That's related to whether you're already logged into the client or not. It is removed when you have a client login. |
| 11:21 |
idjit |
oh, i see. thanks! |
| 11:21 |
kmlussier |
idjit: no problem! |
| 11:22 |
miker |
kmlussier: agreed, count and list should match. I /think/ that means checking the deleted flag on asset.call_number, right? |
| 11:22 |
kmlussier |
miker: Yes |
| 11:22 |
kmlussier |
miker: But the counts in 3.0+ is not checking the deleted flag |
| 11:22 |
kmlussier |
s/is/are |
| 11:23 |
idjit |
^opac counts aren't checking deleted flag. it looks like staff client counts are. |
| 11:23 |
idjit |
(3.0+) |
| 11:23 |
kmlussier |
Yes, what idjit said. I forgot about the client/opac differences. |
| 11:24 |
miker |
right, that's what idjit's patch does IIUC |
| 11:24 |
idjit |
the patch does not care about deleted. it cares about if the copy status has "is_available" set to true or false in config.copy_status. |
| 11:25 |
* miker |
goes looking for the code before speaking more :) |
| 11:26 |
idjit |
what i mean is: there's more than one difference between the staff client and opac queries. asset.opac_ou_record_copy_count vs asset.staff_ou_record_copy_count. |
| 11:27 |
miker |
idjit: ok, gotcha. I looked at the tip commit and that code does include "AND NOT cn.deleted", and misremembered the previous commit ... the patron version needs to learn that part |
| 11:27 |
kmlussier |
Yes, the original report related to availability counts, but, in writing a test for that fix, idjit discovered this other issue with the delete cns |
| 11:27 |
kmlussier |
idjit++ |
| 11:28 |
miker |
since they're very related, I'm in favor of fixing both in one branch, and adding a "UPDATE asset.call_number SET deleted=false WHERE..." to the upgrade script. fwiw |
| 11:29 |
kmlussier |
+1 |
| 11:30 |
idjit |
what about the lasso and metarecord versions of these functions? |
| 11:31 |
mmorgan |
miker: Could there be potential problems with collisions with undeleted call numbers that are otherwise identical? |
| 11:32 |
miker |
mmorgan: yes. would it be preferable to merge those copies to live CNs? |
| 11:33 |
mmorgan |
Yes, I would say so. |
| 11:33 |
miker |
that's straight-forward enough, I think |
| 11:35 |
Dyrcona |
Hm... One of these deleted call numbers was created post upgrade and I know we have not updated any copies in the database since. |
| 11:37 |
kmlussier |
Dyrcona: Possibly a web client issue that hasn't been discovered yet? |
| 11:38 |
Dyrcona |
kmlussier: Looks like it. It was created 6/1 and deleted 5 minutes later. The copy is not deleted. |
| 11:39 |
miker |
Dyrcona: to the logs!(?) |
| 11:39 |
Dyrcona |
Maybe later. |
| 11:49 |
mmorgan |
Interesting, one of the items with a deleted call number has been in that state for several years but has managed to circulate six times without being visible in the catalog. |
| 11:52 |
miker |
mmorgan: the magic of shelf browsing? :) |
| 11:53 |
mmorgan |
Yes, or perhaps holds |
| 11:55 |
kmlussier |
mmorgan: How could there be a hold if it's not visible in the catalog? |
| 11:56 |
mmorgan |
Other libraries have copies so the record is visible. Looks like a title that might attract holds, to me: https://evergreen.noblenet.org/eg/opac/record/3019368 |
| 12:03 |
|
beanjammin joined #evergreen |
| 12:22 |
|
jihpringle joined #evergreen |
| 12:34 |
idjit |
y'all sick of me yet? perhaps a cat would help... https://i.imgur.com/KIPOlfY.gifv |
| 12:34 |
idjit |
anyway, holdings view (web staff client, 3.1) includes call numbers that have no copies, so for record #30 it says there are 26 items, but opac view say 24 items. is "inconsistent" or "expected"? |
| 12:45 |
kmlussier |
idjit: We are never sick of people working to fix a bug! |
| 12:48 |
kmlussier |
idjit: Are you asking if call numbers with no copies should be counted? No, I wouldn't think so. Quite often, the client will show more copies than in the opac, but it's usually due to copies that are not opac visibile. |
| 12:48 |
kmlussier |
visible, even |
| 12:50 |
kmlussier |
Poor kitty. |
| 12:50 |
|
rlefaive joined #evergreen |
| 12:56 |
mmorgan |
kmlussier: idjit: I think the empty call numbers should show in holdings maintenance as long as they are not deleted. Empty call numbers shouldn't be included in copy counts, though. |
| 12:59 |
kmlussier |
Yes, but I don't believe they are showing in current Evergreen holdings view right now. That patch hasn't been merged yet. I was specifically referring to the count in my answer. |
| 13:21 |
idjit |
that looks good then. the rows in the holdings view are numbered, so if you scroll down you can see there are 26 holdings, but 24 records. (because two CNs have no copies). |
| 13:21 |
idjit |
s/records/copies/ |
| 13:41 |
jeffdavis |
Dyrcona: yesterday you mentioned problems with copy templates - are you seeing the problem described in bug 1772062 ? |
| 13:41 |
pinesol_green |
Launchpad bug 1772062 in Evergreen "Copy Template Missing Values When Applied" [High,Confirmed] https://launchpad.net/bugs/1772062 |
| 13:41 |
|
rlefaive joined #evergreen |
| 13:47 |
Dyrcona |
jeffdavis: I don't recall seeing reports of that. We were getting reports of the templates drop down being empty. |
| 13:49 |
jeffdavis |
interesting, thanks |
| 14:06 |
Dyrcona |
jeffdavis: I think the two bugs might be related just the same. |
| 14:07 |
Dyrcona |
I don't see all of our tickets by default, so I'm looking through some others. |
| 14:08 |
kmlussier |
The templates being empty might be related to bug 1773995. |
| 14:08 |
pinesol_green |
Launchpad bug 1773995 in Evergreen "web client: xul copy template conversion does not immediately propagate xul templates to templates tab" [Medium,Confirmed] https://launchpad.net/bugs/1773995 |
| 14:09 |
Dyrcona |
Someone did report stat cats not applying when they used a template, but then when they logged out and logged back in, the templates drop down was empty. |
| 14:09 |
Dyrcona |
kmlussier: It's almost always a case of "they showed up yesterday (i.e. pre-opensrf update) and they're gone today." |
| 14:10 |
Dyrcona |
So, I reverted the OpenSRF patch and went back to the older apache-websocket module. |
| 14:10 |
* kmlussier |
thinks she missed something in that bug description. |
| 14:10 |
kmlussier |
Dyrcona: Sure, I wouldn't be surprised if there were more causes. That's just the one I was able to make happen. |
| 14:11 |
Dyrcona |
OK. |
| 14:11 |
Dyrcona |
It looks like only 1 ticket out of about 5 mentions templates not applying completely. |
| 14:12 |
Dyrcona |
The other tickets are of the variety of some or all of our templates are missing (mostly all). |
| 14:12 |
Dyrcona |
And that one ticket that does mention templates not applying everything is the one I mentioned where the templates later disappeared. |
| 14:19 |
|
rlefaive joined #evergreen |
| 14:24 |
kmlussier |
@dessert [someone] |
| 14:24 |
* pinesol_green |
grabs some coffee frappes for jvwoolf |
| 14:25 |
kmlussier |
If I had known it was going to be coffee frappes, I would have given it to myself. |
| 14:27 |
idjit |
what is asset.copy_vis_attr_cache? |
| 14:31 |
pastebot |
"idjit" at 64.57.241.14 pasted "evergreen=# select target_copy" (28 lines) at http://paste.evergreen-ils.org/9803 |
| 14:31 |
idjit |
i'm still on asset.opac_ou_record_copy_count and i'm getting incorrect counts on concerto data for records 24, 93, 97, and 100. something looks wrong with the data here. |
| 14:34 |
|
JBoyer joined #evergreen |
| 14:38 |
kmlussier |
idjit: It was added with bug 1698206 and is what we now use to determine if a copy is opac visible or not. |
| 14:38 |
pinesol_green |
Launchpad bug 1698206 in Evergreen "Eliminate staged search" [Wishlist,Fix released] https://launchpad.net/bugs/1698206 |
| 14:47 |
idjit |
kmlussier: thanks. it looks like i managed to bork my data then. i'm not getting the same counts on mlnc4.noblenet.org. is it necessarily a problem if the same copy has multiple rows in asset.copy_vis_attr_cache? should that be a unique key for this table? |
| 14:48 |
idjit |
i'm curious if that first query in my paste a minute ago is expected to return anything or not. i suspect not, since those four extra records are the exact four that are making my test fail. |
| 14:56 |
idjit |
wait! it's a foreign item. ....what the heck is a foreign item, and should that be included on the copy counts? |
| 14:59 |
kmlussier |
idjit: Those are for peer bibs, which I'm not very familiar with. There is a bug related to copy counts for peer bibs that pre-dates asset.copy_vis_attr_cache. |
| 14:59 |
kmlussier |
bug 1587620 |
| 14:59 |
pinesol_green |
Launchpad bug 1587620 in Evergreen "Staff copy counts do not include peer bib copies" [Undecided,New] https://launchpad.net/bugs/1587620 |
| 15:00 |
idjit |
kmlussier++ # that's gotta be it. thanks! |
| 15:00 |
kmlussier |
idjit: I also just tried your sql query on mlnc4 and I'm getting the same results. |
| 15:01 |
idjit |
https://mlnc4.noblenet.org/eg/opac/record/24 says there are 32 copies, https://egmaster.grpl.org/eg/opac/record/93?copy_limit=50;copy_offset=0 says 31 copies. the difference is the foreign/peer one. so my test is still failing. guess i figured out which bug to work on next :-) |
| 15:02 |
idjit |
yeah, so the same copyid is allowed to show up multiple times in that table if it's a foreign/peer copy for the listed records. the concerto dataset only has the one copy that uses this. |
| 15:02 |
idjit |
the opac version of copy counts joins on the copy_vis table, but the staff version doesn't, which is why the counts are off. |
| 15:03 |
|
rlefaive joined #evergreen |
| 15:15 |
pinesol_green |
[evergreen|Cesar Velez] LP#1745422 - Add Parts column to Patron holds grids and detail view - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0da274f> |
| 15:15 |
pinesol_green |
[evergreen|Michele Morgan] LP#1745422 - Removed three commented out lines from the code and signoff. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6a41918> |
| 15:19 |
miker |
idjit: you could get multiple rows for one copy if the copy is involved in conjoined bibs (that is, linked to a "foreign" record) |
| 15:19 |
miker |
oh, nm, you figured that out :) |
| 15:20 |
idjit |
miker++ still appreciate it. :-) |
| 15:20 |
* miker |
promises, again, to read all scrollback before answering... |
| 15:21 |
|
sandbergja joined #evergreen |
| 15:24 |
kmlussier |
miker: lol - that could be our new conference karaoke challenge. Anyone who adds to a discussion without reading scrollback has to sing. |
| 15:25 |
* kmlussier |
will do anything to get out of the current karaoke challenge that involves meeting annual report deadlines. |
| 15:25 |
miker |
heh |
| 15:30 |
* rhamby |
makes notes to start logging irc for kmlussier not reading back |
| 15:30 |
kmlussier |
Darn! I didn't realize rhamby was paying attention. |
| 15:31 |
miker |
rhamby /always/ reads the scrollback |
| 15:52 |
* berick |
sings Don't call it a scrollback |
| 15:53 |
rhamby |
berick++ |
| 16:47 |
* miker |
reads berick's first line in the LP comment as "push-ed", like Shakespearian "banish'd" |
| 16:49 |
berick |
bless'ed be the lp reader |
| 16:49 |
kmlussier |
berick++ # Fighting white screens. |
| 16:54 |
|
jvwoolf left #evergreen |
| 16:57 |
|
yboston joined #evergreen |
| 17:01 |
pinesol_green |
[evergreen|a. bellenir] LP1775294: item status should show floating group name - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=10e9ee8> |
| 17:06 |
kmlussier |
I think that may be idjit's first contribution that has been merged. idjit++ |
| 17:06 |
idjit |
whoo! \o/ |
| 17:07 |
mmorgan |
idjit++ |
| 17:07 |
berick |
idjit++ # woo |
| 17:07 |
* idjit |
blushes |
| 17:08 |
|
mmorgan left #evergreen |
| 17:09 |
idjit |
kmlussier: regarding bug 1743801, honestly, i had the same reservations. i think it'd be better if fine_level and loan_duration were "fleshable" fields in the fieldmapper. but the DB constraint says ANY (ARRAY[1, 2, 3]), and it's not a foreign key to anything. |
| 17:09 |
pinesol_green |
Launchpad bug 1743801 in Evergreen 3.0 "web client: item status list view display issues" [High,Confirmed] https://launchpad.net/bugs/1743801 |
| 17:11 |
kmlussier |
idjit: Yes, I think it's probably fine the way it is, but I wanted another set of eyes to look at it just in case I was missing something. |
| 17:11 |
idjit |
were you going to merge the optional page for "yes/no" instead of "true/false" as well? (that bug is a mess. damn n00bz dont know how to submit a proper patch.) |
| 17:11 |
idjit |
s/page/patch/ |
| 17:19 |
pinesol_green |
[evergreen|Geoff Sams] LP#16989634 - Changing z-index to 4 to allow active text boxes to pass under patron tabs naturally. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=60caf87> |
| 17:23 |
kmlussier |
idjit: No, I was going to suggest a new bug for it if people still thought it was an issue. I personally think it's fine the way it is, but I'm happy to go with community consensus. |
| 17:23 |
kmlussier |
It's hard to get that consensus on a bug with so many pieces to it. |
| 17:24 |
kmlussier |
gsams++ # First code contribution! |
| 17:25 |
idjit |
kmlussier: oh, perfect. it was referenced on bug 1741347, too, so i think you're right; a separate issue would be best. |
| 17:25 |
pinesol_green |
Launchpad bug 1741347 in Evergreen "Web client: display issues in Copy buckets" [Undecided,New] https://launchpad.net/bugs/1741347 |
| 17:25 |
idjit |
gsams++ |
| 17:25 |
idjit |
kmlussier++ |
| 17:32 |
gsams |
kmlussier: Thanks! It was small, but I was happy to start somewhere! |
| 17:34 |
kmlussier |
gsams: Most of us started small. But once you get that first commit in, there's no stopping you. :) |
| 17:34 |
kmlussier |
https://wiki.evergreen-ils.org/doku.php?id=contributing:contributors has been updated. A very nice way to end the work week. |
| 17:34 |
kmlussier |
Have a nice weekend everyone! |
| 18:17 |
jeffdavis |
anyone have a magic spell handy for automatically killing long-running search queries? |
| 18:18 |
jeffdavis |
(I know how to manually inspect and cancel backend) |
| 18:26 |
jeffdavis |
nvm, found it |
| 18:30 |
pinesol_green |
News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 6. <http://testing.evergreen-ils.org/~live> |
| 18:37 |
|
stephengwills joined #evergreen |
| 19:49 |
|
bdljohn joined #evergreen |
| 21:07 |
|
bdljohn joined #evergreen |
