Aller directement à la fin des métadonnées
Aller au début des métadonnées

Overview

This is a funded project to develop a Drupal module according to the CMS agnostic extension design pattern (no calls to Drupal APIs) to facilitate registering children in Events.

In phase 1, the infrastructure will be built to process event registrations with multiple contacts and relationships between them. A single use-case will be specified in table entries allowing six contacts to be created for each registrant. Separate profiles for each contact can be edited by staff to include different fields. In this phase, the same profile must be used for each registrant if multiple registrants are enabled for an event, and the same relationships must be created between each registrant and other contacts. It will be possible to enable or disable this enhanced registration functionality on a per event basis via a 'Use Enhanced Registration?' checkbox on the Online Registration tab of the Manage Events interface.

In phase 2, this checkbox will be placed on a new administrative tab in the Manage Events interface. When enabled, administrative options will be revealed to allow the contacts and relationships between to be created between these contacts to be easily edited.

Ideas for a possible future phase 3 are collected at the bottom of this spec.

Sample Use Case

One parent registers one or more of their children at a time in an event. A household is created from the parent and kid(s), as are parent/child relationships. A second parent also has parent/child relationships created. If the 'Is My Spouse?' special field created by the extension is enabled during registration, then a spousal relationship is added between the two parents and the second spouse is also added to the household. Two emergency contacts are entered on the registration form, with 'is emergency contact of' relationships being created between each of them and each registered kid.

This sample use case is the only one supported in Phase I. It is also used below to illustrate the settings and UI for Phase II.

Registration User Experience

The profiles for the various contacts will be displayed to the user on the first page, and on the confirmation and thank you pages. The contacts and relationships will be created after the confirmation page is submitted.

There will be no support in Phase 1 for including in email tokens information from the profiles other than the registrants'.

Phase 1: Hardcoded Sample Event Registration Screen

The following mockup illustrates five profiles for five different contacts on an event registration form. Note that one of the profiles - for the child - will be the only profile displayed on the second registration page. Currently, the multi-profile support in 4.1 for event registration does not allow subsequent registrations to have no profiles for the bottom profile if the first registration has some; this will be overridden by the extension.


Phase 1 Admin User Experience

In Phase I, enabling 'Use Enhanced Registration?' for an event will cause a confirmation dialog 'Are you sure you want to change the profiles for this event to those used in Enhanced Registration? OK Cancel' to be displayed. On confirmation, the hardcoded profiles will overwrite any existing top and bottom profiles in the Online Registration Page, and they will be frozen to prevent further editing.

Phase 2 Admin User Experience

Users with 'administer Enhanced CiviEvent Registration' permission are presented with an additional tab when managing an event, titled 'Enhanced Relationships', to the right of Online Registration. It presents the user with a form as follows (data entered is for illustrative purposes only):

Enable Enhanced Registration (checkbox)

If the checkbox is enabled, then the following page with two sub-forms appears:

Contacts on Registration Form

Label (Contact Position)

Contact

Type

Profile

Include

Profile

Area

Profile

Weight

Shares Address

with

Current User

  
Current User (logged in or not)Individual Registering ParentTop1(not available)Edit 
Registrant(s)Individual Child RegistrantBottom1YesEdit 
Contact Position 1Individual Spouse or Parent 2Top2YesEditDelete
Contact Position 2Individual Emergency ContactTop3NoEditDelete
Contact Position 3Individual Emergency ContactTop4NoEditDelete
Contact Position 4Household New HouseholdHidden YesEditDelete

Add Contact Position

Current User (logged in or not) and Registrant(s) are present by default. Additional contacts may be added by clicking the Add Additional Contact link. The default values for a new row in this table are Contact n (where n is the next highest number of those displayed), Individual, New Individual, Top, next larger weight number, No.

To make a contact required, include a required field in its specified profile. Note that default duplicate identification will be done on all contacts to be created during registration. If a contact already exists, and a relationship that is to be created would allow editting of that existing contact in a way not currently allowed for the Current User, then the registration will fail with an error 'Cannot enable editting of existing contact via online event registration. Please contact the site administrator to register manually.' When this error occurs, all relationships and contact creation and editting that has occurred so far in the transaction will be rolled back.

If 'Shares Address with Current User' is True for a Contact, then during registration by default a checkbox will appear after the last name field in the Contact's profile, and no address fields in the profile will be displayed. If the Shares Address with Me checkbox is disabled for a Contact by the current user during registration, then address fields in that Contact's profile are displayed.

