Evergreen ILS Website

IRC log for #evergreen, 2014-03-04

| 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
02:03 gsams joined #evergreen
03:56 gsams joined #evergreen
07:18 jboyer-isl joined #evergreen
07:27 timf joined #evergreen
08:05 akilsdonk joined #evergreen
08:24 mrpeters joined #evergreen
08:30 Shae joined #evergreen
08:36 RoganH joined #evergreen
08:42 ericar joined #evergreen
08:56 mmorgan joined #evergreen
09:07 kmlussier joined #evergreen
09:23 dluch joined #evergreen
09:24 gsams joined #evergreen
09:28 yboston joined #evergreen
10:19 mrpeters joined #evergreen
11:18 dbs Random fun stats question of the day: how many entries do you have in your money.billing table? "SELECT COUNT(*) FROM money.billing;"
11:18 eeevil dbs: all the entries. all. of. them.
11:18 dbs We're at 2.5 million
11:19 eeevil dbs: I was about to ask if your billing table is longer than your mfr table ... it's not ;)
11:22 dbs Heh, definitely not
11:22 mmorgan dbs: We're at 11.9 million
11:22 jeff 14.1M here, and I know that 9M are not needed.
11:23 jeff with that 14.1M, we're CLOSE to mfr (16.2M) :-)
11:29 jwoodard joined #evergreen
11:29 eeevil back in the day, PINES mfr used to be ~110M, IIRC
11:33 dbs 110 million. Wow.
11:33 dbs oh, MFR :)
11:34 eeevil billing might be that big by now
11:34 bshum dbs: 14434358 for us when I run that query.
11:34 eeevil but if you really want your mind blown, see action.hold_copy_map in a busy 1.4-era install ;)
11:35 dbs Cool. Nice to know that even with our 5-minute fines we're still well within normal limits :)
11:35 eeevil (HINT: there was a good reason for the change from SERIAL to BIGSERIAL)
11:36 dbs Yeah, we're at 102 million MFR rows
11:37 Wyuli joined #evergreen
11:37 dbwells We've only got 200k rows in money.billing.  Our fine policies must be too lax, because I don't think our users are *that* responsible ;)
11:39 snowkitten_ joined #evergreen
11:40 * dbs wonders if anyone else has implemented a sitemap for their Evergreen install
11:42 jeff talked about it long long ago, but no.
11:43 jeff i'd be supportive of something that helped increase search engine visibility while reducing load generated by search engine crawling.
11:43 jeff which i suspect covers the goals you had in mind?
11:45 jeff and, i just noticed you said "anyone else" -- are you saying you created a sitemap? simply a list of all records in the system, or something else?
11:45 kbeswick joined #evergreen
11:45 jeff rather, simply generated a list of all /eg/opac/record/* urls based on a db query, or something else?
11:46 dbs jeff: yeah, I created one a few years ago, lemme expose the very rough doc I created for that
11:46 dbs https://docs.google.com/document/d/1kWZDoRse92WE​WLzGEeVgo6ES01YByRcVdUqYw04dEuA/edit?usp=sharing
11:49 csharp dbs: PINES is at 134.7M billings
11:49 csharp and that's after a purge of pre-2010 billings 2 years ago
11:49 dbs csharp: wow.
11:49 csharp yep
11:51 bshum Hmm, for the SIP config in the part where it lists <checkout_override> events.  Would the actual selfcheck user require the override permissions to automatically override those events?  Or does the SIP server just exclude any listed events as they occur?
11:51 csharp PINES is a humongous green monster
11:52 bshum Some library wants to add more situations where checkouts are just automatically allowed for a particular SIP device.
11:52 bshum Like a selfcheck where everything is greenlit
11:54 RoganH joined #evergreen
12:19 kbeswick joined #evergreen
12:20 jihpringle joined #evergreen
12:20 tsbere bshum: The selfcheck user would, I believe, need override permissions
12:21 tsbere But I could be wrong
12:21 tsbere You do need to list *all* events you want to automatically override, though, so "greenlight everything" would be problematic in that case
12:29 bshum Yeah
12:29 bshum Sigh
12:37 geoffsams joined #evergreen
12:45 mmorgan Does anyone have a recommendation for a kiosk browser for simple self-check?
12:47 dbs mmorgan: "chrome --kiosk <url>"?
12:47 bshum mmorgan: I like openKiosk personally
12:47 bshum http://openkiosk.mozdevgroup.com/
12:47 bshum (oh they changed their website...)
12:51 mmorgan Do slips print with either of those?
12:52 bshum mmorgan: I... think it can.  But I haven't tested it quite yet.
12:54 mmorgan We've had trouble getting the slips to print with different kiosks, but we'll take a look at these. Thanks!
12:57 krvmga joined #evergreen
12:58 krvmga i've got a situation where one of the holds that a patron has placed is causing errors. in the staff client, looking at the patron's holds, there is one that is always "retrieving" and i can't see what it is. how can i get at that hold?
12:59 krvmga i was thinking i'd need to go into the database to look for it.
13:00 krvmga i pulled up the patron's record in the database.
13:00 krvmga under actor.usr
13:00 krvmga where do i pull up his holds?
13:01 mmorgan select * from action.hold_request where usr = <usr.id> and fulfillment_time is null and cancel_time is null
13:01 mmorgan will get you the holds that haven't been filled or cancelled
13:01 krvmga mmorgan++
13:01 krvmga thank you
13:02 Wyuli mmorgan: For self-check kisosks, I've used Firefox Portable (http://portableapps.com/apps​/internet/firefox_portable) with pretty decent results on one of our machines. Having it default to open in fullscreen has worked fine provided you don't have a keyboard attached.
13:02 mmorgan I would look for maybe a broken hold that has hold_type = P
13:03 kbeswick joined #evergreen
13:04 mmorgan Wyuli: Thanks! we'll look at that, too.
13:08 Wyuli mmorgan: Now that I think on it, I believe that we had to edit the page setup to eliminate margins and remove headers/footers/page numbers etc. when printing, else the receipt printer would spit out of a foot of paper for one item.
13:08 Wyuli Is that the problem you're having, or are things just not printing at all?
13:10 mmorgan Things were just not printing at all.
13:16 Wyuli Hmm. Have you made proper sacrificial offerings to appease the printers? Pretty sure that's what they require to work correctly.
13:16 dbs with "chrome --kiosk", you can also pass a "--user-data-dir=<directory>" argument to set up a separate profile, which would presumably enable you to set up printer options
13:18 bshum mmorgan: Oh you know... there was a bug for awhile in selfcheck
13:18 bshum Where the receipts didn't print at all due to a javascript error
13:19 bshum But I can't remember if that was ever resolved in more recent versions.  Or if it only affected certain parts of the receipts.  Like billings.
13:20 mmorgan Do bugs work as sacrificial offerings? :)
13:22 mmorgan I know a few kiosks have been tried and some printed but had other issues. We need to do some more testing, these suggestions will help.
13:23 mmorgan dbs++ bshum++ Wyuli++
13:25 jwoodard joined #evergreen
13:33 tsbere bshum: I think part of the problem with printing is "modern web browsers don't allow automatic printing, or interaction with printer settings in general, at all from web pages anymore"
13:36 Wyuli mmorgan, tsbere: The Evergreen self-check module and I are not on real good terms. :\  There's a pretty slick open source self checkout packge that runs on PHP and is pretty slick.
13:37 Wyuli Upside: Fully customizable
13:37 Wyuli Downside: Fully customizable. Also requires a PHP server.
13:40 dbs Wyuli: which evergreen self-check module?
13:41 mmorgan can't stand the suspense...
13:46 Wyuli Sorry, patrons pulled me away.
13:46 Wyuli I erm...can't say which module we're running. I'm a simple librarian in the Indiana network, I don't have access to the self-check code itself. :)
13:48 Wyuli As far as the custom self-check, please forgive the shameless plug, but I've tried to consolidate as many of the help guides / tutorials / file downloads as I can in one place: http://www.greensburglibrary.org/selfcheck
13:49 dbs Wyuli: the one we support now is at https://[hostname]/eg/circ/selfcheck/main (per http://docs.evergreen-ils.o​rg/2.5/_self_checkout.html)
13:50 Wyuli dbs++ Thank you!
14:05 Wyuli dbs: That site is working correctly and not throwing JavaScript errors when we try and print. Hooray!
14:05 Wyuli I think I ran into some issues with the workstation parameter, though. :|
14:06 Wyuli I can get by without the ?ws=..., but not sure if that would invoke the wrath of folks at Evergreen Indiana central command. :)
14:06 bshum "central command" I love it.
14:10 brent_sage joined #evergreen
14:12 rjackson-isl joined #evergreen
14:17 Dyrcona joined #evergreen
14:25 RoganH joined #evergreen
14:26 gsams joined #evergreen
14:39 jboyer-isl Wyuli, bshum: Always watching. http://www.lightmasterstudios.co.uk/wp-con​tent/uploads/2012/01/Monsters-Inc-Roz.jpg
14:40 bshum jboyer-isl++ #awesome.
14:40 dbwells jboyer-isl: Wait, *you're* number one?
14:41 jboyer-isl Wyuli: More seriously: you have to either 1. register a new workstation id through a real client, or 2. put in a ticket and one of us will make one you can use. The thing after ?ws= has to already exist before you can use it. (And you'll probably want to use it for reporting!)
14:41 * dbwells gasps
14:42 jboyer-isl dbwells: I don't like paperwork enough, to be honest.
14:51 geoffsams joined #evergreen
15:01 Wyuli jboyer-isl: That is basically how I picture ISL staff members every time I submit a help desk ticket.
15:02 Wyuli Though the eyes could be a little more judgmental and filled with hatred, though.
15:02 snowkitten__ joined #evergreen
15:03 Wyuli (Seriously though, you guys are great!)
15:03 jboyer-isl Not at all. We're a kindler, gentler, judgementaler helpdesk. (choose 2, but choose wisely)
15:06 Wyuli Truly a helpdesk of wealth and taste!
15:07 Wyuli Scholars and gentlefolk, all.
15:09 shadowspar joined #evergreen
15:16 rfrasur joined #evergreen
15:20 kmlussier joined #evergreen
15:27 Wyuli Hmm...on the bills tab of the patron's account screen, any idea why billed items in the list are unchecked by default on some staff clients but not others?
15:27 kmlussier Wyuli: There's a setting for that.
15:27 kmlussier Maybe a library setting?
15:28 bshum It is a library setting, yes.
15:29 bshum "Uncheck bills by default in the patron billing interface"
15:29 bshum In the "GUI" category of settings
15:30 kmlussier bshum: Beat me to it. :)
15:30 bshum kmlussier: Does that mean my staff client launching was just fractionally faster than yours?  :D
15:30 Wyuli bshum++ kmlussier++, thanks!
15:30 kmlussier bshum: I was distracted.
15:30 Wyuli It's defaulting to checked on some and unchecked on others...which is odd. Will take a look there.
15:30 bshum kmlussier: So was I, seeing what medals got sent out :D
15:30 bshum dbwells++ # fun!
15:31 kmlussier Wyuli: Are the workstations registered at different org units?
15:31 Wyuli kmlussier: I'm about to find out!!
15:32 Wyuli The staff clients were installed before my time by someone else (*ominous peal of thunder*) so not sure.
15:35 Wyuli Date Changed Location Original Value New Value
15:35 Wyuli 2014-03-04T09:24:58-0500GDCPLGtruenull
15:35 Wyuli 2014-03-04T08:03:19-0500GDCPLGnulltrue
15:36 Wyuli Oh my that is ugly, should have used pastebin, apologies.\
15:36 jboyer-isl Wyuli: Also, some settings are only checked at login, so if some clients were started later in the day (Say, after we changed that setting at your library while working on a ticket...) they'll behave differently.
15:36 Wyuli Looks like the setting was true for...90 minutes earlier today?
15:36 Wyuli Ohoho
15:37 bshum Hehe
15:37 Wyuli jboyer-isl++ Thanks; I think that solves the mystery rather succinctly. :)
15:38 berick dbwells++ # 2.6 beta summary
15:48 senator joined #evergreen
15:54 eeevil I think we have code attached to all the RC blockers now ... https://bugs.launchpad.net/evergre​en/+bugs?field.tag=2.6-rc-blocker is looking for testers.  IMO, the sooner we can get those big ones out of the way the sooner we can start sweeping up the smaller bugs ... so, here's a call for testing, folks!
15:55 dbs eeevil++
15:56 dbwells eeevil++
16:01 gmcharlt eeevil++
16:05 kbeswick joined #evergreen
16:05 eeevil whee thanks!
16:06 eeevil dbwells: not trying to steal your thunder, of course. but I /am/ hoping for a new category of award... ;)
16:52 kbeswick left #evergreen
17:20 mmorgan left #evergreen
17:25 dcook joined #evergreen
17:26 * bshum twiddles his thumbs waiting for 0864 to run on his test server.  (finish already!!)
17:31 bshum And it dies.
17:31 bshum Oy :(
17:31 dbwells :(
17:31 bshum Stupid reporter.classic_current_circ depends on rec_descriptor stuff
17:31 bshum Guess that's a killer.
17:32 bshum @hate custom reporter stuff
17:32 pinesol_green bshum: The operation succeeded.  bshum hates custom reporter stuff.
17:33 dbwells bshum: so classic_current_circ is something local?  I don't think I've heard of it before otherwise.
17:33 bshum dbwells: I think anything "classic" is one of the custom reporter-extension things that PINES created.
17:33 bshum And is used by Indiana, myself, and probably a few others.
17:33 bshum It's part of the stock, but not installed by default.  (and not super well supported)
17:34 dbwells Ah, thanks.
17:34 bshum I try to avoid it when I can, but it's one of the many things I'd like to see revised someday to either become part of stock or unofficial nuked from existence :)
17:35 bshum But that's definitely going to hurt somebody in production someday.
17:35 * bshum ponders
17:35 bshum Yeah, it's looking for metabib.rec_descriptor
17:35 bshum Which is one of the things we're dropping
17:36 dbwells I am guessing we should just drop that view and recreate it when the upgrade is done.  It should still work with the rec_descriptor view replacement, I think.
17:36 dbwells Might be really slow, though.
17:37 bshum I'm not even sure why it's part of the view...
17:37 bshum The join for metabib.rec_descriptor rd isn't even in the SELECT for the view itself.
17:38 bshum Oooh
17:38 bshum I see
17:38 bshum It's used for stuff further on
17:38 bshum Bleh
17:38 dbwells Yeah, it's the middle man for other stuff.
17:40 dbwells Dropping and recreating views is obviously a pretty painless fix, though a better fix would be to rework the view itself to use the new stuff.
17:42 bshum So like... DROP VIEW IF EXISTS reporter.classic_current_circ; before the DROP VIEW for metabib.rec_descriptor, I guess.
17:43 bshum And then maybe put a note at the end about running the recreate for it if you still want it.
17:44 bshum Sigh, maybe that'll be yet another project idea for Hackfest.  Fix and generalize the example reporter scripts and make them stock.
17:44 bshum Because some people do find value in parts of them.
17:48 bshum To make it so that 0864 doesn't kill those of us who have this issue on master, should we write a commit to fix that in the actual file and then make a minor adjustment to the main 2.5-2.6 upgrade scripts?
17:49 * bshum is never sure what's the best way to proceed with broken upgrade scripts.
17:50 bshum And yes, 0864 completes if you put that DROP VIEW for that classic_current_circ
17:50 dbwells How long did it take, and on what size data set?  I am curious about the performance of that upgrade.
17:51 bshum Err
17:51 bshum Couple minutes only
17:52 dbwells ok
17:52 bshum What parts would interest you?  the inserts?
17:52 bshum SELECT 26088753
17:52 bshum DELETE 5073636
17:52 bshum INSERT 0 3344788
17:52 bshum INSERT 0 2021
17:52 bshum INSERT 0 1184798
17:52 bshum Oh, and joy, I guess I can confirm https://bugs.launchpad.net/evergreen/+bug/1287510 too
17:52 bshum :)
17:52 pinesol_green Launchpad bug 1287510 in Evergreen "2.5.2-2.5.3-upgrade-db.sql and ERROR: column "behind_desk" does not exist" (affected: 1, heat: 6) [Undecided,New]
17:53 Callender_ joined #evergreen
17:54 bshum Oh you know dbwells
17:54 bshum This is a bad, bad test
17:54 bshum I keep forgetting I'm using my Thinkpad with the SSD
17:54 bshum So it's probably doing the job much faster than it does with our regular disk servers.
17:54 bshum I'll let you know when I run it on the other machines.
17:54 mrpeters left #evergreen
17:56 dbwells Oh, I was really just curious if we were talking minutes, 10s of minutes, or hours.  I am not too worried about it.
17:56 bshum Well, on the Thinkpad with SSD, it was no more than just minutes then.
17:57 * bshum loves his portable Evergreen instance now.
17:57 dbwells How much RAM do you have in that machine?
17:58 bshum 16 GB
17:58 dbwells sweeeet
17:58 bshum The SSD is a 500 GB one.  I did a full sized copy of our live database.
17:58 bshum The thing is like 50% faster on searching.  And was about 200% better at hold placement too (pre patches)
17:58 mrpeters joined #evergreen
17:58 bshum So I wanted to see if it worked faster at hold placement now that we got those patches in
17:59 dbwells Dang, that SSD is probably worth more than any computer I own.
17:59 mrpeters left #evergreen
17:59 bshum I'm making the pitch to get SSDs for our nextgen database server hardware.  And using my Thinkpad to demo potential gains.
18:00 dbwells Desktop SSDs have definitely become a better value, but enterprise-grade SSDs are still pretty pricey (to my pockets, anyway).
18:01 bshum Indeed they are.
18:01 dbwells Plus, you run the danger of losing touch with us normal folk :)
18:04 bshum Meep, meep.
18:07 bshum dbwells: I'll go ahead and file a new bug regarding what I discovered with the MVF upgrade script.
18:07 bshum And that classic reporter issue
18:07 bshum We'll figure out what to do about it sometime before release I guess :\
18:07 dbwells bshum++ # thanks, man
18:08 bshum I'll finish whipping my test Evergreen frontend into shape and then see what things look like tomorrow.
18:31 bshum @later tell berick When you have a chance, curious to get your opinion on this new bug https://bugs.launchpad.net/evergreen/+bug/1287973
18:31 pinesol_green bshum: The operation succeeded.
18:31 pinesol_green Launchpad bug 1287973 in Evergreen "TPAC - CSS for advanced search filters" (affected: 1, heat: 6) [Undecided,New]
18:31 bshum It's a tiny thing, but it irks me enough that I'd like to get to the bottom of it before 2.6 is "done"
18:33 * bshum boggles at what URIs look like now... gah....
18:36 bshum Oh, I see... that's some weird group formats/editions weirdness maybe.
18:39 bshum Internal server errors and timeouts.  Well that's no good.
18:49 bshum Yeah something is wrong.  It goes 70 seconds and then times out whenever I try to click on a bib that seems to be combined with others through the group formats/editions.  Maybe there's something in the enhancements that berick is working on that I should check out.
18:50 eeevil bshum: there definitely is. I plan to merge a squashed, rebased version of that branch tomorrow morning
18:50 bshum eeevil: Ah, cool.  I'll watch for it then.
18:51 bshum And make sure that nobody clicks on that option in advanced search during tomorrow's demos :)
18:51 eeevil :)
18:52 eeevil I'm not certain that what you're seeing is covered, but I am certain that there are bug fixes and that it works on fresh and upgraded test instances 'round here
18:52 eeevil (and that we don't see ... that)
18:52 ericar joined #evergreen
18:52 bshum I have to take a closer look at these icon_format things
18:52 eeevil bshum: I assume you reingested (or, at least the attrs, if not the full records)?
18:53 bshum eeevil: I was just thinking that maybe I need to do some sort of reingest.  It didn't note that in the upgrade actions.
18:54 eeevil the CRA rewrite takes care of converting the SFV data to the new structure, but I'm not sure it gets all the new attrs ATM, and I am sure it doesn't gather all values for MVF-capable attrs
18:55 eeevil (that upgrade set was written to swap ... have not page faulted it back in yet ;) )
18:59 bshum Well I guess I'll let that run for awhile then.
19:02 bshum eeevil: One thing I saw too that I wasn't sure if maybe it's just a quirk for us is that on bibs that seemed to be grouped with electronic resources, the electronic resources links were displayed numerous times over.  I'm not entirely sure if that's just a quirk with our system and how $9's work for us (I don't think we've enabled any other changes yet)
19:03 bshum But also maybe it's a weird template issue for us
19:03 bshum I'm going to try seeing what this should look like stock too.
19:04 eeevil I'm almost positive that that's fixed. lemme check
19:07 eeevil bshum: hrm... actually, I'm thinking of (part of) 169805f
19:07 pinesol_green [evergreen|Mike Rylander] Teach evergreen.located_uris() about the new URI visiblity flag - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=169805f>
19:07 eeevil whoa .... good work pinesol
19:07 bshum Heh
19:07 eeevil (specifically, the SELECT DISTINCT wrapper query)
19:08 bshum That's what I was wondering at first, but I didn't think it'd bubble up the electronic resources in the results like that for the whole consortium if I did a search unless I toggled the setting.... oh I see.
19:08 * bshum looks again
19:08 eeevil well, as far as duplication is concerned...
19:08 eeevil but I might have misunderstood you
19:09 bshum It's alright, I often have trouble with my words.  And this is the first time I've actually had time to try applying these things to a test system.
19:14 eeevil you know ... we might need to add  "AND all_orgs.flag" (and wrap the pair in parens) for the right hand side of the OR in those where clauses. (let me know if you're not following ... I'm not giving a ton of context, I know)
19:14 bshum Oh I'm surely lost.  But maybe that's a consequence of not going home to eat dinner.
19:15 eeevil heh ... poke me tomorrow re evergreen.located_uris() and all_orgs.flag, I'll know what you mean ;)
19:15 eeevil now, go eat, man!
19:15 bshum Yep, wandering.  Thanks for trying on me anyways.  Cheers and good luck till then.
19:28 timf joined #evergreen
22:29 shadowspar joined #evergreen
22:49 jeff_ joined #evergreen
22:50 gmcharlt joined #evergreen
22:51 zerick joined #evergreen
22:52 bradl joined #evergreen
22:53 dbs joined #evergreen
23:31 Guest76924 joined #evergreen

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