College Match Form Sections 1 thru 7 (excluding Section 2 - Additional Info)

This issue covers tasks required for display and processing of sections 1 thru 7 of the College Match Application - EXCLUDING section 2 which is filed as a separate issue. Please review the "College Match Application (changes from the Preapp application)" on this wiki page for a summary of changes for these sections (Personal Info --> Household Income):
http://wiki.civicrm.org/confluence/display/CRM/College+Match+Application+Specs+and+Tasks

Then use the mockups here...
http://www.questbridge.org/app_staging/cm/appl/app.html

... as your "specification" for the forms, data and behaviors (described in the engineering notes at bottom of each form in red).

Unless specifically noted, existing form behaviors can be cloned from the PreApp forms.

1. Setup new code directories/clone files for College Match application

• Going forward, the Quest codebase will need to handle BOTH the new College Match "wizard" and forms AND the existing Preapplication
  "wizard" and forms. Therefore, any code/tpl that is wizard or form-specific needs to go into new separate "MatchApp" sub-directories
  and file(s) - parallel to the existing PreApp directories and files.

2. Schema modifications
Background:
There will be some modifications to existing data columns (column type and/or option values). These modifications will need to be handled by a data migration script (separate issue). However, columns in existing tables that are NOT USED for the College Match application must be retained (not dropped) - as we will still need the ability to display the PreApplication forms.

Tasks:

• Modify existing Student and Person schemas to handle additional and modified fields.
• Lobo is moving all existing option_group, option_value and other fixed data INSERTS to sql/quest_data_cm.mysql in the Quest repository trunk. You should add/modify the INSERT statements in this script to populate needed option_group and option_value records for new or modified "lookup" type fields in these sections. For example, modify the option_value INSERTS used for ethnicity_id_1 to match the options in the mockup. (NOTE: Even though ethnicity_2 is not used in the new Personal form, we do NOT remove it from the schema - as we will still need to display that field when Preapplications are viewed for existing Student records).

3. Implement Forms / Templates for sections 1, 3-7
Following mockups and engineering notes....implement the forms for these 6 sections. Addtional notes for each section follow...

Section 1- Personal Information
-------------------------------------------

• added and modified fields for this section are described on the wiki page
• add the necessary jscript to handle hide/show of correlated fields (for example, engineering note 6 regarding the dismissed_explain form element).
  • • Do NOT implement the "Upload your picture" form element at this time (spec is TBD) ***

Section 5 - Parent Guardian Detail
-----------------------------------------------

• "Do you have contact with this guardian" - Add a column (is_contact_with_student) to quest_person to store this new question. This field is included in the form IF the following condtions are met (otherwise, it is NULL):

• quest_person.relationship_id = FATHER or MOTHER
  AND
• quest_person.id NOT = quest_household person_1_id OR person_2_id for household_type = "Current"

• Permanent Address fields, and Permanent Phone field are stored in a civicrm_location, civicrm_address, and civicrm_phone records. The location record links to the Parent/Guardian's quest_person table using civicrm_location.entity_table and entity_id.

• "Same as my Permanent Address" checkbox - If this is checked, we want to hide the editable fields (jscript onchange function) and then postProcess() grabs the field values from the Student's "permanent" location and writes them to location/address table. Once the person record has populated location/address - we should display the address fields as read-only (this is probably best done by having 2 div's which we swap based on the checkbox value).
  NOTE: Need to think about how form validation rules work here, since if "Same as ..." is checked, we don't get the required address info from the form, but from another record.

• "Same as my Permanent Phone..." - If this is checked .... (same functionality as for Perm Address).

Section 7 - Household Income
-----------------------------------------

• "Total Income entered for this person:" - This is a new read-only Jscript calculated element on the mockup. The jscript function should add all values for the amount_N fields on the page and rewrite the total "onchange" of any of the amount fields. The jsript function will need to include error trapping for non-numeric input and provide a friendly "alert" message.