Evergreen ILS Website

IRC log for #evergreen, 2015-05-18

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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=1o​8HruJayUSEvXQlU_IjU6xN3cJbuw3yagENlcUM7sUU&amp​;start=false&amp;loop=false&amp;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=ever​green-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

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat