Evergreen ILS Website

IRC log for #evergreen, 2014-01-13

| 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
01:34 b_bonner joined #evergreen
01:35 mtcarlson_away joined #evergreen
01:50 linuxhiker joined #evergreen
01:51 b_bonner joined #evergreen
01:51 mtcarlson_away joined #evergreen
02:33 DPearl joined #evergreen
07:44 rjackson-isl joined #evergreen
08:08 cjohnson joined #evergreen
08:16 cjohnson left #evergreen
08:18 cjohnson joined #evergreen
08:29 collum joined #evergreen
08:32 akilsdonk joined #evergreen
08:39 timf joined #evergreen
08:47 mmorgan1 joined #evergreen
08:47 mmorgan1 left #evergreen
08:47 mmorgan joined #evergreen
08:56 rfrasur joined #evergreen
08:58 ericar joined #evergreen
09:03 bshum @coin
09:03 pinesol_green bshum: tails
09:03 bshum kmlussier: --^
09:04 csharp @developer
09:04 pinesol_green csharp: Communication:10, BigPicture:11, DetailOriented:16, KungFu:14, GetsStuffDone:7, FlakeFactor:13, JavaAvoidance:10
09:04 kmlussier bshum: You need to give me some forewarning next time so I know what heads and tails are.
09:04 kmlussier @librarian
09:04 pinesol_green kmlussier: Management:10, Cataloging:12, Acquisitions:14, Reference:11, Circulation:16, Systems:15, Research:6, Custodial:9
09:04 csharp heads I win, tails you lose
09:05 bshum kmlussier: I was merely showing you how to approach decisions involving two paths.
09:05 csharp @roulette
09:05 pinesol_green *BANG* Hey, who put a blank in here?!
09:05 * pinesol_green reloads and spins the chambers.
09:05 bshum :)
09:05 jboyer-isl Sigh. Has anyone seen this on a 2.5 release:  open-ils.storage.action.ho​ld_request.copy_targeter: Use of uninitialized value $min_prox in anonymous hash ({}) at /usr/local/share/perl/5.14.2/OpenILS/A​pplication/Storage/Publisher/action.pm line 1641.
09:05 bshum Yes, ignore it.
09:06 jboyer-isl That line is deep into the new_hold_targter
09:06 csharp jboyer-isl: yes - I've seen that on our 2.5.1 test server
09:06 jboyer-isl sub
09:06 jboyer-isl For every single hold processed?
09:06 csharp bshum: is there a bug on it?
09:06 jboyer-isl I was really looking forward to moving to 2.5 because I thought there would be so many fewer worthless errors. :(
09:06 csharp jboyer-isl: have you run 'autogen.sh -u' on your utility (holds targeter) server?
09:07 bshum csharp: I think dbs might have worked on quieting down some of those (there used to be LOTS more noise) but I'm not sure where we are today.
09:07 jboyer-isl I doubt it. I'm not the one that set it up.
09:07 * csharp looks forward to a day when autogen.sh is no longer necessary for anything
09:07 rfrasur kmlussier: I received our invoice today.  ty
09:08 bshum It has something to do with all those new custom hold targeting stuff not being fully fleshed out of box. I think.
09:08 jboyer-isl csharp: I have no idea why it (and apache?!) are necessary on a utility server. I hear we're running the same setup, essentially, do you know why off hand?
09:08 bshum But generally it's just noise.
09:08 kmlussier rfrasur: yw. I'm happy to invoice you anytime you want.
09:08 kmlussier Next time, you can just make the check out to kmlussier.
09:08 csharp jboyer-isl: apache is strictly not necessary - just part of the standard stack
09:09 csharp s/strictly not/not strictly/
09:09 rfrasur kmlussier: I figured ;)
09:09 jboyer-isl From my POV, it's it
09:09 jboyer-isl 's not necessary, then it IS "strictly not" ;)
09:09 csharp jboyer-isl: autogen -u refreshes the OU proximity table
09:10 csharp it is otherwise not necessary at all as far as I know
09:10 * csharp defers to berick or eeevil for details ;-)
09:10 jboyer-isl csharp: I knew it did something like that, but I thought it's output was just for the brick heads. I should read more about it probably.
09:11 csharp jboyer-isl: it definitely doesn't conform to the "one program/one purpose" ideal of UNIX servers ;-)
09:15 berick we keep getting closer and closer to no longer needing autogen
09:15 csharp it seems to me that the proximity table refresh could be transformed into a DB trigger that fires each time you add/change an OU
09:15 csharp berick++
09:17 berick we could probably kill it in a hackaway if there was concerted effort
09:18 * csharp would totally participate in that
09:31 tsbere joined #evergreen
09:40 afterl joined #evergreen
09:51 dbs @dice 1d2
09:51 pinesol_green dbs: Error: Dice can't have fewer than 3 sides.
09:51 dbs So much for flipping a coin
09:55 * berick pats self on back for completing an #action item
09:56 dbs Hey, who wants to respond to sec.measure@apple.ca's message to open-ils-feedback "to confrim[sic] your Billing Information records."? We certainly don't want to lose our Apple account.
09:56 yboston joined #evergreen
09:58 rfrasur Somebody can teach pinesol_green to play ddakji.  It'd work as a two sided dice.
09:59 berick @eightball is a two-sided dice the same as a coin?
09:59 pinesol_green berick: It is so.
10:00 rfrasur It is.
10:04 * tsbere has an XDM D2, which is in fact a coin, but has been told that a coin flip and a die roll work too differently and that D2 should thus be done more as a "even vs odd on a D6" to avoid bias in how the coin started >_>
10:05 jcamins tsbere: you can also use a 4-sided dice.
10:05 jcamins *die
10:06 tsbere Interestingly, the set we were using at the time had no D4. Probably why I was told to use a D6 and go Even/Odd instead.
10:06 bradl some conversations only happen in #evergreen
10:08 * berick notes that flipping a cat has similar landing-side biases
10:08 * rfrasur should note that googling Korean words that you know phonetically but not the exact spelling can lead to interesting results.
10:08 rfrasur berick++
10:09 dbs berick: depends on the state of the cat
10:09 dbs badly decomposed cat may land heads-up _and_ tails-up
10:10 rfrasur ew
10:10 rfrasur funny but ew
10:10 csharp dbs: I would reply to sec.measure, but I'm too busy entering my credit card information for this 2.5 Million British  Pounds that we won from their e-mail drawing
10:10 * dbs apologizes, but he has been working with latex for the first time ever for the past weekend and is feeling punchy
10:10 berick dbs: of course!  the only coin that lands on both sides
10:11 jeff dbs: you're supposed to work in a well-ventilated area when dealing with that stuff!
10:11 dbs s/working with latex/& directly/
10:11 rfrasur (all the jokes and none of the appropriate)
10:11 dbs jeff++
10:11 dbs rfrasur++
10:12 csharp I read the LaTeX site after your post on G+, dbs, and was interested to learn that it's supposed to be pronounced "Lay-Tech", not "lay-tex"
10:12 jcamins dbs: how have you avoided LaTeX?
10:13 csharp I then rolled my eyes at F/LOSS product naming weirdness (e.g. "Gah-NU")
10:13 rfrasur csharp++
10:14 jcamins dbs: until now, of course.
10:14 kbeswick joined #evergreen
10:14 * csharp adds notes to evergreen-ils.org on pronunciation "effergruhn-illls"
10:14 dbs jcamins: never submitted a paper to a math/science/engineering conference before
10:14 jeff csharp: little-known-fact: the preferred pronunciation of Evergreen is .. nevermind, you beat me to it.
10:14 csharp hah
10:15 * rfrasur chuckles
10:15 jeff you are likely to be eaten by an ever gruhn.
10:15 csharp we need an umlaut over one of the e's
10:15 dbs jumped from LaTeX-like markup on the commodore 64 to WordPerfect w/ reveal codes to straight-up WYSWIWYG stuff, then back to SGML/XML things like DocBook, then abstracted out to AsciiDoc, now working closer to the source
10:16 dbs circle of doc life
10:17 csharp @quote add < dbs> jumped from LaTeX-like markup on the commodore 64 to WordPerfect w/ reveal codes to straight-up WYSWIWYG stuff, then back to SGML/XML things like DocBook, then abstracted out to AsciiDoc, now working closer to the source - circle of doc life
10:17 pinesol_green csharp: The operation succeeded.  Quote #73 added.
10:18 * rfrasur now has lion king music playing in internal playlist
10:20 Dyrcona joined #evergreen
10:24 * Dyrcona is having a sick day but signed in to chat with bshum if he is paying attention and has some time.
10:25 bshum Dyrcona: Paying attention?  Sure.....
10:33 rfrasur yboston: can you link me to the agenda from the last DIG meeting?
10:35 yboston Here is the agenda for last week's meeting, it was updated by remingtron http://evergreen-ils.org/dokuwiki/doku.php?i​d=evergreen-docs:dig_meeting_20140109-agenda
10:35 rfrasur thanks
10:56 mcooper joined #evergreen
11:20 dMiller__ joined #evergreen
11:45 gsams joined #evergreen
11:57 csharp @quote random
11:57 pinesol_green csharp: Quote #43: "commit 4755baac: There's tears in my coffee. These are not tears of joy." (added by gmcharlt at 05:36 PM, January 25, 2013)
11:58 afterl1 joined #evergreen
12:00 afterl2 joined #evergreen
12:02 mcooper joined #evergreen
12:20 csharp @dunno
12:20 pinesol_green csharp: Beyond here be dragons.
12:26 mrpeters joined #evergreen
12:33 smyers joined #evergreen
12:37 csharp so if you wake up on a Monday and think "Hey, I think I'll run all my monthly reports concurrently right now", resist that urge.
12:38 csharp we have someone who just fired off like 6 concurrent item list reports and my aNag app is a buzzin'
12:42 jeff closest i can come is that we did do a big mass-update of items several months back. the first Tuesday after the batch update, some scheduled reports exhausted memory on the jasperreports server's java vm while generating the PDF reports with barcodes to be e-mailed.
12:43 gsams I suppose I'm lucky that our server seems to be very capable of handling our small groups reporting needs.
12:44 csharp we have a dedicated server to run clark and two RO databases connected via pgpool
12:45 csharp I may need to tweak the load balancing since our beefier DB server seems to get nearly all the queries
12:45 csharp jeff: I can totally see that happening for PINES
12:46 gsams ah, we are small enough to operate on a single server here.  Though i do dream of upgrades...
12:46 gsams eventually it will happen for us, we are attracting the attention of larger libraries.
12:49 csharp gsams++
13:10 kmlussier gsams++ indeed
13:11 sseng_ when doing a "Browse the Catalog" search, what is the significance of a result being bolded? for example, when doing a Titles starging with "concerto", the fifth result down (out of 10) is bolded, and uncertain of what that implies. thanks!
13:13 kmlussier sseng: That's where you landed alphabetically in the list.
13:14 kmlussier Or, I should say, where your search terms landed alphabetically in the list.
13:14 sseng kmlussier: ah ok, got it, that makes sense, thanks!
13:25 Sato`kun joined #evergreen
13:25 kbeswick joined #evergreen
14:00 rfrasur (adobe digital editions deserve all the hate they receive)
14:00 dbs More hate, actually
14:00 rfrasur true, but I'm trying to be nice.
14:01 * rfrasur has to reprimand an employee later so am doing attitude moderation.
14:03 keynote2k joined #evergreen
14:13 gsams Anyone out there move a lot of new books from one shelving location to another regularly?
14:15 rfrasur not recently...but in the past, yes.
14:16 dbs gsams: from time to time
14:16 gsams rfrasur: We have a library joining soon that moves approximately 1500+ items a month from new to regular shelving.
14:16 * dbs warms up http://git.evergreen-ils.org/?p=con​trib/Conifer.git;a=shortlog;h=refs/​heads/feature/move_to_storage_2_4 in preparation
14:17 gsams I'm not sure about the time it takes to make that transition, I was hoping someone had an idea
14:17 rfrasur We move about 200 or so in that same time period.
14:17 rfrasur I guess it depends on their workflow.
14:17 rfrasur And the number of employees doing it.
14:17 dbs gsams: ^ implements a web page where staff can log in, browse to the page in question (like "Move to Storage"), and then scan barcode after barcode and have it update the location for each item
14:17 rfrasur dbs: that's a great idea.
14:17 Dyrcona gsams: Are you concerned more about the time it takes to physically move the copies or the Evergreen database implications?
14:18 rfrasur good point, Dyrcona.
14:18 dbs rfrasur: yeah, it helps track that the items actually moved there
14:18 gsams It was the time it takes to go through the process of updating it in Evergreen.
14:18 Dyrcona We usually handle the database side of things using collection-based stat cats on the copies.
14:19 Dyrcona Our libraires will tell us to put summer reading in storage for instance.
14:19 rfrasur gsams, I think dbs' solution would work better for that many items.
14:19 dbs a direct UPDATE clause is easy enough if it's a whole collection at once
14:19 Dyrcona We run a SQL to make the change and note the changed copies in a custom table: mvlc.changed_copies or some such.
14:20 Dyrcona The extra table makes it easy to undo later.
14:20 gsams dbs: that solution of yours seems the best option, and one that would probably work best for them.  I have no idea how to implement it though.
14:21 Dyrcona It could also be done by scanning the copies into item status and transferring them to a bucket. (I think that is possible.)
14:21 gsams I usually work in small enough amounts that I can make the changes in Item Status
14:22 dbs gsams: way I did it is just a couple of files - one template, and one JS file - for each "Move to" location. lots of copy-paste there
14:22 Dyrcona The bucket would be handy so staff can choose the records and then tell you to do the copies in bucket X.
14:23 csharp backup_tables++
14:23 csharp I forgot to do that once and that was the time I needed to have done it
14:24 csharp fortunately we had a backup that allowed me to undo it :-/
14:24 dbs gsams: if you look at http://git.evergreen-ils.org/?p=cont​rib/Conifer.git;a=commitdiff;h=a6b0e​35e3ce30557c91685d5dafcae6840f3705c then the pertinent bits to change are the strings and the copy.location(), volume.owning_lib(), and copy.circ_lib() calls
14:25 dbs And then you just pop open hostname/eg/cat/moveto/lal_circ (or whatever you called it) in a web browser, log in, and scan away
14:25 bshum dbs: That's pretty neat.
14:25 csharp dbs++
14:25 gsams dbs++
14:26 dbs the owning_lib / circ_lib calls were only because we were moving items to a different library entirely in that case
14:26 gsams that might be doable for me.  I'll have to play around with it a bit I think
14:26 csharp that's definitely something I would have been able to make use of recently
14:26 jeff Another option that we use (in a slightly different scenario) where every item is going in or out of "storage" is to have everything (such as Holiday Music) in a distinct location, and toggling the attributes (holdable, opac visible) and name on the location.
14:26 * dbs has mentioned this a few times in mailing list contexts, but never really explained it so clearly
14:26 jeff dbs++
14:27 bshum jeff: That's kind of what I was thinking too.  Most times people say, we want X new location and then we want to move everything into that new location... and I just go change up the label.
14:27 dbs hah, there is that approach too :)
14:27 bshum Sometimes people are too literal.
14:28 csharp yeah - that's our preferred approach too
14:28 csharp however, I had a great use case for dbs's interface here
14:28 dbs In our case we've done it for big weeding projects (both "move into storage" and "delete!") and also "move subset of stuff into new library", so the hands-on is desired
14:29 csharp one of our libs was remodeling and needed to temporarily move *some* of each collection into cold storage
14:31 gsams The library in question is currently on III and was trying to estimate the impact on their workflow
14:31 gsams dbs++
14:31 gsams Dyrcona++
14:31 Dyrcona gsams: Anyone moving from one system to another should be prepared to change their workflow.
14:32 gsams oh yes, the director is familiar with Evergreen already, but it was in a smaller library context.
14:32 gsams She is doing the work well ahead of schedule thankfully
14:47 csharp so is a system usable while the reingest step is running? or is it better to wait until that's done to reconnect clients to the DB?
14:48 csharp I have plenty of time for it (especially using pingest.pl from Dyrcona) in my window this weekend
14:48 csharp just wanted to know what others have done
14:49 Dyrcona csharp: It is usable, but I usually start the ingest when things are quieter, such as night time when lbraries are closed.
14:49 Bmagic joined #evergreen
14:49 csharp well the system is completely down as far as our libraries are concerned
14:50 Bmagic Where does the staff client get the dropdown list of "depth" in the user permissions UI?
14:50 csharp I'm just trying to figure out when we should start plugging things back in and doing full out testing
14:50 bshum My understanding is that while reingests happen, you can search or whatever, but your results will vary significantly depending on which bibs have or haven't been ingested yet.
14:51 csharp Bmagic: config.org_unit_type? (not looking - that's from memory)
14:51 csharp org_type, maybe
14:51 csharp bshum: okay -that's good to know
14:51 bshum It's probably actor.org_unit_type
14:51 csharp Bmagic: yeah bshum's right - it's actor.org_unit_type
14:52 Bmagic csharp: That is what I thought, does the staff client cache that somehow, It's showing stuff that is not in the database (we recently deleted them)
14:52 bshum csharp: I've left my system running before while reingests happened.  But I'm like Dyrcona and tend to stick to off hours.
14:52 bshum csharp: The other thing I tend to do is vacuum my tables after reingests
14:52 csharp yeah - I'll be doing that too
14:53 bshum Since there's churn in the metabib tables and I like to keep things tidy.  The vacuum lock does kill things, depending on the type of vacuum you pick.
14:53 bshum So for that reason I tend not to turn on Evergreen till after I finish all my tasks.
14:53 csharp yeah, I'm moving to GIN indexes for the metabib tables too, so it sounds like vacuum becomes way more important with those
14:54 csharp that makes sense, I'm just trying to figure out if we can keep moving or if we just need to sit around for the 20+ hours our reingest will take
14:55 csharp + VACUUM ANALYZE
14:55 csharp well, it may be a shorter time - the hardware I'm testing on is about 1/4 the power of our production hardware
14:57 rfrasur (the sign that you've become a real manager/administrator is when you can tell an employee that you have no desire to fire them though they might technically deserve it, tell them that you've been grooming them for a full-time position, make them cry and NOT cry yourself)
15:22 jeff SIP2 is not a suitable means for vendors to validate patrons. :P
15:22 jeff (despite this, many vendors like to use it)
15:23 Dyrcona SIP2 is not a suitable means for anything.
15:24 _bott_ Dyrcona++
15:24 _bott_ that needs to be stored as a quote
15:27 jeff I'm not comfortable with any scenario which involves an electronic resources vendor requesting and storing patron passwords. :P
15:30 Dyrcona jeff: I'll wager that your patrons are not as bothered about it as you are.
15:30 jeff I'm sure.
15:31 jeff "we wanted you to be able to access $content, so we gave this company access to your checkouts, holds, home address, phone number, and... well, pretty much we gave them access to everything that we give you access to."
15:31 * jeff growls
15:32 jboyer-isl jeff: You never told us you work at Facebook! ;)
15:33 jeff "But don't worry -- in theory, they'll never actually pay attention to that data we're sending them, and this is "not an issue with their 100+ partners thus far"
15:33 jeff oops. messed up my quoting there. you get the point.
15:33 jeff anyway. ranting to clear my head before attempting an alternative approach.
15:34 jeff sorry to subject y'all to it. :-)
15:35 csharp @quote add < Dyrcona> SIP2 is not a suitable means for anything.
15:35 pinesol_green csharp: The operation succeeded.  Quote #74 added.
15:36 csharp jeff++
15:36 jeffdavis jeff: do your contracts with vendors using SIP include language about patron privacy/protection of personal info?
15:36 csharp @quote search sip2
15:36 pinesol_green csharp: 1 found: #74: "< Dyrcona> SIP2 is not a suitable means for..."
15:37 Dyrcona @quote search marc
15:37 pinesol_green Dyrcona: 3 found: #38: "<jcamins> At least your MARC frameworks aren't...", #46: "<_bott_> Try restarting apache. not a...", and #52: "<dbs> MARC is not machine readable."
15:37 csharp in our case all the SIP vendor agreements are between the individual libraries and the vendor
15:37 jeff jeffdavis: currently we do not use SIP2 for vendor authentication. I'll know more about contracts if we ever do start using SIP2 with a vendor... which (*growl*, again) is likely soon.
15:38 Dyrcona @quote get 46
15:38 pinesol_green Dyrcona: Quote #46: "<_bott_> Try restarting apache. not a cataloger, but I speak enough MARC to be fun at parties" (added by gmcharlt at 11:43 AM, March 15, 2013)
15:38 csharp _bott_++
15:39 _bott_ Not sure where that "Try restarting apache." came from.  The original started "I am not a cataloger..."
15:40 Dyrcona @quote get 45
15:40 pinesol_green Dyrcona: Quote #45: "<senator> this isn't twitter, @jeff doesn't mean what you think it means" (added by bshum at 11:40 AM, March 05, 2013)
15:41 Dyrcona Uh-oh.
15:41 bshum joined #evergreen
15:41 kmlussier joined #evergreen
15:41 mceraso joined #evergreen
15:41 _bott_ Are the quotes stored in MARC?
15:42 csharp that would definitely explain it ;-)
15:42 gmcharlt yes.  *somebody* has to use the MARC Format for Community Information!
15:42 rfrasur @hate MARC
15:42 pinesol_green rfrasur: But rfrasur already hates MARC!
15:42 rfrasur yes, yes I do
15:43 Dyrcona gmcharlt: We used to on Horizon, but no one was maintaining the database, so the committee (naturally there was a committee) voted to drop the records because Google.
15:44 Dyrcona This was 7 or 8 years ago.
15:45 Dyrcona Leave it to me to respond to a humorous line with an earnest answer. :)
15:45 gmcharlt there is probably a joke somewhere concerning death dates in authority records that are applied to CI records
15:47 _bott_ I fear that MARC was a humorous suggestion that someone took seriously.
15:48 gmcharlt _bott_: well, I'm not quite sure about the feasibility of Linked Data or XML-based metadata formats in the 1960s... ;)
15:48 rfrasur No, I think that it's something that very serious people took very seriously.  That's why very serious people should always be balanced by not so serious people.
15:50 csharp @quote add < _bott_> I fear that MARC was a humorous suggestion that someone took seriously.
15:50 pinesol_green csharp: The operation succeeded.  Quote #75 added.
15:50 csharp and now we have 4 MARC quotes
15:53 bshum joined #evergreen
15:53 kmlussier joined #evergreen
15:53 mceraso joined #evergreen
15:53 csharp @quote get 46
15:53 pinesol_green csharp: Quote #46: "<_bott_> I am not a cataloger, but I speak enough MARC to be fun at parties" (added by gmcharlt at 11:43 AM, March 15, 2013)
15:53 csharp repaired!
15:54 _bott_ csharp++
15:54 _bott_ I know I'll sleep better tonight
15:54 rfrasur I'm glad MARC isn't sentient.
15:55 * rfrasur would feel kinda bad.
16:01 Dyrcona MARC is great for transmitting data on tape that will be printed onto card stock, not much use for anything else.
16:01 dbs @quote search MARC
16:01 pinesol_green dbs: 4 found: #38: "<jcamins> At least your MARC frameworks aren't...", #46: "<_bott_> I am not a cataloger, but I speak...", #52: "<dbs> MARC is not machine readable.", and #75: "< _bott_> I fear that MARC was a humorous..."
16:03 rfrasur ooo, Dyrcona.  That sounds like it'd be a great way to catalog our materials.  I can see it now.  The coolest wooden cabinets with cute little draws that you can pull out and set right on a table.  It'd be like browsing the shelves, but you could sit down.  You could have different ones, too.  Subject catalogs and title catalogs...and author.  Just imagine the possibilities.
16:03 dbs Hipster-driven discovery systems
16:03 Dyrcona rfrasur: :p
16:04 rfrasur No, dbs.  If it's in library land.  It must be HDDS, and you must never ever actually explain what the acronym stands for until a person reaches the 33rd level of the lodge.
16:04 rfrasur I mean, library.
16:05 Dyrcona What is this, Scientology?
16:05 * Dyrcona didn't know he was joining a cult.
16:05 rfrasur Library Scientology
16:06 _bott_ Bibliotology?
16:06 rfrasur Dyrcona, nobody ever knows til they start passing out the koolaid.
16:08 rfrasur btw, I'm flying on Southwest to the conference.  Am wondering if designated airports might just be suggestions now.
16:13 bshum joined #evergreen
16:13 kmlussier joined #evergreen
16:13 mceraso joined #evergreen
16:23 gsams dbs: I am playing with the shelving location changer at the moment, and I believe I have the proper changes in place but it keeps prompting me to login and not making any changes.
16:34 stevenyvr2 joined #evergreen
16:35 stevenyvr joined #evergreen
16:36 stevenyvr2 left #evergreen
16:39 dbs gsams: so you can log in, and it prompts you when you enter a barcode?
16:41 gsams dbs: I log in, scan a barcode, and it prompts me to log in again.  I've tried a few different users.
16:41 Dyrcona gsams: Cookies enabled in your browser?
16:42 dbs gsams: https://?
16:42 * Dyrcona is just guessing.
16:42 dbs gsams: and also, if you changed the name of the lal_circ.tt2 file you'll need to change the <form method="get" action="/eg/cat/moveto/lal_circ"> line in the tt2 file
16:43 dbs Dyrcona could be right
16:43 dbs Also, those users will need cataloguer-type permissions
16:45 gsams I'm showing cookies as enabled, and I see 2 for that site in particular
16:46 dbs gsams: https:// ?
16:46 dbs that is, https://hostname/eg/cat/moveto/blah rather than http://hostname/...
16:47 gsams that was it
16:47 gsams works as intended, wasn't paying attention
16:48 gsams dbs++
16:48 gsams Dyrcona++
16:48 dbs heh, I didn't mention that bit in my overview before :)
17:10 mmorgan left #evergreen
17:33 dcook joined #evergreen
17:53 mcooper joined #evergreen
19:48 Dyrcona @quote random
19:48 pinesol_green Dyrcona: Quote #58: "<groucho> Outside of a dog, a book is man's best friend. Inside of a dog, it is too dark to read." (added by Dyrcona at 11:31 AM, June 15, 2013)
20:18 afterl2 left #evergreen
23:25 stevenyvr2 joined #evergreen
23:25 stevenyvr2 left #evergreen
23:38 kmlussier @coin
23:38 pinesol_green kmlussier: tails

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