Candidate Features for v2.2
Core CiviCRM
- Caching mechanism for Smart Groups (may be done in 2.1?)
- CRM-1527 - Allow multiple values per custom field
- Import refactoring / optimization
- Allow user to pick a specific duplicate matching (dedupe) "rule" for an import session
- Allow user to specify fixed value to be inserted in a column (e.g. import source can be marked in Source field with a fixed string)
- Ajax-based hierarchical select "widget" for Country -> State/Province that can be used in Profile forms
- CiviCRM Groups-to-Drupal-Roles synchronization module
- Improved / separate Activity Search interface
- All users to map related contact info for EXPORTS (similar to how we allow this for IMPORT).
- Allow users to expose "relationships" to profile forms and display (this is currently done in a limited way for Employer Name).
- 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.
- 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.).
Usability Improvements
- Menu improvements:
- Submenu items visible w/o selecting parent menu (via expand icon or mouseover)
- Admins can customize menu order and content, add menu items etc.
- Preserving search results selection across results pages - http://forum.civicrm.org/index.php/topic,2321.0/topicseen.html
- 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.
- Allow custom fields to be edited/displayed within existing core fieldsets.
- Contact view - visually differentiate tabs that have some data for a contact from ones which don't (e.g. Events tab is light gray if no event registrations). http://forum.civicrm.org/index.php/topic,4214.msg18392.html#msg18392. Need to evaluate overhead / caching possibilities for this.
- Streamlining data entry using Ajax / Dojo
- Implement Ajax-based "click to edit" functionality for fields on Contact Summary screen (Name, Phone #'s, Email Address etc.)
- Extend Auto-complete drop-down 'search' on contact name to streamline work-flow for the following tasks. We need to figure out how to allow the user to differentiate contacts with the same or similar names on select (maybe write the primary email and city/state to a read-only block next to the ComboBox when a contact is selected).
- New Contribution
- New Membership
CiviMail
- The link to view "Details" of a CiviMail email from the recipient contact's Activity listing should take you to a page that shows the complete message (w/ header and footer and eval'd tokens). This same page should be accessible directly via a token-generated link that can be placed in mailings..'Can't read this email - click here' (http://forum.civicrm.org/index.php/topic,3551.0.html - also discussed at Apr '08 Melbourne Boot Camp).
- Mailing Report - view mailing should store and show entire mailing. Currently it just shows the message body - it should include header and footer.
- Automated Recurring Mailings in civimail - for recurring meeting reminders etc.
- Profile add to group - option to set status to pending, and send email for opt-in (if CivMail enabled).
Search Enhancements
- Build support for parameterized smart groups - including simple expressions like date() < now()
- Allow user to inject sql to create smart groups
- Location / perimeter based searches (find contacts within X distance from a point or within a defined perimeter)
- Build support for full text search (Solr/Lucene)
- Search contacts by "created" date range
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 in 2.2 to cover any relationship type.
- Permissioning for "Delete contacts" (so some users can be blocked from delete action).
CiviMember and CiviContribute
- Soft credits
- Personal Campaign Pages
- Batch "create membership for contacts" action (from search) http://forum.civicrm.org/index.php/topic,4174.0.html
- Offline recurring contributions (may overlap with pledges? see http://forum.civicrm.org/index.php/topic,2600.0/topicseen.html for additional thoughts)
- Contribution/membership pages with Organization fields (allow an Org to contrib and/or signup for Memberships)
- Add configurable Receipt/Confirmation "subject" (with token support) for Contributions and Event Registration
- Multiple currency support
- Mail-merge tokens for aggregate values (esp total contribution amount YTD, MTD, since inception)
- Integrate civimember_roles module as part of CiviMember
- Enable html emails for automated receipts
CiviEvent
- Additional "discounting" features:
- Configure $ or % discount for current members (e.g. logged in user who has any non-expired CiviMember membership). Also apply/display discount for anonymous registrations at Confirm step if we match on an existing contact who has a membership.
- Volume discounts ($ or % discount if registering > N participants, single tier)
- Redo Price Sets to use custom data group / custom field model to define fields, and new custom_value_<table> model to store data. Figure out how to allow multiple items in a checkbox "set" to have the same price. Participant export should handle price set data same as custom fields so price set field instances can be counted and aggregated in a spreadsheet.
- Admin approved event registration: http://forum.civicrm.org/index.php/topic,1556.0/topicseen.html
- Allow participants to edit their registration info (maybe not cancel? if so how to deal w/ refunds etc.)
- Wait-list management: Allow people to register in "Wait-list" status if event is full - and email them with link to come back and complete / pay for their registration if a space opens up. (This could use similar hash mechanism as the automated Pledge Payment reminder functionality.) See http://forum.civicrm.org/index.php/topic,2712.0.html for use case info.
- Expire pending (pay-later) registrations after NN days (cron job could be used to change status from Pending to Cancelled and send cancellation notification email).
- 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.
- Allow participants to edit selected portions of their registration info (perhaps the associated profile fields) from the contact dashboard.
- CRM-2747 - Allow quick access to an event "Attendance Sheet" by creating single URL invoke for Batch Update Participants via Profile
- Static URL to display current / upcoming Events in HTML format (this is an HTML version of the existing RSS feed).
- Mechanism to pass and store "referring URL" for contributions (should include Widget-referred contribs)
- Mechanism to set default / hidden field values via GET params in online contribution forms, online event reg and profiles
- Enable html emails for automated receipts/registration confirmation
CiviPledge
- Import pledges / pledge payments
Miscellaneous
- Make email address a mailto: on internal search results selector
- "Use Organization Address" option for Individuals (similar to new "Use Household Address")
- Consider using mysql stored procedures and views to store/retrieve complex information
|
|
Allowing people to cancel event registration is is very important. They should not be able to delete themselves, just change their status to cancelled. What I am not sure about is should they then be able to reinstate themselves. Consider the following:
Early Registration (before 1 July) costs $100
Regular Registration (between 1 July and 21 July), less costs $150
Late Registration (between 21 July and 30 July) costs $200
Registration closes on 30 July, the event is 7 August.
Bill registers on 30 June and pays $100.
He then cancels his registration on 10 July and wants to reinstate on the 12th. Should he be required to pay the $50 extra (i.e. should this be treated simply as a new reservation?) Is it different if the refund has not been processed (or if no refunds are provided)?
Tom registers on 30 June and pays $100.
He then cancels on 25 July, but on 4 August wants to reinstate his registration? Again, assume that no refund was allowed (or just no refund was processed).
Including a link in the confirmation email to cancel one's registration, would be a really good thing.
Related would be the ability to add other status items to a registration that would also be user editable.
For example:
How will you be arriving at our event:
On foot or public transportation
Driving - have room for others
Driving - full car
Need a ride
This could be used to help match those who need rides with those who can offer them.
or
Entree choice:
Fish
Chicken
Beef
Vegetarian
Vegan
Both things could change (and in the second case, there might be a cutoff date for allowing changes).
/carmi
It is great that one can now easily create publicly accessible participant lists. What would be very nice is to be able to chose which fields get displayed and how the lists are ordered.
For example:
Registration form collects this data:
First Name
Last Name
Nickname
Year of Graduation
City
State
Gender
One might want to only include first name and city/state or only nickname. One might want to order by year of graduation (so that one could see who of one's classmates was attending), or by city/state to see if one might want to arrange to drive together).
Also, it would be nice to allow a registrant to include/exclude himself on the public list and to choose which items get displayed.
/carmi
As was suggested, an attendance list would be great. Related would be a very lightweight mechanism to make certain changes, so that one could have a check - in desk that had the list of all registered guests with a check boxes for checked ID, accepted payment, gave badge, (etc.) that did were immediately communicated to the database without having to refresh the entire page (there also needs to be some way to notify other open pages of these changes so that one could not pick up ones materials from one person, then walk over to another person and "check in" again).
/carmi
CiviEvent: name tags for participants, based on address label functionality, but allowing a broader set of fields eg job title, including custom fields.
There was a similar suggestion for badge printing made a few releases ago. Ideally, functionality to do this as part of a check-in process would be great (that is, do not print the badges/name tags in bulk, but only as the user shows up and is confirmed) for both cost and security reasons.
/carmi
I think CiviMail is often used for newsletter management. We often include a list of events in an email. also the ability to see archived newsletters would be useful. finally, there are a few different opt-in / signup scenarios, and i think they could be enabled at the group level:
1. when user is added to a group they are automatically signed-up to a newsletter subscription
2. when a user is added to a group they are asked to opt-in to a newsletter subscription
3. the group emails / rules / opt-out are managed independantly (at the group level)
I have some code that i can contribute that may help add events to an email - but that will be a very powerfull feature! Could also add a calendar!
Add to CiviEvent an explicit ability to have an event participant require approval. many events are open to people who have not yet registered (anonymous). They can request event participation (and payment) but we want to make sure they are appropriate for the event. This would work similar to moderated forums.