Skip to end of metadata
Go to start of metadata

Features for v2.1

Note that v2.1 will ONLY support PHP5.2+, MySQL 5.0.x+ (later releases only), Drupal 6.x, Joomla 1.5.x

The approximate timeline for 2.1 is:

  • Code freeze: July 23rd
  • Alpha release: August 6th
  • Beta release: August 28th
  • Final release: October 1st

CMS Compatibility - Current Stable Releases

Search restructuring

  • Split queries up into multiple smaller pieces for scalability ( i.e. restrict the number of left join's to get list of id's etc)
  • Optimize permissioning clauses based on work done by Rob and search restructuring. Might need to do some caching of contact id's and smart groups to avoid multiple left joins in SQL clauses
  • CRM-1569 Optimize CiviContribute query
  • (tick) CRM-3029 - Additional operators for Search Builder - IS NULL, IS NOT NULL

Ajax / Dojo Usability Improvements

  • (tick) CRM-2622 - Provide direct access to selected contact record from Quick Search by adding "View Contact" button. This button is default ENTER key action if an exact contact match is selected from the drop-down list.
  • (tick) CRM-3000 - Use Ajax to prevent reloads of New Activity, New Contribution, New ()Membership, New Event Registration, New Relationship forms to load in custom fieldsets.
  • (tick) CRM-2669- Provide keyboard shortcuts ("access keys") for common tasks like New Contact, and Save.
  • When "Use Household Address" is selected for a contact with an existing relationship to a household - the related household should be selected in the dojo comboBox by default.
  • (tick) CRM-3002, CRM-3047 - Allow site admin to choose a Rich Text (WYSIWYG) Editor to be used for CiviMail compose mailing AND other fields which accept HTML input (e.g. Event Description). TinyMCE and FCKEditor support will be included for 2.1.
  • (tick) CRM-2789 Current Employer in Add/Edit Individual should work like "Use Household Address" - e.g. you can use a comboBox to find existing an organization, or create new organization as needed.

Export and Action/Task Improvements

  • (tick) CRM-2781 - Implement mappable exports for CiviContribute, CiviMember and CiviEvent component searches. Also, streamline "load saved mapping" work-flow by allowing user to choose a mapping from step 2 of the export wizard.
  • Add missing core "actions" to each component search (Find Participants, Find Contributions, Find Members) to make them consistent with each other as appropriate - and provide relevant actions that are provided by Basic and Advanced Contact Search (e.g. Add Contacts to Group, Mailing Labels, New Smart Group, Tag, etc.)

Custom Fields

  • (tick) CRM-1594 - Allow php code for custom fields

Dedupe Optimization / Scalability

CiviMail

  • Expose archives of mailings by mailing list (so it can be exposed to end-users)
  • (tick) CRM-2574 - VERP email addresses are often too long (> 64 characters) violating RFC and thus being rejected
  • (tick) CRM-3049 - Ability to Save a Mailing Draft and finish it / send it later.

CiviPledge

