CiviMail is getting another major upgrade in 2.2. Some of the features coming in 2.2 include:

• PHP return channel solution. This feature should enable more folks to install and run CiviMail. This will obsolete our amavisd return channel solution. No perl or sys admin / root access expertise needed any more :)
• Adding CiviMail as an "action" to search results. This feature will allow folks to send a mailing to a "dynamic smart group" and alleviate the need to create multiple groups just for civimail purposes. Thus if you want to send a targeted mailing to all the folks in the 94135 zip code in your "we want more green trees" group, you enter the relevant search parameters (check the group and type the zip code), do the search and invoke the "Send Bulk Email" action. You can read more about this issue here
• Adding token hooks and ability to send "templatized" emails. This is described in more detail below

Our global meeting resulted in some new features being added to 2.2. Our team worked on a new jQuery based country/state selector and incorporating hook(s) to the "amount" functionality of online contribution and event registration pages. I'll give a brief description of the feature set and functionality of these projects

New jQuery based State Country widget

Our previous widget was a dojo based combo box widget. Both the country and the state were ajax based combo boxes. The state combo box was dependent on the value chosen in the country combo box. This implementation was quite complex and not easily replicated (hence u did not see the widget in many places). For 2.2 we took a slightly different approach: The country field is a simple html select box (the values are restricted by the countries configured in the admin area). The state selector is now dynamic and refreshed with new values whenever the country is changed. We took inspiration and borrowed a fair part of the code from: Simple chained combobox plugin for jQuery.

One of the mini-projects that we worked on during our San Francisco meetup / code sprint was improving the way name and address data is handled during payment transactions (e.g. online contributions, membership signup and event registration). Our goals were:

• Prevent name, email address and postal address information collected during a payment transaction from over-writing existing "non-billing-related" data.
• Store the billing name and address info for EACH transaction - so that it can be retrieved for audit / reconciliation purposes.
• Set a foundation for a more "shopping-cart" style interface where logged in users can select from a set of previously used billing locations.

CiviCase is a new component for CiviCRM targeted at organizations who provide case management services. It is being developed In partnership with the Physician Health Program of British Columbia (PHP-BC). In addition to providing funding for this project, PHP-BC is providing invaluable domain expertise and the current plan is for their staff to start using CiviCase in January 2009. You can learn more about how this project got started and the project goals from these blog posts and the requirements overview.

CiviCase Phase 1 is a major part of the upcoming 2.2 release - and several members of the core team are gathered in San Francisco this month working on bringing it to life. Last week we had a two day "in-person" meetup with PHP-BC folks (Andrew Clarke, Claire Sauve, and Dave Dantowitz) where we reviewed work in progress and got detailed feedback on the basic workflows and screens, as well as the data model and configurability of the component. That meeting resulted in some key refinements and additions to the phase 1 specification - and provided a good reality-check for the project!

The CiviCRM core team is currently meeting in San Francisco. We tend to meet 2-3 times a year. These meetings help us crank out a few large projects as a group and also help improve our communication when we return to our respective home bases. The focus of the San Francisco meetup has been on CiviCase, US PIRG projects and a few features from the 2.2 roadmap.

Our group (kurund, yashodha and me) have been working on extending custom groups with two new features. In 2.2 a custom group can be designated to hold multiple values. This allows a contact (or relationship/group/activity) to have a 1 to n relationship with a custom group. One use cases for this is storing educational history of a contact. A custom group with fields: Name of School, Qualification earned and Graduation Date could be designated as multi-valued. A contact could have 0 or more educational records. Viewing this custom group will show all the educational information associated with the contact. On edit, you can modify the existing information and/or choose to add new information. Implementing this at a group level has fairly minimal schema changes and is a good chunk for us to tackle and get working for 2.2.

I’m happy to report a PHP counterpart to imap2soap is coming in CiviCRM 2.2, so the handling of CiviMail’s return channel should be much easier in the future (ideally as simple as setting up a cronjob).

There are also other CiviMail improvements and changes in 2.2 (kudos to U.S. PIRG for their sponsorship!) which I plan to unveil in upcoming post(s), but let’s concentrate on the return channel for now.

Lately there has been lot of confusion using Name, Title/Label and Value. There is also a lot of inconsistency in code and database, hence we are planning to fix it in CiviCRM v2.x release.

Lets take an example of Participant Status, 'Registered'. In this case Name will be 'Registered', value will be an integer from 1..N (this depends on each install) and Label/title can be "Registered" or "I will come" etc. (or a localized version of the word/phrase).

Basic rules are:

CiviCamp day1 started with good number of participants with a total count of 14. We started with introduction and complaints about civicrm. Most of the complaints were about APIs, upgrades and support of previous versions. Discussions on APIs are scheduled for day2. Regarding upgrades it looked that older version (1.9 or below) generally have problems with upgrades since it requires some technical expertise. Walt was working towards developing a tool which could tell in advance if there are potential problems with the db which could make the upgrade fail.

So the good folks at USPIRG our continuing their support of CiviCRM and are sponsoring quite a few cool features for CiviCRM v2.2. In case you were not aware, they also sponsored quite a few cool features for 2.1.

I had a long conversation with our USPIRG contact, Wes Morgan, on the feature list for 2.2. The wiki page has all the details (we'll add more details and issues over a period of time), but here are a few highlights that i think the community would love and appreciate :)

• Integrating imap2soap.pl into the main code base. This software was community contributed and the core team did not have the skills/expertise/energy to support it. The past few releases we've done a bit of email integration work, and in v2.2 we'll convert imap2soap.pl to php and make it part of the core code base and officially support that version.
• Dynamic groups for mailings. Lets assume you have have a California group. With this feature, you will be able to send a mailing to all the contacts in the 94122 zipcode in the california group. This will avoid creating lots of smaller groups for the sole purpose of sending 1 or more mailings. We'll probably start this off via custom search and then implement the same interface for the built in search
• A few other improvements to CiviMail including a new hook for mailing tokens, more fine grained permissions for mailings, and a categorization scheme for groups and mailings (i.e. ability to maintain them in a folder like structure)
• The beginnings of a new import facility for CiviCRM. Import has been long overdue in need of an overhaul. We'll start off by building a flexible data input mechanism (sql or csv). Also the ability to group and tag each contact indivdually. We'll see if we can squeeze some significant performance gains while we are at it :)
• More improvements to the standalone version.

Overall i'm quite excited with these improvements to CiviCRM. A hat-tip to Wes Morgan for facilitating this and being such a great supporter :)

The CiviCRM team branched off v2.1 late last week. We hope to knock off most of the remaining v2.1 issues over the next few days and release the the first beta candidate. Please do help us out by downloading and testing the release OR testing it on our sandbox site. Your help does help make it a more solid and stable release.

This also means that the core team can start working on CiviCRM v2.2. After a 6 week code freeze / QA / alpha cycle, the developer team is typically ready to go and start working on new things. The list of currently open issues for 2.2 can be found on our issue tracker. Please do add your suggestions and requests to the Feature Requests and Suggestions board. As with any open source projects, requests and suggestions with attached patches/sponsorships are more likely to make it into the release.