Evergreen ILS Website

IRC log for #evergreen, 2015-02-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
05:14 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
07:31 graced joined #evergreen
07:39 rjackson_isl joined #evergreen
07:55 graced joined #evergreen
07:55 collum joined #evergreen
07:59 csharp hmm - okay - I'm seeing a need for a link in the reporter between money.materialized_billable_xact_summary (Billable Transaction Summary) and action.circulation (Circulation) so that I can use things like last_billing_type and balance_owed when doing item list reports
07:59 csharp the use case is a "lost and paid" report
08:00 csharp anyhoo, just wondering if it makes more sense for the link to be on the action.circulation side or the mmbxs side (or both), and if it makes sense to add the same linkage to other reports sources
08:00 * csharp is open to suggestions
08:08 phasefx csharp: not sure how to make use of it in the reporter, but the link would be the id's?
08:11 akilsdonk joined #evergreen
08:16 phasefx csharp: if you're starting with Item as your source, you may want to add something similar to the "rlc" class in fieldmapper that handles the Last Circulation Date link
08:21 csharp phasefx: oh - yeah, I can see that now
08:21 csharp that's probably a better approach
08:30 csharp ah - Billable Transaction has a Circulation Billing link - that may do what I need without further head-scratching
08:30 Shae joined #evergreen
08:35 mrpeters joined #evergreen
08:35 julialima_ joined #evergreen
08:35 mdriscoll joined #evergreen
08:40 Dyrcona joined #evergreen
08:44 maryj joined #evergreen
08:51 ericar joined #evergreen
09:09 krvmga joined #evergreen
09:11 krvmga i'm doing a fresh install of eg and starting with installing opensrf. when i run autoreconf -i, i get a libtoolize message asking me to consider adding things to configure.ac and Makefile.am. i haven't seen this before.
09:12 krvmga it's not clear if autoreconf -i is failing
09:12 bshum krvmga: That's standard
09:12 bshum By standard I mean, nothing unusual
09:13 krvmga bshum: so i can ignore it? or do i have to make changes in configure.ac and Makefile.am?
09:13 bshum See also: https://bugs.launchpad.net/opensrf/+bug/1272937
09:13 pinesol_green Launchpad bug 1272937 in OpenSRF "OpenSRF configure.am showing deprecation warnings with autoreconf -i step" (affected: 3, heat: 16) [Undecided,New]
09:13 bshum krvmga: You can ignore it.
09:13 krvmga bshum: thanks
09:13 bshum They're just deprecation warnings.  Not errors.
09:14 bshum krvmga: With autoreconf -i you only do that on git installs, from a tarball OpenSRF, it's not a necessary step.
09:15 bshum Might be why you never noticed before?  Cause it's been doing those little warnings for years now.
09:18 StomproJ Has anyone tested/used one of the new intel DDR4 memory based servers for postgresql?  Does the increased memory bandwidth give a big boost in performance?
09:18 bshum There's DDR4?  :\
09:18 * bshum goes back to living under his rocks
09:19 bshum StomproJ: Might be an interesting question to ask over in the #postgresql channel too :)
09:21 bshum Hmm
09:22 bshum @later tell gmcharlt Speaking of OpenSRF bugs to fix before 2.4.1, maybe we can wrap up https://bugs.launchpad.net/opensrf/+bug/1272937 (it's mostly done, just a tidbit question in my last comments)
09:22 pinesol_green bshum: The operation succeeded.
09:22 pinesol_green Launchpad bug 1272937 in OpenSRF "OpenSRF configure.am showing deprecation warnings with autoreconf -i step" (affected: 3, heat: 16) [Undecided,New]
09:27 StomproJ bshum, check out http://ark.intel.com/products/81​880/Intel-Server-Board-S2600TPF claims a 115GB/s memory bandwidth, compared to the 14GB/s that the DDR3 server my vendor is quoting me.
09:42 yboston joined #evergreen
09:45 jonadab That does sound like a potentially significant difference.  If memory bandwidth is a major performance bottleneck for a particular deployment.
09:59 goood joined #evergreen
10:05 Dyrcona StomproJ: You might try asking in #postgresql.
10:06 Dyrcona grabbing 0908
10:10 jwoodard joined #evergreen
10:17 pinesol_green [evergreen|Remington Steed] LP#957466: Update editor/edit_date/source on overlay - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=62510da>
10:18 pinesol_green [evergreen|Jason Stephenson] LP#957466 Vandelay set the 905$u on imported bib records to current user. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=522b6ff>
10:18 pinesol_green [evergreen|Jason Stephenson] LP#957466: Stamping Upgrade Script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=fe07338>
10:43 jeff I've noticed an odd (to me) difference between xulrunner and webstaff, and I think it comes down to pcrud permissions vs open-ils.circ api permissions:
10:47 jeff given a patron with open circulations at the CONS level (i can't recall offhand if those were generated by concerto or if that was me manually checking things out without having a workstation set), users without the EVERYTHING permission can't see the circs in the web client.
10:47 jeff but they can in the xulrunner client.
10:47 jeff I haven't yet given it a more realistic test (usually you wouldn't have circs at CONS, etc)
10:48 berick jeff: does your login have global VIEW_CIRCULATIONS permissions?
10:48 jeff And I'm going to take the opportunity to refresh/enhance my understanding of permissions in general, but I wasn't able to make the circs show in the web client even when making someone global admin and assigning them working locations across the org tree.
10:49 jeff berick: i'll verify that specifically. one set.
10:49 jeff er, "one sec"
10:50 berick looks like it's also fleshing copy, workstation, call_number, record, and simple_record
10:50 yboston kmlussier: got a minute to talk about authority related signoffs?
10:50 berick so you'd need the necessary view perms on those.  (but most of those are public, IIRC)
10:51 yboston berick: heads up, I started buildign a new VM yesterday to sign off your authorites overlay code. Glad to see that you have a new rebased branch
10:52 berick yboston++
10:52 berick great
10:56 jeff berick: okay, fresh day, fresh approach, fresh results. i now no longer need to have EVERYTHING, but the behavior does remain changed between open-ils.circ and open-ils.pcrud with regard to permissions required (open-ils.circ is more permissive).
10:56 jeff This may all be normal and expected, of course.
10:57 goood berick: I don't know if you saw my note (as eeevil) last night, or responded ... no quassel core ATM, and lost goood's connection on monday (no log)
10:58 goood berick: nm. irc logs tell the tail
10:59 bshum ++ # yay :)
11:01 csharp lawgs++
11:01 dreuther_ joined #evergreen
11:07 goood jeff:  did you have a workstation set up (and logged out and back in) in the web client? ... which reminds me, we now have the capability to disable (without hiding) OUs in the org dropdown ... we should do that for the workstation UI so you can only select can_have_users OUs
11:22 Dyrcona I should just call it a day. I'm messing up every other thing that I do.
11:23 jeff goood: figured it out, thanks!
11:56 dbs Ah that awesome moment when you choose "All hold requests" as your starting report source because you want *all* hold requests and you discover that it is in fact only the aged hold requests, which is far from all of them
12:09 dreuther joined #evergreen
13:08 sandbergja joined #evergreen
13:21 buzzy joined #evergreen
13:22 jonadab Hmm...  looking at schemata, actor.usr has a passwd field but no salt field?  I'm missing something, right?
13:22 buzzy did any of you get the call a call for sponsors/exhibitors email from me on the the openils list?
13:32 kmlussier yboston: I'm here now
13:32 collum Just got it buzzy
13:32 csharp buzzy: I got it at 1:29 p.m.
13:34 yboston kmlussier: I sent you an email a little earlier. just letting you know I am building a Vm to test auth overlay. Also that, I if you had time/VM, that I have some auth code needing a sign-off bug 1403967
13:34 pinesol_green Launchpad bug 1403967 in Evergreen "Display 'subject heading thesaurus' value in Manage Authorities results" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1403967
13:35 buzzy great, thanks. i just did, too. for some reason, it didn't go through the first time
13:37 mmorgan joined #evergreen
13:41 maryj_ joined #evergreen
13:42 kmlussier yboston: OK, good. I'm a little behind in my testing this week.
13:43 kmlussier yboston: I can take a look at your code.
13:44 maryj joined #evergreen
13:53 jeffdavis jonadab: you are correct - passwords stored in the db are hashed but not salted
13:55 Dyrcona Salt is applied when a user authenticates, but if someone grabs your database, you may have bigger problems than worrying about the user's password hashes.
13:59 goood berick: re authority match sets 1) thanks for the parens update! 2) everything looks sane ... I'll be pushing it in
14:04 berick goood++
14:04 berick many thanks
14:09 jeffdavis Dyrcona: I don't want to beat a dead horse, but "you have bigger problems" isn't really an argument in favor of storing pwds insecurely.
14:12 rangi just my 2cents, instead of adding a salt, (salts stored in the db don't help much, they can still be brute forced in a feasible amount of time) probably better to switch to bcrypt
14:12 jeff There are few arguments for storing passwords without salt. I think there is agreement that we'd like to improve this.
14:13 rangi http://codahale.com/how-to​-safely-store-a-password/
14:13 Dyrcona We have mitigations against remote brute force.
14:13 bshum I vaguely recall talking about this at the first Evergreen Hack-a-way and reaching the agreement jeff refers to.
14:13 rangi jeff: the point is, salts dont help you, if someone has your db
14:13 Dyrcona I know how to store passwords, and I agree that they should be salted.
14:13 rangi its better to not use old hashing techniques
14:13 rangi with or without salts
14:14 Dyrcona That's the trouble with grandfathered data and backward compatibility.
14:14 jeff rangi: hashes with salt help more than unsalted hashes, but it doesn't raise the bar nearly as high as something like bcrypt does. I think we're in agreement here.
14:15 rangi one thing we did, is whenever someone logs in, fix their password
14:15 * jeff nods
14:15 rangi to ease the transition
14:15 jeff that's a standard method of migration.
14:15 jeff though i've also seen the (somewhat less effective) method of upgrading the stored password only on change
14:16 rangi *nod*
14:16 rangi does evergreen allow/enforce (koha doesn't yet) a password expiry?
14:17 jeff not yet.
14:17 rangi forcing people to change is probably a goodish thing to do i would think
14:17 jeff though i'd like to see that also, especially for staff reasons.
14:17 rangi yeah
14:17 jeff forcing people to change a password doesn't help you upgrade the hash from one version to another -- least, not that I can see.
14:17 Dyrcona We're doing that on our email server. Staff just \love\ it.
14:18 rangi jeff if you combine it with the changing the hash on changing password
14:18 jeff I'm more a fan of strong requirements and two factor auth than I am of forced expiry.
14:18 rangi was what i was thinking
14:19 jeffdavis You could always use known techniques to crack your unsalted MD5-hashed pwds in order to re-save them in a more secure form (bcrypt or whatever). :P
14:19 jeff rangi: where technically possible, i would advocate migrating the hash on login instead of migrating it only on password change -- no expiry requirement there. :-)
14:19 rangi yep, thats what we do
14:19 jeff jeffdavis: yes. i've actually used that approach in another context.
14:22 jonadab jeffdavis, Dyrcona Ok, thanks for the info.
14:22 jonadab At least they're hashed, that's an improvement over our current situation with our existing ILS.
14:23 jeffdavis Yes, AFAICT EG is better than common industry practice in this regard.
14:27 dbwells_ joined #evergreen
14:27 goood jonadab: fwiw, the auth app itself actually uses (a variant of) CHAP, so the neither the hash nor the cleartext goes over the network between the immediate client and evergreen proper.  That said, tpac move the immediate client from the browser into mod_perl on the server, depending on SSL/TLS to protect the channel between browser and apache
14:28 goood so, you can rainbow table a dump of the passwords, but can't capture them without attacking the database itself ... or being a malicious staff member
14:30 jonadab Right, just plain hashed is obviously much better than cleartext in the DB.  And yes, I know if someone from outside the library captures the DB there are larger privacy issues.
14:30 jonadab Also I have no argument against bcrypt.
14:31 goood bcrypt++ # indeed
14:31 jeff jeffdavis: the "brute force the weak existing keys" works well in the scenario where the new system can't support the older storage method.
14:32 jeffdavis I feel obliged to mention that I am actually wearing a 2600 t-shirt right now.
14:33 Dyrcona heh
14:33 jeffdavis ^ not cred, just amusing coincidence
14:34 jonadab And yeah, upgrading the hashing/salting/whatever on login is standard practice.
14:34 jonadab (If the passwords are not hashed at *all*, you can upgrade them en masse during an upgrade or migration, which we'll obviously do when we move to Evergreen.)
14:34 captncrunch jeffdavis: whatevs!
14:35 jeffdavis lol
14:36 csharp er... I appear to have two search.query_parser_fts() functions in our database
14:36 jeff @praise namespaces
14:36 * pinesol_green namespaces is one of the few who deserves to be praised
14:36 jihpringle joined #evergreen
14:36 jeff (just because we have no @sarcasticpraise)
14:37 csharp they differ in the parameters they take, but looking at the 300.schema.staged_search.sql file, there's only one created in a stock EG
14:37 csharp or am I missing something?
14:37 jeff (and really, i should probably blame search_path)
14:37 ldw csharp: we had a similar thing.  I believe the one with fewer arguments if from an older version that was never DROPed.
14:37 csharp ldw: thanks for that confirmation
14:39 csharp I ask because the code to fix bug 925776 does not appear to be working - could EG still be calling the older version?
14:39 pinesol_green Launchpad bug 925776 in Evergreen "located URIs appear in staff client OPAC searches regardless of $9's" (affected: 8, heat: 46) [Medium,Fix released] https://launchpad.net/bugs/925776
14:39 jeff yeah. new CREATE OR REPLACE without a DROP IF EXISTS of an already-present one is usually the cause. fresh 2.7 has one, our prod 2.5 has two.
14:40 csharp ok
14:42 csharp well, in any case, the fix for bug 925776 is not working for us and I'm seeking a cause - I'm beginning by attempting to rule out missing upgrade scripts/skipped steps
14:42 pinesol_green Launchpad bug 925776 in Evergreen "located URIs appear in staff client OPAC searches regardless of $9's" (affected: 8, heat: 46) [Medium,Fix released] https://launchpad.net/bugs/925776
14:43 csharp I can see eeevil's fix for the bug in the longer/newer query_parser_fts function, though, which is why I was curious about seeing two
14:43 csharp my example is http://next.gapines.org/eg/opac/results?bool​=and&amp;qtype=keyword&amp;contains=contains​&amp;query=&amp;bool=and&amp;qtype=title&amp​;contains=contains&amp;query=hot+zone&amp;bo​ol=and&amp;qtype=author&amp;contains=contain​s&amp;query=castle&amp;locg=53&amp;pubdate=i​s&amp;date1=&amp;date2=&amp;sort=&amp;_adv=1
14:44 csharp that title shouldn't be showing for Putnam County Public Library since it's owned by a library in another system in the hierarchy
14:44 jeff but this isn't a staff search...
14:44 jeff so i would expect the cause/fix to be different.
14:45 goood csharp: just to make sure the easy stuff is out of the way, it does not have a trancendant [sic] bib source, right?
14:45 csharp lemme check
14:47 csharp goood: actually, yes, it is set to transcendant
14:47 jeff simple cause, simple fix. :-)
14:47 goood :)
14:48 csharp so set transcendant to false, and it should work?
14:48 * csharp never wrapped his head around all this
14:49 * csharp reads the FM: http://docs.evergreen-ils.org/2.6/_using_transce​ndent_bib_sources_for_electronic_resources.html
14:49 goood yes. trancendant means "always show, always"
14:49 goood they "transcend" location :)
14:50 jeff if biblio.record_entry.source points at a config.bib_source entry with transcendant [sic] set to true, then that bib can appear in any search regardless of copies or located urls.
14:50 csharp ha! it works
14:50 csharp goood++ jeff++ # thanks
15:08 kmlussier I'm working on bug 1422802 where we want to provide an option to use radio buttons to select a part on the place holds screen.
15:08 pinesol_green Launchpad bug 1422802 in Evergreen "Parts need to be more visible on the place holds screen" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1422802 - Assigned to Kathy Lussier (klussier)
15:08 kmlussier Ideally, what our libraries want is to not have one of the parts pre-selected so that the user needs to make an explicit choice when selecting a part.
15:08 kmlussier However, if we did so, we would need to make this a required a field, and I'm having trouble figuring out how to do so. I initially used the required attribute for the form input, but I've since discovered it's not supported in Safari.
15:09 kmlussier The only other way I know of to make the field required is to use javascript, but I know we want to avoid using it in the catalog whenever possible. Are there other ways we might be able to tackle this issue?
15:14 phasefx kmlussier: it's heavy, but you can make the page return itself with an informative error
15:15 * phasefx found a wish for this earlier when trying to use Consortium as a pickup lib.. wasn't obvious to me at first what was happening
15:16 jonadab Having the page return a partly-filled form with an informative error about the missing required field(s) is what is what I would probably do, _possibly_ with optional Javascript designed to pre-empt the submit if Javascript is working ok, letting the server-side stuff catch it if not.
15:18 kmlussier phasefx: You can select the consortium as a pickup library?
15:19 phasefx kmlussier: I'm sure it was an admin user on a test system, maybe with the consortium as a the workstation lib.  Once deselected, you can't reselect it
15:19 kmlussier jonadab: The problem with the optional Javascript is that we've tried to keep it out of the catalog unless it's aboslutely necessary.
15:19 phasefx but the user had no sane default for whatever reason
15:19 kmlussier phasefx: Ah, ok.
15:19 phasefx kmlussier: in that case, the page just returned itself with no obvious error
15:20 jonadab kmlussier: Ah.
15:20 jonadab So yeah, just make the server side handle it then.
15:20 phasefx kmlussier: it was probably the home lib of the stock admin user at fault
15:20 maryj joined #evergreen
15:21 jonadab (My objections to Javascript start when it becomes non-optional or else runs for multiple seconds; but I don't have any particular objection to avoiding it, either.)
15:22 * kmlussier would be happier if browsers supported HTML5 elements. :)
15:22 goood grabbing 0909
15:23 Dyrcona kmlussier: Most do. Support is just spotty and limited. It always has been for the most part.
15:23 jonadab Well, HTML5 is pretty new still.  Relatively speaking.
15:23 Dyrcona Plus, which HTML5 and if the living standard, how new? :P
15:24 Dyrcona Well, in general, HTML support in browsers has always been spotty. ;)
15:24 kmlussier From what I read, the required attribute for form fields has been around for a while.
15:24 jonadab I mean, it's only been a couple of years since we got the last major holdout browser to finally do CSS2 correctly.
15:24 Dyrcona Hey! Here's a standard. Let's ignore it.
15:25 jonadab (Ok, more like five years.  Still.  These things take time.)
15:26 Dyrcona I'm all out of tuits, literally. I gave my last one to our help desk staff.
15:27 pinesol_green [evergreen|Bill Erickson] LP#1171984 Vandelay authority record matching - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=af7304c>
15:27 pinesol_green [evergreen|Bill Erickson] LP#1171984 Vandelay auth. match release notes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=fba2cd8>
15:27 pinesol_green [evergreen|Bill Erickson] LP#1171984 vandelay authority rec attr create repair - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=fbaa6bb>
15:27 pinesol_green [evergreen|Mike Rylander] LP1171984: Stamping upgrade script - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=6d6130e>
15:35 jboyer-isl kmlussier: Oh, no! I forgot I had even submitted the code for lp1366026, nevermind that it was waiting for release notes. :(
15:35 kmlussier jboyer-isl: I was actually going to write the release notes today if you didn't see it.
15:36 jboyer-isl I'm not sure I'll have time before the cutoff, unfortunately.
15:36 kmlussier jboyer-isl: OK, I can take care of it. I would hate to see a good feature not make it in due to release notes. :)
15:38 jboyer-isl As far as release notes go though, I wasn't planning any for the lp1210541, because you can already delete copy locations; it just doesn't usually work. I was veiwing that as a bug fix.
15:39 jboyer-isl Huh. pinesol doesn't appear to like my lp style.
15:39 jeff bug 1210541
15:39 pinesol_green Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541
15:39 jboyer-isl lp 1366026
15:39 pinesol_green Launchpad bug 1366026 in Evergreen "Add Copy Active Date to Staff Client Display" (affected: 4, heat: 24) [Wishlist,Incomplete] https://launchpad.net/bugs/1366026
15:39 jboyer-isl lp 1210541
15:40 jboyer-isl Drop the comma or add the space, who knows where things went off.
15:47 yboston berick: am I wrong, or did your authority overlay code get signed off and merged to master? Should I still test off of master or should I test from your rebased branch?
15:48 kmlussier jboyer-isl: Hmmm...I was just discussing it with mmorgan. I think there's a fine line between bug fix and enhancement, but if it isn't mentioned in the release notes, then all the people who gave up on deleting copy locations won't know they can delete them now.
15:49 dbs Bug fixes should have release notes entries too!
15:49 goood yboston: it got pushed today, you are not wrong. testing on master is best now
15:49 jboyer-isl Sigh. I suppose that is true. (dbs's point includeD)
15:49 dbs lots of bug fixes listed in http://www.postgresql.org/docs​/9.4/static/release-9-4-1.html :)
15:50 * dbs promises to start writing now overdue release notes for TPAC features
15:50 jboyer-isl I'm going to try to make a habit of just writing something up the next time I get a patch put together, I am apparently terrible about fixing it after the fact.
15:50 yboston goood: OK, was just about to load his branch, will do master intead
15:58 jeffdavis kmlussier++ # thanks for catching that LP#1423025 was a duplicate!
16:12 hopkinsju yboston: Any reason we use .txt rather than .asciidoc for our documentation? It never occurred to me until I saw Benjamin's post to the General list, but using .asciidoc would allow for automatic rendering in some cases (e.g. Github)
16:18 * dbs pushes overdue release notes for TPAC discoverability features
16:18 goood yboston: I'm about to push your authority thesaurus display branch. thanks for that
16:19 pinesol_green [evergreen|Dan Scott] TPAC discoverability release notes entry - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=12ee39d>
16:21 pinesol_green [evergreen|Yamil Suarez] LP#1403967: show 'subject heading thesaurus' value in Manage Authorities results - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=985313e>
16:22 kmlussier hopkinsju: rsoulliere may be a better person to answer the AsciiDoc question since he is the person who set up the doc repository.
16:22 hopkinsju Right on. Thanks kmlussier!
16:23 bshum dbs: Heh, I think there's an errant copy/paste in your TPAC discoverability note
16:23 bshum There's a link there to the release note for PG 9.4.1
16:25 bshum On line 35
16:39 yboston hopkinsju: kmlussier did a much better job answering your question that I would have
16:40 yboston goood: thanks
16:40 hopkinsju By telling me to ask someone else? :)
16:41 yboston hopkinsju: I can't belive it never crossed my mind before, because I end up having to explain to vounteers to use .asciidoc as a file suffix for github gist to render properly
16:42 yboston hopkinsju: then again I can see some complaining that they don't have an app to open .asciidoc files on their computers; no good deed goes unpunished
16:42 hopkinsju yboston: I was also thinking how unfortunate it is (for the maintainers) that we use the fist style of headers (where h1's are the same number of ~'s as letters in the heading)
16:43 hopkinsju When a double = (==) would have done the same thing. Sounds like a real headache.
16:44 yboston hopkinsju: when preparing training materials I discoverd that other approach, I would hope that the other style worlks. I would consider teaching the other way too
16:44 yboston hopkinsju: I mean works on our rendering set up
16:45 hopkinsju Right. One favors readability, the other writeablilty I suppose
16:56 dbs bshum: aw yeah, that's how I roll. I'll fix it
16:56 bshum dbs++
16:57 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:04 vlewis joined #evergreen
17:05 vlewis joined #evergreen
17:09 mdriscoll left #evergreen
17:11 mmorgan left #evergreen
17:13 pinesol_green [evergreen|Dan Scott] Fix typo in release notes for TPAC discoverability - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c0fabd0>
17:15 wlayton joined #evergreen
17:17 * bshum waves at wlayton :)
17:24 mrpeters left #evergreen
17:30 MrBaggins joined #evergreen
17:30 MrBaggins Good afternoon evergreen
17:31 MrBaggins I hope someone can help a poor creature of the shire
17:31 MrBaggins I'm trying to access the pdf's listed on http://evergreen-ils.org/dokuwiki/dok​u.php?id=existing-docs:existing-docs
17:31 MrBaggins more specifically the 4 on reports
17:32 MrBaggins but the sitka.bclibraries.ca domain links just loop to bc.libraries.coop/wp-login.php
17:36 MrBaggins http://sitka.bclibraries.ca/documentation/sitka-ev​ergreen-user-documentation/Reports%20Training.pdf for example
17:38 jeffdavis MrBaggins: I work for Sitka. Give me a minute and I'll see what I can do for you.
17:38 jeff MrBaggins: i'd start here: https://bc.libraries.coop/support/sitka-support/
17:38 jeff ah, but listen to jeffdavis -- he'll likely be of more help!
17:39 ldw MrBaggins: here is the HTML version: http://docs.sitka.bclibraries.ca​/Sitka/current/html/report.html
17:40 MrBaggins does that contain all the information available on reports?
17:40 ldw That is Sitka's report documentation.  What are you looking for in particular?
17:41 MrBaggins any and all manuals/guides relating to reports.  If that's the only thing thats ok I was just curious
17:42 jeffdavis Note that the Sitka docs discuss some stuff that is specific to Sitka, like report templates that exist on our system but aren't in a regular Evergreen system.
17:42 MrBaggins ok that's good to know, thanks
17:43 jeffdavis http://docs.evergreen-ils.org/2.7/_reports.html is the documentation for version 2.7 of Evergreen
17:44 jeffdavis That's more general. Not sure how much it differs from the Sitka docs.
17:44 MrBaggins Might help, thanks for your time Jeff
17:45 jeffdavis Always happy to help Bagginses.
17:46 berick huh, looks like chrome beat FF to disallowing synchronous xmlhttprequest's.  just like that, vandelay no longer works in chrome.
17:46 jeffdavis That "existing-docs" wiki page looks like it's a list of what documentation existed 5 years ago, so should probably not be relied on as the most current source of info for anything.
18:00 dbs berick: fantastic!
18:03 berick certainly adds pressure to angular-ize (i.e. websocket-ize) legacy UI's
18:03 ldw MrBaggins: I sent a reports howto to the mailing list in 2011, so some of it may not be applicable now, you can find it here: http://georgialibraries.markmail.org/message​/ptlz36kle63spqqb?q=Liam+report+date:201109+
18:04 berick hm, patron reg throws the same warning, but still renders OK
18:04 berick perhaps it's only deprecated, but not yet prevented, and vandelay is just broken for some other reason
18:05 berick oh well, more testing later
18:06 dbs all I've been seeing is deprecation notices, but I thought maybe you were on canary or some such advance build
18:12 MrBaggins Thanks for that ldw, every bit helps
18:23 jonadab As far as asciidoc and people wanting .txt files so they can double click, it should be straightforward to make the build process turn the former into the latter.
18:24 jonadab I believe for example that esr set up the NetHack 4 Guidebook that way.
18:25 jonadab (And then other formats can be generated as well.)
18:38 gmcharlt joined #evergreen
18:38 gmcharlt berick: kmlussier: collab/gmcharlt/lp1410369_message_center
19:08 wlayton joined #evergreen
19:43 kmlussier gmcharlt++
19:48 kmlussier jonadab: Currently, our build process turns the .txt files into html/pdf/epub. I think the question came up because somebody was looking asciidoc files in a github branch that hadn't been merged into master yet, and therefore is not part of the build process.
19:48 jonadab Ah, I see.
20:56 graced joined #evergreen
21:12 ying joined #evergreen
21:15 bmills joined #evergreen
22:20 bmills joined #evergreen

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