| Time |
Nick |
Message |
| 04:21 |
|
dcook__ joined #evergreen |
| 04:58 |
|
gsams joined #evergreen |
| 05:16 |
|
gsams joined #evergreen |
| 08:13 |
|
pgardella joined #evergreen |
| 08:17 |
|
Newziky joined #evergreen |
| 08:30 |
|
collum joined #evergreen |
| 08:32 |
|
rjackson_isl joined #evergreen |
| 08:35 |
|
mrpeters joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:49 |
|
pmurray left #evergreen |
| 08:50 |
|
dcook__ joined #evergreen |
| 08:51 |
|
akilsdonk joined #evergreen |
| 08:53 |
|
Shae joined #evergreen |
| 08:54 |
|
book` joined #evergreen |
| 09:08 |
|
maryj joined #evergreen |
| 09:20 |
|
yboston joined #evergreen |
| 09:31 |
csharp |
for those awake enough to care, I'm taking down the fedora and Ubuntu buildslaves to upgrade the VM host |
| 09:35 |
csharp |
@karma |
| 09:35 |
pinesol_green |
csharp: Highest karma: "dbs" (994), "bshum" (972), and "Dyrcona" (667). Lowest karma: "ie" (-62), "^" (-30), and "marc" (-28). You (csharp) are ranked 9 out of 2479. |
| 09:39 |
|
Newziky left #evergreen |
| 09:53 |
|
dkyle1 joined #evergreen |
| 10:01 |
bshum |
csharp: Thanks for the heads-up :) |
| 10:07 |
kmlussier |
Good morning #evergreen. I hope everyone is more awake than I am! :) |
| 10:07 |
gmcharlt |
@coffee kmlussier |
| 10:07 |
* pinesol_green |
brews and pours a cup of Kenya AA Top, and sends it sliding down the bar to kmlussier |
| 10:10 |
* bshum |
is getting there slowly. |
| 10:10 |
bshum |
But I did sleep more last night than probably all of last week :) |
| 10:11 |
berick |
@coffee everyone |
| 10:11 |
* pinesol_green |
brews and pours a cup of El Salvador Los Planes Pacamara, and sends it sliding down the bar to everyone |
| 10:12 |
mnsri |
berick: bshum : kmlussier : +1 for coffee all day :) |
| 10:13 |
mnsri |
hope you had safe travels back to your homes.. |
| 10:13 |
berick |
you know you're back in the south when the plane windows all fog over from the humidity. |
| 10:14 |
berick |
i've returned to full blown summer |
| 10:14 |
kmlussier |
It was safe travels for me and for all of the beer/wine bottles packed in my luggage. |
| 10:15 |
mnsri |
kmlussier: Great to hear that bottles alos reached safely :) |
| 10:15 |
mnsri |
*also |
| 10:16 |
mnsri |
berick: Its summer in seattle too, gorgeous , but only 75 :) |
| 10:18 |
berick |
mnsri: :) |
| 10:21 |
* bshum |
misses the cooler breeze already |
| 10:21 |
bshum |
Damn heat. |
| 10:25 |
kmlussier |
The cooler breeze caught up with us today. Yesterday was definitely summer-like. |
| 10:25 |
kmlussier |
phasefx++ #Recognizing folks beyond IRC |
| 10:27 |
mnsri |
bshum: 35 years ago today , was not that cold in this area :) , http://www.history.com/topics/us-states/washington/videos/mount-st-helens-erupts |
| 10:28 |
berick |
another hackfest target.. teach supybot to keep yearly karma stats |
| 10:28 |
berick |
@karma most |
| 10:28 |
pinesol_green |
berick: (karma most [<channel>] {increased,decreased,active}) -- Returns the most increased, the most decreased, or the most active (the sum of increased and decreased) karma things. <channel> is only necessary if the message isn't sent in the channel itself. |
| 10:29 |
berick |
@karma most #evergreen |
| 10:29 |
pinesol_green |
berick: (karma most [<channel>] {increased,decreased,active}) -- Returns the most increased, the most decreased, or the most active (the sum of increased and decreased) karma things. <channel> is only necessary if the message isn't sent in the channel itself. |
| 10:29 |
berick |
bah |
| 10:29 |
bshum |
@karma most increased |
| 10:29 |
pinesol_green |
bshum: "dbs": 1055, "bshum": 976, "Dyrcona": 671, "tsbere": 666, "berick": 632, "kmlussier": 632, "jeff": 609, "gmcharlt": 570, "csharp": 486, "dbwells": 473, "eeevil": 422, "denials": 329, "yboston": 295, "phasefx": 278, "senator": 278, "miker_": 147, "paxed": 123, "RoganH": 120, "rfrasur": 118, "mrpeters-isl": 114, "jboyer-isl": 106, "jcamins": 101, "mmorgan": 85, "moodaepo": 82, and "remingtron": (1 more message) |
| 10:29 |
bshum |
:) |
| 10:30 |
kmlussier |
What is most increased? |
| 10:30 |
bshum |
That's just raw ++ |
| 10:30 |
berick |
bshum: oh, you *read* how it worked. so industrious |
| 10:30 |
bshum |
Without - - |
| 10:30 |
kmlussier |
@more |
| 10:30 |
pinesol_green |
kmlussier: Error: You haven't asked me a command; perhaps you want to see someone else's more. To do so, call this command with that person's nick. |
| 10:31 |
mrpeters |
tsbere++ (i didnt want you stuck at that number) |
| 10:31 |
kmlussier |
mrpeters: Ha ha. I was just thinking of doing the same thing. |
| 10:31 |
mrpeters |
:) |
| 10:31 |
kmlussier |
I gave karma to Dyrcona Saturday for the same reason. :) |
| 10:31 |
mrpeters |
@karma mpeters |
| 10:31 |
pinesol_green |
mrpeters: mpeters has neutral karma. |
| 10:32 |
mrpeters |
oops |
| 10:32 |
mrpeters |
@karma mrpeters |
| 10:32 |
gmcharlt |
:) |
| 10:32 |
pinesol_green |
mrpeters: Karma for "mrpeters" has been increased 47 times and decreased 0 times for a total karma of 47. |
| 10:32 |
collum |
@more bshum |
| 10:32 |
pinesol_green |
collum: 69 |
| 10:32 |
bshum |
@karma mrpeters-isl |
| 10:32 |
pinesol_green |
bshum: Karma for "mrpeters-isl" has been increased 114 times and decreased 0 times for a total karma of 114. |
| 10:32 |
jcamins |
Huh. I wouldn't have thought I'd be among the most-increased on this channel. |
| 10:33 |
mrpeters |
i think you top guys deserve to have that record stay around |
| 10:33 |
bshum |
Meh |
| 10:33 |
mrpeters |
thats why i brought up the quesiton |
| 10:33 |
bshum |
I'll tweet my position for posterity. :D |
| 10:33 |
bshum |
But I look forward to the challenge. |
| 10:34 |
mrpeters |
phasefx has a good idea though |
| 10:34 |
mrpeters |
preserve it year to year on the evergreen site or something |
| 10:34 |
mrpeters |
you guys up over 500 deserve to keep your recognition for that, in my opinion |
| 10:36 |
bshum |
I had this funny Game of Thrones geek moment when I said in my head, "the Community remembers" |
| 10:36 |
kmlussier |
mrpeters: I see what you're saying, but, if I start slacking off, and new people like Stomporo or Bmagic keep up their level of contribution, they shouldn't have to work for years to overtake me. |
| 10:37 |
berick |
bshum: no spoilers, i was on a plane last night :) but, yes, the north remembers :) |
| 10:37 |
mrpeters |
fair point, but you put in years to earn it :) |
| 10:39 |
gmcharlt |
FWIW, I'm a member of the 500+ club who not only doesn't mind, but is actively in favor of the clearing |
| 10:39 |
gmcharlt |
although I'll note that as operator of #koha's bot, when I've done a karma result, I've kept the old karma DB around |
| 10:40 |
gmcharlt |
but not to publish so much as to have it in case somebody comes around wanting to do analysis of it |
| 10:40 |
bshum |
It's the archivist in you, eh, gmcharlt? |
| 10:41 |
* bshum |
would have kept the old karma DB too |
| 10:41 |
gmcharlt |
KEEP ALL THE (NON-PERSONALLY-IDENTIFIABLE) DATA!!!!!! |
| 10:41 |
berick |
i also assumed we would dump the db, cuz why not |
| 10:41 |
gmcharlt |
not sure that makes me an archivist though, just a packrat ;) |
| 10:46 |
Bmagic |
csharp: berick: http://pastebin.com/ErnhkZZw here is the latest template applied |
| 10:49 |
berick |
Bmagic++ |
| 10:49 |
berick |
thanks |
| 10:49 |
berick |
a nice big one |
| 10:51 |
Bmagic |
berick: the "before" is the old ruby output |
| 10:51 |
|
mllewellyn joined #evergreen |
| 10:52 |
* berick |
cuts out the GIR segments to compar |
| 10:52 |
berick |
uh, compare |
| 10:54 |
kmlussier |
@karma most increased |
| 10:54 |
pinesol_green |
kmlussier: "dbs": 1055, "bshum": 976, "Dyrcona": 671, "tsbere": 667, "berick": 632, "kmlussier": 632, "jeff": 609, "gmcharlt": 570, "csharp": 486, "dbwells": 473, "eeevil": 422, "denials": 329, "yboston": 295, "phasefx": 278, "senator": 278, "miker_": 147, "paxed": 123, "RoganH": 120, "rfrasur": 118, "mrpeters-isl": 114, "jboyer-isl": 106, "jcamins": 101, "mmorgan": 85, "moodaepo": 82, and (1 more message) |
| 10:54 |
kmlussier |
@more |
| 10:54 |
pinesol_green |
kmlussier: "remingtron": 69 |
| 10:55 |
bshum |
@karma most decreased |
| 10:55 |
pinesol_green |
bshum: "ie": 62, "dbs": 61, "parts": 32, "^": 30, "marc": 28, "----------------------------------": 20, "my_laptop": 15, "berick": 14, "microsoft": 11, "reports": 11, "launchpad": 10, "dojo": 8, "typos": 8, "miker_": 7, "miker": 7, "csharp": 7, "mac": 6, "SIP2": 6, "pinesol_green": 6, "<-": 6, "xulrunner": 6, "failed": 6, "apple": 6, "b&t": 6, and "launchpad_search": 6 |
| 10:55 |
kmlussier |
That's it? I thought we would go a bit further if I did the @more |
| 10:55 |
bshum |
Looks like top 25 |
| 10:56 |
kmlussier |
So sad that parts makes the top 25 for decreased but not for increased |
| 10:56 |
bshum |
kmlussier: Admit it! You want a karma reset to give parts a leg up! |
| 10:56 |
* bshum |
shines the light at kmlussier |
| 10:56 |
kmlussier |
bshum: Yup, you found me out! |
| 10:57 |
kmlussier |
I'm sure the parts haters will be just as likely to give negative karma to parts all over again if they have to. |
| 10:58 |
* mmorgan |
was surprised to see bshum increment parts :) |
| 10:58 |
mrpeters |
what is the easiest way to convert some documentation from DOCX to something appropriate for git? |
| 10:58 |
* jcamins |
doesn't understand karma resets. They just reify the perceived conflict. |
| 10:58 |
mrpeters |
for a readme file |
| 10:58 |
kmlussier |
mmorgan: There was a bit of negotatiation to that. |
| 10:58 |
bshum |
Screenshot or it didn't happen... oh wait.... right. |
| 10:58 |
kmlussier |
logs++ |
| 10:58 |
mmorgan |
negotiation++ |
| 10:59 |
yboston |
mrpeters: what is your definition of more appropirate for git? |
| 10:59 |
kmlussier |
Heh...negotatiation. I sure can spell |
| 10:59 |
mrpeters |
yboston: not sure -- pushing the reports-creator code to git.evergreen-ils.org and i didn't want to be tacky and upload a docx as the documentation |
| 11:00 |
mrpeters |
problem is, it has some tables with permissions info that needs to stay formatted |
| 11:00 |
yboston |
mrpeters: for the EG docs we use asciidoc |
| 11:00 |
mrpeters |
yeah, i was trying to use pandoc to go from html to asc but results were not pretty |
| 11:00 |
yboston |
mrpeters: asciidoc has support for tables, similar to the Dokuwiki syntax |
| 11:00 |
remingtron |
mrpeters: there's usually a lot of excited docs people after the conference. It's possible one of them would be willing to convert it to AsciiDoc for you. |
| 11:01 |
mrpeters |
i should probably learn mysefl |
| 11:02 |
remingtron |
mrpeters: yboston has some great training tools (videos, exercises, etc.) |
| 11:02 |
yboston |
mrpeters: I created a ASCIIDOC tutorial presentation https://docs.google.com/presentation/pub?id=1o8HruJayUSEvXQlU_IjU6xN3cJbuw3yagENlcUM7sUU&start=false&loop=false&delayms=3000 |
| 11:02 |
mrpeters |
thanks checking it out |
| 11:03 |
yboston |
mrpeters: here are some other links from the main DIG page http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig#evergreen_documentation_guidelines |
| 11:03 |
remingtron |
yboston++ |
| 11:03 |
yboston |
remingtron: forgot to tell you that kmlussier rightfully sang your praises on the first day of the conference in front of everybody |
| 11:04 |
yboston |
remingtron: she was talking about your DIG work and your push to document new features |
| 11:04 |
kmlussier |
remingtron: Yes, for forcing us to shoot for new documentation at release time. :) |
| 11:04 |
kmlussier |
remingtron++ |
| 11:04 |
yboston |
remingtron++ |
| 11:04 |
remingtron |
kmlussier: wow, thanks, that's very kind |
| 11:05 |
bshum |
remingtron: Make sure dbwells gives you the pin I sent along with him back for you :) |
| 11:06 |
remingtron |
bshum: pin?! awesome! |
| 11:06 |
remingtron |
bshum++ #making me feel part of the conference |
| 11:14 |
Bmagic |
Does anyone out there have a multi branch system that uses shelving locations at the system level? |
| 11:16 |
tsbere |
Bmagic: We define all of our locations at the consortia or system level right now. |
| 11:16 |
Bmagic |
tsbere: good to know, so there isn't a problem doing so? |
| 11:17 |
tsbere |
Depends on your definition of "problem". The system doesn't care. ;) |
| 11:17 |
Bmagic |
tsbere: permissions? |
| 11:17 |
Bmagic |
when cataloging new copies, does the user need system wide permissions to anything? |
| 11:17 |
bshum |
Bmagic: Presently all copy locations tend towards being held at the library level in our setup. And we control addition/removal of copy locations at HQ. |
| 11:18 |
bshum |
Bmagic: Things can be interesting for copy locations when it comes to acquisitions assignment I think though. |
| 11:18 |
tsbere |
We don't let libraries make their own locations, in part so that a more uniform naming of things is maintained. Beyond that, no special permissions are needed to *use* a location, beyond being able to edit copies. |
| 11:18 |
Bmagic |
gotcha! |
| 11:18 |
Bmagic |
thanks |
| 11:18 |
bshum |
Right, when cataloging, they'll see any copy locations at their location and higher up the tree. |
| 11:18 |
bshum |
That's like how "Stacks" by default is owned at consortium level, but usable at every location under that. |
| 11:19 |
tsbere |
Well, at the circ and owning lib location and higher on the tree ;) |
| 11:19 |
bshum |
Uh, right. |
| 11:19 |
bshum |
:) |
| 11:19 |
bshum |
tsbere++ |
| 11:21 |
Bmagic |
tsbere: do you use AQC? |
| 11:21 |
Bmagic |
/AQC/ACQ/ |
| 11:21 |
tsbere |
We do. No clue what, if any, effects come from copy locations elsewhere on the tree there is. |
| 11:22 |
tsbere |
Because I don't personally know how to use that part of the system. |
| 11:22 |
tsbere |
No complaints about locations, though. |
| 11:22 |
Bmagic |
well, I do know that the module matches names against the specified branch in the copy order |
| 11:23 |
Bmagic |
I wonder if the order needs to specify the system in order for the query to identify the shelving ID |
| 11:24 |
tsbere |
Dunno. |
| 11:24 |
tsbere |
Can't even speculate at this point. ;) |
| 11:58 |
berick |
Bmagic: csharp: fyi, pushed more fixes to bug 1373690 (edi template). thanks again for all the testing |
| 11:58 |
pinesol_green |
Launchpad bug 1373690 in Evergreen "Direct EDI generation for ACQ orders -- AKA kill ruby webrick" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1373690 - Assigned to Bill Erickson (berick) |
| 12:01 |
kmlussier |
Webby is very slow this morning. Is work being done on it? |
| 12:02 |
phasefx |
kmlussier: don't think so |
| 12:02 |
kmlussier |
Time for another kick? |
| 12:03 |
kmlussier |
The poky little duck. |
| 12:03 |
|
RoganH joined #evergreen |
| 12:04 |
csharp |
the poor little thing's disk is nearly full |
| 12:05 |
csharp |
awwww |
| 12:06 |
phasefx |
yeah, disk space is the issue there |
| 12:11 |
phasefx |
kmlussier: behaving okay now? |
| 12:11 |
csharp |
Bmagic: we have some libraries who use system-level copy locations and some that use branch-level. Pros of system level: only need to create one rather than one per branch, Cons: you can't leverage copy location features like circulate yes/no, holdable yes/no, opac visible yes/no |
| 12:12 |
csharp |
like when a library does a partial renovation or something, it's handy to just hide a swath of collections from the OPAC and hold targeter, for instance |
| 12:12 |
RoganH |
chsarp: making sure I understand, you can't use those boolean settings or just can't if they vary branch to branch? |
| 12:12 |
csharp |
RoganH: the latter |
| 12:13 |
RoganH |
csharp: gotcha. that's what I thought. We're actually moving from per branch to system and you scared me that there was a bug I didn't know about. |
| 12:13 |
kmlussier |
phasefx: Faster loading staff client login screen, but my login fails. |
| 12:13 |
kmlussier |
phasefx: Also, there seems to be an internal server error if you go to the opac |
| 12:13 |
phasefx |
kmlussier: k, thanks |
| 12:15 |
phasefx |
kmlussier: how about now? |
| 12:16 |
phasefx |
seems to be okay to me; running to lunch :) |
| 12:18 |
csharp |
well, the biggest problem with branch level copy locations I've seen is that, when combined with system-level cataloging, the copies can end up belonging to another branch's location (when locations are named the same across branches) - but that's fixed in bug 778989 |
| 12:18 |
pinesol_green |
Launchpad bug 778989 in Evergreen "Owning lib of asset.copy_location not visible in Item Attributes Editor UI" (affected: 3, heat: 16) [Medium,Fix released] https://launchpad.net/bugs/778989 |
| 12:27 |
csharp |
berick: I'm afraid I'm going to have to wait for Leslie to get back to test correctly - I don't want to risk placing actual orders and confusing people because I don't know what I'm doing :-/ |
| 12:27 |
csharp |
but that said, |
| 12:27 |
csharp |
berick++ |
| 12:28 |
|
sandbergja joined #evergreen |
| 12:31 |
kmlussier |
phasefx: Works now. Thanks! |
| 12:31 |
kmlussier |
phasefx++ |
| 12:33 |
berick |
csharp: totally understand, thanks |
| 12:52 |
Bmagic |
berick: http://pastebin.com/Zb5fuyXY Your last 2 commits ba64aba3c547 up from d52264a5f59 |
| 12:53 |
Bmagic |
same order as before |
| 13:24 |
berick |
Bmagic++ thanks |
| 13:53 |
|
collum_ joined #evergreen |
| 14:10 |
|
ldwhalen joined #evergreen |
| 14:10 |
|
kmlussier joined #evergreen |
| 14:10 |
|
mceraso joined #evergreen |
| 14:10 |
|
bshum joined #evergreen |
| 14:19 |
Bmagic |
From the code, I can't tell if ITEM_DEPOSIT_REQUIRED can be overridden by the staff user. We have a circ user that is being prompted for credentials. There is nothing in permission.perm_list |
| 14:22 |
tsbere |
Looks like we created "ITEM_DEPOSIT_REQUIRED.override" and "ITEM_RENTAL_FEE_REQUIRED.override" |
| 14:22 |
tsbere |
Or an upgrade script did at some point, I suppose. Haven't checked the code. |
| 14:22 |
jeff |
Those two permissions work, and are designed as a means to "confirm" before billing the patron for the rental/deposit fee. If they're not being created in a stock set of perms, I'd call that a bug. |
| 14:23 |
jeff |
And I'd be happy to submit/fix/signoff, whichever someone else doesn't get to first. |
| 14:24 |
tsbere |
I don't see them in the Pg folder with a quick grep, so I assume they aren't being created by default. |
| 14:24 |
* tsbere |
doesn't have tuits to add them for default creation right now, though |
| 14:24 |
tsbere |
My tuits are being used up elsewhere >_> |
| 14:25 |
Bmagic |
I ran into this for "MAX_HOLDS.override" - I had to create it |
| 14:26 |
Bmagic |
It's implied if you have the "everything" permission |
| 14:26 |
jeff |
amusingly, there are some things (at least one) where EVERYTHING isn't enough. |
| 14:26 |
Bmagic |
ha! |
| 14:27 |
Bmagic |
INYOURFACEADMIN |
| 14:27 |
tsbere |
I believe the superuser flag works where everything doesn't, though. |
| 14:28 |
Bmagic |
https://bugs.launchpad.net/evergreen/+bug/1320301 |
| 14:28 |
pinesol_green |
Launchpad bug 1320301 in Evergreen "No permission in permission.perm_list that give permission to override MAX_HOLDS" (affected: 1, heat: 6) [Undecided,New] |
| 14:30 |
Bmagic |
And now the big one https://bugs.launchpad.net/evergreen/+bug/1456301 |
| 14:30 |
pinesol_green |
Launchpad bug 1456301 in Evergreen "No permission in permission.perm_list that give permission to override ITEM_DEPOSIT_REQUIRED" (affected: 1, heat: 6) [Undecided,New] |
| 14:31 |
jeff |
Bmagic++ |
| 14:31 |
Bmagic |
Do we have a policy to keep these in a certain ID range in the table? |
| 14:32 |
Bmagic |
The last ID I have in sequence is 554 before it jumps to 1000+ |
| 14:35 |
berick |
Bmagic: stock values have id <= 1000. local values get > 1000 |
| 14:35 |
tsbere |
If we ever break 1000 permissions we might need to rethink that one, though. ;) |
| 14:35 |
jeff |
to avoid id conflicts, several tables reserve the first 1000 or so. |
| 14:36 |
Bmagic |
so just pick the next one in sequence? |
| 14:36 |
jeff |
in practice, some of those same tables have other conflicting unique indexes/constraints (such as config.copy_status) |
| 14:36 |
tsbere |
For upgrade scripts I would skip the id. For the seed values I would grab the next one. |
| 14:36 |
berick |
tsbere: maybe that will be the catalyst for killing perm_list.id column for good |
| 14:37 |
berick |
tsbere: why would you skip the ID in the upgrade script? |
| 14:37 |
jeff |
and existing installations that have defined the permissions locally will likely not have the same ID as each other -- let alone the one you choose. |
| 14:37 |
berick |
tsbere: just for ease of writing/managing the upgrade script? |
| 14:37 |
* berick |
always makes the match in both seed data and upgrade script |
| 14:38 |
berick |
s/the/them/ |
| 14:38 |
berick |
Bmagic: pushed another pile of EDI fixes. getting so close |
| 14:38 |
tsbere |
I figure it is less likely to fail due to id conflict if you don't include the id in the upgrade script |
| 14:39 |
tsbere |
Of course, you want to ensure the code isn't there already in the upgrade script as well... |
| 14:40 |
Bmagic |
berick: did our data do anything for you? |
| 14:40 |
Bmagic |
berick: I noticed that with every commit, my EDI message is getting longer |
| 14:41 |
berick |
Bmagic: heh |
| 14:41 |
berick |
yes, your data is what's driving all the changes |
| 14:41 |
berick |
the stock template will always be longer, since it includes copies by default, whereas you are not using them |
| 14:41 |
* csharp |
wishes the PK for permission.perm_list was just the code |
| 14:42 |
Bmagic |
The ruby output was shorter, is what I mean |
| 14:42 |
berick |
when comparing your data, i just ignore the GIR stuff |
| 14:42 |
berick |
Bmagic: right, try setting INC_COPIES=0 before installing the new template |
| 14:42 |
berick |
it's a variable near the top of the template |
| 14:42 |
berick |
they should be closer in size that way |
| 14:42 |
Bmagic |
I see |
| 14:43 |
berick |
csharp: that's the plan, re: perm_list, pending tuits |
| 14:43 |
csharp |
@praise THE PLAN |
| 14:43 |
* pinesol_green |
THE PLAN is the hardest working person in #evergreen. |
| 14:43 |
berick |
@insult negative tuits |
| 14:43 |
pinesol_green |
negative tuits: You are nothing but a headless mass of tasteless rat-farts. |
| 14:44 |
berick |
haha |
| 14:44 |
csharp |
lol |
| 14:44 |
* berick |
feels bad pinesol_green had to taste them |
| 14:44 |
RoganH |
I feel like the bot deserves good karma for that one. |
| 14:44 |
csharp |
@praise pinesol_green |
| 14:44 |
* pinesol_green |
itself is kind and patient to newbies |
| 14:45 |
* csharp |
thinks we should change the bot's nick to opensrf |
| 14:49 |
Bmagic |
berick: http://pastebin.com/Ym6CSznr from 2 more commits e876a4add49109 <- 646b5797d88d448d |
| 14:51 |
berick |
Bmagic: sweet, thanks |
| 14:52 |
csharp |
Bmagic++ |
| 14:54 |
Bmagic |
gotta stop giving me karma, it's gonna get destroyed, lol |
| 14:54 |
berick |
hah |
| 14:54 |
Bmagic |
let's do all this EDI testing after the karmapocolypse |
| 14:58 |
* berick |
promises to manually carry over Bmagic's EDI karma |
| 14:58 |
Bmagic |
haha, I'm just kidding, I dont care |
| 14:58 |
berick |
ok, down to the last (obvious) problem. fixing.. |
| 15:00 |
|
ldwhalen joined #evergreen |
| 15:00 |
Bmagic |
WB Liam |
| 15:01 |
Bmagic |
I guess your presence means you made it home ok! |
| 15:03 |
ldwhalen |
Bmagic: yes. It was a successful train ride. I am at the OpenStack conference currently, so I will be radio silent for the most part. |
| 15:03 |
Bmagic |
ldwhalen: right on! Have a good one! It was fun hanging out! |
| 15:07 |
berick |
Bmagic: in your current EDI setup, it's generating both 13 and 10 digit ISBN identifiers. in the stock template, it only generates one identifier, using 13's when available. |
| 15:08 |
berick |
unless generating both is something we really should be doing, that's the last big difference that I can see |
| 15:08 |
* berick |
confirms his production edi only generates 13's |
| 15:09 |
berick |
Bmagic: do you know why your local template generates both? |
| 15:09 |
* berick |
wonders if that's true for anyone else |
| 15:11 |
jeff |
"13's when available" -- you mean when there's an isbn at all (since you can always calculate the isbn-13 given an isbn-10)? |
| 15:11 |
Bmagic |
I have no idea |
| 15:11 |
* jeff |
doesn't use EDI, so should probably keep silent |
| 15:11 |
Bmagic |
The bib could have more than one 020 |
| 15:12 |
Bmagic |
do you have a bib ID? |
| 15:12 |
mrpeters |
before i go and reinvent the wheel -- did anyone do any work on their database to "break" cloned patron addreses up into unique rows in actor.usr_address to avoid issues when trying to delete a patron with a cloned address. I'm told a recent version stopped using the same address ID value for cloned patrons. |
| 15:12 |
berick |
jeff: edi is pretty dumb about it. it just checks the lineiatem attributes for what's been extracted from the record |
| 15:13 |
jeff |
mrpeters: there is a recent config option to not share addresses between patrons when cloning. |
| 15:14 |
jeff |
mrpeters: but it is just that, an option. |
| 15:14 |
mrpeters |
jeff: cool, i wanted to get clarification on that anyways. appreciate the info. |
| 15:14 |
jeff |
mrpeters: there may also have been a bug/fix to "do the right thing" when deleting a patron with a shared address (or who is owner of a shared address) |
| 15:14 |
mrpeters |
yeah, i think there may have been too |
| 15:15 |
mrpeters |
however, want to make unique address rows for the patrons (with the same information, just new ID's) to break up the shared address ids |
| 15:15 |
mrpeters |
i started, and was like wait....i better make sure someone hasn't already done this |
| 15:15 |
berick |
Bmagic: right, i'm guessing it does have more than one 020. stock templates only display one, though, even if multiple are present. grabbing example.. |
| 15:15 |
jeff |
mrpeters: if and when you do yourself, please share! |
| 15:15 |
mrpeters |
thats the plan! |
| 15:16 |
jeff |
mrpeters: also, you might want to ask on-list. Might get more/better results. |
| 15:16 |
mrpeters |
yeah, also a good point |
| 15:16 |
berick |
Bmagic: for example, isbn 9786313779857 / li # 6413 |
| 15:18 |
mrpeters |
biggest thing im tossing around is the most efficient way to create the new rows from the original data -- i've got all of the "shared" users identified, and how many times they are duped but want to be as tidy as possible and try to do this all in sql -- i could dump to CSV and write a script to iterate over the csv and create "x" number of new rows for a \copy command to create them, but that feels sloppy |
| 15:19 |
jeff |
yeah, don't do that. |
| 15:20 |
mrpeters |
http://pastie.org/10195346 is where i currently sit |
| 15:22 |
mrpeters |
i guess it would be worth noting in the evergreen.actor_usr_address_new_billing/mailing tables how many times the original is shared |
| 15:23 |
mrpeters |
then maybe a function to create that number of new rows with the original data, but a new id value in the newidval column |
| 15:24 |
mrpeters |
looks like jboyer-isl already did this in the bug about deleting shared addresses |
| 15:24 |
mrpeters |
https://bugs.launchpad.net/evergreen/+bug/885270 |
| 15:24 |
pinesol_green |
Launchpad bug 885270 in Evergreen "Delete User Aborts on Shared Address" (affected: 4, heat: 22) [Medium,Confirmed] |
| 15:26 |
mrpeters |
jboyer-isl++ |
| 15:26 |
Bmagic |
berick: we haven't edited the stock template 23 |
| 15:29 |
|
geoffsams joined #evergreen |
| 15:30 |
|
Librator joined #evergreen |
| 15:31 |
Bmagic |
berick: a quick compare to 0733.data.jedi_with_copies.sql, we are missing a clause "copies" : |
| 15:32 |
Bmagic |
berick: I have no idea why we would be missing that clause from the JEDI template ID 23, but we are |
| 15:35 |
csharp |
Bmagic: maybe this is relevant? (it's what I was thinking of when we were waiting in line at PDX): https://bugs.launchpad.net/evergreen/+bug/1297967 |
| 15:35 |
pinesol_green |
Launchpad bug 1297967 in Evergreen "document openils-mapper code for enriched EDI" (affected: 1, heat: 6) [Undecided,New] |
| 15:35 |
csharp |
but it sounds like you have GIR segments, so maybe not |
| 15:37 |
Bmagic |
interesting |
| 15:37 |
berick |
Bmagic: interesting... OK. maybe i'm mistaken. will dig further on that. the "copies" clause was added for "enriched" edi (sending copy data) |
| 15:37 |
berick |
if you're not using it, you don't technically need it |
| 15:38 |
Bmagic |
beats me honestly |
| 15:38 |
csharp |
several vendors expect it (from what I know about it) |
| 15:38 |
Bmagic |
it's working as far as I know the way it is |
| 15:38 |
Bmagic |
the majority of our stuff is created from the acq import proceedure |
| 15:39 |
berick |
csharp: GIR segments came along well after EDI was in wide use. I'd be surprised if any vendors required it globally |
| 15:39 |
berick |
maybe for certain accounts |
| 15:45 |
berick |
Bmagic: what EG version are you on? |
| 15:47 |
bshum |
Hmm |
| 15:47 |
berick |
still only seeing one ISBN even for records w/ multiples using existing edi on master |
| 15:48 |
bshum |
https://bugs.launchpad.net/bugs/1456289 - if memory serves, Bmagic and I saw this on 2.7 too, and it's cause autogen.sh wasn't run on the system with apache restarted |
| 15:48 |
pinesol_green |
Launchpad bug 1456289 in Evergreen "Tpac "edit" link on record screen does not save changes" (affected: 1, heat: 6) [Undecided,New] |
| 15:49 |
kmlussier |
Ah! I recall that one. |
| 15:50 |
bshum |
I'll put a note on the bug to that effect I guess |
| 15:50 |
bshum |
And we can probably close it with invalid. |
| 16:01 |
bshum |
gmcharlt: eeevil: mllewynn tells me that the vandelay loader for web client works fine (we tested it on our test server). |
| 16:01 |
bshum |
She also says that the flat text editor doesn't stay as the default option when opening additional records (aka, remain checked) |
| 16:01 |
bshum |
But otherwise, the sprint2 stuff so far, so good |
| 16:06 |
Bmagic |
berick: 2.7.0 |
| 16:07 |
|
mrpeters left #evergreen |
| 16:08 |
berick |
Bmagic: thanks |
| 16:11 |
tsbere |
So....I have an evergreen install that, for some reason, isn't getting pcrud transaction.begin calls from the staff client. I can't find any error logs, other pcrud calls from the client seem to work fine. Anyone have a thought as to what broke? |
| 16:14 |
berick |
tsbere: multiple apache servers? |
| 16:14 |
jeff |
I think that I have seen that possibly multiple times before on a scratch install and I do not recall if/how I fixed it. |
| 16:14 |
tsbere |
Basically a single-machine brick |
| 16:14 |
tsbere |
I can't even see an *attempt* at making the call in the server logs. |
| 16:16 |
berick |
seems like the CONNECT is failing / not returning, so the .begin is never attempted |
| 16:17 |
jeff |
tsbere: what specific pcrud-based interface(s) are you testing with? |
| 16:18 |
tsbere |
Parts creation. Apparently from any interface you can create parts. |
| 16:22 |
bshum |
Parts... sigh. |
| 16:33 |
* tsbere |
glares at the javascript console of the staff client and the lineless "Transaction begin error" that tells him nothing about which of the four possible points that is generated did so |
| 16:44 |
* tsbere |
glares even more as now everything is working |
| 16:44 |
tsbere |
and nobody changed anything. I have just been trying to find logs. |
| 17:07 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:10 |
|
ldwhalen joined #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 17:26 |
|
ldwhalen joined #evergreen |
| 23:06 |
|
dcook joined #evergreen |
