16:59 -!- dkg [~dkg@lair.fifthhorseman.net] has joined #ussf
16:59 -!- micah [~micah@micah.riseup.net] has joined #ussf
16:59 < dkg> howdy folks
16:59 < micah> greetz
17:00 < jamie_> hi all - shall we get started? 
17:00 < LouNovak> hey folks,
17:01 < LouNovak> sure, lets go for it
17:01 -!- libkuman [~libkuman@167-89.nyc.dsl.access.net] has joined #ussf
17:01 < jamie_> hey mark
17:02 < jamie_> our goal today is to get civicrm setup and running
17:02 < libkuman> hi, mark libkuman here with jamie at norio, won't be able to 
                  give lots of support but will do my best to pay attention
17:02 < jamie_> I think we have a couple bigger picture items to discuss before 
                we dig in.
17:02 < LouNovak> question, it this a test installation or our production site
17:02 < jamie_> yes - exactly :)
17:02 < dkg> that's a good question, Lou.
17:02 < dkg> i think we need to address the plans for doing developmnet
17:03 < jamie_> my suggestion is that we setup a completely separate drupal 
                installation for civicrm.
17:03 < micah> i'm also payin' attention, but not much of a drupal person, i'll 
               be hovering and helping in whatever capacity I can
17:03 < jamie_> it would run the same (or similar) drupal theme - so for a user 
                to go between the www.ussf2010.org site and the civi site, it 
                would look the same, however, transparently to the user, they 
                would be accessing a different site altogether, which could in 
                theory even be on a different machine.
17:04 < jamie_> the reasons for this setup is:
17:04 < jamie_> (are):
17:04 < jamie_> * increased security - the civicrm installation will contain 
                sensitive information. limiting that sensitive information to a 
                single server will improve security.
17:05 < jamie_> * reliabilty: if the main site gets slammed, we won't be 
                affected on the civi site and vice versa