CiviEvent / CiviMember / CiviContribute

  • (tick) CRM-2759 Option to submit live credit card transaction for offline Membership signup/renewal and offline Event registration (as we do for offline contributions).
  • For offline Membership signup and Event registration:
    • (tick) CRM-2970 - Include Event Name / Membership Type at the beginning of the automatically generated "source" value for the associated contribution record.
    • (tick) CRM-2970 - Give access to Transaction ID field in "Record Payment" fieldset - so check # or other transaction ID can be entered
  • (tick) CRM-2877 - Provide a way to administratively configure the Participant Statuses which are considered "registered". (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.
  • (tick) CRM-3086 - Allow one person to register multiple participants. All profile fields configured for the event are used to collect contact and participant info for the person registering and each additional participant.
  • (tick) CRM-3088 - Discounted fee levels by registration date (early-bird pricing). Supports one or multiple discount date ranges.
  • (tick) CRM-2758 - Allow custom templates for Event at the event_id level, and Online Contribution pages at the contribution page id level (as we do with profile)
  • Allow admin to add custom message to offline contribution receipt email (as we now do w/ membership and event).
  • (tick) CRM-2984 - Find Member and Find Participant 'standard export' should provide basic information needed to calculate income from memberships and events. This means including following field values from the linked contribution record: Total Amount, Contribution Status, Received Date, Payment Instrument, Transaction ID.
  • (tick) CRM-2964 - Allow individuals to signup for membership and/or make contributions "on behalf of" an organization. This will involve creating a permissioned relationship between the individual and the organization contact records which allows the "logged in individual" to renew a membership, view a dashboard for their related organization(s), and conditionally access a profile to update organization information.

Miscellaneous Improvements and Fixes

  • (tick) CRM-2968 - Improved access to Current Employer value for contacts (this is defined as an Individual contact's newest active Employer relationship):
    • Include Current Employer (organization name) in default contact export set (PRIMARY fields).
    • Current Employer is available when "selecting fields" for export.
    • Current Employer is displayed (when populated) on Contact Summary screen (contact/view) in front of Job Title display.
    • Current Employer token is available to be included in Mailing Labels
  • (tick) CRM-2222 - Fix Profile Listings so that Current Employer can be displayed in search results.
  • If individual contact has an active household relationship (member of, head of) - display Household Name on Contact Summary screen.
  • Take componentization to the next level (auto-registration of components, remove remaining component artifacts from core...?? )
  • (tick) CRM-2780 - Store default mail "factory" (smtp) in config and allow admin to change to using sendmail instead.
  • (tick) CRM-2589 - Searchable custom fields within a given range doesn't work (tested w/ Memberships - using member search)
  • Nestable groups (see http://wiki.civicrm.org/confluence/display/CRM/Proposed+nestable+groups+implementation)
  • (tick) CRM-3030 - Batch update via profile for Find Members (as we currently have for Participants and Contributions)
Labels
  • None
  1. Feb 16, 2008

    As always it sounds like its getting better with each release. (smile)

    With the updates for CiviEvent it sounds like you may already be doing this(or at least have the tools in place) but I wanted to make sure. You mention early bird and member pricing(love it), and I was wondering if there was also an option for members to be able to register before non-members? With maybe an option for non0-members to become members as time of registration to qualify. A use case would be a limited space event where we want to make sure that our ongoing supporters had first crack at a limited number of seats/tickets, plus it provides a benefit for people to join up.

    1. Mar 10, 2008

      Paul,

      I see a lot of good stuff coming up for v 2.0... I share the same challenge. Due to limited seats on my events, I would like to see the following:

      a) I would like to prioritize seats taken based on the types of membership. That way, for example, platinum members would be able to book seats prior to gold or silver members and so on. I think it would be ideal to have ranges of seats per membership type, like total # of seats: 200. Silver members can book up to 50 tickets out of 200. Gold members can book up to 50 tickets out of 200 tickets, plus all 50 tickets reserved for silver as well. Platinum members can book up to 100 tickets out of 200 or any other available ticket from the other lower memberships types.

      b) Canditate features for v2.1 already includes the ability to one person register to multiple participants which is awesome, but if we could be able to generate tickets for controlled events that would be even better. I think the ideal solution would have a way to print a ticket, and probably generate a barcode/token or something that could be validated at entrance probably using a palm barcode reader that would validate this against the registration list. (not sure yet of the feasibility of this)

      c) I may be wrong but I havent seen yet the option to offline payments for events. This could be an interesting alternative for some technical issues/limitations during the registration process. 

      d) I think it makes sense to document the type of membership someone has and provide a badge or preferred contributor type of thing so depending on the event, just being the cardholder would provide entrance, additional discounts on the community business, etc. This could probably be implemented the same way mailing lists work, so I could print my own badge or the organization would print those and mail it to everybody...

      Sorry if my post is not appropriate for this thread but these are the enhancements I would like to see in one of the upcoming releases of this great system. What I can tell you guys is this is a thrilling application. I've been working with CiviCRM for a couple of months and I simply love it. I cannot think a organization could build up a new application from scratch without seeing all CiviCRM is capable of or without considering all the hard work you guys have put here already.

      Cheers and congratulations! 

  2. Feb 17, 2008

    Request for 2.1 --

    Improve integration with Joomla user's table (jos_user) to at least match the currently functionality given to Drupal users. My wishlist:

    • connection/synch email fields, or have the option of overriding Joomla fields with CiviCRM records (like Community Builder plugin)
    • ability to control user access based on CiviCRM member status (lock users if membership expires; probably would want to create a status rule type to control that)
    • ability to have a single sign-up form with CiviCRM profiles, member join, contribution collection, AND user access fields (so a person can join the organization and create their username/pwd in a single process)

    See also this topic discussion on the issues: http://forum.civicrm.org/index.php?topic=1745.new;topicseen#new

    Thanks!

    1. Apr 18, 2008

      On this point, I think it would be useful to look at a Joomla 1.5! authentication plugin that simply authenticates against CiviCRM data and ignores the jos_user table altogether to the extent possible.  If J1.5! can authenticate against LDAP, I would think it can authenticate against other things like CiviCRM user/membership tables?  In fact, should CiviCRM be exposing certain data through LDAP so that it can provide a central directory of information and credentials that any LDAP compliant application with appropriate security can query it?

  3. Feb 18, 2008

    Another area that I think could use some improvementis how event registrations and membership records are connected with their corresponding contribution. Right now, CiviCRM is basically built to assume payment is received with an event registration/membership renewal. But a lot of the associations I work with may receive a registration/membership with a voucher, PO, or indication that a "check is in the mail." It's very difficult to run a list of delinquent registrants/memberships, because there's not a strong connection between the event/membership and the corresponding contribution (or lack of contribution).

    Some of this might be resolved in the 2.0 one-step registration -- at least it encourages the staff person to create a corresponding contribution right away, which can be flagged as pending and followed-up later. But I still think there need to be a better way of connecting the contribution with whatever it's paying for. 

    1. Feb 18, 2008

      Brian - Can you check out the "Pay Later / Pay By Check" functionality in 2.0 and see if that meets the needs above?

      1. Feb 28, 2008

        No. That new functionality only impacts the frontend registration form. The issue is with the backend. And I took a closer look at the one-step registration, and really don't think it gets close enough to addressing the issue. The problem with a "lack of connection" between the two components impacts two issues.

        Here's one issue, working backwards from what I would like to get out of the end --

        Let's say that I want to pull a report of all payments received (contribution status = completed) for Training Event #1 (perhaps in order to track the revenue vs. budget, or some other financial purpose). Right now there's no connection between the event registration and it's associated contribution -- aside from the contribution type field, which is generic (e.g. "Event Fee"), not event-specific. So basically, I am not able to pull a list of financial records for an event (or a membership type, as the disconnect between CiviMember and CiviContribute exists as well).

        When someone registers for an event online, the name of the event is inserted in the Source field for the contribution. That's somewhat helpful, as I could search based on that Source field to find my records. But that's not a very "strong" way of bridging the gap. And for any registrations happening through the backend, there's no easy way to ensure the same content is being placed in the Source field to make it consistently searchable (between frontend and backend registrations).

        Perhaps one way to handle this is when the contribution record is created, and the contribution type is selected, provide a dropdown field next to the contribution type where the user can select an event (if Event Fee is the type), or membership (if Dues Fee is the type). That data can then be queried.

        The other issue (likely more complicated), and what I tried to explain in the earlier comment, is with registrations that don't immediately have an associated contribution record. Let's say I get a registration in the mail, and they inform me that a check is on the way (maybe its a government institution and takes 4 weeks plus 14 levels of bureaucracy to get a check cut). So I register them for the event, because I know they're good for the money. How do I, at a later date, pull my list of "delinquent" registrants -- those who I've not yet received payment for? One-step registration does help, because it encourages me to create a "pending" status contribution record for them. But there's still not the connection between the two puzzle pieces that I would like to have.

        Does this make sense?  

        1. May 05, 2008

          With both "One-step" (back office) registration, and online registration (pay now OR pay later) - we do create a record which explicitly links the participant record to the corresponding contribution record (civicrm_participant_payment table). In 2.0 we don't do a good job of exposing this connection. Although it is used - when you update a Pending contribution record which is linked to a participant (event registration) record - we find and update the corresponding Pending participant record using the link table record.

          In 2.1 we are exposing this linkage in two new ways that I think will cover your requirements:

          1. Jul 07, 2008

            On this issue, could we add a dropdown in CiviContribute so that you can associate a contribution with a specific event/membership. Currently, if you create a contribution record for event fees in CiviContribute, it's not connected to the associated event. Custom searches are providing more capability to take advantage of that connection -- but we need to make sure the connection can be built from both directions (CiviEvent/CiviMember and CiviContribute).

            Building a dynamic dropdown for event fees or membership records would help overcome the fact that integrating the credit card transaction mechanism into the CiviMember/CiviEvent record transaction block was bumped to 2.2.

            1. Jul 08, 2008

              Brian - Credit card transactions for events and memberships are back on the 2.1 queue - the issue is currently resolved and awaiting QA (http://issues.civicrm.org/jira/browse/CRM-2759) (smile)

  4. Feb 27, 2008

    Hi David Greenberg

    I have 2 suggestion regarding CiviEvent : 

    1) Currency : Currently Only USD, Why can it be customized in to local currency like oscommerce system?

    2) Country : In Admin I don't see except USA as country.

    Why cant it be simple ? May be it could be more simple with all countries and leave the states to be filled by the registered delegates.Instead of auto complete by the current system.

    http://demo.oscommerce.com/  

    In that Admin can create currencies and values. Same time user or the people who want to signup have a choice of currency selection depending of his location and choice of currency he want to pay. If a module can be created just like osCommerce the payment module can be universal. It will facilitate choice of payment currency and accessible by everyone from different countries using different currencies for same value (default currency)

    Example http://demo.oscommerce.com/   (select the choice of your currency bottom left)

    (In this demo only 2 currencies were demonstrated but there is option of infinite number of currencies choice which ADMIN can create.

    1. Feb 27, 2008

      Hey John,

      Both things can be changed through CiviCRM Administration - you can change currency (single currency per system at the moment) and you can extend the list of countries available.

    2. Feb 28, 2008

      Hi Michal Mach,

      Thank you! for the info. (list of countries - SOLVED)

      Multiple currency is more important for CiviCRM as it is global solution.

      If multiple currency option is included: User /Delegate/ Contributor / Doner can choose the currency of his/her choice. This will drive the motivation factor for the user to donate/contribute or to register. ( Currencies are always fluctuating) this will solve the floating exchange rate problems.

      I hope you understood what i mean. (Currently USD is on downfall and other currencies such as Euro/ Pound and many more are on the rise.. this is effecting worldwide)

      Example http://demo.oscommerce.com (select the choice of your currency bottom left)

      (In this demo only 2 currencies were demonstrated but there is option of infinite number of currencies choice which Administrator can define/create/set value for multiple currency.

      1. Feb 28, 2008

        This discussion should happen on the forums, http://forum.civicrm.org/

  5. Feb 28, 2008

    Another area where I think there could be some improvement is workflow efficiency. Many CiviCRM functions work in a very logic-flow, wizard-like way. While the logic makes sense, it's not always efficient, as multiple page reloads are required to perform simple actions. For example, when registering someone for an event from the backend, the registration page is reloaded like 3 times because of conditional fields that impact options. While some of this is unavoidable, and some of it is gradually being addressed through ajaxification, I think there are a few ways some of the steps could be consolidated. Here are a few areas I've noticed:

    Event Registration:
    Currently the process steps for registering from the backend is to locate the contact, select the Events tab, click the register for event link (reload), select event (reload), select participant role (reload), complete form and save. Two suggestions: 1) add the event selection dropdown to the contact-event tab. So once the contact is located and the event tab is selected, the admin selects the appropriate event from the dropdown and click a link/button to register the individual for that event. 2) enable a default value for the participant role, and have the appropriate conditional fields preload based on the default value. If the value is changed, the page will necessarily reload. But since likely 80+% of the time the role is attendee, that could significantly improve efficiency.

    Data Export:
    Similarly, the data export process seems to have a few too many steps. Perhaps if you added a drop down with saved mapping options to the first export screen (where you either select the Primary export fields OR custom fields option), that would get people a little farther a little more quickly.

    These are two areas that I recently took notice of, though I'm sure there are more. The first has been from some users that have significant numbers of registrations to handle through the backend, and find it's taking a long time to work through them.

    On another note --
    The component area searches (e.g. show registrants for an event through CiviEvent rather than through the advanced search) are somewhat limited in terms of the action-options and other criteria options. It would be nice to extend some of those functions/options to match what's available in the primary search tools. For example, you can't export to mailing labels directly from within CiviEvent/CiviContribute/CiviMember. You also don't have the option of selecting a Search View from within any of the components.

    Since so much capability and functionality is built into the advanced search tool already, maybe there's a way to extend that existing tool to the component-specific areas rather than have separate search forms for each. I know there's benefit in simplicity, but it seems like those search forms need just a little more going for them.

    -Brian 

  6. Mar 01, 2008

    While CiviMember currently offers some great resources it would be good to see it receive some improvements. I'd be keen to see the ideas around the  CiviContribute & CiviMember membership renewal payment process  as described here: http://wiki.civicrm.org/confluence/display/CRM/CiviContribute+++CiviMember+membership+renewal+payment+process+requirements

    Also, a lower priority for me personally, but a major advance would be Multi-Organization Support http://wiki.civicrm.org/confluence/display/CRM/Multi-Organization+Support+in+CiviCRM

  7. Mar 12, 2008

    Just a comment to reiterate that every civi-event feature would be very valuable (see below for quote.) Also, improved tax deduction reporting for civievents and civicontribute so a tax deduction receipt can include price - market value.  Finally, having an event treated as a drupal node would improve cms integration (ie civinode for events.)

    • Provide option to submit live credit card transaction for offline Membership signup/renewal and offline Event registration (as we do for offline contributions).
    • For offline Membership signup and Event registration:
      • Include Event Name / Membership Type at the beginning of the automatically generated "source" value for the associated contribution record.
      • Give access to Transaction ID field in "Record Payment" fieldset - so check # or other transaction ID can be entered
    • Allow one person to register multiple participants - with or w/o contact names (configurable)
    • Event "pricing" features (extending price sets?):
      • Prices based on signup date (e.g. early-bird pricing)
      • Prices based on ACL role (e.g. member vs. non-member pricing)
      • Volume discounts
    • Allow custom templates for Event at the event_id level (as we do with profile)
    • 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
    • Allow admin to add custom message to offline contribution receipt email (as we now do w/ membership and event)
  8. Mar 15, 2008

    Current_employer form field, when populated, creates an organization record and builds a relationship between the individual and that organization. I've found this to be a dangerous tool for users because they complete the individual's contact records, fill in that form field thinking it's just a static field like all the others, and then we end up having a lot of duplicate organization records created. If that field remains in its current state, there should be some mechanism to do a search on existing organizations (similar to the new relationship form) or confirmation that a new org record should be created.

  9. Mar 15, 2008

    Groups:

    • ability to categorize groups (as the list grows it becomes cumbersome to manage). at a minimum, the existence of categories (with the ability to easily filter the list) in the manage groups view would help with managing things.
    • the addition of a filter to distinguish between smart and static groups in the manage groups view would be helpful.
    • smart groups should be excluded from both frontend and backend join lists. since they are defined through query criteria, the ability to join or be removed should not be handled through manual options
  10. Apr 14, 2008

    I'd like to see the ability to specify custom data sets for participants to specific event categories, and even specific events. Currently, when creating a participant-type custom data set, the only specification beyond that is the participant type (e.g. attendee). But some custom data sets are specific to a certain event type, or event to a single event. Having the set apply to all events of a particular participant type clutters the backend interface for those events that don't need to collect that data.

  11. Apr 25, 2008

    I posted several wish list items at http://forum.civicrm.org/index.php/topic,3186.0.html. Some are on the list above. Is it okay if I add a child page here where I would start working out some engineering implementation plans for feedback from the community?

    1. May 05, 2008

      Definitely ok to add a child page here. We can decide on an eventual "home" location for the page depending on timing and process of implementing the feature set.

  12. May 13, 2008

    We just launched and have a few gaps that we would love to hit the roadmap:

    Reply message when a user is added to a group (may be planned in future release) as enhancement to subscriptions

    Show complete price set details in event receipt and cc's (ie. event thank you message) - rather than just the total amount.

    Support event registration for ACL (access control lists) based on group so only members of a certain group (say 'Men') can register online for an event or an event type (ie "Men's Only Events".)

    A report showing price set fields (is show 'Name, Address, PriceSetField 1, PriceSetfield 2) and allow a "count" for a price set field (ie. number of tickets, not just total ticket dollars.)


    1. May 14, 2008

      Reply message when a user is added to a group (may be planned in future release) as enhancement to subscriptions

      Show complete price set details in event receipt and cc's (ie. event thank you message) - rather than just the total amount.

      Support event registration for ACL (access control lists) based on group so only members of a certain group (say 'Men') can register online for an event or an event type (ie "Men's Only Events".)

      • Limiting access to events via ACLs is part of 2.0. You'll probably need to experiment a bit to see if it meets your needs. You'll need to "turn off" the Drupal role-based permission for "register for events" and then add ACL's for each event (some events can have an ACL which gives access to Everyone if they are 'open').

      A report showing price set fields (is show 'Name, Address, PriceSetField 1, PriceSetfield 2) and allow a "count" for a price set field (ie. number of tickets, not just total ticket dollars.)

      • Export / "reporting" changes for Price Sets probably won't happen until 2.2+ as we are going to overhaul / improve the data model (probably fit it into the new custom field model).

Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.