CiviEvent: Migrate participant statuts types and add new ones

Migrate civicrm_option_value entries referring to participant status types to a new table.

1. Create civicrm_participant_status_type with the following fields (same as civicrm_option_value unless otherwise specified):

• id, with data from civicrm_option_value.value (and the autoincrement moved past the last entry),
• name,
• label,
• class, with pending/positive/negative depending on what's the general type of the status type,
• weight,
• is_reserved,
• is_active,
• is_counted (boolean), with data from civicrm_option_value.filter,
• is_expiring (boolean).

2. Migrate the data from civicrm_option_value.

3. Fix all the places in the database (like civicrm_participant.status_id) and code which refer to the civicrm_option_value entries.

4. Extend the list of reserved statuses with:

• On waitlist,
• Pending from waitlist,
• Pending from approval,
• Awaiting approval,
• Rejected,
• Expired.

— Additional specifications (dgg 7/27/2009) ----

5. We also need to handle the "Pending (Incomplete Transaction)" status. The 2.2.x code uses "Pending" (status_id = 5) in combination with is_pay_later = false to determine that the participant status is the result of an incomplete contribution transaction (e.g. IPN where we didn't get notification of success). Since all the other Pending statuses are specific now, we probably need another status for this condition. ALSO, need to check code (I think need to check .php and .tpl) for places where we're still assuming a shared participant status (id = 5) for BOTH conditions (pay later and incomplete). Example in Participant.tpl:

{if $participant_status_id eq 5} {if $participant_is_pay_later}

:

{ts}Pay Later{/ts}{else}: {ts}

Incomplete Transaction

{/ts} {/if}

6. Exposing all the new waiting list and approval statuses to the 80% of users who won't use / need them is a bad idea. Lobo and I came up with a plan to keep the interfaces simple for MOST users:

6.1 Status listings (e.g. Find Participants, other drop-downs) should be sorted alpabetically.

6.2 Disable by default (in new installs and upgrades) all participant statuses related to WAITING LIST and APPROVAL functionality (this is statuses 6 - 10 inclusive). Users who need Wait List feature can enable 6 and 8. Users who need Approval functionality can enable 7, 9, and 10. Verify that disabled statuses don't show on drop-downs or search forms.

6.3 Event Configuration >> Event Information - Hide has_waitlist (and therefore waitlist_text) fields UNLESS the 2 statuses required for waitlisting are ENABLED. (So if a user wants waitlisting feature on their site, they enable statuses for it).

6.3 Event Configuration >> Event Information Online Registration - Hide requires_approval (and therefore approval_req_text) field UNLESS the 3 statuses required for approval workflow are ENABLED.