Relationships Created During Registration

Contact PositionRelationshipContact PositionOptional

Label

for

Option

Left Can

View and Edit

Right

Right Can

View and Edit

Left

  
Current User (logged in or not)Parent ofRegistrant(s)No YesNoEditDelete
Current User (logged in or not)Spouse ofContact Position 1Yes YesYesEditDelete
Current User (logged in or not)Head of Household forContact Position 4No YesYesEditDelete
Registrant(s)Child ofCurrent userNo NoYesEditDelete
Registrant(s)Child ofContact Position 1No NoYesEditDelete
Registrant(s)Sibling ofRegistrant(s)No NoNoEditDelete
Registrant(s)Emergency contact isContact Position 2No NoNoEditDelete
Registrant(s)Emergency contact isContact Position 3No NoNoEditDelete
Registrant(s)Household member isContact Position 4No NoNoEditDelete
Contact Position 1

Spouse of (optional for

divorced parents)

Current userYes

Is My Spouse?

YesYesEditDelete
Contact Position 1Parent ofRegistrant(s)No YesNoEditDelete
Contact Position 1Head of Household forContact Position 4No YesYesEditDelete
Contact Position 2Emergency contact forRegistrant(s)No NoNoEditDelete
Contact Position 3Emergency contact forRegistrant(s)No NoNoEditDelete
Contact Position 4Head of Household isCurrent userNo YesYesEditDelete
Contact Position 4Household Member isRegistrant(s)No YesNoEditDelete
Contact Position 4Head of Household isContact Position 1No YesYesEditDelete

Add Relationship

There are no default relationships. When Add Relationship is clicked, a form with select fields for the two Contact Positions, Relationship, Yes/No field for Optional, a text field for Option Label, and Yes/No fields for View and Edit between the Contact Positions is presented to the user with Save and Cancel buttons. Clicking Edit brings up the same form with appropriate values filled in. Clicking Delete brings up a confirmation dialog.

Relationships are those defined elsewhere in the system, and have similar restrictions on the contact types that may participate in them. When a relationship is added, its reverse relationship is also added to the list. The Can View and Edit columns provide the values to be used when creating the registration. The date at the time of registration is used as the start date for the relationship if it does not exist between the contacts and is therefore being added. No End Date is specified.

If Optional is Yes for a relationship, then a Label needs to be added to one of the two contacts in the relationship. The Label will be used for a Checkbox at the top of that contact's profile, and will default to True. If True when submitted, then the relationship is created, otherwise it is not.

One special relationship may be specified on this form that is not present elsewhere in CiviCRM: Current User 'is a' Registrant(s) / Registrant(s) 'include the' Current User. When added, a confirmation dialog is presented to the user: "Do you want the current user to be the first registrant? Okay, Cancel" If Okay is selected, then the Current User row in the first subform is deleted, and 'Shares Address with Current User' is set to No for all rows.

If a Household contact is specified in the first table, then a relationship of 'Head of Household is' or 'Household Member is' must be specified for it. If the Profile for a Household is hidden, then its name will be formed by concatenating the names of all of the Heads of Household, or if there are none, then by concatenating the names of the Members of the Household, eg 'The Joe Murray / Lisa Austin Household' if Joe Murray is the Current User and Lisa Austin is spouse in the example configuration above (ie 'The FirstName LastName / FirstName LastName Household').

Phase 3

Add support for registering people already in the system, pre-populating fields with appropriate values based on existing relationships between contacts and a logged in user. Some discussion will be required to make a reasonable, usable interface for situations where there is more than one contact in a particular relationship with the current user: probably there will need to be support for a variable of contacts in a particular 'Contact Position'.

Add support for all fields in all profiles on the form being included in email messages.

Change from recording payment as from first registrant (a child in the use case above) to recording it against the current user if a payment is made at time of registration. This will make use of CiviAccounts functionality expected in 4.3.

Phase 1 Implementation

Schema

Create a custom table, civicrm_event_enhanced, as follows:

  • id
  • event_id
  • is_enhanced tinyint(4) default 0

