2011-12-12T03:52:47 *** idm has joined #evergreen 2011-12-12T08:08:00 *** idm has quit IRC 2011-12-12T08:12:11 *** Dyrcona has joined #evergreen 2011-12-12T08:24:54 *** plux has joined #evergreen 2011-12-12T08:26:04 *** csharp changes topic to "Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://pastebin.ca or http://paste.lisp.org/new/evergreen or something like that" 2011-12-12T08:26:16 maxfly-- 2011-12-12T08:32:20 *** kmlussier has joined #evergreen 2011-12-12T08:33:15 *** AaronZ-PLS has joined #evergreen 2011-12-12T08:43:33 *** AaronZ-PLS has quit IRC 2011-12-12T08:52:28 *** AaronZ-PLS has joined #evergreen 2011-12-12T09:04:46 *** gdunbar has joined #evergreen 2011-12-12T09:09:54 *** Meliss has joined #evergreen 2011-12-12T09:11:28 *** _bott_ has quit IRC 2011-12-12T09:12:31 *** _bott_ has joined #evergreen 2011-12-12T09:14:43 *** StephenGWills has joined #evergreen 2011-12-12T09:15:01 *** berick_ is now known as berick 2011-12-12T09:25:05 *** bwicksall has joined #evergreen 2011-12-12T09:29:17 berick: On 898248 I have one potentially significant concern on the SQL: Why are you lowercasing the regular expressions? 2011-12-12T09:34:38 tsbere: my thought was most people will not use the address fields like regular expressions. they'll simply enter some text and assume case is not relevant 2011-12-12T09:34:54 berick: Then why not use ~* instead of ~? 2011-12-12T09:35:07 because I didn't know about ~* 2011-12-12T09:35:09 :) 2011-12-12T09:36:15 <-- sql tourist 2011-12-12T09:36:53 *** dbs has joined #evergreen 2011-12-12T09:36:53 *** dbs has joined #evergreen 2011-12-12T09:37:37 berick: My main concern is things like \D, \S, and \W that mean "not digit", "not space", and "not alphanumeric or whitespace". The opposite meanings of \d, \s, and \w 2011-12-12T09:38:45 tsbere: ah, yes, good catch 2011-12-12T09:38:49 i didn't consider those 2011-12-12T09:39:15 so, ~* handles those gracefully? 2011-12-12T09:39:42 ~* is "case insensitive regex match". The equivelent of starting the regex with (?i) to turn on the i flag, I believe. 2011-12-12T09:39:53 excellent 2011-12-12T09:40:46 * berick can make that change 2011-12-12T09:41:19 berick: Maybe we should document that if you *want* case sensitivity for a field you can use (?c) at the beginning of the regex? 2011-12-12T09:42:37 I agree 2011-12-12T09:43:19 sure 2011-12-12T09:43:48 use ~, prepend (?i), and document (?c) (which will follow, and "turn off", (?i)) to turn on case sensitivity 2011-12-12T09:44:41 cool, make sense 2011-12-12T09:44:44 ~ you need to (?i) to make it case-insensitive. ~* you need (?c) to make it case-sensitive. I think defaulting to case insensitive is the better choice. 2011-12-12T09:44:45 *makes 2011-12-12T09:45:21 If you force a (?i) on the front of a (?c) then the (?c) is considered *part* of the regex, and not a flag setter, I believe. 2011-12-12T09:45:29 *** tspindler has joined #evergreen 2011-12-12T09:45:39 tsbere: have you tested ~* with (?c)? (I have not) 2011-12-12T09:45:55 eeevil: I am reading the......8.3! docs describing it. 2011-12-12T09:46:03 * tsbere can test though, has a SQL window open 2011-12-12T09:46:46 eeevil: Quick test says ~* with a regex starting with (?c) is case sensitive 2011-12-12T09:48:23 righto, sounds good 2011-12-12T09:49:05 so, back to tsbere's proposal ... ~*, document (?c) (or offer a check box to prepend that) 2011-12-12T09:50:01 eeevil: Also, a regex starting with (?c)(?i) or (?i)(?c) throws an error ;) 2011-12-12T09:50:15 well, that's lame 2011-12-12T09:50:33 * tsbere would be tempted to document (?c) specifically, and then point at the postgres docs for more information 2011-12-12T09:52:45 eeevil: (?ci) works (insensitive) as does (?ic) (sensitive) though ;) 2011-12-12T09:55:42 Hmmm. Should we document the "exact match" ***= prefix too? 2011-12-12T09:56:13 (which does not support anchors....hmmm) 2011-12-12T09:56:53 Or changing case sensitivity. Lets not document that one. 2011-12-12T10:16:36 *** granitize has joined #evergreen 2011-12-12T10:16:47 *** granitize has left #evergreen 2011-12-12T10:22:39 Hmm. Wonders if Fieldmapper::new_from_struct is a good name for a factory function, or if it should be named something else. 2011-12-12T10:23:43 *** kmlussier has quit IRC 2011-12-12T10:26:27 * dbs wonders what the protocol is for branches that you know are going to end up conflicting with one another because they're both playing in the same area of origin/master 2011-12-12T10:27:52 dbs: One option may be to create a "joint" branch that includes both, so that the reviewer could (in theory) look at both at the same time and push it all at once? 2011-12-12T10:28:00 I'm trying to keep my TPAC bugs relatively granular so that there's a low cognitive bar for review / testing in hope of a correspondingly faster integration time 2011-12-12T10:28:31 Dyrcona: eh? like, pass in a hash, get back a FM object? there should be something like that already 2011-12-12T10:32:26 tsbere: Yes, I guess. As a potential reviewer, would you prefer to see entangled branches like that or to review each branch on its own merits? 2011-12-12T10:50:54 * dbs could end up building lots of integration branches to support a variety of combinations, should reviewers take issue with one of the bugs 2011-12-12T10:53:16 *** collum has joined #evergreen 2011-12-12T11:00:57 dbs: I am not sure (was in a meeting) but if you know they are going to conflict a note about how to manually correct for that might not be a bad thing. Rather than waiting for you to fix up the conflicting branches after a merge. 2011-12-12T11:01:32 tsbere: I guess. But I can't predict what order people are going to look at things 2011-12-12T11:02:01 * dbs would rather have some branches integrated quickly than lots lingering around 2011-12-12T11:02:05 Dyrcona: hrm... seems I'm wrong. of course, I see why not ... it's trivial: my $obj = $class->new; map { $obj->$_($hash{$_}) } $obj->properties; 2011-12-12T11:07:27 dbs: I agree on the quickly front. >_> 2011-12-12T11:11:45 tsbere: aye, you're the posterboy for having lots of branches waiting for review & sign-off 2011-12-12T11:16:07 Bugs currently targeted for 2.2.0-alpha2 awaiting review & sign-off: http://ur1.ca/6mnoc 2011-12-12T11:16:20 tsbere: I guess you're not targeting your bugs? 2011-12-12T11:16:57 dbs: I have notes about "remember to target bug fixes". I don't bother with features, though. >_> 2011-12-12T11:17:24 * tsbere tends to ignore the notes even for bug fixes, though 2011-12-12T11:17:58 Okay, I guess the risk is that untargeted bugs might get ignored, depending on what query one uses. Of course, they might get ignored anyway 2011-12-12T11:18:00 I am not sure how qualified I am to decide what to target something for, as I don't currently do *anything* from a "released version" ;) 2011-12-12T11:20:06 *** wolf29 has joined #evergreen 2011-12-12T11:20:49 heh 2011-12-12T11:23:21 Is anybody testing on Debian-SID yet? 2011-12-12T11:23:23 dbs: A note on 878264: I avoid reviewing bugs that are assigned to someone else. Though I suspect that one has been assigned since it was created. >_> 2011-12-12T11:24:52 tsbere: huh, yeah, I didn't notice that it was assigned - I'll go unassign it 2011-12-12T11:25:42 tsbere: yeah, that's what my understanding of "Assigned" means: "I'm working on reviewing / signing-off on this bug" 2011-12-12T11:25:56 I suspect senator just assigned it to himself when he opened it 2011-12-12T11:26:37 Yea. I found no evidence he had grabbed it anytime other than when it was opened. 2011-12-12T11:27:04 dbs: You tend to be the go-to for opensrf. Care to take a look at https://bugs.launchpad.net/opensrf/+bug/903264 while I look at 878264? ;) 2011-12-12T11:28:18 tsbere: sounds good to me! I've got to run up to a VP's office to look over some paperwork but will tackle it over lunch 2011-12-12T11:30:30 *** dbs has quit IRC 2011-12-12T11:53:02 eeevil: I'll see if that works for me. 2011-12-12T11:55:05 eeevil: That will work with bare hashes, but not with the structs used in xml rpc. I'm going to stick with what I've for the xml-rpc-gateway-improvement branch. 2011-12-12T12:08:37 *** bradl_ is now known as bradl 2011-12-12T12:10:07 *** dbs has joined #evergreen 2011-12-12T12:10:07 *** dbs has joined #evergreen 2011-12-12T12:19:40 *** pmpcat has joined #evergreen 2011-12-12T12:28:41 Instead of fighting with every commit on the branch, we decided that for more than a couple of commits we can just merge and sign off on the merge, right? 2011-12-12T12:29:36 tsbere: oh, I don't like that idea much 2011-12-12T12:30:11 if you do that, you lose all of the history of the changes, don't you? 2011-12-12T12:30:21 No 2011-12-12T12:30:33 You just get a bunch of commits with one sign-off and a merge commit at the top signed off by someone else 2011-12-12T12:30:53 *** kmlussier has joined #evergreen 2011-12-12T12:31:28 oh, that sounds okay 2011-12-12T12:31:49 I thought it was the equivalent of squashing all commits into one ginormous one :) 2011-12-12T12:31:51 basically, git merge , then amend the merge commit to sign-off 2011-12-12T12:32:17 Sounds good to me 2011-12-12T12:32:59 I think that is basically what was done for the "merge the TPac!" event 2011-12-12T12:34:48 We should probably document some of these agreements other than in IRC logs :) 2011-12-12T12:35:05 dbs: See what I just pushed for an example ;) 2011-12-12T12:36:40 tsbere++ # it's like xmas come early 2011-12-12T12:40:08 * tsbere would have done a "go and amend every commit" if it weren't for the conflicts fixed by previous merges 2011-12-12T12:40:56 tsbere: agreed - signing off on merge commits is nice and clean 2011-12-12T12:51:44 tsbere: opensrf.validator is looking good so far (just reading through the code); nice and concise 2011-12-12T12:52:42 might need to tweak some of the Build.PL stuff for it though - poking 2011-12-12T12:53:07 * tsbere didn't see any need to tweak that stuff when he tested....including make && make install. Things worked? 2011-12-12T12:53:27 Then again, I didn't even consider looking at Build.PL 2011-12-12T12:55:09 no problemo, I'll take care of it 2011-12-12T12:55:48 MANIFEST I think 2011-12-12T12:57:01 mmm, yeah, and some requirements to list in Build.PL. small stuff though 2011-12-12T13:02:46 * tsbere admits to only thinking about going for stuff like that when things *don't* seem to work 2011-12-12T13:04:38 heh 2011-12-12T13:05:12 * dbs adds "use_ok(OpenSRF::Application::Validator);" to the list of tests... it's not much, but it's something 2011-12-12T13:11:51 you can see my changes at user/dbs/opensrf_validator if you're curious - just about to actually run the code, now that it's installed :) 2011-12-12T13:13:11 Heh. Apparently this isn't the only thing to miss the Manifest ;) 2011-12-12T13:18:34 Yay: 'request opensrf.validator opensrf.validator.emailaddress.validate {"emailaddress":"dan@coffeecode.net"}' says that I (or at least my email address) is valid! 2011-12-12T13:18:45 Or at a minimum the domain for your address ;) 2011-12-12T13:19:01 yep, "dan@coffeecode.ne" not so much 2011-12-12T13:19:55 I was a bit surprised by the input hash requirement - that's somewhat atypical - but I guess it leaves the door open for more challenging structures like mailing addresses eh? 2011-12-12T13:20:05 yea 2011-12-12T13:20:20 I *was* going to write a USPS webtool address standardizer one..... 2011-12-12T13:20:27 But they only let you use that tool for shipping packages. :( 2011-12-12T13:21:09 only other question I have is: do you want this service to be publicly exposed in opensrf_core.xml? 2011-12-12T13:21:11 * tsbere also figured that if one wanted to they could create a single chain that checks several fields at a time 2011-12-12T13:21:42 * dbs would like to use MVLC's gateway to validate all of his patron's email addresses 2011-12-12T13:22:22 dbs: Originally I was thinking "have the patron editor call things directly" but have been re-thinking that in the past half hour or so. 2011-12-12T13:22:53 tsbere: I'm willing to commit this as-is, and have some follow-on commits if you like 2011-12-12T13:23:13 s/and have some/and we can always go with some/ 2011-12-12T13:23:33 Won't be the end of the world if it sits in the public side by default on the opensrf default config....it doesn't even *exist* in the evergreen default config yet ;) 2011-12-12T13:23:58 Right. Let's let the Evergreen default config duke it out 2011-12-12T13:24:53 tsbere: one comment on opensrf.validator, any reason to use module::load instead of universal::use, since the latter is already in use in opensrf? 2011-12-12T13:25:17 eeevil: Lack of experience with either....and Dyrcona's mentioning of the former. 2011-12-12T13:25:56 TIMTOWTDI 2011-12-12T13:26:27 Dyrcona: there are, indeed. is module::load a core perl mod? 2011-12-12T13:26:29 also, when I read up on module::load it said "this is a core module" so I figured "nothing more to install there!" and didn't look much further ;) 2011-12-12T13:26:36 :) 2011-12-12T13:26:48 question answered 2011-12-12T13:27:19 I guess we need an OpenSRF 2.1.0 milestone for new features 2011-12-12T13:31:09 Okay, created an 2.1.0-alpha milestone and targeted 902364 at it. Thanks tsbere 2011-12-12T13:32:59 *** kmlussier_ has joined #evergreen 2011-12-12T13:33:41 dbs: Apparently I never reached the point of trying to put the validator on the public side of things in OpenSRF. I didn't touch opensrf_core.xml at all. 2011-12-12T13:33:47 *** kmlussier has quit IRC 2011-12-12T13:33:56 *** kmlussier_ is now known as kmlussier 2011-12-12T13:34:08 tsbere: I know (at least in terms of committed code), that's why I was asking :) 2011-12-12T13:34:47 * tsbere has notes of "this could be abused if not filtered via an authtoken" do to the dns lookups and who knows what else people will put in there 2011-12-12T13:38:40 to which OpenSRF replies, "What's an authtoken?" ;-) 2011-12-12T13:38:41 dbs: The hash input also lets you, if you are crazy, add validators for extra information to multiple chains that deal with different information. They can then figure out what was passed in by the hash members. 2011-12-12T13:39:31 * dbs looks forward to someone building a "password strength" validator and passing the validation request over HTTP 2011-12-12T13:39:51 Or, if you want an all in one shot, chain mailing address, email address, and phone number validators together. :P 2011-12-12T14:16:08 *** wolf29 has quit IRC 2011-12-12T14:25:37 *** edoceo has joined #evergreen 2011-12-12T14:36:03 * dbs sends a quick reply on JS receipt templates 2011-12-12T14:36:55 * bshum was just reading that 2011-12-12T14:37:22 I thought there was something written on it during the time of the 2.1.0 cut/release, but now I can't find anything. 2011-12-12T14:38:40 the only other place I can think of would be the upgrade docs, and that seems unlikely 2011-12-12T14:39:32 I mean, we mention the print_custom OU setting in the release notes, but that's hardly a "hey - your receipt templates might be breaking severely!" heads up 2011-12-12T14:40:13 :( 2011-12-12T14:43:34 hrm. we're on 2.1 and we're still using js in receipts. 2011-12-12T14:43:47 guess i should look into that. i had it pegged as a post-2.1 change 2011-12-12T14:46:12 <_bott_> Can I get an opinion on whether or not this is a good or bad approach... https://github.com/grpl-eg/rel_2_1/commit/91ca4bc998dff26d15712fb51657827bbbb58318#diff-1 2011-12-12T14:46:38 <_bott_> The issue is, on the rdetails page, the "N of X results" does not allow for the page offset 2011-12-12T14:47:27 <_bott_> So, page 2, record two of say, 50 comes up as "2 of 50" instead of "12 of 50" ...assuming 10 per page 2011-12-12T14:47:43 *** adbowling-isl has joined #evergreen 2011-12-12T14:48:26 jeff: yeah, http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3a3faae60f68b103003379660869ed5379d81215 is the relevant rel_2_1 commit 2011-12-12T14:48:28 _bott_: looks sane. i'm not looking at the whole context, but i'm wondering if it's always been a cosmetic issue, or if something broke. 2011-12-12T14:48:35 dbs++ 2011-12-12T14:48:36 thanks 2011-12-12T14:49:03 <_bott_> I checked Indiana, MVLC, and us, and we all had the issue 2011-12-12T14:49:18 <_bott_> or have, rather 2011-12-12T14:50:16 _bott_: we have the same issue - never really been a priority 2011-12-12T14:50:26 seems sane enough to me 2011-12-12T14:50:37 <_bott_> I never even noticed until a couple days ago 2011-12-12T14:50:49 <_bott_> I figure the query string should always include the offset 2011-12-12T14:51:07 "git branch -r --contains" is incredibly handy (with and without -r) 2011-12-12T14:51:08 *** jmorris42 has joined #evergreen 2011-12-12T14:54:04 dbs: okay, landed after we upgraded. mental note revised. thanks again! 2011-12-12T14:54:24 (it wasn't post-2.1 it was post-2.1-pre -- simple!) 2011-12-12T14:56:53 Ok, I have a crazy one. Just cut over to 2.0.10 from 1.6.0.8 and almost everything is beautiful. A couple of staff can't edit users, they get a screwed up display and hitting debug, view source refuses to show anything so I'm at a loss. No user has individual permissions, just the group stuff. 2011-12-12T14:58:26 what does the screwed up display look like? (standard check:) do the staff users in question have working locations set? 2011-12-12T14:59:26 *** dbs has quit IRC 2011-12-12T15:00:32 The users don't see any of the editable fields. A couple of buttons are present such as reset password and lost card. They also see the button to add an address and it does indeed open up the fields to add an address if clicked. 2011-12-12T15:00:59 branch --contains isn't that helpful in some cases... master doesn't contain that commit. 2011-12-12T15:01:03 That sounds vaguely familiar. 2011-12-12T15:01:13 Like a broken dojo 2011-12-12T15:01:19 I can't identify any difference between working and non-working users. Even tried blowing up .openils in their home and reregistering them. 2011-12-12T15:02:59 Oh, and we tried different workstations and the problem moves with the user. 2011-12-12T15:04:39 *** mrpeters-isl_ has joined #evergreen 2011-12-12T15:04:53 The workstations are Linux with NFS mounted homes. 2011-12-12T15:05:07 still talking to myself, mostly. the master version of 3a3faae60f68b103003379660869ed5379d81215 is 865c23330a9e891024e2df3696dfe5a827ed545c and differs in that it contains a modification to 950.data.seed-values.sql 2011-12-12T15:05:44 jmorris42: moves with the OS user or the Evergreen user? 2011-12-12T15:06:37 Hmm. So far they have been the same. Probably should try that, login in as me to the ws then use a known bad EG login. Gimme a sec. 2011-12-12T15:08:00 jmorris42: Any clues from the Apache error logs? 2011-12-12T15:14:02 Ok, just tried. Login to ws as me, then EG as bad user doesn't work. Login to ws as bad user and EG as me works. That settles that, it isn't the workstation or home directory. 2011-12-12T15:14:38 Where would I look in the logs? I have grepped around in the /openils/var/log entries. Lemme have a look at apache's log. 2011-12-12T15:17:16 <_bott_> jmorris42: sure sounds like some of what we'd see when staff didn't have working locations set. 1.6.0.x didn't seem to care,and we found many that needed to be updated 2011-12-12T15:21:23 So where do I look for working location? The workstation ID is branch-userid on everyone working and non-working. 2011-12-12T15:25:37 jmorris42: in the user permission editor in the staff client, retrieve a "good" and a "bad" user and compare their "working locations" near the top of the editor. 2011-12-12T15:25:50 (going from memory there, so consider that paraphrased) 2011-12-12T15:26:41 jmorris42: at the db level, working locations are stored in permission.usr_work_ou_map 2011-12-12T15:27:37 jmorris42: You can also set it up per user in the client 2011-12-12T15:27:46 so, if you have the user id (not barcode, not usrname, but the au.id / internal id) of a good and a bad staff user, you can select from permission.usr_work_ou_map where usr in (123, 765) and compare 2011-12-12T15:28:31 Under - Other>User Permission Editor 2011-12-12T15:28:57 *** plux has quit IRC 2011-12-12T15:30:42 *** mrpeters-isl_ has quit IRC 2011-12-12T15:30:46 ok, my account as entries for all of our branches, non-working user has nothing. So where do I fix it from? It doesn't appear to be on the user record where I can see it. 2011-12-12T15:31:32 jmorris42: moodaepo and i mentioned the User Permission Editor in the staff client. 2011-12-12T15:31:45 jmorris42: The "working locations" should be check boxes at the top. 2011-12-12T15:32:21 Ah! Thar it be. 2011-12-12T15:32:29 jmorris42: alternately, you could update it from the database level, depending on the number of staff users you're fixing. 2011-12-12T15:32:48 jeff++ # Was just typing ^^ 2011-12-12T15:34:13 It is wierd that 1.6 didn't care if they weren't actually allowed to work here. :) About to go have em try again. 2011-12-12T15:36:27 jmorris42: 1.2 didn't have work_ou, 1.4 treated home_ou as primary for staff (basically ignoring work_ou), 1.6 used work_ou but always fell back to home_ou failing that, and 2.0 introduced code that only considered work_ou ... it was a slow transition 2011-12-12T15:40:11 Ok, but the users could circulate items with no permission? Should that be considered a bug? 2011-12-12T15:41:40 the transition isn't complete, so it's simply more to work on ... you could bug it on LP 2011-12-12T15:43:34 So it looks like we are now settled into 2.0 as this was the only real "Oh poop!" issue. Not bad at all. 2011-12-12T15:46:50 Should I be seeing not found errors in the apache logs for /openils/var/web/js/dojo/openils/User/nls/en? 2011-12-12T15:48:37 yep 2011-12-12T15:48:44 those are normal 2011-12-12T15:49:06 Ok, figured it couldn't be really bad if the system is working without it. 2011-12-12T15:49:51 One more long standing issue though I wonder about. The staff group has REGISTER_WORKSTATION but only admin can actually do the deed. 2011-12-12T15:50:12 Is there something else required? This one was in both 1.6 and still there in 2.0 2011-12-12T15:52:58 *** tspindler has quit IRC 2011-12-12T15:59:17 *** Meliss has quit IRC 2011-12-12T16:02:43 Ok. It's late in the day and my brain is tired. If I log in as 'circulator' and try to register a patron the ORG Units are not appearing in the Home library drop down. 2011-12-12T16:02:52 What permission are my circulators missing? 2011-12-12T16:03:12 I'm assuming it's permissions. 2011-12-12T16:06:32 collum: What version of Evergreen? 2011-12-12T16:06:41 collum: It might also be weird autogen issues 2011-12-12T16:07:09 2.0.9 2011-12-12T16:07:23 jmorris42: Depending on what depth you assigned the group permission, perhaps they also need working permissions set in order to register new workstations. 2011-12-12T16:07:36 I just ran autogen about 30 minutes ago 2011-12-12T16:08:13 collum: Restarted apache and restarted the staff client too? 2011-12-12T16:08:35 yep 2011-12-12T16:09:24 If i log in as admin, I'm ok. 2011-12-12T16:13:41 What do you get from the org unit dropdown? Nothing at all? Or just wrong entries? 2011-12-12T16:13:51 For the circulator 2011-12-12T16:13:54 Nevermind bshum. I just logged in as another user that is also a part of the circulator permission group and it works. I'll just compare the two accounts tomorrow. 2011-12-12T16:13:58 nothing at all 2011-12-12T16:14:07 Oh wacky. 2011-12-12T16:14:20 Thanks for your help. 2011-12-12T16:14:28 Okay, good luck tomorrow then. 2011-12-12T16:19:10 *** collum has quit IRC 2011-12-12T16:22:11 *** pmpcat has quit IRC 2011-12-12T16:28:21 *** akilsdonk has joined #evergreen 2011-12-12T16:34:34 I loaded the sample data from this set provided by Indiana (I think) but I don't have any items available to check out? Do I have to add some inventory or something? 2011-12-12T16:55:32 *** dbs has joined #evergreen 2011-12-12T17:16:29 *** akilsdonk has quit IRC 2011-12-12T17:17:19 *** kmlussier has quit IRC 2011-12-12T17:28:21 *** Dyrcona has quit IRC 2011-12-12T17:56:32 *** bwicksall has quit IRC 2011-12-12T19:02:24 edoceo: I was going to say that maybe the items didn't get created but looking at the code the seems to be created. Can you search and retrieve titles/items in the opac? 2011-12-12T19:04:51 *** youdonotexist has joined #evergreen 2011-12-12T19:07:38 *** jmorris42 has quit IRC 2011-12-12T19:10:17 *** pmpcat has joined #evergreen 2011-12-12T19:47:23 *** youdonotexist has quit IRC 2011-12-12T20:16:42 *** youdonotexist has joined #evergreen 2011-12-12T21:27:35 *** dbs has quit IRC 2011-12-12T21:43:15 *** dbs has joined #evergreen 2011-12-12T22:17:47 moodaepo: yep, I can see things but I cannot make a checkout of the item. The Client system is visible, would let you take a look. Will be back on afternoon Pacific time