Features for v2.2
The approximate timeline for 2.2 is:
- Code freeze: December 3rd, 2008
- Alpha release: January 12th, 2009
- Beta release: February 4th, 2009
- Final release: March 11th, 2009
Core CiviCRM
CRM-3788 Admin can "force" the Create User option in a profile.
CRM-3602 Activity and Relationship search components should expose searchable custom fields.
CRM-3264 - Ajax-based hierarchical select "widget" for Country -> State/Province that can be used in Profile forms
CRM-1527 - Allow multiple values per custom field
CRM-3494 - Cleanup billing name and address handling
CRM-3974 - First steps towards import refactoring
CiviCase
Case Management component - sponsored by Physicians Health Program of British Columbia.
CiviMail
CRM-3835 Layout improvements to compose mailing form.
CRM-3752 Ability to archive completed mailings.
CRM-3711 Ability to CiviMail all the contacts from a search result (i.e target mailings from searches without explicitly creating a group first).
CRM-3616 PHP-based option to handle return channel (bounces, replies ...) - replaces AMAVIS - simplifies installation and server access requirements.
CRM-3712 Hook to implement additional tokens that can be used in mailings.
CRM-3552 Allow admin to set default "from email address" and use the FROM Email Address options for CiviMail mailings
Search Enhancements
Search contacts by "Created" date range - allows users to find newly added contacts easily (done via a custom search)
CiviMember and CiviContribute
CRM-3514 - Personal Campaign Pages
CRM-3874 - Soft credits (phase 1)
CRM-3923 Add separate field in contribution record for Check Number (no uniqueness constraint)
CRM-3810 - Add hook for Contribution Page and Event buildAmount() functions. This will allow folks to implement the Dynamic Ask http://forum.civicrm.org/index.php/topic,4727.msg20607.html#msg20607, and to implement "member-based" event discounts based on their own business rules (re. What is a "member")
CiviEvent
- CRM-4167 - In "Register Multiple Participants" workflow - allow additional participants to be registered without requiring an email address for each of them (http://forum.civicrm.org/index.php/topic,4915.msg21424.html#msg21424). A profile with First and Last Name fields must be included in the event registration form if you want Email to be optional for additional participants.
CRM-3546, CRM-3547 - Event Statuses: Visibility setting (public vs. admin-only), and ability to modify status "labels".
- These two changes are being made primarily to support an RSVP style registration flow. A brief specification and additional customizations required to implement this for 2.2 are described here: RSVP-style Event Registration
- Discounts for members and membership signup integrated with event registration (you can use a hook for this in 2.2+)
- Configure $ or % discount for current members (e.g. logged in user who has any/specified 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.
- CRM-4182 - Multiple participant discounts via hook
CiviGrant
CRM-3922 Add support for attachments to the New / Edit Grant form (CiviGrant)
Comments (14)
Aug 01, 2008
Carmi Weinzweig says:
Allowing people to cancel event registration is is very important. They should n...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
Aug 01, 2008
Carmi Weinzweig says:
It is great that one can now easily create publicly accessible participant lists...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
Aug 01, 2008
Carmi Weinzweig says:
As was suggested, an attendance list would be great. Related would be a very lig...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
Aug 02, 2008
JoeMurray says:
CiviEvent: name tags for participants, based on address label functionality, but...CiviEvent: name tags for participants, based on address label functionality, but allowing a broader set of fields eg job title, including custom fields.
Aug 09, 2008
Carmi Weinzweig says:
There was a similar suggestion for badge printing made a few releases ago. Ideal...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
Aug 05, 2008
shawn holt says:
I think CiviMail is often used for newsletter management. We often include a lis...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!
Aug 05, 2008
shawn holt says:
Add to CiviEvent an explicit ability to have an event participant require approv...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.
Sep 05, 2008
mark says:
hi All, i think the recurring events will be huge for CiviEvents. It will open ...hi All,
i think the recurring events will be huge for CiviEvents. It will open up the whole realm of training sessions, ongoing advocacy forums, regular classes. I'm working on a project for BayNVC and this will be perfect, so...
+1 for recurring events.
you can see more possible permutations here: http://forum.civicrm.org/index.php/topic,4648.0.html
thanks!
m
Sep 09, 2008
Paul Hardwick says:
A request for the upcoming redo of price sets in CiviEvents. If we have a single...A request for the upcoming redo of price sets in CiviEvents. If we have a single Event there is a maximum allowed number of tickets that can be sold. But when you use price sets you can't really take advantage of this feature fully. As an event limit it can only be used to limit the total number of people allowed to purch tik, but can not differentiate between the diff types of tickets. For example for an upcoming event we have three diff admission types with diff prices and diff max tik sales. Now the price sets can handle the diff prices, but can not restrict the number of each type. What I would like to be able to do is the following
Standing room - $20.00 / 200 people
Seating - $50 / 40 people
VIP (Front row seating) - $100 / 20 people
Now I believe that I can do an event tik sale limit of 260 people, but I can't break that down to the different tik types. Something like that currently has to be tracked manually, and when I hit the 20 VIP seats, disable that type of tik. Otherwise I could have 50 VIP tiks sell and i run out of places to put them. Now while the extra money is nice, my attendees will be rather unhappy. And unhappy attendees don't make good donors.
Thanks
Paul aka MacRonin
Sep 09, 2008
Paul Hardwick says:
I was just reminded of another request for CiviEvent. I guess it actually would ...I was just reminded of another request for CiviEvent. I guess it actually would go in two places. The basic event processing and the price Sets processing. Although if the resources to handle it could only do one area I'd vote for Price Sets since that could probably cover regular sales also.
The request is the ability to limit the number of an item that could be purchased by an individual in a single transaction. While making the limit cover all purchases for an event by an individual, I assume that taking it beyond the scope of a single transaction would be much more involved. And a single transaction is a limit that I can easily live with. The following example would be great
Standing room - $20.00 / 200 people / purchase max. per transaction of 4
Seating - $50 / 40 people / purchase max. per transaction of 4
VIP (Front row seating) - $100 / 20 people / purchase max. per transaction of 4
making a limit that went across all items in the set would be great, but I'm not greedy.
(OK maybe a little greedy) But just in case, here is an idea.
At the base level of CiviEvent create a maximum item count. This could then handle basic transactions. Price sets could then be extended as above with the additional option(check-box) of saying "Count against basic total transaction limit" Given a transaction limit of 4 tiks. This would then allow 2 SRO tiks + 2 Seating Tiks but say limit # reached if the person tried to add another ticket type or increase either the SRO or Seating counts to a larger number going over the transaction limit of four.
We would need the check box to say count against the transaction(or reverse it and say this item exempt) so that entries like "handicap access required" or "Vegetarian meal requested" do not count against the transaction count limit.
Sep 09, 2008
xavier dutoit says:
Awsome. On civimail, it's been discussed to be able to change the format ...Awsome.
On civimail, it's been discussed to be able to change the format of the email enveloppe to something like news+uniqueID (the + separator allowing a single mailbox to get all the bounce)
X+
Sep 18, 2008
Shawn Duncan says:
It doesn't seem like it would be too much additional code to enhance the CiviMem...It doesn't seem like it would be too much additional code to enhance the CiviMember proposal from "Batch create" to "Batch create or renew" from search... That would probably save some of us a lot of work!
Sep 19, 2008
dave hansen-lange says:
The spec is looking pretty good. Things are progressing along nicely. I thin...The spec is looking pretty good. Things are progressing along nicely.
I think CiviCRM can make a lot of improvement in the area of front-end performance. A CiviCRM page generally gets a YSlow score about 20 points lower than a similar Drupal page on the same site (YSlow gives scores betwen 0 and 100).
For those of you unfamiliar with YSlow you can find it here: http://developer.yahoo.com/yslow/
I think a full audit of the front-end would really offer a lot of suggestions for improvements. But here's a few things that I can think up off of the top of my head:
I think there's possibly many more little things that could together offer a big decrease in page-load times.
Oct 24, 2008
Brian Shaughnessy says:
In CiviMember, one thing I'd like to see enhanced -- For those with org...In CiviMember, one thing I'd like to see enhanced --
For those with organization-based members (membership is attached to the organization, not the individual), CiviMember does a nice job of allowing membership inheritance through relationships (from the org to the indiv). However, it's not easy to do a search for just the "primary" member -- the organization itself, because an actual membership record is created for all of the inherited indivs.
Inheritance is handled through the owner_membership_id field in civicrm_membership, so a search for NULL on that field yields everyone who doesn't have a "parent" and thus is the "primary". I think we just need a field in CiviMember search that allows the user to query by primary member only.