We refer to the proposal as "living" to mean that we need everyone to participate in shaping it now, during, and after the social forum. ICT is never a finished product, but instead a collaborative process, just like the social forum itself.
Every page provides a link at the bottom to enable you to post a comment. Please help us out by giving us feedback! Even if you agree, hearing from you will make an important contribution to our work.
When providing feedback, you may choose to omit your name or organizational affiliation. However, providing us that information will enable us to better evaluate your comments.
Please be as detailed as possible in your feedback. Also, please read existing comments before posting and build on what has been said whenever possible.
The Introduction includes who we are and how we understand our role.
If you are interested in understanding how we developed this introduction, you may want to jump to the original outline here.
As the preparations for the first US Social Forum started to gain some momentum, the need for concentrated attention on the technology aspects emerged. May First/People Link, building on their experience with the Republican National Convention, put a call out for social justice technologists in NYC to come together to support the USSF.
This group of social justice techs, mostly physically located in NYC (although Atlanta and Milwaukee have been represented), is the technology sub-committee of the communications working group of the USSF. It is clear that this group needs to grow if we are going to be successful.
The immediate priority of this group is to help bring about a successful US Social Forum at the end of June 2007 in Atlanta, GA. Another immediate priority, because it has direct impact on the first, is to redefine what it means to be a technologist that is working for social change.
These priorities illustrate the need for a broad network of technologists that want to participate in creating real change in our society. A national network that creates an environment where technologists support and learn from each other. A national network that has experience working with, and therefore has earned the respect of, grassroots movement-building organizations all over the country.
More information about the IC is available here.
As stated on the USSF website,
"The USSF will provide space to build relationships, learn from each other's experiences, share our analysis of the problems our communities face, and bring renewed insight and inspiration.
"It will help develop leadership and develop consciousness, vision, and strategy needed to realize another world."
We understand that we take on a very specific and critically important role in the Social Forum's organization: to provide technology and tools that will enable and enhance the organization of the Social Forum, the work of the Forum while it's going on, and the appropriate and contributive follow-up to it by all its participants.
At the same time we understand that, to be truly productive, this work must be reflective of and driven by the Social Forum's
principles of inclusion, democracy and relationship-building.
While it may be possible for a small group of "techies" to build some of what is needed, such efforts would fall short of both the Forum's real needs and potential. We believe the development of the Social Forum's Internet and technology capability should be an exercise in collaborative planning and development by the entire Social Forum organizing community.
In that sense, this workgroup sees itself as an organizing group committed to using technology development to:
In short, this is not only work to make the real Social Forum's work possible, it is part of the Social Forum's organizing and should be reflective of the Social Forum's approach, goals and vision.
Making that happen is the responsibility of this Group.
We will publish this tech proposal for public feedback by January 1, 2007 in sections, with public threaded comments enabled on each section. Our goal in organizing the feedback process is too maximize the amount of feedback we can get from activists with varying degrees of technical experience. We want everyone to contribute to our thinking.
We will remove abusive, spamming, or off-topic comments, but we will use discretion with this ability. if you think your comment has been removed improperly, please mail ussf-tech-feedback -at- ussf2007.mayfirst.org for further review.
The initial draft will contain a set of problem areas that we expect will need to be addressed technically ("needs"). During the first review process we want all interested parties to point out needs that we haven't anticipated, clarify already-posted needs, or argue that existing needs are not necessary or of low importance.
The discussion of "need" will take place without any discussion of technically how the need will be addressed. This approach is designed to allow activists with little technical experience to participate fully in the discussion of how to understand what is needed. Comments that begin discussion of what software to use, or how the solution to the need should be engineered will be disregarded or unpublished.
Each need will be posted with a proposed review deadline period (minimally set to one week from the post date). The review deadline will vary depending on the scope/complexity (complex needs will have a longer comment period) and the urgency (urgent needs will have a shorter period).
The ICT sub group will review the posted comments, and post summaries that reflect our change in thinking based on the feedback, preserving the originally posted need and all commentary on it. In addition, we will attempt to prioritize the separate needs, and state our reasons behind the prioritization. The threads will remain open to the public both for reading and commenting on even after the need as been addressed.
After the commentary deadline has passed, a proposal for how to accomplish the need will be published. The original need will have a link to this post, allowing users to easily read the discussion on the need, and then click on a link to participate in a discussion on how to implement the need. In addition, the discussion on how to implement the need will have a corresponding link back to the discussion of the need itself.
We look forward to your participation in this process so that your needs are met.
In addition to these three areas, the technology working group also understands the technology work as being broken down into three phases: before, during, and after. The technology plan will cover ideas around how technology can support the forum during all three periods.
To democratize the process of developing technology for the US Social Forum, we have broken down this part of the proposal into individual technology "issues." We encourage people to add comments to the issues, letting us know what you think about their importance and our proposals for how to address them.
There are three "types" of issues:
1. Need - a "need" is a plain English description of what is desired. It does not include any technological language or suggestions for how to solve the need. All needs should be written so that they can be understood by people with limited technology experience.
2. Implementation - an "implementation" is a proposal for how to implement a particular need (once there has been enough discussion that we can feel we fully understand the need). Implementation issues are technical.
3. Bug - a "bug" is an issue that describes something that is supposed to work, but is not working.
To view our list of issues, click the link below. At the top of the page, you can limit the issues by type (need, implementation, bug) or by any of the other fields available.
The Appendices contains meeting notes and other historical documents. They are published here to give new people coming into the process an opportunity to see how the current site and technology tools have developed.
Another important spot to visit: The ICT mailing list archives.
All meeting notes are posted in this chapter. If you are posting notes: Please give your post a weight of 0 and Title the notes with the date the meeting took place (e.g. 2006-11-01). This will keep the notes in chronological order, making it easier to follow.
big question: to cck or not to CCK on the endorsement forms. We'll use webforms. Nat and Josue will work on this.
Subject: Recruitment and Planning Process
Facilitator:
Agenda:
* What kind of roles are we looking to fill?
* What kind of background do we want to make known in terms of what has and explicitly hasn't been decided?
I think there is a larger scale question about process and how we are going to work, that we need to address if this committee is going to grow.
Agenda:
Notes:
Development log
All ICT related nodes should be book nodes so they can be better organized for new people coming in
byoung has been volunteered (in absentia) to review the system for registering users/organizations for the social forum - to make sure it's working and weed out tests and spam, etc.
Issue: drupal web site user registration: we will not allow anonymous user registration because it makes it easier to train new people (you tell them - go here to get your account, we'll talk tomorrow on how to use it). To prevent random people from registering: it won't be linked to (you have to know the URL) and there will be text explaining that random people will not be allowed to register (at this point)
More log issues: please check the dev log for the details - decisions are posted as comments. Logs that have no comments were deemed low priority and skipped for now.
Goals for the rest of December
We will NOT be meeting next sunday the 10th. We will be meeting Sunday the 17th. We won't be meeting Dec. 24 or Dec. 31. We MAY be meeting on an alternate date in late December - to be decided on the 17th depending on how much more work we have to do.
Our goal for the end of December is to finish:
Volunteer Database
First draft of tech planning proposal
Tech Planning Proposal
Jamie will work with Mark to get draft of needs and dkg to get down the planning process
Josue wants help - someone to finish the edits on his section. Amanda will help
Alfredo is mostly done with his
Volunteer Database
CiviCRM was discussed - but we felt it was too complicated for the task at hand.
We decided to go with a CCK node for volunteers to sign up and a basebuilder back end for volunteer coordinators to manage
Outreach Plan
There is a loose group of techs in NYC that get together from time to time - they are organizing "technology infrastructure audits" to discuss how technology is used to address certain problems. We decided to put the USSF as the first of these audits - to take place in person in Brooklyn on Sunday January 21. Details to follow.
Much more discussion on outreach - we will need more time to discuss.
Agenda:
plone v. drupal
outreach (including the email, and dealing with people who respond to our outreach)
needs and the need submission process
tech plan
spam
(16:24:17) ana: so there are several issues that are waiting to be figured out:
(16:25:01) ana: 0) getting the 'administrative use only' to disappear unless someone is a site editor or has similar privilages
(16:25:14) ana: 1) getting nodetogo to work
(16:25:41) ana: 2) getting subforms to not shoot out delayed error messages about required fields
(16:26:11) ana: 3) putting the 'create' button at the bottom of the subform entry instead of at the top
(16:27:09) ana: 4) getting subforms to auto increment nid's so that we don't get errors about that, and can still continue to test and delete people and orgs without getting errors...
(16:27:48) libkuman: damn, 4 sucks ass if thats whats really happening
(16:28:03) ana: 5) customizing a script/s for when we integrate with paypal so that payment information gets automatically stored in the 'administrative use section.
(16:28:28) ana: libkuman: see registration hang ups emails. it was what alfredo suggested was happening
(16:28:54) libkuman: yeah, i saw his suggestions, i didn't see if fixing that fixed anything (if anybody tried)
(16:29:08) ana: don't think anyone tried...
(16:29:14) libkuman: nod
(16:29:21) ana: let me look a minute to see if there was anything else...
(16:30:30) ana: I think that is it for now...
(16:30:47) ana: do folks want to start the bidding?
(16:31:35) libkuman: ok, lets start them, although i'm really bummed eric can't be here for this (his mom has been in and out of hospital all week :(
(16:31:45) libkuman: cuz these are some scary issues
(16:31:57) ana: sad to hear...is she going to be okay?
(16:31:58) libkuman: i guess we should just do them in order
(16:32:52) libkuman: yes and no, she has pretty severe dementia and having a surgery last week really messed with her mind
(16:33:23) ana: wow...sad.
(16:33:39) libkuman: yeah, definitely no fun for his family
(16:33:54) ana: very upsetting...
(16:33:55) libkuman: ok, so should we start with 0)
(16:34:18) libkuman: can you show me an example?
(16:34:31) ana: http://www.ussf2007.org/en/node/add/content_ussf_registration
(16:34:41) ana: under organizations and individuals
(16:34:49) ana: the last 'subform'
(16:36:04) libkuman: gotcha
(16:36:31) libkuman: so basically somebody from the general public fills out registration form
(16:36:45) libkuman: than a site admin goes and edits the node and fills in this information?
(16:37:11) ana: exactly, or alternately, when they pay with paypal, it gets filled in automatically
(16:37:28) ana: because people who sign up online are going to have to pay with paypal.
(16:37:43) ana: others will send in theri registrations, and someone will hand enter the whole shebang
(16:37:54) libkuman: ok, so we have two options
(16:38:28) libkuman: first, we can figure out how to have fields be on a per role basis, which i've heard mention that functionality either exists, or is being currently worked on
(16:39:02) libkuman: second, we don't make this a subform
(16:39:38) ana: how will the administrative stuff get linked with the registration?
(16:40:08) libkuman: haven't thought it out, it might be a giant pain in the ass
(16:40:56) ana: i think the first option makes the most sense to me, actually, from the perspective of consistency
(16:41:14) ana: unless there is another way to make child/parent relationships between cck nodes
(16:41:19) libkuman: i agree, if somebody has successfully coded it for us
(16:41:27) libkuman: there are
(16:41:32) libkuman: just not on the same form
(16:41:41) ana: how would this work?
(16:42:04) libkuman: actually, now that i think about it it would give the filler outer a link to create the new node
(16:42:20) libkuman: sorry, i'm jumbling many thoughts at once
(16:42:23) ana: you lost me
(16:42:53) ana: is dkg still on?
(16:42:53) libkuman: actually before we go down the road of ditching subform for this, lets really look at how to make subform work for this
(16:43:09) libkuman: he's probably updating computers at norio, so he'll be on and off
(16:43:17) ana: i agree about making subforms work
(16:43:18) libkuman: he's covering my shift today
(16:43:22) ana: ahh
(16:43:38) libkuman: so i am now looking at http://drupal.org/node/63240
(16:44:00) dkg: i'm here.
(16:44:27) ana: this is what we would need...will/does/can we make it work?
(16:44:34) dkg: sorry. i'm actually breaking computers at no rio, apparently, and monitoring a mail server which is crashing and burning.
(16:44:35) dkg: sigh...
(16:45:14) ana: sokay. we're just wonderring about stuff that you'd probably be able to have some good input for...
(16:45:15) libkuman: trying to figure out if this is just an idea, or if anybody did anything with it
(16:45:36) dkg: reading the buffer...
(16:46:13) ana: views...
(16:46:22) ana: would this work with subforms?
(16:47:14) libkuman: in what way?
(16:48:03) ana: well, first, is it an actual solution?
(16:48:11) ana: or just a proposal?
(16:48:21) ana: i see that Ber did something...
(16:48:29) libkuman: http://drupal.org/project/cck_field_perms
(16:49:10) ana: great! can we implement this?
(16:50:01) libkuman: maybe, this kind of scares me though "Note: that when you enable this module for a specific field, you must grant view access for users- when you enable it, it strips view access for all users except the root user. If you disable this module, all access is returned to normal."
(16:50:30) libkuman: for one i really don't understand what he is saying
(16:50:41) ana: i read that too. i want it to restrict view of the entire nodetype 'Administrative'
(16:50:58) ana: but individual fields would work too
(16:51:14) libkuman: i think individual fields is the only way this module works
(16:51:15) ana: yeah, view is mostly for assembling lists, etc, no?
(16:51:48) ana: like the tech issues list, or the proposals list
(16:51:51) libkuman: is there any reason why a non admin should be able to view a registration node?
(16:52:18) libkuman: or view their already filled out registration node?
(16:52:20) ana: site editors - what is alice and the staff at project south?
(16:52:41) ana: yes...what if the org wants to edit or add to the list of attendees
(16:53:01) ana: but that would ghappen at a different time
(16:53:27) libkuman: lets take one step back here, when you were talking about "view"
(16:53:40) libkuman: did you mean lookin gat the node in view mode?
(16:53:48) ana: yew
(16:53:50) ana: yes
(16:53:58) libkuman: or were you talking about using the "views" module to look at a list of nodes
(16:53:59) libkuman: ok
(16:54:08) ana: the second
(16:54:13) libkuman: oh
(16:54:16) ana: i think
(16:54:23) ana: i never went to drupal camp
(16:54:26) libkuman: he he
(16:54:34) libkuman: yeah, its a little confusing
(16:54:42) libkuman: for a node, there are different ways to look at it
(16:54:50) libkuman: "edit" mode and "view" mode
(16:55:07) libkuman: however, there is a Views module, that lets you create custom lists of nodes for viewing
(16:55:17) ana: i was refereing to the 2nd
(16:55:24) libkuman: gotcha
(16:55:52) ana: the person would not be in view or edit mode. we just need to get them through the submitting process without filling any administrative stuff out
(16:56:02) libkuman: so, in the links i sent you, when they are talking about "view" they are talking about an indidual node's view mode
(16:56:14) ana: and then LATER, if they want to edit, to give them access to editing or adding attendees
(16:56:22) ana: ahh
(16:57:14) ana: so then does them refering to views for this module make sense to you?
(16:57:35) ana: is it a view when you are creating the node?
(16:58:47) libkuman: ok, let me take a step back here and describe the ideal flow of creating a node using the cck field permission module
(16:59:30) libkuman: 0. user clicks a link to get to them in the registration form
(17:00:42) libkuman: 1. they will be on the registration node submit form in the mode "create", which is almost the same as "edit" except we don't have a nodeId yet
(17:01:15) libkuman: 2. the node CCk field permission module should be able to restrict fields which the user doesn't have permission to fill out
(17:02:05) libkuman: 3. which should only be "Administrative Use Only" field
(17:02:17) libkuman: 4. user then submits their node
(17:02:36) ana: yes. great.
(17:02:43) ana: how does that get configured with respect to what they were saying about views though?
(17:02:57) libkuman: 5. admin user goes to a page which is a "View" of all the registration nodes
(17:03:22) ana: hold up
(17:03:24) libkuman: 6. admin user clicks on one of the registration nodes and goes to the "view" mode for the node
(17:03:36) ***amanda peers in. I'm actually going to quit unless you want me for something tonight.
(17:03:45) libkuman: na, have a good night amanda
(17:03:57) amanda: g'nite
(17:03:59) amanda left the room (leaving).
(17:04:03) ana: bye amanda!
(17:04:21) ana: only user who pay via paypal will be enterring this form
(17:04:29) ana: and we want paypal to enter the other stuff
(17:04:39) ana: but for admins to be able to view that data later
(17:04:41) ana: secondly
(17:04:53) ana: when a person sends their registration by mail
(17:05:16) ana: a site eiditor will input thier entire information, including the administrative use only fields
(17:05:24) ana: does that make sense?
(17:05:30) libkuman: yes
(17:06:06) libkuman: so skip 5 and 6
(17:06:20) ana: yes
(17:06:37) ana: except to check on information
(17:06:42) libkuman: nod
(17:07:15) libkuman: so i'll continue with some other use case steps
(17:07:58) libkuman: 5. user who submits a registration form wants to go back and edit their form (i.e. they forgot to add a person for their organization registration
(17:08:30) libkuman: 6. somehow (i'm not sure yet) they find their registration node
(17:08:52) libkuman: 7. they click on a link and get brought to their registration in "view" mode
(17:08:59) ana: yes
(17:09:17) libkuman: ok, so to answer your earlier question
(17:09:18) libkuman: how does that get configured with respect to what they
(17:09:18) ana: only that last use case scenario is less important to figure out now
(17:09:19) libkuman: were saying about views though?
(17:09:50) ana: i do not know...I printed it out...
(17:10:03) libkuman: ?
(17:10:25) ana: i think it's more important to focus on the first scenario, and tell people that if they add people, they will need to call in
(17:10:29) ana: or email in.
(17:11:08) libkuman: yeah, i was just trying to explain what the "view" issues mentioned on the links i sent out
(17:11:34) libkuman: that if the user goes back to their submitted node, the field permission things might have some issues in that case
(17:11:35) ana: i think the user module, that would have them recognized when they login, would be how we would point them to a specific node for editing later...?
(17:11:55) libkuman: i.e. fields might get displayed that didn't show up on submit registration page
(17:12:04) ana: that's okay with me for now...
(17:12:18) ana: especially since that last part is icing on the cake
(17:12:32) libkuman: yeah, i jsut wanted to make sure you understood the issues with this module
(17:12:41) ana: thanks
(17:12:51) libkuman: so if i installed it, do you think you could play around with it?
(17:13:00) libkuman: is there more with this issue that you want to discuss?
(17:13:00) ana: yes. absolutely
(17:13:13) ana: not unless I run into issues later...
(17:13:17) ana: so no for now...
(17:13:42) libkuman: ok, i'll install it after we're done and let you know
(17:13:48) ana: thanks!
(17:14:00) ana: should we more to the next?
(17:14:10) libkuman: yes, nodegoto
(17:14:57) ana: when i submit a registration, it sends me to the 'view' of it. i want to be able to have it eventually take the person to a paypal.
(17:15:13) ana: but am experimenting by having it send me to other pages
(17:15:20) ana: and it doesn't seem to be working...
(17:16:23) libkuman: can you remind me where the nodegoto settings are?
(17:16:48) ana: under admin/settings/
(17:17:43) libkuman: gotcha, let me look at things for a sec
(17:18:04) ana: sure...
(17:22:51) libkuman: ok, so i just did a test, i configured nodegoto for the page content type just as a test
(17:23:04) libkuman: i made it go to the payment page
(17:23:10) libkuman: which it succssfully did
(17:23:33) ana: so is the issue about the subforms cofusing things a little?
(17:23:34) libkuman: so i'm scared this is another subform issue :(
(17:23:43) ana: i had a feeling
(17:24:00) ana: what's the prognosis...we need to to work or else we got nothing...
(17:25:37) libkuman: i'm a little stumped right now, i just wish i had more time this week, too many freakin projects at the same time
(17:25:56) libkuman: a workaround could be a computed field
(17:26:10) libkuman: that appears at the top of the registration node in view mode
(17:26:15) ana: i just had a thought
(17:26:41) ana: actually, keep going
(17:26:44) ana: ...
(17:27:19) libkuman: that contains all of the text on
(17:27:25) libkuman: the /payment page
(17:27:47) libkuman: computed fields don't show up on the submit form
(17:28:13) libkuman: and computed fields can just be display text
(17:28:22) libkuman: and could include links
(17:28:42) ana: but the user would have to link themselves...?
(17:29:02) libkuman: i'm a little confused now
(17:29:13) libkuman: in the proposed flow using nodegoto
(17:29:21) libkuman: which page should it be landing on?
(17:29:30) ana: we would want them to get sent to paypal
(17:30:00) libkuman: yes, tehn the answer to your question is they would have to link themselves
(17:30:11) ana: that wouldn't work...
(17:30:47) libkuman: i can see how it would not be ideal, but am confused on why it wouldn't work at all?
(17:31:05) ana: it would make Alice angry.
(17:31:22) ana: and would give the option for that person to miss going to paypal/
(17:31:36) ana: which would make things administratively difficult...
(17:31:42) ana: for the ground troups
(17:32:13) ana: does that make sense?
(17:32:51) libkuman: yes, it makes sense, i don't necessarily agree but Alice isn't here to debate about it so i'll just take it as a requirement
(17:33:21) ana: thanks
(17:33:53) ana: i'm wonderring if there is a way to have two registration links
(17:33:59) ana: so as to avoid using subforms
(17:34:04) ana: one for inidividuals
(17:34:09) ana: and one for organizations
(17:34:36) ana: the individual administrative fields could disappear for users
(17:34:40) ana: in each
(17:34:56) ana: that way, we don;t need subforms
(17:35:20) libkuman: so we wouldnt' need an parent child node relationships in that case?
(17:35:31) ana: exactly
(17:35:53) ana: it's not ideal because it would require different paypal scripts for inserting payment information
(17:36:02) ana: does that make sense?
(17:36:23) libkuman: yeah
(17:36:29) ana: it also would not give us the ability to have inidividuals listed individually who come as an organization
(17:36:52) ana: but that might be a small price to pay, administratively
(17:37:07) ana: they'd have to be accounted for separately by the ground folks... does that make sense?
(17:37:30) libkuman: as much as my head can wrap around it at this point, yes
(17:37:50) ana: in administerring registrations, it would make it harder to get a list of people.
(17:38:03) ana: you would need to have a list of people with organizations,
(17:38:11) ana: and then a list of inidividually registered folk
(17:38:29) ana: it would make things harder to track
(17:38:47) ana: and make follow up with inidividuals who registered with an organization more difficult
(17:39:16) ana: because we'd have to ask for less information from them
(17:39:29) ana: orelse the form would extend infinitely
(17:39:52) ana: but should we go to this plan, and try it out?
(17:40:14) ana: or are the subforms solvable in the next couple weeks?
(17:40:16) libkuman: hmmm, having a lot of trouble getting my head wrapped around this
(17:40:42) ana: should i try again...?
(17:40:45) ana: i don;t ming
(17:40:47) ana: mind
(17:40:51) libkuman: i would like to look deeper into subform stuff, but i'm concerned i don't have the time
(17:41:09) ana: i'm worried about time too.
(17:41:22) ana: and am feeling like we need something that ultimately will work.
(17:41:27) ana: soon
(17:41:28) libkuman: how about this, lets walk through the remaining issues
(17:41:48) libkuman: talk about them, then have another meeting this week
(17:41:54) libkuman: like tuesday or wednesday
(17:41:57) ana: a lot of them are subforms related...
(17:42:15) ana: tuesday or wednesday sounds good. I'm scrolling up now to look...
(17:42:18) libkuman: yeah, even if we can't solve them i'd like to make sure i understand the issue completely
(17:42:37) libkuman: i'd also like to get other people's input before we completely switch boats midstream
(17:42:51) libkuman: especially since i don't trust my mind right now for this big of a decision
(17:43:16) ana: (16:25:41) ana: 2) getting subforms to not shoot out delayed error messages about required fields
(16:26:11) ana: 3) putting the 'create' button at the bottom of the subform entry instead of at the top
(16:27:09) ana: 4) getting subforms to auto increment nid's so that we don't get errors about that, and can still continue to test and delete people and orgs without getting errors...
(16:27:48) libkuman: damn, 4 sucks ass if thats whats really happening
(16:28:03) ana: 5) customizing a script/s for when we integrate with paypal so that payment information gets automatically stored in the 'administrative use section.
(17:43:33) ana: for number 2...
(17:43:46) libkuman: ok, so can we just cover these issues enough so i udnerstand them for now?
(17:44:01) ana: the real issue might be that when I enter an individual and hit 'create' it gives me an error message:...
(17:44:43) ana: Warning: Duplicate entry '628-0' for key 1 query: INSERT INTO node_data_field_participation_interests (field_participation_interests_value, vid, nid, delta) VALUES ('', 628, 560, 0) in /usr/local/share/drupal-4.7.6/includes/database.mysql.inc on line 121
Warning: Duplicate entry '628-0' for key 1 query: INSERT INTO node_data_field_sector (field_sector_value, vid, nid, delta) VALUES ('', 628, 560, 0) in /usr/local/share/drupal-4.7.6/includes/database.mysql.inc on line 121
Warning: Cannot modify header information - headers already sent by (output started at /usr/local/share/drupal-4.7.6/includes/database.mysql.inc:121) in /usr/local/share/drupal-4.7.6/includes/common.inc on line 267
(17:45:32) ana: if after filling out the individual information, I just press 'submit' at the bottom, it ignores what I put into the individual node, and just registeres the registration node
(17:46:00) libkuman: so if you hit submit without hitting the "create" link it just ignores the subform information?
(17:46:06) ana: exactly
(17:46:19) ana: and if you hit create, you get that message
(17:46:44) libkuman: ok, i'll take a deeper look into what is causing the error message before we meet again
(17:47:09) ana: okay. if you look, it think that 2-4 are all related issues.
(17:47:09) libkuman: but, if submit doesnt' automaticially trigger the subnode create action
(17:47:21) ana: that subforms isn't working in an integrated way with itself.
(17:47:48) libkuman: that might be a showstopper for subforms, if that doesnt' work it won't work for us at all
(17:47:59) ana: the last issue is just having paypal automatically enter stuff into the originating node's administrative fields which will be hidden from the user
(17:48:02) ana: exactly.
(17:48:09) libkuman: can't trust users with that type of compication
(17:48:14) ana: i think subforms might at this point be a show stopper
(17:49:02) libkuman: unfortunately i'm agreeing, and unless i find some encouraging results by the time we meet again i think we should scrap it
(17:49:09) ana: but can we configure on entry of paypal information that some of that information gets stored in cck fields?
(17:49:19) ana: easily?
(17:49:25) libkuman: ok, step me through the use case here
(17:49:31) ana: that would be the only remaining issue...
(17:49:34) ana: okay...
(17:49:37) libkuman: i'm confused when you say "paypal automatically enter"
(17:49:53) ana: organization use case:
(17:50:28) ana: 0) from registration page, user clicks link to register either an organization or an individual
(17:50:41) ana: they will be separate links to separate nodetypes
(17:51:17) ana: 1) user enters information in fields, but not in 'admin' fields cause they are hidden.
(17:51:40) ana: 2) user clicks submit and is take to paypalvis a vis nodetogo
(17:52:40) ana: 3) user enters paypal information, and moves through the paypal process. At the last part when they click 'submit' two things happen:
(17:52:50) ana: three things
(17:53:14) ana: 4.1) their money goes to our paypal account
(17:53:50) ana: 4.2) they get transfered back to a page on our website that lets them play some more (page to be determined)
(17:54:37) ana: 4.3) the payment number, payment date, and payment amount get put in the invisible 'admin' fields in the originating node (which could be either the oragnization node or the individual node).
(17:55:19) libkuman: how do we get the three fields in 4.3?
(17:55:29) libkuman: does that come in the query string of the url they use to link to us?
(17:55:41) libkuman: or do we have to do API calls to paypal?
(17:55:53) ana: they will be part of those nodes, but hidden from the user
(17:56:23) ana: i can't answer that without knowing more information. i just know that we did this at Bioneers
(17:56:54) ana: what are the pros and cons fo each?
(17:56:58) libkuman: well, either way we just create a drupal page, that has a code snippit to insert this information into CCK nodes
(17:57:01) ana: which is more doable?
(17:57:10) libkuman: both are easily doable
(17:57:16) libkuman: it all depends on how paypal does it
(17:57:17) ana: great. good to hear.
(17:57:28) ana: how can i help you find out?
(17:57:29) libkuman: actually, let me rephrase that
(17:57:43) libkuman: it'll be easy once we get the info
(17:57:59) libkuman: if it requires API calls it might be more difficult
(17:58:06) ana: okay. so do you want to look for the info (you might know better what you are looking for
(17:58:29) ana: or i could do some homework and see what I can find before we meet next...
(17:59:05) libkuman: if i'm going to look into subforms before we meet, i don't think i'll have time
(17:59:18) libkuman: feel free to bounce things off me though if you have time
(17:59:37) ana: great. i'll go to paypal and take a look...
(17:59:37) libkuman: shit, its 8 oclock, i really got to run an errand soon
(17:59:44) ana: okay. thanks.
(17:59:52) libkuman: so do you want to meet on wednesday?
(17:59:53) ana: when do you want to meet next?
(17:59:59) ana: and do others want to be there>
(18:00:12) libkuman: i could do anytime, later probably better
(18:00:33) ana: okay. Let's meet at 9 your time? pm?
(18:00:35) libkuman: i can send our time out to the list and see anybody wants to show up
(18:00:42) ana: is that too late?
(18:00:50) ana: i can do 8 also?
(18:00:58) libkuman: yeah, lets say 8
(18:01:06) ana: okay. 8 on wednesday.
(18:01:07) libkuman: i'll send out email, hopefully eric can make it
(18:01:18) ana: great. thansk again, mark
(18:01:24) libkuman: ok, i got to run
(18:01:30) ana: bye!
(18:01:40) ana: I think jamie is logging this...
(18:01:42) libkuman: thank you! you are a life saver on this project
(18:01:47) ana: thanks.
(18:01:52) ana: we'll get through this...
(11:08:40) Channel founder on ussf is libkuman
(11:08:46) anawillem: hello folks.
(12:03:02) anawillem: So are we having a registration meeting? libkuman, jamie, eric, nat?
(12:03:11) You are now known as ana
(12:07:52) abh [abh@static-70-107-231-75.ny325.east.verizon.net] entered the room.
(12:08:02) abh: (i'm just here to listen)
(12:08:19) ana: no one else is hear yet, it doesn't seem like...
(12:08:23) ana: here
(12:08:51) ana: libkuman, jamie, eric, nat...
(12:16:18) ana: abh did you get my email? I'm emailing folks now...to remind them
(12:18:26) abh: i did.
(12:18:44) abh: usually, right about now, Mark is showing up in Sunset Park
(12:19:00) ana: what is sunset park?
(12:19:05) ana: i'm not a local
(12:19:17) abh: Sunset Park is a neighborhood.
(12:19:20) abh: Alfredo lives there
(12:19:24) ana: ahh
(12:19:26) abh: and Mayfirst's offices are there
(12:19:34) abh: in Alfredo's house
(12:19:46) abh: and on Thursdays, a few of us go and work there.
(12:19:53) ana: okay. great... I guess we'll wait then...
(12:20:46) abh: I'm calling mark now.
(12:21:23) abh: just as i suspected.
(12:21:34) abh: Mark just got ot Mayfirst and he's logging in.
(12:21:44) ana: sweet...
(12:22:53) ***libkuman waves
(12:22:58) ana: hi mark!\
(12:23:25) libkuman: hi! thanks for putting up with my lateness
(12:23:41) ana: not a problem
(12:23:55) ana: did you get my email with the .doc attachment?
(12:24:11) ana: I'm thinking we should move forward without subforms
(12:24:23) libkuman: sent recently? just checking email now
(12:25:01) ana: And that document sort of starts by asking some questions about how we can best quanlify and quantify individuals who register with an organization.
(12:25:19) amanda [amanda@ool-457237ba.dyn.optonline.net] entered the room.
(12:25:40) ana: amanda, you have a twin?
(12:25:42) abh left the room (leaving).
(12:25:48) amanda: something like that
(12:25:51) libkuman: reading agenda now
(12:25:55) amanda: i finally installed a local, kinda gui silc client.
(12:26:03) ana: yer gry now, instead of yellow. i like the grey better...
(12:26:31) amanda: i've been using a command line client and I don't know how to isntall it locally. So I'm using SILKY instead.
(12:26:42) ana: nice
(12:26:50) ana: i'm just on gaim
(12:28:12) libkuman: so jamie says hi, he is fussing with electronics in the room, so is available for uestions, but that is about it
(12:28:24) ana: oaky
(12:28:26) amanda: I'm on an Ubunut box, and one thing I wasn't able to figure was how to install the SILC extension on gaim.
(12:28:34) ana: wanna weigh in on subforms?
(12:29:05) libkuman: i think ditching them at this point is probabyly a good idea
(12:29:17) ana: amanda: don't know how to help with that...
(12:29:29) ana: libkuman: then should we just go down the agenda?
(12:29:29) libkuman: if eric or i had more time now, i might change my mind
(12:29:50) libkuman: but that is obviously not the case now
(12:29:55) ana: yeah
(12:30:02) libkuman: ana@1693: yeah, agenda sounds good
(12:30:14) amanda: (I don't have anything deep to add)
(12:30:50) ana: Cool. I think the first parts 1.a., b., and c.) are just process flow notes for me.
(12:31:31) amanda: i guess the question I have is whether/how to walk through this with Alice.
(12:31:34) ana: unless there is something that someone wants to add, i think the questions on 1.d. regarding how much to ask about individuals is the key.
(12:31:43) ana: let me give you both a couple of links.
(12:32:09) ana: the first is for the individual registration...
(12:32:11) ana: http://www.ussf2007.org/en/admin/node/types/content_individual/fields
(12:32:20) amanda: (I did get some specs on this from Alice, there is a bit of demographic info that she needs)
(12:32:31) ana: as you can see, we ask a lot of questions
(12:32:42) ana: i got those notes from you, amanda, and incorporated them...
(12:33:07) amanda: right. I see that now.
(12:33:15) amanda: That would be the demographics section of the form ...
(12:33:17) amanda: :)
(12:33:18) ana: but my question is what specifically we should ask for organization memberships
(12:33:22) ana: ;)
(12:33:37) ana: should they be the same questions for each attendee? that's a lot of filling out...?
(12:34:18) dkg [dkg@dyn-160-39-20-86.dyn.columbia.edu] entered the room.
(12:34:35) ***libkuman waves at dkg
(12:34:37) ana: We can probably ditch the region and sectors for attendee, but the real question is what folks will need to keep track of
(12:34:38) amanda: Well, the alternative is that we get fancy behind the scenes to avoid filling out?
(12:34:40) ana: hi dkg
(12:34:53) ana: amanda: how so?
(12:35:25) amanda: I don't know how so, it is so fancy. I mean, options like filling in with the last values you used -- that kind of fancy.
(12:35:35) amanda: I don't think it is necessarily a good use of our time to get that fancy.
(12:35:52) ana: calculated fields would do that...
(12:36:25) ana: i haven't actually used any yet. would they be able to get sector and demographics from teh org field and insert them into the individual field?
(12:36:37) ana: does that make sense?
(12:36:54) ana: here's the beginings of the org reg. page...
(12:37:06) ana: http://www.ussf2007.org/en/admin/node/types/content_organization/fields
(12:37:29) libkuman: i'm a littl slow here, is the information we want to get for individuals the same information from the org registratoin?
(12:37:41) ana: yea
(12:37:58) ana: they will all be in one large registration as groups
(12:38:18) ana: i've started delineating that on the org page. take a look at the link i just sent
(12:38:21) libkuman: if so, calculated fields would need to know which org registration to lookup
(12:38:58) ana: it would be like this: look up the value from the field maybe ten fields up the form in the org_demoraphics field
(12:39:13) ana: sorry, the org demographics group
(12:39:13) libkuman: if so, the first time viewing the individual registration, calc field could grab alll teh values we need pretty easily and store them in teh individual reg node
(12:39:30) ana: but we would need subforms for that
(12:39:48) ana: we have to have all values in one big ass cck node called organizational registrations
(12:40:03) ana: with groups called...
(12:40:14) libkuman: sorry, i'm not understanding how subform is necessary here?
(12:40:23) ana: attendee 1, attendee 2, attendee 3, etc
(12:40:45) ana: and then in those have fields that are similar to the ones in teh individual registration node_type
(12:40:58) ana: does this make sense, or did I misunderstand you, mark?
(12:41:29) ana: put simply, the calc field would look up fields in the dame node
(12:41:35) ana: same, not dame
(12:41:38) libkuman: can we take a small step back and do the entire use case?
(12:41:42) ana: sure
(12:41:48) libkuman: thanks
(12:42:10) ana: so lets say a person is registering for their entire organization
(12:42:16) libkuman: k
(12:42:50) ana: they will eventually get to the organization registration page (which is a different node than for individual registrations)
(12:43:09) libkuman: eventually?
(12:43:31) libkuman: just for m slow brain can we do all the steps?
(12:43:40) ana: sure...
(12:43:42) libkuman: /m/my
(12:44:29) ana: 0. when they press the registration navbar link, they will be taken to a page that directs them depending on what they want to do.
(12:44:56) ana: if they want to pay online and do an individual registration, they will be linked to the individual registration page where they fill out the form.
(12:45:21) ana: if they want to pay online and register for an organization, they will have a link to teh organization registration node
(12:45:46) ana: if they want to pay with a check or later, they will download either the organization or the individual registration form
(12:46:35) ana: 1. in the case that they are an individual registering now and paying with paypal, they will be taken next to the Inidividual registration form...
(12:46:59) ana: http://www.ussf2007.org/en/node/add/content_individual
(12:47:39) ana: 2. in the case that they are registering an organization, they will go to a different organization registration page...
(12:47:57) ana: which is not finished yet but which I started...
(12:47:58) ana: http://www.ussf2007.org/en/node/add/content_organization
(12:48:05) ana: you with me?
(12:48:15) libkuman: yup, this is helpful
(12:48:43) ana: okay, so the question is, if you compare the two input forms...here are the two links again for the field lists...
(12:49:04) ana: individuals: http://www.ussf2007.org/en/admin/node/types/content_individual/fields
(12:49:29) ana: organizations: http://www.ussf2007.org/en/admin/node/types/content_organization/fields
(12:50:14) ana: if you look on the organization page with fields, you will see that I started to ask questions about Attendee 1 in the attendee 1 group
(12:50:56) ana: my question is if we need to ask the same questions of each attendee as we do for each individual. the specific fields in question are:
(12:51:47) ana: Demographics (which you can compare witht he finished demographics fields on the individual registration form)
(12:52:35) ana: Participation Interests, which are things like Volunteer, Press, Funder, Artist/Performer, Cultural Worker
(12:53:05) ana: and Official Participation Roles which will be filled in only by USSF staff...
(12:53:41) ana: My thinking is that 'participation interests' and official participation are important to keep for each attendee
(12:54:17) libkuman: and demographics are only necessary for an org
(12:55:02) libkuman: ?
(12:55:25) ana: no we ask individuals for their demographics as well
(12:55:31) ana: my question is..
(12:55:41) ana: regarding specifically sector and region
(12:55:52) ana: if we already ask those of the organization
(12:56:13) ana: 1. do we need to ask it of the individuals as well? and
(12:56:42) ana: if so, 2. can those fields autopopulate for each attendee (as they will probably be the same...
(12:56:49) libkuman: just a sec, talking to josue
(12:57:02) ana: that is what the question about calculated fields was about
(12:57:45) amanda left the room.
(12:57:53) ana: can we calculate a field in the group 'attendee 1' to read the same as the field in organization_demographics groups
(12:57:58) libkuman: josue just gave some opinions
(12:58:36) libkuman: he brought up the point that if a person from an organizatons is filling this out, they might not now the individual people's participaton interests
(12:58:37) amanda [amanda@ool-457237ba.dyn.optonline.net] entered the room.
(12:58:42) amanda: sorry.
(12:58:50) libkuman: [14:59] he brought up the point that if a person from an organizatons is filling this out, they might not now the individual people's participaton
(12:58:51) libkuman: interests
(12:58:51) ana: yup
(12:58:56) ana: exactly
(12:59:02) libkuman: and anothr wrinkle
(12:59:26) ana: we could make them not required
(12:59:26) libkuman: ther was a request for an org to register more than 3 people
(12:59:31) libkuman: by paying more
(12:59:38) ana: uhh...
(12:59:43) libkuman: that migt be a later addition though
(12:59:47) ana: that last option will be a bitch.
(12:59:57) libkuman: and it s a request at this point, not a requirement
(13:00:02) ana: without subforms
(13:01:13) ana: so...
(13:01:15) libkuman: there are other modules that do some things similar to subforms, but without all the complexity
(13:01:36) libkuman: but also, at that point the extra people could just fill out individula registrations
(13:01:47) libkuman: and somehow pick the group that thy are associatd with
(13:02:25) ana: we would need them to pick an organization that has already registered
(13:02:56) libkuman: ys, adn would need to figure out some way to validat those linkings
(13:03:01) libkuman: which might be scary
(13:03:21) ana: and if they are not registering as organization (but as an inidividual) that would complicate this because the field would have to be a node reference, adn that node would not exist for people registering as an individual, but they would still be asked...
(13:03:48) amanda: is there a human solution?
(13:03:59) amanda: (to the validation)
(13:04:20) amanda: like Alice pulls up a list of folks registered as connected to an organization and sends it to the organization's contact?
(13:04:40) ana: the human solution is say (three of you can register as an organization, and the others will have to register as individuals, even if they are coming with the organization
(13:04:53) libkuman: that could work if our node field permission module works the way we want it to
(13:05:00) amanda: ok.
(13:05:01) ana: how so?
(13:05:29) libkuman: only admins ar allowed to associate individula registratons with org registrations
(13:05:37) ana: in the case that I just described, I would add a field in the individual table that would have a space for organization
(13:05:46) libkuman: yes
(13:06:16) ana: and so alice could just sort them to attach them to organizations that have registered...
(13:06:36) ana: does this make sense?
(13:07:06) libkuman: (here are other modules that do a simplified functionality of subform, node relativity, node family, relationship)
(13:07:06) ana: And we could also do the linking through org's only
(13:07:24) ana: nevermind what I just said
(13:07:46) libkuman: yes, that makes sense, the person in alice's role would have to know which ones to link up
(13:07:56) ana: i believe node relativity is already installed...
(13:08:12) ana: is it?
(13:08:33) ana: nodereference is
(13:08:37) ana: is this the same thing?
(13:08:49) libkuman: basically, they do linking, without doing forms witin forms, they just giv links
(13:09:13) ana: right. that makes sense. I can do that.
(13:09:21) libkuman: i bethca it is a little bit different
(13:09:33) ana: can you install node relativity?
(13:09:44) ana: and i'll check them out
(13:10:14) libkuman: sure, want me to install node family as well? i think the Relationship module had some bugs if i remember corrctly
(13:10:37) ana: I have to go to a meeting in about 20 minutes, so we might have to go fast on the rest of this...
(13:10:48) libkuman: i think node relativity was somewhat stable
(13:10:58) ana: Yeah, go ahead ans install that one too. That would be a relief
(13:11:08) ana: Okay...
(13:11:20) libkuman: i'll do it first thing after meeting
(13:11:23) ana: I think I have enough information about that part...should we move on?
(13:11:26) ana: thanks, mark...
(13:11:59) libkuman: yeah, we'll have to talk more about this soon, its a lot of shit for on persn to juggle, espcecially with all the decision making
(13:12:20) ana: Basically, all that would be left is for someone with some actual coding knowledge (libkuman, dkg, eric) to deal with the paypal part...
(13:12:28) ana: does josue have those numbers yet?
(13:12:31) libkuman: feel free to move on with whatever you consider th most important
(13:12:38) ana: I'm sorry, the password and user name?
(13:12:59) libkuman: i'm bringing in josue to silc to discus paypal
(13:13:26) ana: okay, i'll wait...
(13:13:35) ana: for him to get on.
(13:13:37) josue [josue@viewsic.mayfirst.org] entered the room.
(13:13:46) ***josue waves
(13:13:54) ana: hi josue
(13:14:05) ana: i'm going to copy the paypal part of the agenda...
(13:14:07) libkuman: josue: wanna give us current status of paypal
(13:14:16) josue: paypal update:
(13:14:49) josue: i sent an email to will at project south detailing what needs to be done to change the name on the account to jerome scott so that we can properly verify the acct
(13:15:12) josue: i tried to create a new acct but cannot do so with an account that is already being used
(13:15:26) josue: i will call will now to see if i can get an update and an eta
(13:15:38) ana: thanks...
(13:15:54) ana: there are some adjustments that might need to be made to the paypal account type...
(13:16:09) ana: depending on what type of account we purchased with them
(13:16:39) josue: i believe it is a bsiness acct. amanda, do you know?
(13:17:00) ana: we need it to be a Payflow Pro Account
(13:17:03) ***amanda peers back just in time to try to answer
(13:17:15) ana: $249.00 set up fee
(13:17:23) libkuman: yikes
(13:17:36) ana: $59.95 monthly fee (includes 1000 transactions per month)
(13:17:53) ana: $0.10 per tranaction after the first 1000
(13:18:09) amanda: Uff. We can't even get the free account verified.
(13:18:13) ana: because we need it to play with our drupal website
(13:18:25) amanda: Right.
(13:18:43) amanda: We really need full buy-in from Alice et. al. on this, because they need to manage the banking.
(13:19:24) ana: exactly. could someone work on that? The other option is payflow link...
(13:19:31) ana: $179 set up fee
(13:19:46) amanda: is "Payflow" not paypal?
(13:19:51) amanda: or is that a paypal program?
(13:19:52) ana: $19.95 monthly for 500 transactions
(13:19:58) ana: its a paypal program
(13:20:09) ana: and .10 after the first 500 transactions
(13:20:39) ana: we need one of these. 500*.10 is $50
(13:20:53) ana: so we'll probably save money with the more expensive one...
(13:21:02) ana: but it's all equal really.
(13:21:07) ana: we just need one of them.
(13:21:18) ana: the last version comes with more bells and whistles...
(13:21:25) ana: (the expensive one)
(13:21:37) ana: who wants to talk to alice, josue?
(13:21:42) ana: ;)
(13:21:49) ana: pretty please...
(13:22:16) ana: here's the paypal link for these programs (it's also on the agenda I sent out...)
(13:22:17) ana: https://www.paypal.com/us/cgi-bin/webscr?cmd=_payflow-gateway-pricing-outside
(13:23:04) amanda: about talking to alice?
(13:23:28) ana: yeah, can josue talk to her?
(13:24:27) ana: Here is the techy link for interacting with Paypal (also in the agenda)...
(13:24:43) ana: https://www.paypal.com/IntegrationCenter/ic_pro_home.html
(13:26:22) libkuman: josue is dealing wwith nitty gritty on phone
(13:27:59) libkuman: josue is off phone
(13:28:08) libkuman: and luckily not under desk
(13:28:09) josue: update:
(13:28:47) josue: will is going to fax the necessary docs tomorrow, when jerome comes into the office and has his photo id
(13:29:02) josue: we'll see if that works
(13:29:27) josue: apparently it is his name on the bank acct
(13:29:34) libkuman: ana@1693: which paypl account do you recommend?
(13:29:41) josue: jerome is not in the office today
(13:29:54) ana: a. Recommended: Payflow Pro
b. $249.00 USD/set-up c. $59.95 USD monthly d. Up to 1,000 transactions included per month e. $0.10 USD per transaction after 1000.
(13:30:01) ana: from the agenda...
(13:30:13) ana: This is all there....
(13:30:52) ***libkuman slaps head for not reading closely enough
(13:31:11) ana: mark, don't be too hard on yourself. you are over worked, remember?
(13:31:25) josue: i was told he would be there tomorrow and that his id would be copied and faxed, along with all the other necessary docs
(13:31:30) libkuman: oh yeah, i forget ;)
(13:31:31) ana: okay.
(13:31:32) josue: will let you know tomorrow what the deal is
(13:31:46) ana: sorry, josue. I'm just frustrated. Venting...
(13:31:59) josue: please, who you talking too.... ;)
(13:32:06) ana: Josue: can you talk to alice about payflows account?
(13:33:53) josue: i think i will start with an email to the A-team, which is the working group heading up the npc
(13:34:07) josue: it includes alice, so i will ask the question to that group
(13:34:16) josue: as to what kind of paypal acct we need
(13:34:17) ana: okay
(13:34:32) ana: let them know that registration cannot move forward untill they make a decision on this.
(13:34:43) ana: this is a real life dependencyu
(13:34:44) libkuman: nod
(13:34:52) josue: i will. thanks for all your work on this, all of you.
(13:34:58) ana: :)
(13:35:17) libkuman: do you have to run now ana?
(13:35:25) ana: All that would be left is to talk about hooking it all up (with paypal).
(13:35:30) ana: soon
(13:35:56) ana: Libkuman, can you check out the links that I have in the agenda with paypal, and we can all talk again about this on Sunday?
(13:36:07) ana: Or DKG?
(13:36:10) ana: or ERIC?
(13:36:37) libkuman: yup, i can do that
(13:36:39) ana: We just need to understand how we will eventually hook drupal with paypal cck.
(13:36:41) ana: thanks.
(13:36:47) ana: That's all for me...
(13:37:00) ana: Anyone else have something?
(13:37:07) libkuman: i might not figure it out completly, but cn write up a report on any holes i might have
(13:37:33) ana: Thanks SOOOO much, LIBKUMAN, and Josue, and Amanda.
(13:37:38) libkuman: not right now, i just want to make sure you are getting enough help and input
(13:37:55) ana: and Libkuman...thanks I know you're stuffed. I really appreciate all the help you've given me..
(13:38:02) libkuman: (does the capital letters mean i'm special?)
(13:38:09) ana: yes. ;)
(13:38:09) libkuman: cuz i hope so ;)
(13:38:14) libkuman: woo hoo!
(13:38:21) ana: I've gotta run.
(13:38:23) libkuman: i like being special
(13:38:35) libkuman: cool, be in touch if you run into new hurdles
(13:38:37) ana: You were meant to be special mark...
(13:38:42) libkuman: awww
(13:38:45) ana: on the short bus with all the rest of us geeks...
(13:38:51) libkuman: woo hoo
(13:00:58) anawillem: I see you're on the site...do you copy?
(13:05:26) libkuman45: ya
(13:05:53) libkuman45: still having a little difficulty getting subform to work correctly
(13:06:01) anawillem: are you busy, or would you like to chat...I want to pick a time that works well for you...
(13:06:06) anawillem: ahh
(13:06:50) libkuman45: i'm half busy, but i don' mind doing multiple things
(13:08:42) anawillem: go for it. let me know when you make progress with subforms, and we can set up a time to talk about it at that point. I might also poke around...if I have specific questions, I'll shoot them to you...
(13:09:02) libkuman45: cool, do you want an overview now of how it works?
(13:09:15) libkuman45: just a top level kind of thing
(13:09:41) anawillem: is there a way to change the theme on drupal just for when I log in? Like to personalize it. I'm working on this at work, and I want something less conspicuous...
(13:09:53) anawillem: sure, I'd love a quick over view
(13:10:12) libkuman45: yeah, let me refresh myself on how to do the theme thing
(13:18:14) libkuman45: hmmm, can't figure out the theme thing, i thought it was possible but i'm just not finding it
(13:18:32) libkuman45: trying to get help in openflows silc channel
(13:18:40) anawillem: its all good
(13:18:55) libkuman45: err, just got a reply, but unfortunately it was the same answer as mine, think its possible, can't figure out how
(13:23:10) libkuman45: ok, figured it out
(13:23:16) anawillem: sweet
(13:24:01) libkuman45: basically first you have to go to the http://www.ussf2007.org/admin/themes and enable the theme you'd like to use
(13:24:12) libkuman45: i just enabled B7 (the top one to test)
(13:24:39) libkuman45: once you have your desired them enabled, go to http://www.ussf2007.org/user/
(13:24:48) libkuman45: then hit the edit tab
(13:24:56) libkuman45: then pick your theme at the bottom of the page
(13:26:10) anawillem: cool thanks
(13:26:18) anawillem: i appreciate that
(13:29:57) libkuman45: back in a sec
(13:32:30) anawillem: I think we're good for now. sounds like you are busy. if, at your own convenience, you wanted to shoot me a quick email at your convenience giving me an overview, that would be great, and we can go from there. I will probably poke around a little tonight. But I want to defer to your level of busy-ness.
(13:33:09) libkuman45: i'm actually alright to do it now, i just went to the bathroom
(13:33:24) libkuman45: and the only thing i'm busy on is trying to get the subform working correctly
(13:33:39) anawillem: ohh, cool. then now works, too.
(13:33:44) libkuman45: i wouldn't mind giving you a quick overview now, so you can play with it and help me debug
(13:34:01) libkuman45: because like i said on sunday, this module is pretty bleeding edge
(13:34:22) anawillem: lets do it
(13:34:52) libkuman45: ok
(13:35:24) libkuman45: so the first thing you have to do is create a node of type relation_type
(13:35:35) libkuman45: http://www.ussf2007.org/node/add/content_relation_type
(13:36:00) libkuman45: this node will define a relationship between two node types
(13:36:16) anawillem: what is type one cardinality
(13:37:06) libkuman45: so say type one is Test Registration, and type two is Individual Registration
(13:37:28) libkuman45: so say i put 2 into the type one cardinality
(13:37:50) libkuman45: that means a Test Registration can have 2 Individual Registrations
(13:37:58) anawillem: ahh
(13:38:02) libkuman45: if i put 1 into type two cardinality
(13:38:15) anawillem: nice
(13:38:16) libkuman45: then a Individual Registration can have one Test Registration
(13:38:31) anawillem: now, we will want that the other way areound, right?
(13:38:49) libkuman45: i'm actually not sure on how you are setting up the registration objects
(13:38:49) anawillem: With a registration having more than one Individula if it is an organizational reg.
(13:39:07) libkuman45: nod
(13:39:25) libkuman45: for my testing, i created two relation_type nodes
(13:39:59) anawillem: so for the table (that isn't created yet) called 'Registration Event' or something like that, I will have a spot for one organization and up to 5 individual organizations.
(13:40:21) libkuman45: individual organizations?
(13:40:28) anawillem: sorry. Individuals
(13:40:33) libkuman45: gotcha
(13:40:49) libkuman45: for right now i have my Test Registration node type
(13:41:00) libkuman45: which can have 3 individuals and one organization
(13:41:25) libkuman45: which is just for testing, i'm definitly not trying to do it for real
(13:41:32) anawillem: yup
(13:41:37) anawillem: that's fine.
(13:41:38) libkuman45: so therefore i created two relation type objects
(13:41:45) anawillem: nod
(13:42:30) libkuman45: so now go to http://www.ussf2007.org/admin/node/types/content_registration_test/fields
(13:43:03) libkuman45: (oh, i forgot i added a relation_type node between Registration Test and Technology Issues when i was debugging)
(13:43:27) libkuman45: so lets add a subform field to see how that works
(13:43:28) anawillem: i can wait if you want to fix that...
(13:43:34) anawillem: okay
(13:43:49) libkuman45: click the "add field" tab
(13:44:04) anawillem: yup
(13:44:20) libkuman45: add a Label (whatever you want) then click the subform box at the bottom
(13:44:22) anawillem: i'm logging this, by the way, so that others can see.
(13:44:28) libkuman45: cool
(13:44:32) libkuman45: good idea
(13:44:59) anawillem: okay
(13:45:55) libkuman45: ok, so did you click submit after entering a label and clicking the subform box?
(13:46:04) anawillem: yup
(13:47:43) libkuman45: so first off, i'm confused on why the Required field and Multiple values labels aren't form elements, seems like you should be able to toggle Required
(13:47:53) libkuman45: but we'll ignore that for now
(13:48:08) libkuman45: so in the Relation to show drop down
(13:48:15) anawillem: yeah. that is weird. we'll pick it up as a question for later...
(13:48:32) libkuman45: you'll see 3 nodes of type relation_type
(13:48:36) anawillem: yup
(13:48:46) anawillem: you created those in relation types
(13:48:50) libkuman45: yup
(13:48:52) anawillem: the thing we just did?
(13:48:57) anawillem: good
(13:49:38) libkuman45: ya, there is another weird thing where choices in the drop down could be between two nodes, but neither of those nodes could be the node we are editing
(13:49:53) anawillem: huh?
(13:49:58) anawillem: ohh yeah
(13:49:59) anawillem: right
(13:50:00) libkuman45: let me explain better
(13:50:06) anawillem: so we have to be careful...
(13:50:15) libkuman45: we are editing the Registration Test content type
(13:50:49) libkuman45: if we picked a relation_type that didn't include the Registration Test content type it would have unexpected results
(13:50:53) libkuman45: whatever they were
(13:51:01) anawillem: right
(13:51:13) anawillem: weird
(13:52:19) libkuman45: yeah, just goes back to us using this module (both ussf and openflows) means we have to help bring it along
(13:52:41) anawillem: right. are you working on this project?
(13:52:53) anawillem: the submodules - as a developer?
(13:53:25) anawillem: or will we just use it and give feedback as we go?
(13:53:31) libkuman45: kind of, i'm working on a huge project for Manhattan Neighborhood Network (a public access station)
(13:53:41) libkuman45: where we are relying on the subform module
(13:53:42) anawillem: nice
(13:53:52) libkuman45: and have agreed to become co-maintainers of the module
(13:54:01) anawillem: so you're invested in this working. That's awesome
(13:54:03) libkuman45: but i'm not the one who has been doing the bug fixes for it
(13:54:48) libkuman45: my co-workers have, i've only been involved in conversations about it, and have seen it in play on the MNN site after it was configured and installed
(13:55:02) anawillem: ahh
(13:55:15) libkuman45: Eric has did the initial configuration and installation
(13:55:18) anawillem: should we continue?
(13:55:24) libkuman45: ya
(13:55:26) anawillem: ohh...interesting
(13:55:27) libkuman45: ok, so the next field is "Type to show"
(13:55:42) libkuman45: (and unfortunately eric is on his way to Hawaii for a week right now)
(13:55:43) anawillem: eric is the more silent programer on this project, but super sweet.
(13:55:51) anawillem: that would explain his silence
(13:56:13) libkuman45: yeah, and he's been completely overwhelmed the last few weeks/months/years ;)
(13:56:35) libkuman45: ok, so back to the "Type to show"
(13:56:37) anawillem: ever since bush got in to office, no doubt...:(
(13:57:01) libkuman45: maybe since Reagen ;)
(13:57:14) anawillem: right...
(13:57:23) libkuman45: ok, so continuing on to "Type to show"
(13:57:34) anawillem: i guess it's pretty much been shitty since then. unfortunately, that's half of my life (over)
(13:57:41) anawillem: yup
(13:58:02) libkuman45: i really don't understand exatly how it works
(13:58:39) anawillem: only two choices. we can figure that out pretty easy once it's done...
(13:58:54) libkuman45: all i know is i orginally picked "left"
(13:58:55) anawillem: i'll choose left
(13:59:01) anawillem: jinx
(13:59:06) libkuman45: and it didn't work that well
(13:59:10) anawillem: oops
(13:59:13) libkuman45: then i picked right, and it worked a lot better
(13:59:14) anawillem: i'll choose right
(13:59:19) libkuman45: i have no idea why
(13:59:24) anawillem: do you think they are talking right/left joins...?
(13:59:52) libkuman45: got to be something like that
(14:00:05) anawillem: we can figure that out. I'll choose right this time...
(14:00:09) libkuman45: cool
(14:00:20) libkuman45: ok now on to the check boxes
(14:00:36) libkuman45: those are a little more self explanatory
(14:01:01) libkuman45: Display Children says whether or not to display the child nodes
(14:01:31) libkuman45: Allow Node Edits means already associated children nodes can be edited on the spot
(14:02:19) anawillem: yup. they are self explainatory. but I'm going to let you continue because this is for posterity...
(14:02:24) libkuman45: Allow New Node Additions means you can have javascript automatically insert the child node submit form into the overall form
(14:02:33) libkuman45: allowing you to create a child node on the spot
(14:03:18) libkuman45: Reference Deletions allows you to delete child nodes (not deleting the node itself, just deleting the relationship)
(14:03:38) libkuman45: Allow Reference Additions allows you to link to already existing nodes
(14:04:35) libkuman45: for Reference Additions, you can tweak the view of existing possible nodes by clicking this text " Customize reference list. (If you have selected a new relation type or direction in this window, save these changes before using this link, otherwise this link will point you at a stale view definition)"
(14:04:52) anawillem: ahh
(14:04:54) anawillem: okay
(14:05:06) libkuman45: (weird, i didn't realize i could copy and paste links into gaim)
(14:05:21) anawillem: that might come in handy depending on how we configure the registration process through pages...
(14:05:55) libkuman45: nod, i haven't played with that so i'm not sure exactly how it plays out
(14:06:22) libkuman45: ok the next check box "Continue editing after changes....."
(14:06:31) libkuman45: i think i might have given you some bum info on sunday
(14:06:39) libkuman45: say you are editing the parent
(14:06:43) libkuman45: and you add a new child
(14:06:59) libkuman45: when you submit that child, the parent also gets submitted
(14:07:12) anawillem: ohh, good.
(14:07:19) libkuman45: normally when you submit a node, it goes straight to view
(14:07:27) libkuman45: but if you check this box, it goes back to edit
(14:07:40) libkuman45: which allows you add more child nodes or continue to edit the parent
(14:07:43) anawillem: okay, that makes sense
(14:08:24) libkuman45: for me, i'd almost rather have the child node submit be separate from the parent node, but i guess its tough to do that, especially when the parent hasn't been created yet
(14:08:28) anawillem: that will come in handy
(14:08:37) anawillem: yeah
(14:09:00) libkuman45: ok, the next form element is the nesting dropdown
(14:09:56) libkuman45: which i guess prevents you from having a node have a subform field for a node that in turn has a subform field for a node that in turn has another subform field
(14:10:16) anawillem: we will want that, though. right?
(14:10:38) anawillem: registration event parent of organizations parent of individuals
(14:10:42) anawillem: or alternatively
(14:11:05) anawillem: registration event parent of organizations and individuals with not all filled out
(14:11:21) anawillem: am I making sense?
(14:12:00) libkuman45: yeah
(14:12:10) libkuman45: i think we'll really have to play with it though
(14:12:14) anawillem: yup
(14:12:22) libkuman45: to see how subform really works (or doesn't)
(14:12:36) anawillem: I'm hoping it does. We need this.
(14:13:07) anawillem: So for now, what number do I put there. it defaulted to 4
(14:13:29) libkuman45: i think that is fine for now
(14:13:33) anawillem: oaky
(14:13:39) anawillem: I'm pushing save?
(14:13:46) libkuman45: ya
(14:14:47) anawillem: Cleared views submodule cache to force new subform selection views to show up. Saved field Proposal form. 604:223: Subform Test 5 was unable to calculate what type to display 604:223: Subform Test 5 was unable to calculate what type to display
(14:14:53) libkuman45: yeah
(14:14:56) anawillem: that is what shows up in green up top
(14:14:58) libkuman45: i think thats my fuck up
(14:15:00) anawillem: like an error, but greener
(14:15:07) libkuman45: i bailed on the middle of creating the field
(14:15:14) anawillem: ahhh
(14:15:16) libkuman45: creating the subform field
(14:15:18) anawillem: which field?
(14:15:24) libkuman45: Test 5
(14:15:25) anawillem: ohh, you're doing this as well...
(14:15:32) anawillem: ?
(14:15:36) libkuman45: but now it doesn't display on my manage fields list
(14:15:39) anawillem: Test 5 is a field you created before
(14:15:43) libkuman45: ya
(14:15:51) libkuman45: i was mirroring what you were doing
(14:16:08) anawillem: okay
(14:16:09) libkuman45: but i didn't feel the need to submit the subform configuration form
(14:16:12) anawillem: so how to undo?
(14:16:20) anawillem: or do we need to
(14:16:28) libkuman45: well luckily this Registration Test CCK type is not going to be used
(14:16:33) anawillem: right
(14:16:42) libkuman45: so i think when we are done testing we can just delete the whole CCK type
(14:16:50) libkuman45: but that definitely shouln't happen
(14:16:59) libkuman45: because i can't think of a way to get rid of it otherwise
(14:17:21) anawillem: right
(14:18:09) libkuman45: ok, so now go to http://www.ussf2007.org/node/add/content_registration_test
(14:18:38) anawillem: yup
(14:18:44) libkuman45: you'll see our three subforms
(14:18:51) anawillem: wow
(14:18:52) anawillem: nice
(14:18:56) libkuman45: unfortunately, i think my error is causing side effects
(14:18:59) anawillem: works good with the skins too
(14:19:22) libkuman45: there should be a link to not only create a new individual, but a way to link to pre-existing individuals
(14:19:28) libkuman45: that was showing up before
(14:19:37) anawillem: but isn't now?
(14:19:41) libkuman45: nope
(14:19:52) anawillem: because of the Test 5?
(14:20:01) libkuman45: i'm guessing thats the case
(14:20:14) libkuman45: because it was working right before we started our demo
(14:20:38) anawillem: okay. and I'm assuming it's kosher if we don't fill all the hooks - like if there are no individuals
(14:21:05) libkuman45: i hope so
(14:21:06) anawillem: what if someone thinks they should submit an organization even though they are registering as an individual?
(14:21:32) libkuman45: i think in the subform config you can add help text to the subform field
(14:21:35) anawillem: did you make the organization nodes?
(14:21:42) anawillem: right
(14:21:43) libkuman45: i think i made one called test
(14:21:52) anawillem: okay
(14:22:00) anawillem: I might steal someof your fields
(14:22:12) libkuman45: no worries
(14:22:25) anawillem: why does organizationsay fill out and individuals says new
(14:22:26) libkuman45: so now you pretty much know what i know about subforms
(14:22:35) libkuman45: yeah, i was wondering that too
(14:23:01) libkuman45: oh, i think i might now what it is
(14:23:05) anawillem: I'll check the difference in the field configuration of them. but I wonder if they behave differently?
(14:23:08) libkuman45: for organizations, you can only add one
(14:23:12) anawillem: ahh
(14:23:13) anawillem: right
(14:23:19) anawillem: good job
(14:23:22) libkuman45: for individuals and proposal forms you can add multiple
(14:23:46) anawillem: and the product...ect, can we loose that for when this goes live?
(14:24:00) anawillem: or make them not engage?
(14:24:10) anawillem: or is that just because I'm loged in as admin?
(14:24:42) libkuman45: yeah, i'm pretty sure that'll go away for non admin people
(14:24:50) anawillem: sweet.
(14:24:56) anawillem: thanks for going over this with me.
(14:25:02) anawillem: It REALLY healp
(14:25:06) anawillem: healps
(14:25:09) anawillem: helps
(14:25:12) libkuman45: he he
(14:25:15) libkuman45: no problem
(14:25:18) anawillem: unfortunately, it doesn't help my typing any
(14:25:27) libkuman45: keep a list of any issues you run across
(14:25:32) anawillem: yup
(14:25:35) libkuman45: even if you aren't sure its a bug
(14:25:40) anawillem: I will. For sure
(14:25:54) anawillem: Specially since I know that you are working on the module a little
(14:25:58) libkuman45: i'm a little concerned it might be a little funky, even funkier than we have for MNN
(14:26:01) anawillem: and becasue we want this to work right
(14:26:17) anawillem: do you have a different version for MNN?
(14:26:19) libkuman45: because MNN project isn't using the most up to date CCK module like we are
(14:26:24) anawillem: oh
(14:26:26) anawillem: okay
(14:26:30) libkuman45: same version of subform, different CCK
(14:26:40) anawillem: mmm.
(14:26:51) libkuman45: you can tell because the newest version of CCK lets you reweight fields from the manage fields page
(14:26:55) libkuman45: which is a massive improvement
(14:27:04) anawillem: i agree
(14:27:11) anawillem: that helps a lot
(14:27:25) anawillem: i'll play around with this tonight
(14:27:34) libkuman45: we had to install the newest version of CCK because of an issue with the subform module and php5
(14:27:48) anawillem: why was this not the case with MNN>
(14:27:54) libkuman45: php5 barfs on some stuff that php4 doesn't
(14:27:58) anawillem: ahhh
(14:28:00) anawillem: okay
(14:28:00) libkuman45: MNN is running php4
(14:28:05) anawillem: good to know.
(14:28:15) libkuman45: that was all that whoop to do yesterday about the array arguments
(14:28:25) anawillem: So, I'm going to play more tonight with this, and see what I can do.
(14:28:28) libkuman45: cool
(14:28:33) anawillem: right (array)
(14:28:50) anawillem: I'll let you know when I have something that resembles what we want
(14:28:53) libkuman45: holler if you have any questions, but i probably won't be online after 5:30 or 6
(14:29:08) anawillem: Okay. It will probably not be untill tomorrow then
(14:29:16) libkuman45: cool
(14:29:16) anawillem: but thatnks....REALLY
(14:29:36) anawillem: Have a great rest of your day
(14:29:59) anawillem: I'll log this and put it up with our meeting notes or something
(14:30:02) libkuman45: you too! cheers
(14:30:06) libkuman45: awesome, thx
(14:30:09) anawillem: so that people can catch up
(14:30:11) anawillem: cheers
These documents are good for historical reference, however, they have been superceded by other documents.
NOTE: This document is here for context purposes but is no longer being used. Please see the Current ICT proposal.
These are the tasks that the tech working group is looking for support, ideas, insight, and resources for in the months leading up to the USSF. You can see more specific info in the Tech development log
MAIN WEBSITE
*how many languages do we need to support?
*deploy a calendar/scheduling system whereby attendees can post their schedules publicly
*allow people to create easily printable forum schedules
REGISTRATION SYSTEM
*a way for attendees to register online, with payment through paypal
PROGRAM
*a way for attendees to propose fora
*a place for groups to develop forum proposals
**allow forum organizers and/or attendees to upload documents in advance, and collaborate on document production
**allow groups to endorse various forum proposals
*allow for program events to be displayed in various custom ways, by theme or scheduling or allow people to create custom programs.
LOGISTICS (housing, transportation, space)
*provide a housing board, a la lightningbug
*provide a ride shares board, a la lightningbug
*provide online maps of Atlanta, using open GIS software, listing the existing capabilities of each location on a map
SUPPORTING REGIONAL-->NATIONAL-->REGIONAL COORDINATION
*provide technical support for regional organizers for various purposes
*(we need to consult with regional representatives as to what those purposes are.... Kevin will talk to Midwest people in mid-November)
*web functionality on main ussf2007.org page to facilitate hooking visitors into what's happening locally/regionally
POSSIBLE NON-WEB RELATED PROJECTS
*something akin to "I am New York City" i.e. a print newspaper containing interviews with local organizers, explaining what they are upto.
*organizing local trips to places outside of Atlanta ( e.g.places damaged byhurricanes Katrina and Rita)
*a print map project, similar to the RNC map efforts which werevery fruitful.
*radical ref. : ready reference kit similar to RNC
NOTE: This document is here for context purposes but is no longer being used. Please see the Current ICT proposal.
Not all of these are guaranteed projects, this was a brainstorm. We need to discuss what's the highest priority, and what's missing from this list.
DOCUMENTATION/BROADCASTING
*a place to post video of each forum
*pick half doz. sessions to put on live feed on the internet
*video conferencing?be careful with this one... everyone will want it, and that's problematic because it is very resource-intensive.we should maybe investigate the existence of youtube-style resources that aren't for-profit?
on the ground computer infrastructure
COMMUNICATIONS SYSTEM
Online
*place in which forum organizers can post notes (maybe on a wiki?) during the event
*place to discuss what was talked about at each forum, thread style
Telephone/cellphone-based
*txtmob installation for forum support
*organizers should be able to txt directions, reminders to attendees
*possibly build a system of reminders into txtmob
*create various event-wide alert lists
*set up a ussf hotline
*you should be able to hear a recording of all the locations, events, times...
*maybe listen to sessions live? allow people to call in to different fora?
* there should be one phone no. which can take multiple lines
it should be multi-lingual (IVR: spanish--press 1, esperanto - press 2,...)
* this is going to be limited by the number of phone lines we'll have available
* speakeasy is the software we want to consider using for this project.
A/V
*what tech do we want to make available at forum locations (e.g. printers, projectors)
WHAT IS THIS?? (-kev)
*perhaps allow conference organizers to export their group's data to a text document?
so that i as an attendee can get somebody on the line who speaks my language and knows the answer to my forum-related question
NOTE: This document is here for context purposes but is no longer being used. Please see the Current ICT proposal.
* mechanism or coalition or agreement to provide tech support for attendees who want to continue to maintain the site that was created for their forum.
* listserves for various fora
* allow attendees to post feedback after the event
* break it down into content areas(?)
* continue the calendar afterwards, w/ place to post big future events
* a place for the results of each forum to persist, regardless of whether or not the organizers are interested in continuing to maintain their forum's site.
"The USSF will provide space to build relationships, learn from each other's experiences, share our analysis of the problems our communities face, and bring renewed insight and inspiration. "It will help develop leadership and develop consciousness, vision, and strategy needed to realize another world."We understand that we take on a very specific and critically important role in the Social Forum's organization: to provide technology and tools that will enable and enhance the organization of the Social Forum, the work of the Forum while it's going on, and the appropriate and contributive follow-up to it by all its participants. At the same time we understand that, to be truly productive, this work must be reflective of and driven by the Social Forum's principles of inclusion, democracy and relationship-building. While it may be possible for a small group of "techies" to build some of what is needed, such efforts would fall short of both the Forum's real needs and potential. We believe the development of the Social Forum's Internet and technology capability should be an exercise in collaborative planning and development by the entire Social Forum organizing community. In that sense, this workgroup sees itself as an organizing group committed to using technology development to: