Candidate Features for 3.2 Release

Schedule

Alpha: June 6th, 2010
Beta: June 15th, 2010
Final: July 28th, 2010

Issues currently assigned to 3.2 in the issue queue

Core CiviCRM

• Modify form and page code to reduce the work done on ajax requests. For example, looking at Contribute_Form_Contribution - the call to load custom data does good job since it returns quickly in functions once it's work is done. However, the formType invoke (which loads credit card payment block and additional panes) isn't structured properly since the code does NOT return in preProcess and setDefaults even though no work is needed.
• Support for hierarchical custom fields (pending spec details and sponsorship).
• Automated install system for contributed code: Custom Searches, Reports, Payment Processors, etc.
• Option to display Activities on the Contact Dashboard (as an additional section).
• Separate operations / permissions for "Move to Trash" vs. "Permanent Delete" for contact records. The default action is "Move to Trash". Users with "Permanent Delete" permission can periodically run an "Empty Trash" operation. While implementing, look at providing immediate Undo action for deletes and eliminating the extra clicks (are you sure...) - as described here: http://www.alistapart.com/articles/neveruseawarning/ (XD: high on my wish list)
• Enhance external / bin script authentication function to allow passing in a verification of expected permissions (e.g. 'access CiviPledge' for UpdatePledgeRecord.php script, etc.). (XD: ???)
• Introduce consistent date created, date last modified solution across the system (maybe together with moving logging to db layer?)

Usability Improvements

• Reset button for search forms (clears all search criteria/sets them back to defaults). Note that this can NOT be the standard HTML reset button, since once the form is submitted - reset doesn't set field values to pre-submit values).
• Provide mechanism for field-level configurability for the edit form and summary screen (include / exclude core fields, set order and grouping...). See Xavier's forum post here for one possible approach: http://forum.civicrm.org/index.php/topic,6350.0.html

Search Enhancements

• Add "Preferred communications method" to advanced search (http://forum.civicrm.org/index.php/topic,6802.msg29983.html#msg29983)

CiviCase

• Phase 3 enhancements

CiviEvent

• Define and store "Name Tag" content (via tokens). Task to print Name Tags from Find Participants (search results action).
• CRM-3175 Bind event pricing options to memberships
• Allow someone to register for another person or persons without themselves being a registered participant (e.g. parent registered children for a camp or class, etc.)
• In 3.0, we added code to bypass the "already registered" check for logged in users if "Register multiple participants with same email address" is enabled (http://issues.civicrm.org/jira/browse/CRM-4855). However, this invites problems with users unintentionally over-writing their own contact info. Rather than bypassing "already registered" check. We should provide a link which passes an additional parameter which specifically forces the code to NOT use the registered user's contact record. "You're already registered for this event. Click here if you want to register someone else."