Time |
Nick |
Message |
00:58 |
|
Mark__T joined #evergreen |
01:01 |
|
dcook joined #evergreen |
06:40 |
|
rlefaive joined #evergreen |
07:43 |
|
jboyer-isl joined #evergreen |
08:01 |
|
rjackson_isl joined #evergreen |
08:22 |
|
jwoodard joined #evergreen |
08:32 |
|
mrpeters joined #evergreen |
08:37 |
|
mmorgan joined #evergreen |
08:49 |
|
Dyrcona joined #evergreen |
08:55 |
|
parsleyfirefly joined #evergreen |
08:56 |
|
Shae joined #evergreen |
09:27 |
Bmagic |
@coffee someone |
09:27 |
* pinesol_green |
brews and pours a cup of Ethiopia Sidamo Natural Korate, and sends it sliding down the bar to someone |
09:28 |
Bmagic |
Enjoy someone! |
09:28 |
bshum |
Hehe |
09:28 |
bshum |
@tea [someone] |
09:28 |
* pinesol_green |
brews and pours a pot of Keemun Full Leaf Tea, and sends it sliding down the bar to taterrr (http://ratetea.com/tea/foojoy/keemun-full-leaf/6686/) |
09:28 |
Bmagic |
In reality I'm drinking "Harolds Coffee" from a local brew house! |
09:31 |
kmlussier |
Heh. Reminds me of the time I did this: |
09:31 |
kmlussier |
@coffee [somebody] |
09:31 |
* pinesol_green |
brews and pours a cup of El Salvador Finca Kilimanjaro, and sends it sliding down the bar to The horror... The horror... |
09:31 |
bshum |
Hehe |
09:32 |
bshum |
That's funny, kmlussier. |
09:32 |
kmlussier |
pinesol_green is a funny bot |
09:32 |
pinesol_green |
kmlussier: If all else fails, try this: http://en.wikipedia.org/wiki/Rubber_duck_debugging |
09:32 |
pinesol_green |
Factoid 'is a funny bot' not found |
09:33 |
Dyrcona |
@dunno |
09:33 |
pinesol_green |
Dyrcona: Have you confirmed your ISBN SPIDs with your service provider? |
09:33 |
dbwells |
That bot is full of bits and vinegar today, alright |
09:38 |
|
yboston joined #evergreen |
10:10 |
jwoodard |
are we picking on pinesol today? |
10:11 |
Dyrcona |
pinesol_green is picking on us. |
10:11 |
pinesol_green |
Dyrcona: Mr. Spock: Something fascinating just happened. |
10:11 |
pinesol_green |
Dyrcona: I am only a bot, please don't think I'm intelligent :) |
10:11 |
Dyrcona |
You keep saying that, pinesol_green, but I don't think it is true. :) |
10:12 |
Dyrcona |
I'm only human. Please don't think I'm intelligent. |
10:12 |
jwoodard |
I'm afraid it might go all skynet on us if we continue. |
10:12 |
Bmagic |
Is it possible to define usr.home_ou for "context_org" for a new definition that I'm working on in action_trigger_filters.json ? I have already tried usr.home_ou and the error is "Attempt to reference non-existent column "usr.home_ou" on money.usr_summary (mus)" |
10:14 |
Dyrcona |
Bmagic, you'd have to flesh usr on mus in your template definition somewhere, then reference mus.usr.home_ou |
10:15 |
Dyrcona |
I know in broad terms how to do it, but would need to look up the specifics of how to actually configure it. |
10:15 |
Bmagic |
This is just scoping the at, not even at the parsing of the TT yet |
10:15 |
Bmagic |
/at/AT |
10:16 |
Dyrcona |
Then, you probably can't, but I'm not an expert on A/T. |
10:18 |
Bmagic |
yeah, I was afraid of that, it seems like the table that I work with needs to have an org unit column directly in order to compare it to "context_org". Or maybe I can just give it "1"... I'll keep playing |
10:20 |
jboyer-isl |
Bmagic: I think the "environment" settings for the event_definition can help you do that, but I'm also not that in tune with the triggered events. Maybe there are some stock examples that do something similar that you can crib? |
10:22 |
Bmagic |
It's getting hung up on this http://paste.evergreen-ils.org/14 |
10:24 |
Bmagic |
"1" is what i have it set to currently. This query is created in Trigger.pm starting on line 389ish |
10:25 |
Bmagic |
$location_field = action_trigger_filters.json:context_org definition |
10:26 |
Bmagic |
I guess I could change the mus view to have an org unit column, but that seems wrong |
10:44 |
Dyrcona |
Yeah, it's in the environment where you'd add the fleshing of the usr, but I don't know if that takes effect at the point you're trying to modify, Bmagic. |
10:45 |
Bmagic |
yeah, I've resolved to edit the view |
10:46 |
Bmagic |
Do you think adding the usr.home_ou as a column in the view would be <ok> in the context of getting this feature merged to master? |
10:47 |
Dyrcona |
Bmagic: I'm not keen on it. |
10:48 |
Bmagic |
Sorta what I was thinking |
10:48 |
Bmagic |
I'm trying to create an AT that will simply fire off a notice to patrons based upon their balance_owed |
10:49 |
Bmagic |
easier said than done, as Im learning |
10:51 |
Bmagic |
That view is handy because it has the usr and the sum of the balance_owed in one package, perhaps there is another table/view that would fit the bill which contains an org unit column? |
10:52 |
Dyrcona |
Well, a user can owe money to org_units other than its home_ou. |
10:53 |
Dyrcona |
We have a number of patrons who live in one town, but work in another, and use the library where they work more than the one in their own town, for instance. |
10:53 |
Bmagic |
That is true, hmmm, an interesting twist. The view could have a balance_owed for each org unit I suppose |
10:54 |
Bmagic |
but that will probably break some other code that uses that view |
10:54 |
Bmagic |
perhaps a new view is in order |
10:54 |
Dyrcona |
If you just want to send the patron a notice when they over > X dollars, why do you need the ou for the trigger to fire? |
10:54 |
Bmagic |
it's required for the current code in Trigger.pm |
10:55 |
Dyrcona |
I did not realize that. |
10:55 |
Dyrcona |
See, I don't know that much about A/T. :) |
10:55 |
Bmagic |
return undef unless ($key && $location_field); |
10:56 |
|
TaraC joined #evergreen |
11:01 |
yboston |
Morning, I was looking for confirmation that in EG "in-house" circs are not added to a copy's circ total, |
11:01 |
yboston |
i.e. no entry is made in the action.circulation table. Instead it looks like that in-house circs are only tracked in action.in_house_use? |
11:01 |
yboston |
I started looking at Circ.PM and also ran into this bug 1186391 which led me to my current theory. Thanks |
11:01 |
pinesol_green |
Launchpad bug 1186391 in Evergreen "In house use count does not appear on item status summary " [Wishlist,Triaged] https://launchpad.net/bugs/1186391 |
11:02 |
jeff |
yboston: I can confirm that, yes. |
11:02 |
yboston |
jeff: gracias |
11:03 |
yboston |
on a circ realted note, how are renewals handled in EG? for the most part a new row in action.circulation? |
11:03 |
jeff |
yboston: also, in-house use is recorded in two different places depending on if the item is cataloged or not. |
11:03 |
jeff |
yboston: always a new row in action.circulation, with one of the renewal booleans set to true. |
11:03 |
yboston |
jeff: that explains some if statements in Circ.PM |
11:04 |
jeff |
one of phone_renewal, desk_renewal, or opac_renewal |
11:04 |
yboston |
jeff: muchas gracias |
11:20 |
|
Christineb joined #evergreen |
11:39 |
Bmagic |
/wave Christineb |
11:40 |
Christineb |
Good Morning :D |
11:46 |
* dbs |
wonders yet again why opportunistic capture does not seem to be working, even now that we're on in-db rules. *sigh* |
11:47 |
jboyer-isl |
Bmagic: I stepped away to a meeting almost as soon as I replied to you about your A/T issues (sorry!) But I've done some looking again and have some ideas as to how to proceed if you're still looking into it. |
11:47 |
jboyer-isl |
dbs: action.find_hold_matrix_matchpoint is your friend. |
11:48 |
|
bmills joined #evergreen |
11:49 |
jboyer-isl |
unless this was an issue before in-db holds, in which case it's probably stumbling over an ou setting. (ick.) |
11:49 |
Bmagic |
jboyer-isl: I am still working on it. I have overcome my hurdle, and I have generating output finally. I created a new view. What are your thoughts? |
11:49 |
tsbere |
dbs: I assume you have hold_copy_maps for the hold(s) in question, but do you have stalling configured? |
11:51 |
jboyer-isl |
I'm assuming that your current event_def is using mus as the core type? If you start from au instead and add usr.money_summary to the event environment you should be able to satisfy the need for an ou (home_ou is right there) and still access the balance through money_summary.balance_owed. |
11:51 |
jboyer-isl |
Completely untested, of course! |
11:51 |
|
bmills1 joined #evergreen |
11:52 |
dbs |
jboyer-isl: okay, that returns 1, which is the default rule (and our only rule) |
11:52 |
jboyer-isl |
Though that is an interesting notice type that we've been without for a long time... I should probably fine time to try it out here. |
11:53 |
dbs |
tsbere: yep, we have one entry in hold_copy_map for the hold in question |
11:53 |
tsbere |
dbs: Is that one entry the copy you are trying to capture? |
11:53 |
jboyer-isl |
dbs: Ah. Well, that means it's almost certainly a settings issue then. I didn't realize you only had the 1 hold rule. I was hoping it would return the rule causing the capture to fail (results.holdable = f or something similar). tsbere's hold stalling question sounds like a more fruitfull avenue. |
11:53 |
Bmagic |
jboyer-isl: yeah, the core type was* mus, now it's muspou (money.usr_summary_by_org_unit) because I wasn't thinking that they could owe money at places that are not their home_ou. Now I'm just working through the template syntax. I think Im home free |
11:53 |
dbs |
of course, part of the problem in debugging this is that the non-capture happened yesterday afternoon |
11:54 |
jboyer-isl |
Bmagic: Cool. |
11:54 |
tsbere |
dbs: Check your logs (gateway?) for if suppress holds and transit was turned on for a checkin modifier too, for that matter... |
11:54 |
* tsbere |
goes to lunch |
11:54 |
dbs |
So the hold targeter may have populated hold_copy_map since then I guess |
11:55 |
dbs |
tsbere: yeah, I'll check those too. Brand new workstations so they shouldn't be set, but who knows. People play. |
11:56 |
* mmorgan |
had a hold capture issue the other day that was puzzling. |
11:56 |
dbs |
Neither hard nor soft stalling are set. |
11:56 |
mmorgan |
A library checked in one of their own items. There were holds for pickup at that library, but a hold for pickup at a different library was captured. |
11:57 |
dbs |
And we typically have only one call number and copy per bib, because we're academic. Should be the simplest possible setup for holds you can ever get :) |
11:58 |
mmorgan |
They aborted the transit. Tried retargeting several times, but the target for the other library's hold wouldn't budge. |
11:58 |
jeff |
dbs: SELECT auditor.create_auditor_retroactively ( 'action', 'hold_copy_map', NOW()::DATE - '2 days'::INTERVAL); |
11:58 |
* jeff |
ducks |
11:59 |
mmorgan |
Finally changed the item to a nonholdable status, retargeted the other library's hold so there was no copy for the hold. Retargeted the owning library's hold and all was well. |
12:00 |
mmorgan |
Don't think I've ever had to do that dance before. |
12:00 |
mmorgan |
Not sure if this is at all related to what dbs is seeing, though. |
12:01 |
dbs |
mmorgan: probably not, other than that "holds are almost inscrutable" :) |
12:02 |
mmorgan |
Holds certainly do have an ecosystem all their own!:) |
12:17 |
|
parsleyfirefly joined #evergreen |
12:19 |
Bmagic |
evergreen++ |
12:19 |
Bmagic |
iii-- |
12:19 |
kmlussier |
@karma iii |
12:20 |
pinesol_green |
kmlussier: Karma for "iii" has been increased 0 times and decreased 7 times for a total karma of -7. |
12:20 |
Stompro |
iii-- |
12:20 |
Stompro |
iii-postmaster-- |
12:23 |
Bmagic |
lol |
12:23 |
Bmagic |
poor innovative |
12:23 |
Bmagic |
they only have a few hundred programmers and millions of dollars |
12:24 |
Bmagic |
so cut them some slack |
12:25 |
Stompro |
Hehe, where is that study about how adding more programmers to a project just makes it more likely to fail and be over schedule and budget. |
12:33 |
jboyer-isl |
Bmagic: I looked at some of our existing notices and there's a simple way to do what you're after without a new view. We have a notice tied to the date a particular penalty (you owe too much money) is applied + a few days in case they pay it off. |
12:34 |
jboyer-isl |
It's not a big deal since you figured it out already, but if you want more details about what we've got set up here just let me know. |
12:34 |
jboyer-isl |
(but first, lunch.) |
12:34 |
tsbere |
dbs: Back from lunch with a thought: Is there a problem with the *patron* that is preventing holds? (also, is the hold frozen?) |
12:36 |
dbs |
tsbere: that's a good thought. Lemme check |
12:40 |
|
jihpringle joined #evergreen |
12:40 |
dbs |
everything seems good with the patron |
12:42 |
* dbs |
goes to check the associated workstation where the checkin occurred, which is *not* one of the new ones |
12:54 |
Bmagic |
jboyer-isl: I saw that hook, however, the intention is to continue to notify on a regular basis. I created a library setting for the threshold and added a validator to respect that settings. I suppose the exceeds penalty could be equal to the library setting but it wouldnt have to be |
12:54 |
kmlussier |
bug 1467663 strikes again :( |
12:55 |
pinesol_green |
Launchpad bug 1467663 in Evergreen "Cannot login to web staff client if work station does not exist in database" [Low,New] https://launchpad.net/bugs/1467663 |
12:57 |
Dyrcona |
kmlussier: window.localStorage.clear(); in the JavaScript console of the browser staff client tab/window. |
12:58 |
kmlussier |
Dyrcona: Yeah, I know. I just have to reducate myself each time. It will become second nature soon enough. :) |
13:00 |
dbs |
The best theory that I can come up with is that the hold targeter script is using the timezone of the bash environment (PDT), whereas the database is in EDT, and that the 3-hour difference means that the script thinks that the copy is not actually available for three hours. |
13:00 |
* dbs |
grasps |
13:00 |
kmlussier |
ugh |
13:00 |
kmlussier |
I'm so happy the MassLNC consortia are all in one timezone. |
13:04 |
* dbs |
looks into the 24h check_expire parm being passed into new_hold_copy_targeter |
13:06 |
dbs |
we run the hold targeter hourly... |
13:08 |
miker |
dbs: do you intend to retarget all holds hourly? |
13:09 |
dbs |
miker: That may be a hangover of "why the hell aren't these holds getting captured? Let's ensure that they're targeted" |
13:11 |
miker |
dbs: the 24h being passed is interpreted on the server side, so no timezone stuff is involved in that, in particular |
13:12 |
* dbs |
tries running the targetable holds list with 24h, gets 11 mrs, tries 1m, gets 77 mrs |
13:12 |
dbs |
1m seems naively better |
13:12 |
dbs |
(we obviously have very few holds to worry about) |
13:14 |
jeff |
What is "mrs" in this context? |
13:14 |
tsbere |
dbs: But do you add copies every few minutes that need to be added to the copy maps? ;) |
13:14 |
dbs |
jeff: metarecords |
13:15 |
dbs |
hold, metarecord id |
13:15 |
dbs |
sorry, that didn't make a lot of sense |
13:15 |
dbs |
tsbere: no, heh |
13:15 |
jeff |
dbs: oh, okay. that's where I went first but then questioned and confused myself. |
13:24 |
dbs |
I think I'm going to need to sprinkle a whole bunch of logger messages throughout attempt_checkin_hold_capture() to see where we're bailing |
13:36 |
jboyer-isl |
dbs: Here's a thought. That item that wasn't captured yesterday wasn't created yesterday, was it? We still run into that fairly often, brand new items don't exist in the hold copy maps until their hold gets re-evaluated (i.e. last_check_time is 24+ hours old) |
13:37 |
jboyer-isl |
leading to situations where an item is shelved, then shows up on the pull list first thing in the AM. |
13:54 |
Dyrcona |
Fill not hold copy does, hmm? Activate "Rertarget all statuses" you must. |
13:55 |
dbs |
"Retarget all statuses", that's interesting |
13:55 |
dbs |
Dyrcona++ |
13:55 |
tsbere |
dbs: the all statuses option only works when the "Retarget Local Holds" option is also enabled |
13:55 |
dbs |
jboyer-isl: Some of the cases may be that, as people do like to place holds on on-order items |
13:55 |
Dyrcona |
And it helps mostly with brand, spanking new copies. |
13:55 |
tsbere |
(and I doubt it will help with your issue, given your earlier description of your data) |
13:55 |
yboston |
heads up, the DIG monthly meeting will be starting at 2 PM EST |
13:56 |
dbs |
but then... the item already exists as ACQ857 or whatever, so it should have been targeted long ago. |
13:57 |
jboyer-isl |
dbs: depends on cataloger workflows. Rename on-order item vs create new and delete on-order, etc. |
14:00 |
jeff |
Being in an "on order" status excludes it from ahcm eligibility, iirc. |
14:00 |
yboston |
#startmeeting DIG Monthly Meeting Evergreen Documentation Interest Group (DIG) Monthly Meeting. |
14:00 |
pinesol_green |
Meeting started Thu Oct 1 14:00:53 2015 US/Eastern. The chair is yboston. Information about MeetBot at http://wiki.debian.org/MeetBot. |
14:00 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
14:00 |
pinesol_green |
The meeting name has been set to 'dig_monthly_meeting_evergreen_documentation_interest_group__dig__monthly_meeting_' |
14:00 |
jeff |
i.e., the differences between a brand new copy and a newly-okay-status copy for hold targeting purposes are slim to none, last i looked. |
14:01 |
yboston |
The agenda can be found here http://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:dig_meeting_20151001-agenda |
14:01 |
dbs |
jboyer-isl: not in this case, create_time 2015-09-18, request_time 2015-09-22 |
14:01 |
yboston |
#topic Introductions |
14:01 |
* dbs |
shuts up |
14:01 |
yboston |
Please feel free to start introducing yourselves... |
14:01 |
yboston |
#info yboston is Yamil Suarez @ Berklee College of Music - DIG meeting facilitator |
14:01 |
|
kbutler joined #evergreen |
14:01 |
remingtron |
#info remingtron is Remington Steed, Hekman Library (Calvin College) |
14:01 |
Christineb |
#info Christineb is Christine Burns @ BC Libraries Cooperative / Sitka |
14:01 |
jihpringle |
#info jihpringle is Jennifer Pringle, BC Libraries Cooperative (Sitka) |
14:02 |
kbutler |
#info kbutler is Kate Butler, Rodgers Memorial Library (Hudson, NH) |
14:03 |
yboston |
welcome everyone |
14:03 |
yboston |
#topic Updates from Content Coordinators |
14:03 |
yboston |
I don't think we have any contner coordinators present |
14:03 |
yboston |
kmlussier may be around, but she is the process of stepping down |
14:04 |
yboston |
*in the process |
14:04 |
yboston |
I will move on |
14:04 |
yboston |
#topic previous meeting action items |
14:05 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
14:05 |
yboston |
kmlussier: did you have anything to add about the lrelease? |
14:05 |
kmlussier |
nope |
14:05 |
yboston |
OK |
14:05 |
yboston |
#info 1) kmlussier will complete the marc stream importer work and check on the status of the RDA docs |
14:06 |
yboston |
kmlussier: shoudl I defer this task for next meeting? |
14:06 |
kmlussier |
No progress, but maybe we can get one of those off my plate. I think the status of the RDA docs came from last year's hackaway where jihpringle was working on them. |
14:07 |
kmlussier |
But I don't think they ever were added. |
14:07 |
yboston |
I can defer but not under your name? |
14:08 |
yboston |
or just added to one of our to do lists? |
14:08 |
yboston |
*add it |
14:08 |
kmlussier |
You can defer it then. |
14:09 |
remingtron |
jihpringle: any idea if your work was shared anywhere? |
14:09 |
kmlussier |
I didn't know if she was around right now. |
14:09 |
yboston |
#action need a volunteer to complete the marc stream importer work and check on the status of the RDA docs |
14:09 |
jihpringle |
I'm not sure, I would have to go digging - I think it was around some of the cataloguing content we have in the Sitka manuals that isn't in the docs |
14:10 |
yboston |
should I asign an action item for looking into this? |
14:10 |
jihpringle |
sure |
14:11 |
Stompro |
#info Stompro is Josh Stompro LARL |
14:11 |
yboston |
sorry my phone wrang |
14:12 |
yboston |
how about this… "jihpringle will research the state of missign RDA content" |
14:12 |
jihpringle |
perfect |
14:12 |
yboston |
#action jihpringle will research the state of missign RDA content |
14:12 |
yboston |
movign on |
14:13 |
yboston |
#info 3) kbutler will send an email to the DIG list anouncing she posted her 2.8 work for a DIG memebr to add to docs?. |
14:13 |
yboston |
I beleive this was done(?) |
14:13 |
kbutler |
Yep, I did that. |
14:14 |
remingtron |
kbutler++ |
14:14 |
yboston |
can't remmber if it has been pushed yet |
14:14 |
|
Shae joined #evergreen |
14:14 |
kbutler |
That I do not know. I totally forgot to look. |
14:14 |
yboston |
I can look into it |
14:15 |
yboston |
#action yboston will check that kbutler recenlty shared work has been pushed to the repo |
14:15 |
yboston |
#info 4) Stompro will send a list to DIG list summarizing the 2.8 docs work he has so far shared |
14:16 |
Stompro |
Hmm, I don't think I did this... but I've been keeping all my work in Gists that I link to the doc needs page. |
14:16 |
Stompro |
I've got too many in progress now, I need to finish some up. |
14:16 |
yboston |
no worries |
14:16 |
Stompro |
Going live on the 26th, so I'm not sure I'll have time for a month or two. |
14:17 |
yboston |
let us know on the list or directly if there are things that are deady to be pushed |
14:17 |
remingtron |
Stompro++ #for sharing via gists |
14:17 |
yboston |
*ready |
14:17 |
Stompro |
Hehe, Deadly to be pushed. I like it. |
14:17 |
kmlussier |
Stompro: Good luck with the go live! |
14:17 |
Stompro |
Thanks |
14:18 |
yboston |
Stompro++ |
14:18 |
yboston |
moving on |
14:18 |
yboston |
#info 5) yboston will move the undocumented content of the 2.8 new feature “TPAC Discoverability Enhancements” to its own section in the docs |
14:18 |
yboston |
will need to defer |
14:18 |
yboston |
#action yboston will move the undocumented content of the 2.8 new feature “TPAC Discoverability Enhancements” to its own section in the docs |
14:19 |
yboston |
#info 6) remingtron will create the 2.9 new features needing docs wiki page |
14:19 |
yboston |
done |
14:19 |
remingtron |
yup |
14:19 |
yboston |
#link http://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:2.9_needs |
14:19 |
remingtron |
and it has the backlog from previous versions at the bottom |
14:19 |
remingtron |
so it's the master page |
14:19 |
yboston |
BTW, shoudl we pull the "backlog" stuff from the 2.8 page |
14:19 |
yboston |
so it only apperas on one page? |
14:20 |
yboston |
*appears |
14:20 |
remingtron |
great idea |
14:20 |
remingtron |
I'll do that right now... |
14:20 |
* kmlussier |
needs to update her assignment on that page. |
14:20 |
yboston |
#action should I bother with an actionitem? |
14:21 |
kmlussier |
Heh |
14:21 |
yboston |
oops |
14:21 |
yboston |
also, make sure that the two versions have not diverged |
14:21 |
yboston |
I wonder how I can erase an action item? |
14:22 |
remingtron |
#action yboston will erase the previous action item from the record |
14:22 |
remingtron |
:) |
14:22 |
yboston |
:) |
14:23 |
yboston |
#action remingtron will remove "backloged" features missing docs from 2.8 docs needs, so they only appear in the 2,9 doc needs |
14:23 |
yboston |
moving on |
14:23 |
yboston |
#info 7) jihpringle will create a doodle poll for scheduling a DIG hackfest for 2.9 features |
14:23 |
yboston |
this was done, thanks! |
14:24 |
yboston |
moving on |
14:24 |
remingtron |
jihpringle++ |
14:24 |
yboston |
jihpringle++ |
14:24 |
yboston |
#info 8) kmlussier will document the general wokflow for being DIG release coordinator |
14:24 |
yboston |
defar? |
14:24 |
kmlussier |
yes |
14:24 |
yboston |
defer? |
14:24 |
yboston |
#action kmlussier will document the general wokflow for being DIG release coordinator |
14:24 |
yboston |
moving on |
14:24 |
yboston |
#info 9) kmlussier will send email to list about stepping down as release coordinator; and will ask for volunteer replacement |
14:24 |
kmlussier |
One of the reasons I need to step down is because I don't have time, which means I apparently don't have time to find a need release coordinator or document processes. :( |
14:25 |
* kmlussier |
will really do it before the next meeting |
14:25 |
yboston |
we need to clone you |
14:25 |
yboston |
moving on |
14:25 |
Stompro |
Or digitize & copy. |
14:25 |
kmlussier |
No, really. My clone would just volunteer for more stuff. |
14:25 |
yboston |
so we are done with the previous meeting action items |
14:26 |
remingtron |
discuss 2.9 remaining items? |
14:26 |
yboston |
looks like the three major topics to cover overall are: 2.9 doc needs; web docs; docs re-org |
14:27 |
yboston |
remingtron: yes that is a good topic to address now |
14:27 |
yboston |
first off all thanks to every one that helped out for the hackfest |
14:28 |
yboston |
just looking over the 2.9 page to refresh my memory |
14:28 |
yboston |
#link http://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:2.9_needs |
14:29 |
yboston |
I see 9 completed items |
14:30 |
yboston |
I see two items labeled in progress |
14:30 |
yboston |
sorry 3 in progress |
14:31 |
yboston |
Also see that Lynn signed up for an item, but I don't see a progress report on that page at this point |
14:31 |
yboston |
at this point we should all volunteer for the pending 2.9 new features that need docs |
14:32 |
yboston |
woudl someone like to volunteer to alert the others on the list of the need for a new push for 2.9 new features? |
14:32 |
remingtron |
some of them may not need docs, or may be very small changes |
14:32 |
yboston |
good point |
14:33 |
Stompro |
I'll take the selfcheck inactivity warning since I've been trying to update the selfcheck docs. |
14:33 |
jihpringle |
I can send the email to the list (but probably won't have time to volunteer for any more 2.9 docs) |
14:33 |
yboston |
Stompro++ |
14:33 |
yboston |
jihpringle: works for me |
14:34 |
yboston |
#action jihpringle will send out an email to the list to ask DIG memebers to sign up for pending 2.9 new featutres |
14:34 |
* kmlussier |
should start documenting new features while she's testing them. |
14:35 |
yboston |
remingtron: about deciding if a new feature/release not entries needs docs. maybe we can team up to make that assesment together? |
14:35 |
yboston |
remingtron: so we can save volunteer time? |
14:35 |
remingtron |
yboston: yes, I can help with that |
14:36 |
yboston |
cool |
14:36 |
yboston |
#action yboston & remingtron will asses which 2.9 new features do not require new documentation |
14:37 |
yboston |
I'll send you an email |
14:37 |
Stompro |
If anyone wants to test out the adding adoc to the release notes commit, that would be appreciated. LP 1482336 |
14:37 |
pinesol_green |
Launchpad bug 1482336 in Evergreen "create_release_notes.sh include .adoc files" [Undecided,New] https://launchpad.net/bugs/1482336 |
14:38 |
yboston |
#action yboston will test and sign-off on Launchpad bug 1482336 - allowing release notes with ".adoc" suffix |
14:38 |
pinesol_green |
Launchpad bug 1482336 in Evergreen "create_release_notes.sh include .adoc files" [Undecided,New] https://launchpad.net/bugs/1482336 |
14:38 |
yboston |
anything else on 2.9 new features? |
14:39 |
remingtron |
regarding the .adoc conversion testing, I think we found a reason to halt |
14:39 |
yboston |
the git history concern? |
14:40 |
remingtron |
yes, git can track history across file name changes, but only if you use an additional command line parameter |
14:41 |
yboston |
remingtron: darn, I thought it would do it automatically |
14:41 |
Stompro |
How about a gradual approch, new docs and docs that get major changes should move to .adoc format. |
14:42 |
Stompro |
Err, extension, not format. |
14:42 |
yboston |
what is the parameter? |
14:42 |
remingtron |
Stompro: yes, I think we should encourage using .adoc for new files |
14:43 |
remingtron |
yboston: the parameter is --follow, like 'git log --follow' |
14:43 |
yboston |
have we tested that Robert's ascidoc parsing code can handle it? |
14:44 |
yboston |
remingtron: had no idea, but I am no git expert. all tutorial made it sound that renaming would "just work" if I used "git mv" |
14:44 |
remingtron |
yboston: I guess it works from some perspectives, but not the git log view |
14:44 |
Stompro |
yboston, when something gets included from the root.txt I don't think the parser knows what the file extension was, so it shouldn't matter. |
14:45 |
remingtron |
yboston: yes, the official docs already include an .adoc file |
14:45 |
yboston |
Stompro: I was just realizing that |
14:45 |
yboston |
thanks |
14:45 |
remingtron |
and it built fine via Robert's script |
14:46 |
yboston |
I guess in the future we may want to change root.txt suffix, but I don't know how pressing that is |
14:47 |
remingtron |
yboston: yeah, my conclusion so far is that it isn't pressing, so let's use the gradual approach (new files get .adoc extension) |
14:47 |
remingtron |
I'd rather focus on 2.9 features first |
14:48 |
yboston |
I agree |
14:48 |
yboston |
just thinking out loud |
14:48 |
yboston |
BTW, before I forget I had two things to bring up |
14:48 |
remingtron |
yboston: thanks for sharing your thoughts |
14:49 |
yboston |
#info DIG now has a EG community VM that in the future will be used for building docs |
14:50 |
yboston |
we still need to set it up. For now I am the only one with access, besides EG community sysadmins like gmcharlt |
14:50 |
yboston |
gmcharlt++ |
14:50 |
gmcharlt |
speaking of which... |
14:50 |
gmcharlt |
I've been poking around at recreating the docbook build steps |
14:50 |
remingtron |
gmcharlt++ |
14:51 |
gmcharlt |
and per yboston's request will be giving shell access to a couple others famiilar with the main docs server |
14:51 |
yboston |
gmcharlt++ |
14:51 |
yboston |
on a less positive note.... |
14:52 |
yboston |
#info the PDF docs for 2.9 and the master/dev version is not currently building |
14:52 |
yboston |
you get a 404 error if you visit the link |
14:52 |
yboston |
the good news/bad news of all the new content that we pushed probably broke something in the PDF build |
14:53 |
yboston |
I will set a generic action item to have folks look into it |
14:53 |
remingtron |
hm, guess we should email Robert to ask what errors he's seeing |
14:53 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade script and test file - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a9298b2> |
14:54 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 libdbi DATE types translated via gmtime - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2c42d4c> |
14:54 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 DoB as date PGTAP test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e174b43> |
14:54 |
pinesol_green |
[evergreen|Bill Erickson] LP#838525 Store date of birth as SQL DATE type - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7159229> |
14:54 |
yboston |
#action need volunteers to see why the 2.9 and the master/dev PDF is not being built |
14:54 |
yboston |
#action yboston will send Robert an email to check on problems with 2.9 and master PDF |
14:56 |
yboston |
I need to attend a meeting at 3 PM EST |
14:56 |
yboston |
final thoughts or questions? |
14:56 |
jihpringle |
is it just the MassLNC demo server running on 2.9? (I want to include a link in the email to where people can test features to document if they don't have their own 2.9 server) |
14:56 |
kmlussier |
Do we know when it stopped building? |
14:56 |
remingtron |
kmlussier: not sure we have that info besides Robert |
14:56 |
kmlussier |
Yes. The MassLNC demo server is running 2.9 and the ESI server is running 2.8. We coordinated this time around so that we would have the two stable releases on demo servers. |
14:57 |
remingtron |
jihpringle: could point people here: http://wiki.evergreen-ils.org/doku.php?id=community_servers |
14:57 |
yboston |
I use a free service that alerts me |
14:57 |
kmlussier |
Ugh. I had the last doc commit. |
14:57 |
jihpringle |
perfect, thanks |
14:57 |
yboston |
It might have been Sunday, which does nto make much sense. |
14:58 |
yboston |
I might have missed soem ealier alerts |
14:58 |
remingtron |
yboston: thanks for leading, you should get to your other mtg |
14:58 |
yboston |
OK |
14:58 |
yboston |
was just emailing Rovertt |
14:58 |
yboston |
thanks everybody |
14:58 |
yboston |
#endmeeting |
14:59 |
pinesol_green |
Meeting ended Thu Oct 1 14:58:59 2015 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
14:59 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-10-01-14.00.html |
14:59 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-10-01-14.00.txt |
14:59 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-10-01-14.00.log.html |
14:59 |
remingtron |
yboston++ |
14:59 |
kmlussier |
yboston++ |
14:59 |
kmlussier |
I'll update the MassLNC demo server today so that it's running 2.9.0 |
14:59 |
kmlussier |
Forgot I still had the RC on there. |
15:05 |
kbutler |
yboston++ |
15:08 |
Stompro |
yboston++ |
15:13 |
Stompro |
tsbere++, hbrennan++ I had no idea there was a %SORT macro, thanks for bringing that up on the listserve. |
15:20 |
tsbere |
Stompro: I generally know about it because I wrote it. <_< |
15:21 |
tsbere |
We had at least one library that didn't want to see javascript in the templates go away because they were ignoring the line item template entirely and writing out a sorted bit with javascript in the header |
15:26 |
Stompro |
It wasn't mentioned in the docs that I found, so I didn't know it existed. I added a note to the 2.9 documentation needs page to get everything listed on the mentioned MASSLNC page into the official docs. |
15:30 |
tsbere |
For fun, said MassLNC page is a copy of an internal MVLC page in the first place. >_> |
15:31 |
dbs |
yboston, remingtron: to figure out why the PDF build breaks, you can usually run "a2x --format=pdf root.txt" and find out what breaks |
15:31 |
* dbs |
runs that |
15:32 |
* dbs |
throws in "-vvv" for good verbose measure |
15:35 |
dbs |
guess I should do that against rel_2_9 instead of master, but master complains about IDREF attribute linkend references an unknown ID "_evergreen_2_8_release_notes" (and unknown ID library_settings_editor too) |
15:37 |
dbs |
maybe installation/server_upgrade.txt should reference _evergreen_2_9_release_notes instead? |
15:37 |
* dbs |
tries |
15:40 |
kmlussier |
Huh...I thought we moved that page to the official docs at one time. I must be thinking of something else that came from MVLC. |
15:45 |
tsbere |
kmlussier: The search/icon formats, I suspect |
15:49 |
kmlussier |
possibly |
15:56 |
dbs |
admin/sip_server.txt is breaking my docs builds for epub and pdf pretty badly, as it doesn't like the IDs that are generated for things like "[17-18_item_information]" in the XML |
15:57 |
dbs |
and when I comment it out, I run into things like missing docs/media/my_list_call_numbers.jpg |
15:57 |
dbs |
lots of fun! |
15:58 |
dbs |
(png vs. jpg there) |
16:02 |
dbs |
yay, finally got a working PDF build |
16:06 |
dbs |
Looks like the sip_server.txt errors are from ids starting with a number, which is not a valid NameStartChar: http://www.w3.org/TR/REC-xml/#NT-NameStartChar |
16:07 |
|
bmills joined #evergreen |
16:07 |
dbs |
One more rebuild and hopefully I'll have a bunch of fixes to check in. |
16:07 |
bshum |
dbs++ |
16:14 |
kmlussier |
dbs++ |
16:15 |
miker |
grabbing 0945 (he said well after doing so, having waited for the meeting to end) |
16:18 |
Bmagic |
anyone had trouble with a query like this: update asset.copy set location=2083 where location=1783; ? |
16:18 |
jeff |
Bmagic: define "trouble"? |
16:19 |
Bmagic |
I've done this hundreds of times, but for some reason, the location doesnt change! |
16:19 |
Bmagic |
Im just using one row for an example. update asset.copy set location=2083 where id=1623991; |
16:19 |
jeff |
Bmagic: does the UPDATE return 0, or a non-zero number of rows? |
16:19 |
Bmagic |
it says: UPDATE 1 and yet, I look at the database, and the location is still the old number! |
16:20 |
Bmagic |
WTF |
16:20 |
dbs |
Got any funky triggers on the table? :) |
16:20 |
Bmagic |
stock |
16:20 |
Dyrcona |
Got transaction? |
16:20 |
jeff |
Bmagic: are you performing a SELECT within the same psql shell/instance? If not, I'd double check that you're not within an uncommitted transaction, connected to different databases, etc. |
16:20 |
berick |
that's it, we're switching to sqlite |
16:21 |
jeff |
berick++ |
16:21 |
Bmagic |
yeah!, lol |
16:21 |
Dyrcona |
heh. |
16:21 |
Dyrcona |
Bmagic: It sounds like either someone added a funky trigger on the table, or you've got a transaction that you're not committing. |
16:22 |
Bmagic |
same shell, same session, my select query shows the old location |
16:22 |
Bmagic |
totally bizzare |
16:23 |
* jeff |
eyes asset.acp_location_fixer |
16:23 |
Bmagic |
maybe I need to run select asset.refresh_opac_visible_copies_mat_view(); ? some sort of row locking? |
16:23 |
tsbere |
Bmagic: I would pay attention to what jeff is paying attention to ;) |
16:24 |
* Bmagic |
grasps at straws |
16:24 |
Dyrcona |
Bmagic: If it were a row lock, your query would die with a deadlock. |
16:24 |
Bmagic |
ok, I see the trigger |
16:25 |
jeff |
Bmagic: are the new and old locations identally named? |
16:25 |
jeff |
(in terms of the value of asset.copy_location.name) |
16:25 |
Bmagic |
they are! |
16:25 |
Bmagic |
same exact name |
16:25 |
jeff |
there you go. |
16:25 |
jeff |
bug 778989 |
16:25 |
pinesol_green |
Launchpad bug 778989 in Evergreen "Owning lib of asset.copy_location not visible in Item Attributes Editor UI" [Medium,Fix released] https://launchpad.net/bugs/778989 |
16:25 |
jeff |
commit 6e6540a |
16:25 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#778989: Attempt to find "Correct" copy location - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6e6540a> |
16:26 |
jeff |
and followup commit d38d0e |
16:26 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#778989: Add circ lib to location fixer - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d38d0e7> |
16:26 |
jeff |
The trigger thinks that the change you are trying to make is illogical, and it is fixing it for you. |
16:26 |
Bmagic |
omg |
16:27 |
Bmagic |
let me show that trigger what I think of what it thinks |
16:28 |
jeff |
If there is an identically-named location "closer" to the copy's circ_lib, that trigger will use that location instead. |
16:28 |
Bmagic |
ok, so, updating the name to something different allowed the update to go through. Thanks you all. Crazy! |
16:29 |
|
jlitrell joined #evergreen |
16:30 |
jeff |
The check is skipped on update if the copy's location, call_number, and circ_lib are unchanged. Otherwise, it will come into play. This means that transferring a copy from one volume at BR1 to another volume at BR1 can cause the location to be changed. |
16:31 |
dbs |
okay, pushed a bunch of fixes in small, self-contained commits to master and rel_2_9 to fix up those builds |
16:31 |
jeff |
dbs++ |
16:31 |
dbs |
might be some stuff that can be cherry-picked back to rel_2_8, haven't had time to look there yet |
16:31 |
bshum |
jeff++ # good times :) |
16:31 |
* bshum |
runs away to get pizza! |
16:32 |
pinesol_green |
Showing latest 5 of 6 commits to Evergreen... |
16:32 |
pinesol_green |
[evergreen|Remington Steed] Docs: Update release notes reference to 2.9 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=213f811> |
16:32 |
pinesol_green |
[evergreen|Dan Scott] Doc build: use the implicit ID for lib settings editor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=60c29c9> |
16:32 |
pinesol_green |
[evergreen|Dan Scott] Doc build: link to the right media file - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9db9797> |
16:32 |
pinesol_green |
[evergreen|Dan Scott] Doc build: use XML-compliant IDs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=447e38d> |
16:32 |
pinesol_green |
[evergreen|Dan Scott] Avoid duplicate IDs in doc build - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=969dbbe> |
16:40 |
* miker |
reads up and prepares to dust of opensrf.persist for all backend data storage |
16:56 |
remingtron |
dbs++ #fixing docs build bugs |
16:56 |
yboston |
dbs++ |
16:58 |
|
mtj_ joined #evergreen |
16:59 |
Stompro |
dbs++ for fixing the SIP docs linking errors. That created so much noise when building the docs. |
17:00 |
|
mmorgan left #evergreen |
17:21 |
|
mrpeters left #evergreen |
17:32 |
|
Dyrcona joined #evergreen |
17:32 |
|
Dyrcona left #evergreen |
19:01 |
jwoodard |
sooo when are we going to have an Evergreen app? |
19:09 |
|
bmills joined #evergreen |
20:29 |
|
bmills joined #evergreen |
23:05 |
dbs |
http://docs.evergreen-ils.org/2.9/Evergreen_Documentation.pdf is alive. Yay! |
23:06 |
dbs |
(and epub too) |