Evergreen ILS Website

IRC log for #evergreen, 2014-07-31

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

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

Time Nick Message
01:03 dcook joined #evergreen
05:13 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
05:20 ldw joined #evergreen
07:41 _bott_1 joined #evergreen
07:51 rjackson-isl joined #evergreen
08:02 krvmga joined #evergreen
08:03 krvmga where is the default "stay logged in" time defined for the system (if the patron checks the "Stay logged in" checkbox on the opac login screen)?
08:05 eeevil krvmga: the default is in the opensrf.xml file, in the open-ils.auth section. there are timeouts for staff, opac and temp, IIRC
08:05 krvmga eeevil: thanks :)
08:05 krvmga eeevil++
08:07 krvmga <default_timeout>
08:07 krvmga <!-- default login timeouts based on login type -->
08:07 krvmga <opac>420</opac>
08:07 krvmga <staff>7200</staff>
08:07 krvmga <temp>300</temp>
08:07 krvmga <persist>2 weeks</persist>
08:07 krvmga </default_timeout>
08:08 krvmga from opensrf.xml
08:11 krvmga if i'm reading this right, it says that the opac login time out is 7 minutes, the staff 2 hours, temp (not sure what temp is) 5 minutes, and i'm guessing "persist" is the "Stay logged in" bit.
08:11 krvmga i don't know if it's safe to assume that opac login time out means "7 minutes without activity"?
08:12 krvmga and that the counter gets reset on activity
08:16 eeevil persist is for selfcheck, IIRC
08:17 pinesol_green [evergreen|Bill Erickson] LP#1348731: Optional Auth login nonce to differentiate same-username logins - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=1143fc8>
08:17 pinesol_green [evergreen|Bill Erickson] LP#1348731: have SIP gateway use a login nonce - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=7917dc6>
08:17 eeevil and I believe it is "7 mins without activity"
08:21 akilsdonk joined #evergreen
08:22 krvmga hmmmm, in that case, is persist also used for "Stay logged in"?
08:23 krvmga because i see this
08:23 Dyrcona joined #evergreen
08:23 krvmga <input type="checkbox" name="persist" id="login_persist" /><label for="login_persist"> [% l('Stay logged in?') %]</label>
08:23 krvmga in form.tt2
08:23 krvmga and see the name="persist"
08:24 krvmga so perhaps i just answered my own question?
08:28 Dyrcona I missed the question, so I can't say. ;)
08:30 krvmga Dyrcona: i was trying to find where the default "Stay logged in" time was in the system. eeevil said opensrf.xml. looked there and <persist>2 weeks</persist>
08:31 krvmga eeevil said this was used for self-check stations and i was guessing that it was also used for "Stay logged in".
08:32 krvmga and i noticed in form.tt2 that the checkbox name="persist"
08:32 berick krvmga: yep, it's used there
08:33 krvmga tiny mystery solved then. :)
08:35 eeevil berick++
08:36 krvmga berick++
08:42 mmorgan joined #evergreen
08:45 ericar joined #evergreen
08:47 mrpeters joined #evergreen
08:47 DPearl joined #evergreen
08:50 tspindler joined #evergreen
08:53 Shae joined #evergreen
09:02 tsbere krvmga: I believe "temp" was intended for (and should be usable in) operator change in the staff client. "Temporarily change to this user" ;)
09:02 krvmga tsbere: thanks :)
09:02 krvmga tsbere++
09:18 serflog joined #evergreen
09:18 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org
09:20 pmurray_away joined #evergreen
09:31 yboston joined #evergreen
09:53 eeevil tsbere: you believe rightly. and also for workstation registration, maybe.
09:55 RoganH joined #evergreen
10:02 Dyrcona eeevil: I was on vacation when you posted your fix on lp 1322285 so I'll give it a whirl today.
10:02 pinesol_green Launchpad bug 1322285 in Evergreen "MVF ingest uses default values inappropriately " (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1322285
10:02 Dyrcona eeevil: I assume that it requires a reingest. Would I need to delete anything beforehand?
10:06 eeevil Dyrcona: I'll look...
10:08 eeevil Dyrcona: a delete should not be required, and just an attr reingest (and just for the impacted attrs, if you want to trim it all the way down)
10:08 Dyrcona eeevil: Cool. Thanks!
10:18 edoceo joined #evergreen
10:21 kmlussier joined #evergreen
10:34 Dyrcona eeevil: I pushed a small fix for the upgrade script to your collab branch on that one. I added "IF EXISTS" in the DROP FUNCTION statements.
10:34 Dyrcona eeevil: At least one of those was missing in my development database.
10:35 Dyrcona I haven't had a chance to test the changes, yet.
10:35 eeevil Dyrcona: ahh, cool. otherwise it seems happy?
10:35 eeevil oh
10:35 eeevil :)
10:36 frank____ Hi all, I have a question, Does someone know why when I run the command cat /home/opensrf/recordsBabelExportar30Julio14.txt | ./marc_export -i -c /openils/conf/opensrf_core.xml -e UTF8 -x /openils/conf/fm_IDL.xml -f USMARC --timeout 5 > /home/opensrf/exported_file​s14Julio14SummonUpdate.mrc, it doesnt export the e-books records?
10:37 Dyrcona frank____: What version of Evergreen? marc_export recently had a major rewrite in 2.6.
10:38 frank____ We have the 2.6.0 EG version
10:40 jboyer-isl Hallo, hallo to any CollectionHQ users (outside of Indiana), I would bend your ear if you have a minute. (Re: development of the CHQ extract scripts)
10:41 jboyer-isl development as in, is anyone working on anything currently?
10:42 Dyrcona frank____: The -i option to include item information excludes records without copies. It also fails to add records with located URIs, apparently.
10:43 frank____ Dyrcona: ok, so If I want to import all the marc records I just have to exclude the -i option?
10:44 Dyrcona frank____: Yes, but you will not then get item information in the MARC output.
10:45 Dyrcona I *think* the old marc_export behaved that way, too, but I'm too busy to look it up right now.
10:45 Dyrcona This should probably be fixed. frank____ , could you open a Launchpad bug on it?
10:46 Dyrcona I think -i should at least include records with located URIs.
10:47 jwoodard joined #evergreen
10:47 frank____ Dyrcona: yes, sure
11:01 Dyrcona eeevil: I dumped the lit_form for some records we had a ticket on, and then reingested them, and dumped the lit_forms again. I don't see any difference.
11:01 Dyrcona eeevil: These are records showing up both as fiction and nonfiction.
11:13 Dyrcona Hmm. Looks like my run of metabib.reingest_record_attributes did nothing.
11:20 Dyrcona Dunno if that is because of the code I just loaded or something else.
11:23 Dyrcona It happens in training, too, so it is not the code from eeevil's branch.
11:23 Dyrcona I hesitate to test in production, but that is closer to 2.6.0.
11:30 eeevil Dyrcona: ah, so the reingest didn't actually happen?
11:30 eeevil (just making sure I understand)
11:34 Dyrcona eeevil: That's what it looks like.
11:34 Dyrcona I'm digging to see if I missed something.
11:36 eeevil Dyrcona: maybe a force-on-same=enabled full reingest of a specific set of records (n=1 is enough, probably) to make sure reingest didn't break with my code?
11:36 Dyrcona Hmm... It didn't like my arguments, apparently.
11:36 Dyrcona eeevil: I did it with just the id and it worked.
11:37 Dyrcona I guess it didn't like pattr_list or something.
11:38 Dyrcona Anyway, now that I have the reingest happening. Nothing appears to have changed.
11:38 Dyrcona My fiction record with only an 008 is still showing up as both fiction and non-fiction.
11:45 eeevil Dyrcona: I'll try to look later, but I'm about to become a pumpkin for the rest of the day
11:46 Dyrcona eeevil: np, so am I.
11:46 eeevil thanks for giving it a first poke!
11:46 Dyrcona I figured out why the reingest didn't work after the deletion.
11:46 Dyrcona I needed true in the final argument.
11:59 Dyrcona Heh. "You keep passing that argument. I don't think it does what you think it does."
11:59 frank____ Dyrcona: https://bugs.launchpad.net/evergreen/+bug/1350916
11:59 pinesol_green Launchpad bug 1350916 in Evergreen "Use -i in marc_export exclude records with located URIs.should at least include records with located URIs" (affected: 1, heat: 6) [Undecided,New]
12:01 Dyrcona frank____: Thanks.
12:01 bshum I'm not sure I'd agree with that.  If I pass an argument for -i for item holdings, I'd rather it did not include URI bibs
12:02 bshum I mean, they really don't have copies associated with them.  So to me, they should be skipped.
12:04 frank____ bshum: how should I get the records with related
12:04 frank____ sorry, with located uris
12:04 bshum If it was me
12:04 bshum I would identify those bibs separately in another file to be exported
12:04 bshum And run it without the -i flag
12:05 bshum But that's just one opinion.  I could do the same on my end and skip over URI bibs when I specify specific bibs to be exported with -i and then I'd avoid having them accidentally included in my batches.
12:06 bshum It's just different viewpoints
12:06 dbwells I believe the thinking is that -i should affect the contents of the records, not the selectivity of the set.  There are lots of other means to change the set of records being exported.
12:07 tsbere bshum: If I hand the exporter a list of records I expect to get that list of records, items or not. ;)
12:07 bshum Well, then I'll keep my disagreement to myself then :)
12:12 Dyrcona One thing I was thinking of is -i should just delete the record whether it has copies, URIs, or not.
12:12 Dyrcona Heh. See if anyone notices.
12:13 dkyle joined #evergreen
12:13 bshum Heh
12:14 dbs -i, --incinerate
12:16 Dyrcona Anyway, too much messing in the database this morning.
12:26 * Dyrcona disappears in a puff of smoke.
12:42 ericar joined #evergreen
13:10 hbrennan joined #evergreen
13:10 berickm joined #evergreen
13:16 kmlussier joined #evergreen
13:24 kmlussier Just sending along my daily reminder to fill out the Doodle poll for bug squashing day. http://doodle.com/6ush6hyx9pa39pv3
13:25 jeff @later tell Dyrcona For CollectionHQ, we're using the method in the ESI contrib git repo -- see the collectionHQ directory.
13:25 pinesol_green jeff: The operation succeeded.
13:30 kmlussier Ugh! And I am just now noticing that I put July dates in that poll instead of August. No wonder nobody filled out the first three options.
13:32 jeff hah
13:32 jeff oops

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