Candidate Features for 4.2 Release

Under evaluation

• Remove js code from php and templates and move it to filename.js.tpl
• Upgrade Smarty to 3.0
• Improve upgrader and consider using Batch API
• Profile UI Changes
• Migrating to DBTNG for database layer
• Wordpress style upgrades - investigate more rajan

Issues currently assigned to 4.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.
• Finalize HTML markup and css conventions for all forms and pages and implement modifications. (Layout Standards)
• Support for hierarchical custom fields (pending spec details and sponsorship).
• Additional config options for navigation menu, including: Configure "Home" nav item (URL, title, disable it...); configure hover vs click behavior; possibly option to suck it into drupal admin_menu ?.
• Make left side blocks hookable for Joomla and Standalone so they can add / remove / change order.
• Demographics : move these fields to a custom data group (instead of core data) so sites can add/remove fields as needed. (XD: I am using date_birth from api+ custom code, please don't rename to custom_xyz) (BPS: make sure no "special" functionality of is_deceased is lost)(PTP: please note that civi_engage has demographics custom data group)
• Display Smart Groups that contact is a part of in the Contact Groups tab. (Can these be marked so it is clear which are SmartGroups on the list PD)
• Add ability to create group categories and filter the category list based on those classifications. Also brainstorm other ways to improve navigability of groups as the current very basic structure becomes cumbersome when a large number of groups are created. Possibly add permissions so certain groups can be flagged as reserved by high level admins. (BPS)
• Automated install system for contributed code: Custom Searches, Reports, Payment Processors, etc.
• CRM-4572 - Address sharing between any contact types (includes "use employer address") (XD: high prio, can discuss sponsorship)
• Cleanup "billing address" functionality. Currently we have two ways to mark billing address (is_billing flag and Billing location type). This is confusing and redundant. (KJ)
• Option to display Activities on the Contact Dashboard (as an additional section).
• Allow admin to specify that certain relationship types are explicitly one-to-one, one-to-many, or many-to-one. http://forum.civicrm.org/index.php/topic,5535.msg24480.html#msg24480
• All users to map related contact info (e.g. spouse, household, etc.) for EXPORTS (similar to how we allow this for IMPORT).
• Integrate creating a household at the same time user creates a new individual (they can enter household name and spouse at the same time).
• Workflow for easily creating related individual from a household. User can supply 2 or more individual names and we'll create their individual contact records w/ "Member of Household" relationship and Use Household Address flag set. (XD: same from organisation)
• Allow users to expose "relationships" to profile forms and display (this is currently done in a limited way for Employer Name). (XD: done, use crmAPI in a custom template)
• 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)
• Enable multiple "used for" selections for custom groups and ability to duplicate custom group sets (http://forum.civicrm.org/index.php/topic,4213.msg18391.html)
• 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?)
• Option to put a mailing/postal address on hold similar to putting emails on hold.

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
• Option to display Groups that contact is part of in the Summary tab (as we do with Tags).
• Possibly the ability to have the session show OR hide all help text so user can switch from "beginner mode" to "advanced mode" when ready. (Let's look at other sites for examples of how this can be done. dgg)
• "Grid" batch input of new records - initially for Contributions (rough spec here), but possibly extend for:
  • New Membership
  • New Event Registration
  • New Pledge
• Add "Previous" and "Next" contact in group navigation to contact detail screens to make it easy to browse through the contacts in a particular group. (interesting example of this kind of functionality available in Jira, where you can basically jump through search results using "prev/next" actions)
• Allow custom fields to be edited/displayed within existing core fieldsets.
• Move to tab interface for CiviMail / CiviContribute creation pages

Search Enhancements

• Add "Preferred communications method" to advanced search (http://forum.civicrm.org/index.php/topic,6802.msg29983.html#msg29983)
• Search Builder - provide drop-downs via ajax when user selects fields like "Groups" or "Tags" as a search criteria (e.g. search fields where we currently expect user to enter an ID).

Permissioning / ACLs

• Move all permissioning to within CiviCRM (i.e. no longer use Drupal permissions, but this enables us to better support Joomla and other CMS' (like WebGUI)
• User (constituent) - level control over sharing / visibility of their own (profile) data.
• Task-level permissioning - control over 'actions' list (send email, mailing labels, delete contact, etc.)
• Permissioned access to contact tabs which aren't component-related - Relationships, Activities, Groups, Notes, Tags (hide tabs that a user doesn't have permission for).
• Extend the "permissioned relationship" concept implemented for Employee / Employer to cover any relationship type.
• Create separate permission for each kind of Import functionality. Currently there is one for Import Contacts, but not for Import Participant or Import Contribution.
• Create separate permissions for administering each component. Ie add Administer CiviEvent, etc.

CiviCase

• Phase 3 enhancements

CiviMember and CiviContribute

• CiviMember Phase 2
• Implement Personal Campaign search and listings (front-end) - based on rayogram's BCRF implementation.
• Soft credits - search functionality
• Renewal Reminder Date: allow users to import this field (Import Memberships), allow it to be editable (edit membership), and allow it to be added to a Membership Profile and used in Batch Update Memberships via Profile functionality.
• Inherited memberships should be created if a relevant relationship is created during Contact Import (e.g. import a new contact individual w/ "Employee of" relationship defined in the import mapping)
• "Get Donation Button" feature - provide a screen under "Configure Online Contribution Page" where the user can input button title, and select some style properties (e.g. bgcolor, font...) and we return an HTML snippet that they can paste on any page or block to add a donation button. We can use the CSS-generated "button" code that we currently use for our action buttons (e.g. >> New Event )
• Offline recurring contributions (may overlap with pledges? see http://forum.civicrm.org/index.php/topic,2600.0/topicseen.html for additional thoughts)
• Multiple currency support
• Mail-merge tokens for aggregate values (esp total contribution amount YTD, MTD, since inception)
• batch action to enable "Email Contribution Receipts" as per the "Print Contribution Receipts" that was added in 2.1 (from Find Contributions results)
• Batch "create membership for contacts" and "renew memberships" action (from search) http://forum.civicrm.org/index.php/topic,4174.0.html
• Volume discounts ($ or % discount if registering > N participants, single tier) via hook
• Allow separate contribution types to be specified for donations and memberships when separate payments for each are enabled (see http://forum.civicrm.org/index.php/topic,14104.0.html)

CiviEvent

• "Register for event" option with event pre-selected (from Manage Events AND / OR link from event info page for permissioned users). http://forum.civicrm.org/index.php/topic,12606.0.html#msg54254
• Provide an option to send an event invitation (using an HTML/text CiviMail invitation template) at the end of creating an event (or at a later time) to a specific group (not necessarily a Mailing group)
• 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."
• Give a person completing registration for others to select from existing contacts that they have a permissioned relationships (and/or enter a new contact). See http://forum.civicrm.org/index.php/topic,6840.0.html (and several other posts) for some specific use cases.
• "Register Multiple Participants" - allow admin to set maximum number of participants that can be registered in one registration sequence.
• Allow participants to edit selected portions of their registration info (the associated profile fields only) from the contact dashboard. (Restricted to online event registrations - since we don't have profiles for offline registrations).
• Conditionally allow authenticated participants to Cancel their event registration (provide a link from the Event Info page when we recognize that the user is registered). This should be configurable per event (Allow self-service cancellations).
• Look at implementing CalDAV feed / download format
• Calendar widget to display events in a block or on a page (alternative to Drupal calendar, solution for Joomla and standalone).
• Recurring Events:
  • With frequency + duration - Every Monday at 7pm for 12 weeks
  • OR with a set of dates - April 7, April 10, April 14, April 17
  • Review the Recurring Events data representation in the iCalendar specification for additional properties - http://www.ietf.org/rfc/rfc2445.txt
• Extend the data model to allow entities in the CiviCRM DB to "own" an event (e.g. and Organization, Group or Individual). This has implications for permissioning and also probably means we would need a simplified "end-user" event creation wizard which hides many of the current config options.
• Allow for nesting events. One event should be able to contain multiple other events. Ideally administrators would be able to designate certain child events as mandatory (participant automatically registered for child when registered for parent) or optional.
• CRM-2747 - Allow quick access to an event "Attendance Sheet" by creating single URL invoke for Batch Update Participants via Profile

CiviMail

• "Forward to a Friend" feature so that a mailing recipient can trigger the mail being resent to a new person, who is added as a contact if they don't already exist (could this ensure that checksum gets dropped out of the fwded email?)
• Automated Recurring Mailings in civimail - for recurring meeting reminders etc.
• replace the wizard by a tab (like civiEvent) XD

CiviPledge

• Phase 2 items
• Apply partial payments to a pledge

CiviReport

• Add ability to create new report from existing report (rather than start from scratch with creating from template).