Do you need to allow parents to register their children? Tired of using custom data fields on a child to collect information about their parents and emergency contacts? Would you like the information collected during the registration to create (or update) the various contact records needed in the back-office? Then this blog post is for you. This recipe creates a contact record for each child, each parent, each emergency contact, the household contact, and also builds the appropriate relationships between each contact.
This goes out to CiviCRM users (yes YOU too!), admins and developers.
A key productivity tool in my day to day life is a set of Q&A websites called Stack Exchange. They have different sites for all sorts, from programming through to parenting(!). Typically, I'm on the programming ones usually, but stay with me, this isn't about to get technical.
There is a new native extension available for allowing parents to register their children for events within CiviEvent. Tired of using custom data fields on a child to collect information about their parents and emergency contacts? Would you like the information collected during the event registration to create ( or update ) the various contact records needed in the back-office? Then this is the extension for you.
Lisa presented this work at the SF Meetup in March. Her presentation slides are here
Three years ago I set up a Drupal-based community site for our children’s K-8 public charter school. As the school’s needs grew, I integrated CiviCRM to enable online enrollment, tour registration, ticket sales, volunteer hour tracking, and other functionality that had previously been accomplished through unwieldy paper forms.
As I began to work more closely with a local arts education non-profit, I realized the lessons I had learned from working on the school site were directly applicable to the organization’s needs. SFArtsED runs a summer camp program for children. Till this year, all registrations were completed on a paper form that was sent, along with a check, via snail mail. The Registrar mailed back four forms to the parent, who filled them out and mailed them back to SFArtsEd, along with a receipt for payment. Last month I set out modernize their camp enrollment process using Drupal, CiviCRM, Ubercart and Webform Integration.
I blogged a while ago about "Putting the R back in CRM" about the limits on relationships in the self-service areas. Well I am happy to have an update. I (Pogstone Inc) have sponsored the creation of a new extension ( along with JMA Consulting). This extension is taking advantage of the CiviCRM extension framework for modules, so it should work under Drupal, Joomla or Word Press.
Since CRM stands for Constituent Relationship Management, one would expect to have robust capabilies for dealing with relationships. This expectation is met when using the staff areas of CiviCRM.
However, in any of the self-service areas such as event registration profiles, membership profiles, and stand-alone profiles then relationships are missing. Each profile can only be used to collect information about a single contact.
This lack of support for relationships causes headaches in the following situations:
- Parent account setup : A parent goes to the school site and uses a civicrm registration profile to create an account and enters the site. The account automatically gets assigned a "Applicant Parent" subtype.
- Filling admission application forms : From the dashboard parent fills admission application forms for an applicant (child). Parent can apply for 1 or more applicants. All applicants are assigned a "Applicant" subtype.
- Submitting a payment : Depending on whether financial aid is taken or not, parent submits a payment for an applicant. The payment is done via contribution page with contribution type - "Application Fee". Since parent is the one making the payment, to keep track of which applicant the payment is being done for, an extra argument is passed to the payment/contribution url. We using a hook to make all the checks and link the payment to the applicant.
- Scheduling appointments : Once the application is complete and payment is made (if needed), parent can schedule a child visit or a parent interview. A school tour could be booked at any stage of the process.
- Household Information: Name, Email, Phone and Address of the household. We currently support 2 household and 4 contacts. These are stored as CiviCRM contacts with a relationship link of type Parent / Child to the student. We created a custom group to store which household a parent belonged to. We did not use CiviCRM's household functionality.
The next phase of the CiviSchool project is collecting and maintaining all parent / student information online. This avoids the annual filling out forms work by the parents, and also the stuffing of envelopes by school staff during the summer and reentering all the information in the SIS when school starts.
We had a great day at DrupalCon SF 2010 today, especially in our BoF sessions :) To keep the momentum going, we are planning to have a few more BoF sessions:
- Maintain name/email/phone/address information for people associated with the school (students, staff and parents)
- Maintain relationships between parents and their children
- Maintain relationships between a teacher / advisor and their students
Current Features deployed at SFS
- Give all parents and staff a login/password
- Online signups for all Parent Teacher Conferences
- Online signups for all extended care activity (classes after school)
- Sign-in / Sign-out for students attending extended care
- Computation of how many "activity" blocks a student has spent on extended care
- Parent viewing of the various extended care activities their kids have attended in the past
- Online maps of "Where we Live" of the school families
- Online directories of the schools and grades.
New Code Structure and Directory Layout
I've been working on customizing CiviCRM for my kids school. I documented how i exposed relationship information on a profile view in this blog post. In the past week i've also exposed "activities" and "a multiple record custom group" via profiles which i'll describe in this blog post. All this work was done via civicrm hooks and custom templates and run on CiviCRM v2.2.8. You can download the code from here.
- Implement hook_civicrm_pageRun for the profile view page (CRM_Profile_Page_Dynamic). Only implement this hook for the specific profile id's you want relationship information. In this case we have two profiles, a Parent Profile (gid=3) and a Student Profile (gid=4)
- The pageRun hook also adds the module's template directory to the smarty include path, so we dont have to set it globally. This also allow multiple modules to append different template directories to the template include path (check the function _sfschool_initialize)
- The hook gets either the parent or the child information using a custom query. We ensure that only permissioned parents can see their child information (in case of some complicated family structures). The queries are relatively simple at this stage, i suspect they will increase in complexity over the next few weeks
- The hook exposes the information gathered from the database to the smarty template
- The custom template (templates/CRM/Profile/Page/3/Dynamic.tpl) uses that information to display the relationship data on the page. I also edited the View.tpl template to eliminate the "Back to Listings" link.