Integrating CiviCRM with an email client (specifically Outlook) has been a long requested feature. Unfortunately we dont really have any internal windows expertise to make this happen (for now). For now, we've built some code for the HRD project that attaches incoming email as an activity to the contact record of emails that are in the from / to / cc / bcc fields (we create a contact record if not found)

From a forum post by Chris Burgess (with Green Party NZ). A related blog post is: Another approach to ACL and permissioning for hierarchical organizations

Our (Drupal5+CiviCRM2.0) site needed a regional ACL implementation in order to give us the ability to easily grant access for our internal staff to contacts in their geographic region. Because we have staff at a provincial, regional and branch level, we needed to be able to configure permissions for each level.

We did this by implementing code which overrides the ACL implementation in CiviCRM. I'd appreciate any input and suggestions on our methodology - it's a work in progress, but it's working well for us so far.

CiviEvent is one of the more popular components in CiviCRM (followed by CiviContribute, CiviMember and CiviMail). We have improved CiviEvent significantly in the past few releases and more improvements are slated for CiviEvent in v2.1. With this increased usage, we've seen more folks using Price Sets. Briefly, price sets gives admins the option to break an event into smaller pieces and charge for each selected piece. Price Sets was one of the first significant of code contributions to CiviCRM (thanx to Ideal Solutions and Marshal Newrock). We were planning to restructure this code in 2.2, but there were two missing features which came up a few times with some of our 'regular' users.

The first missing feature was that two options in a price set item could not have the same amount. In order to include meals on multiple days with the same price, you would have to separate them into different items. Price Sets did not allow an amount of 0 either in an option. Fixing this was relatively easy, we just shuffled around a few fields that we used in the civicrm_option_value table to fix the above problems.

So while doing the custom data hook, CRM-1594, I also implemented a hook for setting the default values of a 'Form' in CiviCRM, CRM-3176. So now we have a defaults and validate hook for the form object. The two missing hooks are for buildQuickForm and postProcess, which I'm planning to implement in the next couple of days. This coupled with template customization will allow developers to inject form elements and save them to the database (similar to drupal hook_form_alter). I'm also planning to implement the ACL improvements as an ACL related hook (along with a sample implementation). These new features should give CiviCRM developers more power and flexibility in tailoring CiviCRM to their specific needs without hacking core.

With the new custom data model in 2.0, it seemed a good time to allow developers to add columns to a custom group that are computed rather than entered. Some examples of this is computing the GPA of a student given the student's individual grades, computing the age of a contact given his/her birthday. This has been an outstanding issue, CRM-1594, for quite some time.

Earlier this month Evan posted a query about a CiviCRM AMI for Amazon EC2. Joe Murray responded with some proof of concept scripts along with the persistent storage space limitations in EC2. Seems like the folks at EC2 have been busy addressing these limitations and have introduced persistent storage support for EC2 (its currently in beta).

So i've been looking a bit closely at performance for 2.1 (both database and usability) and am attempting to boost it up significantly compared to 2.0 (and prior). Here are some of the highlights

• We've introduced a new database cache table (civicrm_cache) to cache a few database queries that are repeated a lot. Some of the specific queries include listing all the fields available for the contact types (individual/org/household). This is a combination of the built-in fields (name, address etc) and the custom fields added by the user. This reduces the number of queries invoked from 5 complex queries to 1 simple cache query (and an un-serialize)
• We've added a column (group_type) to the profile table (civicrm_uf_group), so we know the profile type rather than recompute it every time we need it.
• Thanx to Dave Lange who reported and did some analysis on this, we've reduced the number of LOWER( dbColumnName) LIKE 'value' to skip the LOWER part. Email is now stored as lower case, so we can skip the LOWER part in all email comparison. In his tests, these have improved performance a fair bit
• Smart Groups
• Hierarchical Select
• Menu System
• DeDupe
• We will integrate the ACL changes into core either as a pluggable ACL architecture and/or via the hook system.

Overall 2.1 is shaping up to be a significant improvement over 2.0 :). You can get more details on the 2.1 feature set and release schedule on the CiviCRM v2.1 wiki page.

One of the core features of CiviCRM is the ability to store a query as a group (smart group). This allows folks to create groups of contacts that share the same attribute(s). For e.g. A group of all the people in California. Thus contacts can be added/edited/deleted from the database, and the smart group will always give you all the contacts who live in CA at that point in time. I suspect this feature is heavily used by quite a few installs. Hierarchical organizations / political parties can separate their contacts based on electorate / voting segment / branch etc by using smart groups.

Today we spent a fair amount of time with Pete and Chris from the NZ greens. We got a pretty good overview of how the NZ Greens are using the system and some of their pain points. We saw some of the cool integration that Chris has done with the NZ voter database and linking the electorate ID to a CiviCRM contact ID, ability to merge the address from the voter database etc. Its kinda cool how folks can extend and integrate the systems with other db's and we need to make it significantly easier to enable folks to build such system within CiviCRM.

The past few days we've been focussed on improving the user experience of CiviCRM. This also included optimizing page size and number of database queries invoked per page load. One of the things that has bothered me for some time was the inefficient implementation of the quickform hierarchical select widget for our case. That form element is quite awesome and is used quite extensively within CiviCRM. However for our "mapping" case it generates a lot of javascript, which increases page size and duplicates a lot of data.
We can optimize this significantly based on our use cases.