Details
Major
Description
Provide a way to administratively configure the Participant Statuses which are counted against Maximum Participants and shown in Participant counts. (Analogous to the is_current flag on membership status.). Modify code which displays # or registered participants, and code which evaluates whether an event is "full" to use this flag in count queries.
1. We need to have an is_counted boolean for participant status. Since these are stored in civicrm_option_value - I think it probably makes sense to use the civicrm_option_value.filter column for this purpose. However, please check with Lobo and/or Kurund on this gameplan before proceeding. (If we go this way, the form and selector code will need conditional logic to display and properly label this element when group = participant_status.)
2. ISSUE: The count shown in the Dashboard for "Participants" currently counts records with status = Registered OR Attended. However, when you click the "show" link, we load a search for all participants in the event (no status filter is included). Hence, the resulting recordset will often have a different number of records than what the dashboard shows.
2.1 We should modify participant search so that we can pass event statuses (and event types) via GET parameters.
2.2 Then fix the query which gets the Participant "counts" to filter on status(s) which have the is_counted flag = true.
2.3 Then fix the link in Dashboard.tpl to pass in all statuses that have the is_counted flag = true.
3. Update the code in Register.php which prevents a contact from registering for the same event multiple times. This is currently hard-coded to prevent dupe registrations if existing participant status is "Registered" or "Attended". We should modify this to use the is_counted = 1 flag to determine which participant statuses should be "blocked" from registering "again."
Attachments
Activity
Viewing and editing the new is_counted setting from the admin interface doesn't appear to have been implemented yet (http://<your site>/civicrm/admin/options?group=participant_status&reset=1&action=browse)
From the original spec:
(If we go this way, the form and selector code will need conditional logic to display and properly label this element when group = participant_status.)
... so we need conditional logic in the selector and edit form to display / allow updates to this value. Form field / selector label = "Counted?"
AND, we need to allow folks to modify this value for is_reserved statuses ('Pending' in particular). Let's discuss how to do this at the chat tonight since it's a more general issue.
Retesting with r13944. The following bug and issue need to be fixed:
1. BUG : Attempting to ADD another Participant Status option gives a fatal error (http://<mysite>/civicrm/admin/options?group=participant_status&action=add&reset=1 ):
/Users/dgg/svn/trunk/CRM/Core/Error.php, backtrace, 258
/Users/dgg/svn/trunk/CRM/Core/DAO.php, fatal, 655
/Users/dgg/svn/trunk/CRM/Admin/Form/Options.php, getFieldValue, 134
/Users/dgg/svn/trunk/CRM/Core/Form.php, buildQuickForm, 306
/Users/dgg/svn/trunk/CRM/Core/QuickForm/Action/Display.php, buildForm, 98
/Users/dgg/svn/trunk/packages/HTML/QuickForm/Controller.php, perform, 203
/Users/dgg/svn/trunk/packages/HTML/QuickForm/Page.php, handle, 103
/Users/dgg/svn/trunk/CRM/Core/Controller.php, handle, 223
/Users/dgg/svn/trunk/CRM/Core/Page/Basic.php, run, 325
/Users/dgg/svn/trunk/CRM/Core/Page/Basic.php, edit, 170
/Users/dgg/svn/trunk/CRM/Admin/Page/Options.php, run, 173
/Users/dgg/svn/trunk/CRM/Core/Invoke.php, run, 765
/Users/dgg/svn/trunk/CRM/Core/Invoke.php, admin, 102
/Users/dgg/svn/trunk/drupal/civicrm.module, invoke, 325
, civicrm_invoke,
/Users/dgg/htdocs/drupal6/includes/menu.inc, call_user_func_array, 346
/Users/dgg/htdocs/drupal6/index.php, menu_execute_active_handler, 18
2. ISSUE : Now the the CiviEvent Dashboard Event summary shows which status are "counted" against the max participants - I think we should remove the separate hard-coded "Pending" count. (Especially since if "Pending" is set to is_counted you get a confusing double-count in the box - as shown in event_dashboard.tiff screen snippet attached to this issue.)
Otherwise, I moved around things a bit in Options.tpl - and prevented inclusion of an empty field block for the filter field when it's not defined. After above is fixed, you can resolve the issue.
-fixed in revision 14356
-fixed in revision 13879