Determine which table is storing the multiple profiles for events in 4.1 - it seems like it should have a foreign keys to civicrm_event and civicrm_uf_group, but I can't find it. Perhaps a non-db friendly has been used and these keys are being serialized into a field in civicrm_event. Aim to create a new table that has a one-to-one correspondence of its records with those event-profile references. Fields in this civicrm_event_enhanced_profile table will include:

  • id
  • event_id NOT NULL
  • uf_group_id NOT NULL
  • area INT(10) NULL COMMENT 'NULL means hidden, 1 means top, 2 means bottom'
  • weight INT(10) NULL 'within an area, weight determines position' // must be NON NULL if area is NON NULL, NULL if area is NULL
  • label varchar(255) NOT NULL 'Override of the Profile's title'
  • shares_address_id INT(10) default 0 NULL COMMENT 'id of the contact profile with which this contact profile shares an address'

Next create civicrm_event_enhanced_relationship table:

  • id
  • event_enhanced_profile_id_a
  • relationship_type_id
  • event_enhanced_profile_id_b
  • is_optional tinyint(4) default 0
  • label varchar(255) NULL
  • is_permission_a_b tinyint(4) default 0
  • is_permission_b_a tinyint(4) default 0

Hooks

Unset all profiles except the registrants during alterContent hook. Add the other profiles in buildForm hook, validate them in validate hook, and process them in postProcess. Create a new hook if necessary or backport validateForm to allow form rules to be unset for the profiles that are removed during alterContent (e.g. remove rules requiring content in fields that have been removed, etc.). Reuse existing code (or pattern) to add field validation rules based on profiles. Add a rule to test that the permissions that would be added for relationships specified would not violate or exceed existing permissions if there is a match between a contact entered on the form and an existing contact in the db, where the existing contact that could be viewed and/or editted previously could not be by the other contact. In other words, no one gets new permissions on an existing contact just because of an event registration.

 

 

Étiquette
  • Aucun
  1. Jun 20, 2012

    There needs to be a way for the parent filling out the form to indicate if they are a spouse of parent number 2 or not. If not, then parent number 2 should NOT be a household member of the child's household. There should then also be a place to provide the physical home address of parent number 2.

    1. Jun 21, 2012

      JoeMurray dit :

      I have added support for users registering their kids to indicate whether the other parent is their spouse.

      We will create a hook that will be called before each relationship is created that will be passed the data from the form and will return whether the relationship should be created or not. In the example data above, this would allow custom code to decide not to create the Head of Household is relationship for the second parent if 'Is My Spouse?' is false.

  2. Jun 28, 2012

    Dave Heffron dit :

    Is there a project page on d.o. where the progress of this can be followed?

    1. Jun 28, 2012

      JoeMurray dit :

      We've started coding and expect to have something to show for Phase I by next week. It's a 4 day Canada Day long weekend for us here, so I won't have the repo open until next week.

      I don't want to host it on d.o because it will be able to run with Joomla! and WordPress as well.

  3. Jul 04, 2012

    JoeMurray dit :

    Sarah, FYI, if the first child does not have an email, then no receipt will be sent out in phase 1.

  4. Apr 09, 2013

    J. Ridgway dit :

    This looks like a great extension.  Any news on how this project is going? Is there something available to test yet?

  5. Sep 14, 2013

    Richard dit :

    Hello Sarah, thanks for picking up this much-anticipated extension. WIll you follow the same phases as suggested above? We hope to use it for our 2014 summercamp registrations that will start in december. Wish you all the best with development! Thanks again (sourire)

    1. Sep 15, 2013

      Richard - At the moment, I do not have any budget for any major changes to the extensions. I am hoping the community will talk to their respective stake-holders ( ie the people who can write a check to sponsor more improvements) to sponsor improvements the extension. The current limitations are, (which eliminating would be my priorities):

      • Only works for paid events (of course event fee can be 0.00)
      • Physical address info (street address, city, etc) must be collected for the primary parent, or disaster follows.
      • The profiles for both parents and both emergency contacts are the same for ALL events using this extension.
      • Assumes a common family situation: A parent is registering their own child for an event
      • Financial data ends up on the contact record of the first child being registered, not the primary parent.
      • If a field such as "nickname" is used for parent 1, then it will not show for the 2nd parent profile or emergency contact profiles.

      My Enhancement ideas:

      • Allow for unpaid events
      • Record financial data on the contact record of the primary parent
      • Create "sibling of" relationships between children registered together; or this could be done in batch after the fact for any contacts with the same parent(s)
      • Allow other kinds of adults to register a child for an event. (For example: allow for a step-parent to register their step-child for an event, or allow a grandparent to register their grandchild for an event)
      • Allow logged in users to be able to choose to register an existing child ( ie a child in the database with a relationship to the current user ) for an event/school/camp without having to re-type the child's data

Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.