17:05 < jamie_> how does this sound to other people?
17:05 #ussf: < dkg> i'm concerned about shared logins, etc
17:05 #ussf: < dkg> if we're using openid then it won't be too confusing for authentication purposes
17:06 #ussf: < dkg> but people might be confused that they want to do something on the main site and something on the db
17:06 #ussf: < libkuman> and i'm a little concerned about how we share information form civi so that other sites can use it
17:06 #ussf: < libkuman> and making sure that any profile information is always written to the civi site and pushed out
17:07 #ussf: < dkg> i guess my concern is a general one though -- since we've talked about wanting to have distributed services, this woud be a first step in that direction.
17:07 #ussf: < libkuman> would hate to have different parts of user profiles in different db's, or even worse to have things get out of synch
17:07 #ussf: < dkg> jamie_: any thoughts about how to address libkuman's concerns?  synchronization is a tough one.
17:07 #ussf: < dkg> maybe we would only need to have user profiles in one place?
17:08 #ussf: < jamie_> I think it's going to be tough. 
17:08 #ussf: < jamie_> however, we have some options
17:09 #ussf: < jamie_> first - to back up for people not familiar with openid...
17:09 #ussf: < dkg> (just so folks know: jamie_ is logging this, and we may publish it later as documentation of what we did.  So we should all probably consider this conversation public)
17:09 #ussf: < LouNovak> I'm not too familiar with CiviCRM, I assume it uses drupal user authentication and I believe drupal can authenticate across installations, right?
17:10 #ussf: < jamie_> OpenID is a single login system. It allows you to have a "user id" - for example, https://id.mayfirst.org/jamie - in which your personal information is stored on one server.
17:10 #ussf: < jamie_> LouNovak: yes - *and* drupal 6 also supports OpenID.
17:10 #ussf: < jamie_> as another method for logins accross sites.
17:10 #ussf: < jamie_> once you have an openid "provider" - you can then login on any website that supports openid. These sites are referred to as openid "consumers"
17:11 #ussf: < micah> (and micah 
17:11 #ussf: < micah> took a screenshot)
17:11 #ussf: < LouNovak> sounds to me that drupal could handle the  issues itself,  using drupal id's or openids
17:11 #ussf: < jamie_> If you login to a site that supports openid (a consumer), you can enter you openid instead of getting user account. You will be redirected to your openid provider, which logs you in and sends you back to the consumer site as logged in.
17:12 #ussf: < libkuman> authentication isn't theh problem, its the profile info for users and for contacts in civi being accessible by sites other than the civi site
17:12 #ussf: < jamie_> LouNovak: yes - exactly. I think that would be a huge gain to the social forum if we formally supported open id.
17:12 #ussf: < jamie_> libkuman: right... so the added benefit is that 
17:12 #ussf: < jamie_> when an openid consumer logs you in for the first time with your open id, it can request information from your provider (like your email address, first name, last name, etc). You have the option of deciding which information you want to divulge.
17:13 #ussf: < jamie_> this does *not* address the issues of sync'ing.
17:13 #ussf: < jamie_> (or I'm not sure if it does)
17:13 #ussf: < libkuman> jamie: did you find out if it works if that info is stored in civi, not drupal?
17:13 #ussf: < jamie_> but it does allow you to do a one time dump of your info into the new site, rather than re-enter it.
17:13 #ussf: < jamie_> libkuman: nope. still to be researched.
17:13 #ussf: < LouNovak> what are the downsides to openid?
17:14 #ussf: < libkuman> we really need to find out how nicely it plays with civi
17:14 #ussf: < jamie_> the main downsite to openid is user education. Most people don't know what it is.
17:14 #ussf: < jamie_> however, I think it's a powerful and important development on the INternet, so training people on it's use would be a net benefit.
17:14 #ussf: < jamie_> libkuman: yes - I think it's possible we might need to contribute some code to get things working the way we want them to work.
17:16 #ussf: <@rossg> Are there downsides to having a separate drupal install?
17:16 #ussf: < jamie_> I think the main downside is the one identified by libkuman - that it will make it harder to share data between different sites.
17:16 #ussf: < jamie_> for exmaple - if all main sites worked on the same drupal install, then it would be eaiser to share info between them.
17:17 #ussf: < dkg> for instance:
17:17 #ussf: < dkg> if the main site has a list of all the events and workshops
17:17 #ussf: < dkg> and the civicrm has a list of all the attendees (and their payment status or whatever)
17:17 #ussf: < libkuman> also a thing to consider is will there be civi contacts that won't have drupal accounts (say like organizations), will we be able to push that information out to all the other sites that might need that
17:17 #ussf: < libkuman> ?
17:17 #ussf: < dkg> then it would be more difficult to use a single drupal install to do signups for the workshops.
17:19 #ussf: < jamie_> Yes - these are all disadvantages. I think one factor that mitigates them is that most of the data we collect is public data. For example - if we linked all workshops to the openid that submitted them - we could craft links to the civi site - keyed to the openid - that displays whatever information that person wants displayed. 
17:20 #ussf: < jamie_> as for the events and workshops - all of that data is public - so publishing it in machine readable way for other sites to pull it in would be fairly easy.
17:20 #ussf: < jamie_> I think it's actually a very small amount of information that is private and could not simply be exposed via the web.
17:20 #ussf: < dkg> are proposed events and workshops published too?
17:20 #ussf: < dkg> or just approved events and workshops?
17:20 #ussf: < jamie_> I don't think we're at that question just yet :).
17:21 #ussf: < jamie_> (although I certainly have an opinion!)
17:21 #ussf: < dkg> ;)
17:21 #ussf: < dkg> it would affect the workflow choices
17:21 #ussf: < dkg> if the synchronization was done via public channels
17:21 #ussf: < dkg> then it would force signups
17:21 #ussf: < dkg> to happen after approvals
17:21 #ussf: < dkg> but i guess that makes sense anyway.
17:21 #ussf: < jamie_> at this point - I think our decision is whether the civi site should be separate from the main www site.
17:22 #ussf: < jamie_> I feel pretty strongly that the answer is yes to that question.
17:22 #ussf: < dkg> never mind.  sorry about my digression (people can't sign up to non-public workshops anyway :p)
17:22 #ussf: < jamie_> whether the civi site should be separate from the workshop site is a different beast perhaps.
17:22 #ussf: < libkuman> this alll seems to be assuming that the only contacts entered into civi will be entered by the contact themselves, what about organizers who use civi to enter contacts for organizational purposes, sharing that info wouldn't be easy since the contact would not be interacting with the system
17:23 #ussf: < libkuman> just want to make sure we don't take away from the usefullness of civi by isolating it
17:23 #ussf: < jamie_> i'm not sure I follow libkuman. 
17:24 #ussf: < jamie_> "since the contact would not be interacting with the system" part I don't follow.
17:24 #ussf: < LouNovak> can we build civi on the existing drupal site and move it later if we have to?
17:24 #ussf: < libkuman> say i'm a volunteer coordinater, i get contact info for people that might want to help out, i therefore would want to add them as a contact to civicrm
17:24 #ussf: < libkuman> those people may never login to any of the ussf sites
17:24 #ussf: < jamie_> LouNovak: Yes - I think that's fairly easy. The only tricky part is that if we did a lot of custom stuff on the drupal side to present the civi forms, it might be harder to transfer those pieces.
17:25 #ussf: < LouNovak> a contact in civi is not neccessarily a user, right?
17:25 #ussf: <@rossg> right
17:25 #ussf: < dkg> LouNovak: i think that's right.
17:25 #ussf: < libkuman> correct
17:25 #ussf: < dkg> from the CRM world, these systems are often used to track people who never interact with them directly at all.
17:25 #ussf: < dkg> (e.g. lists of donors who write checks)
17:26 #ussf: < libkuman> on a site i worked on, creating a drupal account wold create a civi contact
17:26 #ussf: < libkuman> but not the opposite
17:26 #ussf: <@rossg> Which we could not do with a separate install.
17:27 #ussf: < LouNovak> I'm tempted to say let's build it on the current site and move it if we have to. 
17:27 #ussf: < jamie_> Hm - I'm not following. My understanding is that this would be possible.
17:27 #ussf: < LouNovak> address security and reliability at the server level, 
17:27 #ussf: < libkuman> i don't think it would be impossible, but would require some possible tricky synch code acrosss sites
17:28 #ussf: < jamie_> I'm still not following exactly what is not possible with separate installs?
17:28 #ussf: < jamie_> specifically talking about the www site versus the civi site.
17:28 #ussf: < libkuman> (at least the drupal account creation -> civi contact creation, i don't know if the opposite is possible or recommended using either plan)
17:29 #ussf: < jamie_> how does this impact the decision for a separate installation? It seems like it's an issue we will have to address with civicrm regardless of a separate installation or whether we put it on the www site.
17:29 #ussf: <@rossg> jamie_: I'm not sure I understand 'exactly' what you're proposing.
17:30 #ussf: <@rossg> How would the two sites interact?
17:30 #ussf: < jamie_> Currently we have one drupal installation for the www site.
17:30 #ussf: < jamie_> I'm proposing that we setup a second drupal installation (say, register or id.ussf2010.org).
17:30 #ussf: < LouNovak> www.ussf2010.org and civicrm.ussf2010.org, each it's own drupal intstallation, one with civicrm on top
17:30 #ussf: < jamie_> it would have the same theme as www - so as users move between the two sites, it looks the same.
17:31 #ussf: < jamie_> right - exactly.
17:31 #ussf: < jamie_> so - if you click on the "register" or "donate" links on www, you get sent to civicrm.ussf2010.org. You don't necessarily notice it, but that's where you go.
17:31 #ussf: < LouNovak> do we have the hardware or are these virtual servers?
17:31 #ussf: < jamie_> right now, we have one virtual server dedicated to the ussf
17:32 #ussf: < jamie_> as we continue we'll be adding more virtual and physical servers to address our needs.
17:32 #ussf: <@rossg> Okay so what about using organic groups and civicrm together?
17:32 #ussf: < jamie_> yes: I think we should do that. On the civi site.
17:32 #ussf: < LouNovak> Organic groups? another piece of software?
17:33 #ussf: <@rossg> Yes.  It's a pretty good tool for creating a community of users within a site
17:33 #ussf: < jamie_> the reason I'm a strong advocate for the two servers - despite some of the potential problems is because of both the security gains we get from having them separate and also the performance onces (we want www to load immediately without any delay - yet civicrm is a real resource hog).
17:33 #ussf: <@rossg> jamie_: Now the user question, are you seeing user sign ups happening on the civi site?
17:34 #ussf: < jamie_> yes.
17:34 #ussf: < jamie_> and *not* on the www site.
17:34 #ussf: < jamie_> the www site should have a relatively small number of users who can login to change content.
17:34 #ussf: <@rossg> oh..I'm totally with you then! Thanks for the extrapolation.
17:34 #ussf: < jamie_> everyone should be able to login to the civi site to control their info.
17:34 #ussf: < libkuman> i'm willing to go along with it, i just really want the civi site to be the container for all CRM needs, i.e. i would hate to have other sites start to collect information that really should be stored in civi (i.e. if we are going to use a CRM, lets fully use it and not have multiple places where that type of information gets stored)
17:35 #ussf: < dkg> libkuman: i agree with that.
17:35 #ussf: < jamie_> libkuman: yes - I agree. And - just because there are good arguments for the separate sites, doesn't mean that we are going to sacrifice things as well. However - I think the really important decision will be whether we want to put things like workshop registration on the civi site or a separate site. 
17:35 #ussf: < LouNovak> I'm with libkuman (mark?), if we have a separate civicrm, keep all users there except those
17:35 #ussf: < dkg> we should do what we can to make that really clear.
17:35 #ussf: < LouNovak> needed to keep www up and current
17:36 #ussf: < libkuman> and that means down the road we might have to deal with some difficult synching issues to really allow all USSF volunteers to be able to use civi for their organizing needs, even if we are dealing with information not tied to a person with openid authentication information
17:37 #ussf: < jamie_> ok. I think we've noted some serious concerns with separate sites, but we're coming to consensus that having civicrm.ussf2010.org as a separate site than www.ussf2010.org is what we want to do.
17:37 #ussf: < LouNovak> si
17:38 #ussf: < jamie_> ok... next question... is civicrm.ussf2010.org the domain we want to use? maybe a more generic crm.issf2010.org might be better? Thoughts?
17:38 #ussf: < dkg> i dont like the term crm
17:38 #ussf: < dkg> these are not customers
17:38 #ussf: < jamie_> id.ussf2010.org? user.ussf2010.org? 
17:39 #ussf: < dkg> people.ussf2010.org
17:39 #ussf: < LouNovak> I like user, member or id
17:39 #ussf: < libkuman> dkg: constituent is also used besides customers
17:39 #ussf: < jamie_> people sounds nicely human to me.
17:39 #ussf: < LouNovak> what about organizations?
17:40 #ussf: < LouNovak> do they need ID's
17:40 #ussf: < libkuman> dkg: civicrm explicitly says Constituent Relationshp Manager, not Customer Relationship Manager
17:40 #ussf: < jamie_> i think we'll want a person in the organization to have a login with authority for the organization.
17:40 #ussf: < dkg> yeah, but even so it feels yucky to me 
17:41 #ussf: < LouNovak> participant.ussf....
17:41 #ussf: < jamie_> hm - that's another good suggestion.
17:41 #ussf: < jamie_> i like both people and participant. 
17:42 #ussf: < LouNovak> contributor. partner. compadre.
17:42 #ussf: < jamie_> companero
17:42 #ussf: < dkg> folks
17:42 #ussf: < libkuman> jamie, you are still thinking everyone will have a login, people will use this tool to track their outreach needs, and that might just be the organization name and email/phone number
17:43 #ussf: < LouNovak> community.ussf2010.org
17:43 #ussf: < libkuman> i like that
17:43 #ussf: < LouNovak> I love my community :)
17:43 #ussf: < dkg> i like community too
17:43 #ussf: < micah> Customer is just as gross as Constituent
17:44 #ussf: < dkg> customer is grosser than constituent
17:44 #ussf: < micah> community is ood
17:44 #ussf: < micah> good
17:44 #ussf: < jamie_> libkuman: yes - I think all participants will have a login that allows them to minimally update their personal info.
17:44 #ussf: < dkg> crm == community relationship matrix
17:44 #ussf: < LouNovak> sweet!
17:44 #ussf: < jamie_> and some organizers will have access to the civicrm backend to communicate with the people in the database.
17:44 #ussf: < libkuman> jamie, then i think civi will be used for more than participants then
17:45 #ussf: < jamie_> I like community too.
17:45 #ussf: < libkuman> unless we limit the functionalness of civi
17:45 #ussf: < dkg> sounds like consensus, if rossg is ok with community.
17:45 #ussf: <@rossg> okay consensus.uusf2008.org
17:45 #ussf:  * dkg glares at rossg
17:45 #ussf: < jamie_> ha!
17:46 #ussf: < dkg> wise guy!
17:46 #ussf: < LouNovak> :-/
17:46 #ussf: <@rossg> : )
17:46 #ussf: < jamie_> ok... I think we have a name. yay!
17:46 #ussf: < jamie_> the name of the server currently hosting ussf stuff is mendes.mayfirst.org
17:47 #ussf: < jamie_> currently it is hosting www.ussf2007.org and www.2010.org
17:47 #ussf: < jamie_> I can add community.ussf2010.org now, create a login for it, and share access.
17:47 #ussf: < jamie_> maybe i should take 10 minutes and set up this stuff now?
17:47 #ussf: < LouNovak> brb
17:47 #ussf: < jamie_> then we can re-group, share access, and get started on the civi install?
17:48 #ussf: < micah> sounds good
17:48 #ussf: <@rossg> Sounds good to me.
17:48 #ussf: < libkuman> i gotta do a quick phone call, back in a bit
17:48 #ussf:  * micah takes a screenshot
17:48 #ussf: < jamie_> ok... regroup at 6:00 pm America/New_York
17:48 #ussf: < micah> everyone smile
17:50 #ussf:  * dkg smiles
17:50 #ussf: < LouNovak> :-D
17:59 #ussf: <@rossg> nicotine...  (^o^)
18:03 #ussf: < jamie_> ok... we're setup now: http://community.ussf2010.org/ I added the same theme used by the www site.
18:03 #ussf: < jamie_> can everyone paste in the email address that you'd like to use with your initial drupal user account? 
18:03 #ussf: < LouNovak> lmn@lppals.com
18:04 #ussf: <@rossg> ross@ross.mayfirst.org
18:05 #ussf: < dkg> dkg@fifthhorseman.net, natch
18:08 #ussf: < jamie_> ok - I've created accounts for all of you.
18:08 #ussf: < jamie_> I accidentally didn't hit the "notify user" option for you ross! sorry.
18:08 #ussf: < jamie_> everyone else should have an email with your login credentials. Ross - can you go to the reset password link and request a new password?
18:08 #ussf: <@rossg> okay
18:09 #ussf: < libkuman> libkuman@openflows.com
18:10 #ussf: < LouNovak> setup pw and changed username to lounovak
18:11 #ussf: <@rossg> I think I'm getting the spam assassin delay. : (
18:11 #ussf: < micah> http://micah.riseup.net/shots/shot-2009.06.14-18.10.41.png
18:13 #ussf: < jamie_> ... sorry for the delay... we're trying to shoot video for documentation purposes!
18:13 #ussf: < dkg> yeah, my mail is delayed also.
18:16 #ussf: < jamie_> ok... just got you in libkuman.
18:16 #ussf: <@rossg> Just a note...there's a css issue with the header on the password request page.
18:17 #ussf: <@rossg> I think line 244 in style.css should have the width set to 880px
18:17 #ussf: < jamie_> ok... can I give you access to the user account to fix that?
18:17 #ussf: < jamie_> :)
18:17 #ussf: <@rossg> that is body.no-sidebars #header { width: 880px }
18:18 #ussf: <@rossg> please
18:19 #ussf:  * libkuman successfully logs in
18:19 #ussf: <@rossg> ross: still no email
18:19 #ussf: < jamie_> rossg: do you have an ssh key somehwere that I could use?
18:20 #ussf: < LouNovak> community.ussf2010.org is still a drupal only, no civicrm yet right?
18:20 #ussf: < jamie_> LouNovak: yes, that's correct.
18:20 #ussf: < jamie_> if anyone has an ssh key - I can add you to the linux user so you can ssh or secure FTP into the site.
18:20 #ussf: < jamie_> I will put the civicrm module in place now...
18:20 #ussf: < LouNovak> Ross: Jaime mentioned that he didn't send you the email...
18:20 #ussf: <@rossg> should we email you the ssh key?
18:21 #ussf: <@rossg> jamie_: have you thought about using a separate db for civi?
18:21 #ussf: < jamie_> rossg: Only about 2 seconds ago... I think that would make sense - right?
18:21 #ussf: < dkg> i'i haven't gotten an e-mail either.
18:21 #ussf: <@rossg> Yes definitely
18:22 #ussf: < dkg> jamie_: yeah, we should use a separate db.
18:22 #ussf: < dkg> otherwise the performance and security benefits are kinda moot
18:24 -!- Irssi: Starting query in oftc with dkg
18:24 <dkg> you're jamie_sadly ?
18:25 -!- Irssi: Starting query in oftc with rossg
18:25 <rossg> ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAx6GMKXF9vICV7ADEdAEO26VWX7bxi8VRJEzNyZaf4Nn/jkQvoDmb1tjJYUtMEGq9DGyytRGaPVso8BumyUZLa8iwk9IpIh94kI5PhmAsC6MPJp1hem+XO37lw3+2nJgVUwHI5aN9ku68XLO3U/iXf3uW5YiM9+yC1X5sK5/iOut788286Lkolkv7aHwBo+LAnUFLLoIxH0spIzK9B8q8o4uI3zvtj/4iVDoWNjcQR/3vc0kFCgp4wbXTgkM+B8jeM0QfYx6vDHzbTF/UoKjP+9gApIALaiFHEuenw7DvFNquLQoSkzfS16MaP1wiQrG5hdDJZCB80UXodex+8lloDw== ross@duchamp
18:26 <jamie_> ok... yes this is me...
18:26 <jamie_> thanks ross
18:27 <jamie_> ok - you are in.
18:27 <jamie_> can you try: ssh ussf2010-community@mendes.mayfirst.org
18:27 <rossg> cool thanks
18:27 <jamie_> fingerprint: ef:d9:69:86:3b:af:bf:89:8c:4a:3e:2a:3a:95:16:1a
18:28 #ussf: < jamie_> ok... just downloaded civi, setup separate db, installting it now...
18:28 #ussf: < dkg> oh wait -- are you saying that the civicrm parts use a different db than the drupal db?
18:29 #ussf: < dkg> or is the question about using a different db for www. than community. ?
18:29 <rossg> crap...Permission denied (publickey) 
18:30 #ussf: < jamie_> dkg: the first one.
18:30 #ussf: < dkg> oh, that seems weird.
18:30 #ussf: < jamie_> so - we now have *three* database: one for www, one for drupal-community and one for civi community.
18:30 #ussf: < dkg> what's the rationale for that?
18:31 #ussf: < jamie_> by having separate databases it gives us more flexibility if we did decide to merge our civi with a different drupal installation.
18:31 #ussf: <@rossg> A couple of things...helps with updates without breaking the drupal site
18:31 #ussf: < jamie_> it also means that drupal doesn't have access to the civi data directly.
18:32 #ussf: < dkg> is there some documentation about that choice?  i'd be happy to read more about it and don't want to waste everyone's time here while i wrap my head around the details.
18:33 #ussf: < dkg> jamie_: it's all being accessed by the same user, right?  and the access to the civi db is available to that user; so drupal *does* have access, no?
18:33 #ussf: <@rossg> Civi has access to drupal but not the other way round.
18:34 #ussf: < jamie_> the unix user running the site does have the credentials to read the civicrm settings file - so could have access to the civi database.
18:34 #ussf: < jamie_> however - an errant piece of drupal code can't access the data.
18:35 #ussf: < jamie_> ok... one click away from starting the civi install.
18:35 #ussf: < jamie_> should I load default data?
18:35 #ussf: < jamie_> civicrm comes with a bunch of sample records to help people understand how it works.
18:35 #ussf: < jamie_> would that be useful?
18:35 #ussf: <@rossg> I found it helpful
18:36 #ussf: < LouNovak> yep!
18:36 #ussf: < jamie_> ok... going with default data...
18:37 #ussf: < jamie_> done!
18:37 #ussf: < jamie_> i've put all of you in the admin group.
18:38 #ussf: < jamie_> I'm now granting people in the admin group access to civi from this page: http://community.ussf2010.org/admin/user/permissions
18:38 #ussf: < jamie_> The installer suggests that we run through this check list:
18:38 #ussf: < jamie_> http://community.ussf2010.org/index.php?q=civicrm/admin/configtask&reset=1
18:40 #ussf: < dkg> i'm a little bit concerned that we're using cleartext http for this.
18:43 #ussf: < jamie_> yes - I think we should get an ssl certificate.
18:43 #ussf: < jamie_> do you think we should get one from a provider widely adopted in most browsers (i.e. a corporate certificate provider)?
18:44 #ussf: < dkg> i think we should overthrow the x.509 cabal
18:44 #ussf: < dkg> but i don't know if that will happen before june 22nd
18:44 #ussf: < jamie_> yeah - 2009, but maybe 2010!
18:44 #ussf: < dkg> maybe
18:45 #ussf: < LouNovak> :)
18:45 #ussf: < dkg> in the meantime, we might need to suck it up
18:45 #ussf: < dkg> and ask the cabal to certify us
18:45 #ussf: < jamie_> unless there are objections... I will go ahead and get a certificate (sponsored by mfpl) right now. I think this is the type of site we want to be ssl from as close to the beginning as possible.
18:46 #ussf: < jamie_> LouNovak: do you think you could lead us through: http://community.ussf2010.org/index.php?q=civicrm/admin/configtask&reset=1 ?
18:47 #ussf: < jamie_> i'm going to really suck it up and get a 2 year certificate. I don't think we want the certificate to fail on June 14, 2010 - one week for the social forum!
18:48 #ussf: < LouNovak> sure, is everyone at the checklist page? Localization is listed first...
18:49 #ussf: <@rossg> yep
18:49 #ussf: < LouNovak> and if you click on the Localization link, you'll see settings, starting with default language, currency, ...
18:50 #ussf: <@rossg> Are we planning on importing any contacts?
18:51 #ussf: < LouNovak> defaults look good until the legacy encoding, of which I am unfamiliar, any suggestions?
18:51 #ussf: <@rossg> It's fine as is.  we should import with utf-8 anyway
18:52 #ussf: < jamie_> rossg: yes - we will be importing contacts. I agree with utf-8.
18:52 #ussf: < dkg> are we supposed to all be looking at this page together?
18:52 #ussf: < dkg> will there be any conflicts or anything?
18:52 #ussf: < LouNovak> dkg: yep, We're all walking through the checklist togethher
18:52 #ussf: <@rossg> only if you want to be one of the cool kids - Lou hits submit
18:53 #ussf: <@rossg> (Save)
18:53 #ussf: < LouNovak> the default Legacy is Windows-1252, do we want to change it to UTF-8
18:53 #ussf: < LouNovak> >
18:53 #ussf: < LouNovak> ??
18:53 #ussf: <@rossg> LouNovak, no UTF-8 is the default
18:54 #ussf: <@rossg> can leave it as is
18:54 #ussf: < LouNovak> I'm seeing Windows-1252 in that field ?!???
18:54 #ussf: < dkg> LouNovak: that's the default "from" charset
18:54 #ussf: < dkg> basically, it's saying "if the incoming data isn't UTF-8, and we don't know what it is,
18:54 #ussf: < dkg> then assume it's windows-1252"
18:54 #ussf: < dkg> i think
18:55 #ussf: < dkg> and as a general rule, the clients that don't play well with others
18:55 #ussf: < LouNovak> GOTCHA!!!
18:55 #ussf: < dkg> because they don't announce their charset
18:55 #ussf: < dkg> are MS clients :/
18:56 #ussf: < LouNovak> ok, how about CSV separator? comma seems too common, how about |
18:56 #ussf: < dkg> i'd leave the default alone there.
18:56 #ussf: < LouNovak> sorry, bad joke :'(
18:57 #ussf: < LouNovak> I'll add all the countries to the Available Countries, OK?
18:57 #ussf: < dkg> ok, gotcha. 
18:57 #ussf: < dkg> why add all countries?
18:57 #ussf: < dkg> this is the USSF
18:57 #ussf: < dkg> are we expecting an albanian contingent?
18:57 #ussf: < LouNovak> yeah but others may want to register, participate, attend, present perhaps?
18:57 #ussf: <@rossg> We did have quite a few international participants in 07
18:58 #ussf: < dkg> ok, cool
18:58 #ussf: < LouNovak> same with the available states and provinces, all in?
18:59 #ussf: < dkg> no, i don't think so
18:59 #ussf: < LouNovak> that list looks a little messes up, same as countries list, no states or provinces I can see...
18:59 #ussf: < dkg> read the text below for an explanation
18:59 #ussf: < dkg> that's the list of which countries get a state/province sub-list
19:00 #ussf: < LouNovak> GOTCHA!
19:00 #ussf: < dkg> do we need to know what latvian province our latvian participants come from?
19:00 #ussf: < LouNovak> so I'll leave that as United States
19:00 #ussf: < jamie_> hi all - I just completed the application for an ssl certificate. It usually take a day or so - I will report to the list when I get the certificate.
19:00 #ussf: <@rossg> dkg: I remember having issues with the state thing last time
19:01 #ussf: <@rossg> It's worth taking a minute to discuss
19:01 #ussf: < LouNovak> Language support provides no options. so It looks like the only change from defaults is Available Countries
19:02 #ussf: <@rossg> I still think it might be worth including the states.  What if our Albanian only wants to receive snail mail?
19:02 #ussf: <@rossg> And needs that for a visa?
19:02 #ussf: < dkg> ok by me, as long as i don't have to sift through all the albanian states to find new york :p
19:03 #ussf: <@rossg> It says it loads dynamically based on country.
19:03 #ussf: < jamie_> no- civi is good with that - provided you have javascript properly enabled.
19:03 #ussf: < dkg> ok, i'm down.
19:03 #ussf: < jamie_> one advantage of all the states is that the import will work more slowly. otherwise, states not made available will cause the record to be rejected on import.
19:04 #ussf: < dkg> wait, slowly is an advantage?
19:04 #ussf: <@rossg> That could be a bunch of rejected contacts.
19:05 #ussf: < LouNovak> OK, then add all states just like all countries. do we have consensus
19:05 #ussf: <@rossg> Jamie has given me doubt...
19:06 #ussf: < LouNovak> I'd think we'll take slow over handling rejects manually.
19:06 #ussf: < jamie_> woops - sorry I didn't mean slowly .
19:06 #ussf: < jamie_> I meant to say it will work period.
19:07 #ussf: < jamie_> if we *don't* use the states - than the import will fail.
19:07 -!- mallory [~abc@167-89.nyc.dsl.access.net] has joined #ussf
19:07 #ussf: < dkg> hi mallory!
19:07 #ussf: < mallory> hey, folks
19:07 #ussf: < jamie_> I think the word "slowly" was bouncing around my head in an un-related way (or else it's a weird premonition)
19:07 #ussf: < LouNovak> so, we'll reduce rejected imports, is that it, or the whole import will fail?
19:07 #ussf: <@rossg> hi mallory
19:07 #ussf: < LouNovak> hey m
19:07 #ussf: < jamie_> only the records with states not allowed will fail.
19:07 #ussf: < jamie_> hi mallory!
19:07 #ussf: < jamie_> not the entire import.
19:07 #ussf: < dkg> working slowly is better than not failing
19:07 #ussf: < jamie_> I think enabling all states is a good idea.
19:07 #ussf: < dkg> uh, i mean better than failing
19:08 #ussf: <@rossg> lol...All States, All Countries...SAVE!
19:08 #ussf: < LouNovak> do I hear any objections?
19:08 #ussf: < LouNovak> going once...
19:09 #ussf: < LouNovak> SAVED
19:09 #ussf: < jamie_> wahoo!
19:09 #ussf: < LouNovak> go back to the checklist and hit the Domain Information Link please.
19:10 #ussf: < LouNovak> Domain Name: ussf2010.org
19:11 #ussf: < LouNovak> Description: United Stated Social Forum, Detroit, June 22-26
19:11 #ussf: < LouNovak> States
19:11 #ussf: < dkg> domain should be community.ussf2010.org
19:11 #ussf: < LouNovak> machine or domain?
19:11 #ussf: <@rossg> can someone translate the {domain.org} token?
19:12 #ussf: < dkg> rossg: what do you mean translate?
19:12 #ussf: < dkg> do you mean "what does {domain.name} token really mean?" ?
19:12 #ussf: < jamie_> it's a weird use of the term "domain name"
19:12 #ussf: <@rossg> {domain.org} is syntax for civicrm
19:13 #ussf: < jamie_> i think it refesrs to the friendly name of the organization - I think Unites States Social Forum
19:13 #ussf: < LouNovak> yeah I read it strictly, the description reads differently, what jamie says.
19:13 #ussf: <@rossg> My reading is that you could use both US Soc Forum {ussf2010.org}
19:15 #ussf: < dkg> after re-re-reading the help text, i think i agree with jamie_ above.
19:15 #ussf: < dkg> Domain Name = "United States Social Forum"
19:15 <jamie_> just getting caught up... can you try again while I tail the log file?
19:15 #ussf: < LouNovak> OK Domain Name as dkg specifies
19:16 #ussf: < LouNovak> Description?
19:16 #ussf: < LouNovak> United States Social Forum, Detroit, June 22-26 2010  perhaps
19:16 <rossg> done
19:16 #ussf: < jamie_> sure - sounds good to me.
19:16 #ussf: < mallory> there's something on the front page of ussf2010.org
19:16 <jamie_> oh uh.
19:16 <jamie_> Public key dc:33:03:b3:a4:5f:c4:04:b5:56:2d:1d:2f:07:86:f2 blacklisted (see ssh-vulnkey(1))
19:16 #ussf: < mallory> oh, sure, it doesn't need that much text
19:17 #ussf: < LouNovak> FROM Name: USSF 2010 Community
19:17 <jamie_> that means, I think, that your key was generated with a compromised version of ssh (prior to the debian ssh fiasco of last year).
19:17 #ussf: < LouNovak> Email Address do-not-reply@ussf2010.org
19:18 <jamie_> Public key dc:33:03:b3:a4:5f:c4:04:b5:56:2d:1d:2f:07:86:f2  blacklisted (see ssh-vulnkey(1))
19:18 <jamie_> that means, I think, that your key was generated with a  compromised version of ssh (prior to the debian ssh fiasco of  last year).
19:18 #ussf: < jamie_> i think info@ussf2010.org
19:18 #ussf: < dkg> i really dislike "do-not-reply" addresses
19:18 #ussf: < jamie_> at the moment that goes to josue and i.
19:18 <rossg> okay I'll create a new one.
19:18 #ussf: < dkg> why send someone mail if you're unwilling to receive mail from them?
19:18 #ussf: < mallory> i agree with both jamie_ and dkg
19:19 #ussf: < dkg> it feels heavy-handed
19:19 #ussf: < LouNovak> OK, info is set up and handled?
19:19 #ussf:  * jamie_ is guilty of that heavy-handedness on other sites.
19:19 #ussf: < LouNovak> the Press Release for June 22 09 mentions DetroitInfo@ussf2010.org
19:20 #ussf: < jamie_> that could work too.
19:20 #ussf: < jamie_> that goes to a mailbox on our servers - not sure who is checking it.
19:21 #ussf: < dkg> that would be good to know before the press release goes out
19:21 #ussf: < jamie_> i think using the same address as the press release is a good idea.
19:21 #ussf: < jamie_> and that we should make sure someone is checking it!
19:21 #ussf: < dkg> but i don't think we should make the web site generate e-mails "from" an account that is checked by folks who aren't prepared for it.
19:23 #ussf: < jamie_> ok... how about coming up with a specific address like community-web@ussf2010.org and have it deliver to the local address?
19:23 #ussf: < jamie_> that way we can always redirect it.
19:23 #ussf: < dkg> that's reasonable.
19:23 #ussf: < LouNovak> community-web@ussf2010.org  it is then
19:24 #ussf: < dkg> can we make it redirect to info@ for the moment, since at least one person here knows that it's being checked and can agree to fielding stray responses?
19:24 #ussf: < LouNovak> anyone have the office address handy?
19:24 #ussf: < jamie_> yes. I can do that.
19:25 #ussf: < LouNovak> brb
19:25 #ussf: < jamie_> is it the detroit welfare rights coalition?
19:25 <rossg> ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA636ykelFH/QRi4zmc8c9xinUw3xBNFWbsxoDCz8t8dDcXQL8/E+o2AguwtoGu7M0stWykAg0mn+GzK/hYnDBr4uEHVvc9BlO23h5KaDVGmMtK62btebNq4l/2kRfbaOIiiTtJxxPqqEa6LqKJZ9abJNsYPZm5NSpjGR/uZMEmtWojB3dP3Alks8IHBLgxG2X5oJahCZSDyKbEd7EtpFu8zTV9rGlFB3mJfwM5Vr0qSJI6Esu3BrNwugHsH+9l0l1orD0DJ9DH12XuUnv/qfOEw7d959rRcEqLoyd2WcKtFyemOb7Hd210ZFOJDs0A6GYlN8RYBnpsnpcNb5bWJfvGQ== ross@deleuze
19:26 #ussf: < LouNovak> MI welfare rights organization MWRO
19:27 #ussf: < jamie_> 23 E. Adams, 4th Floor, Detroit, MI 48226
19:27 #ussf: < jamie_> from http://www.mwro.org/contact.htm
19:27 #ussf: < LouNovak> thx Jamie
19:27 <jamie_> ok - now it's in place
19:28 <jamie_> can you try again?
19:28 #ussf: < jamie_> np :)
19:28 <rossg> success!
19:28 <jamie_> yay!
19:28 #ussf: <@rossg> I'm sure this was obvious to everyone but me, but {domain.name} token can be used in civimail to reference (i.e. print) the domain name field
19:29 #ussf: < LouNovak> Additional Domain Contact Information, email and phone. I got the 877 number for phone, do we want to use the same community-web... email here?
19:30 #ussf: < jamie_> yeah - sounds good to me.
19:31 #ussf: < LouNovak> hit save, it wants an existing valid email address
19:31 #ussf: < jamie_> hm - for which field?
19:31 #ussf: < LouNovak> From email and additional domain contact email as well
19:31 #ussf: < jamie_> sometimes I get validation errors if there are spaces after an email address.
19:32 #ussf: < mallory> ok, so i'm off!
19:32 #ussf: < LouNovak> damn spaces. that was it
19:32 #ussf: < LouNovak> thx again j
19:32 #ussf: < jamie_> bye mallory 
19:33 #ussf: < mallory> bye everyone!
19:33 #ussf: < mallory> keep up the good work
19:33 -!- mallory [~abc@167-89.nyc.dsl.access.net] has left #ussf []
19:33 #ussf: < LouNovak> OK on to Viewing and editting contacts, bye M
19:33 <rossg> Is there protocol for noting changes to css?
19:33 #ussf: < LouNovak> Site Preferences
19:34 #ussf: < LouNovak> woah, too many check boxes ...
19:34 #ussf: < jamie_> wow. lots of options here!
19:34 #ussf: < dkg> seems like drupal could trim() the e-=mail addresses and no one would mind
19:34 #ussf: < LouNovak> Grants? 
19:34 <jamie_> I think the best option would be to create a ticket at ict.ussf2010.org and then close it when you fix it.
19:34 #ussf: < LouNovak> I'm one for leaving this one alone for now
19:34 #ussf: < jamie_> i think less is more.
19:35 #ussf: < jamie_> I would rather add new functionality that people want later, then include extras things in the interface that will get in the way of training people.
19:36 #ussf: < jamie_> so - I think "cases" for example is for case work tracking, and can be unchecked.
19:36 #ussf: < jamie_> I also think we can uncheck membership.
19:37 #ussf: < LouNovak> OK, and Change Log and Grants as well
19:37 #ussf: < jamie_> ok
19:37 #ussf: < jamie_> sounds good to me.
19:37 #ussf: < LouNovak> I'll remove the same from the Contact Search section as well then
19:38 #ussf: < jamie_> sounds good.
19:39 #ussf: < jamie_> i think everything else we should probably keep.
19:39 #ussf: < LouNovak> how about that Contact Dashboard? no idea here
19:39 #ussf: < LouNovak> OK, including FCKEditor over TinyMCE?
19:40 #ussf: < jamie_> I think we can remove memberships from the dash board since I don't think we'll be using it.
19:40 #ussf: < jamie_> no idea on wysiwyg - i guess the default is the way to go.
19:41 #ussf: < LouNovak> alright then, ready to SAVE unless...
19:41 #ussf: < jamie_> sounds good!
19:41 #ussf: < LouNovak> Saved and on to Settings Adressess
19:42 #ussf: < LouNovak> Here I'm seeing a lot if {tags} 
19:42 #ussf: < jamie_> i think probably defaults all the way through... until we start working on generating mailing labels.
19:42 #ussf: < LouNovak> OK
19:43 #ussf: < LouNovak> do we use a USPS adress standardization service?
19:43 #ussf: <@rossg> Is anyone else getting the screen cut off?
19:44 #ussf: < jamie_> rossg: you mean horizonatally? yes - I think it's probably theme related.
19:44 #ussf: < LouNovak> Mapping Provider, Yahoo or Google? or leave blank?
19:44 #ussf: < jamie_> LouNovak: let's leave blank for now.
19:44 #ussf: <@rossg> jamie_: it might make sense to have a civicrm admin theme
19:44 #ussf: < LouNovak> micellaneous
19:45 #ussf: < LouNovak> we gonna use CAPTCHAs
19:45 #ussf: < LouNovak> ?
19:45 #ussf: < jamie_> i'd say blank for now.... maybe a later project.
19:47 #ussf: < LouNovak> I say leave Misc alone and move on to Outbound Mail
19:48 #ussf: < LouNovak> SMTP of Sendmail (as I'm assuming we'll be sending email using civi)
19:48 #ussf: < LouNovak> SMTP *or* Sendmail
19:49 #ussf: < dkg> i think sending mail through the local MTA (what they call "sendmail") is the way to go
19:49 #ussf: <@rossg> MTA?
19:49 #ussf: < jamie_> I think that ultimately we want to use civimail - which is it's own beast to configure.
19:49 #ussf: < dkg> mail transfer agent
19:49 #ussf: < jamie_> however, in the meantime, I'd like us to use the smtp server: bulk.mayfirst.org.
19:50 #ussf: < jamie_> that's our server that is dedicated to sending bulk mail for mfpl.
19:50 #ussf: < LouNovak> any authentication required for bulk.mayfirst.org?
19:50 #ussf: < jamie_> nope - not if you are sending from an IP address on our network (like mendes is).
19:50 #ussf: < dkg> i'm happy to defer to jamie_ on this.
19:50 #ussf: < LouNovak> standard port: 25?
19:51 #ussf: < jamie_> yes
19:51 #ussf: < LouNovak> OK set and saved.
19:52 #ussf: < LouNovak> From Email Address Options appears to use the Domain Name and email address we set previously 
19:52 #ussf: < LouNovak> reads as: "USSF 2010 Community"<community-web@ussf2010.org>
19:52 #ussf: < jamie_> looks good to me.
19:52 #ussf: < LouNovak> Weight???
19:52 #ussf: < jamie_> I'm noting that we have the option to enter multiple from addresses (for future reference).
19:53 #ussf: < jamie_> I think weight is if we have more than one address - it would set which one appears higher on the drop down list when sending an email.
19:53 #ussf: < LouNovak> ahhh, I'll leave it at 1
19:54 #ussf: < LouNovak> now we're at Payment Processors, can we do that now or should we put off until later? 
19:55 #ussf: < LouNovak> In fact, I see it's almost 8pm. Should we call it a day and come back to the rest later?
19:57 #ussf: <@rossg> I think it would be useful to have an extended discussion on groups and tags, perhaps a wiki page
19:57 #ussf: < LouNovak> Quick glance at Anonymous Permissions looks like defaults make sense...
19:57 #ussf: < LouNovak> Good idea r
19:57 #ussf: < jamie_> yes - I agree - the tags discussion should be carefully had!
19:57 #ussf: < jamie_> if we don't do it carefully, we can end up with a royal mess.
19:57 #ussf: < jamie_> I'm fine with calling it a day. I thikn we've made huge progress!
19:58 #ussf: <@rossg> Agreed!  
19:58 #ussf: < LouNovak> Great, I could use a bit of rest myself, been a busy weekend. Check out www.peoplessumit.org
19:58 #ussf: < LouNovak> www.peoplessummit.org
19:59 #ussf: <@rossg> I wonder if it would make sense to look at the 07 contact db as a way to think through tags and groups
19:59 #ussf: < LouNovak> We're handing out USSF2010 cards to all
19:59 #ussf: < jamie_> wow - that looks great lou
20:00 #ussf: <@rossg> nice lou
20:00 #ussf: < LouNovak> It's gotten off to a slow start this afternoon, I hope for bigger things when I return this evening
20:00 #ussf: < jamie_> rossg: yes - I think that's a good idea. I think sarah might offer some help as well - since I think she did some work on massaging the data from the 07 database.
20:00 #ussf: < LouNovak> Wish you were here folks...
20:00 #ussf: < jamie_> me too!
20:01 #ussf: <@rossg> same here.
20:01 #ussf: < jamie_> I will post our session on our wiki - along with links to the micah's screen shots and the video :).
20:01 #ussf: < LouNovak> and will someone start the tags page please?
20:02 #ussf: <@rossg> I'll do that
20:02 #ussf: < LouNovak> thanks rossg
20:02 #ussf: < jamie_> great - thanks ross.
20:02 #ussf: < LouNovak> OK, I'm outta here folks, enjoy what remains of the weekend.
20:02 #ussf: <@rossg> np...Should it be groups and tags together?
20:02 #ussf: < jamie_> I've always been confused with civi about when to use groups and when to use tags
20:03 #ussf: <@rossg> Rock Motor city Lou
20:03 #ussf: < jamie_> so my sense is that we should tackle them together as a way of sorting it out.
20:03 #ussf: <@rossg> Sounds right to me. 
20:03 -!- LouNovak [~lou@adsl-76-226-253-14.dsl.sfldmi.sbcglobal.net] has left #ussf []
20:06 #ussf: <@rossg> jamie_: which wiki page are you using for today's work?
20:07 #ussf: < jamie_> i haven't set one up yet.
20:08 #ussf: < jamie_> how about workday-ict-20090614
20:08 #ussf: <@rossg> Sounds good...Just wasn't sure which working group this would fall under.
20:09 #ussf: < jamie_> http://ict.ussf2010.org/wiki/workday-ict-20090614