I have been working on dedupe optimization, part of 3.3 release and a make it happen project, and we are quite happy with the results. A fuzzy rule (first+last+email) which would take 4.3 mins on a 65K contact database, now takes 1.02 sec (tested on a iCore5, 4Gig machine). On a 1.45 million database same rule which used to take forever (i had to quit after 1 hr), now takes 13 sec. Below are some more stats.

A school needed an online admission application process to be developed and integrated with CiviSchool. The application form is a different workflow from the online family forms. Web Access helped convert this idea to working application as part of the CiviSchool Project. I have been working with Web Access on this project and we have completed most of it. Now seemed to be a good time to let everyone know about what we have done so far. Here is how the admission workflow is -

• Parent account setup :
  A parent goes to the school site and uses a civicrm registration profile to create an account and enters the site. The account automatically gets assigned a "Applicant Parent" subtype.
• Filling admission application forms :
  From the dashboard parent fills admission application forms for an applicant (child). Parent can apply for 1 or more applicants. All applicants are assigned a "Applicant" subtype.
• Submitting a payment :
  Depending on whether financial aid is taken or not, parent submits a payment for an applicant. The payment is done via contribution page with contribution type - "Application Fee". Since parent is the one making the payment, to keep track of which applicant the payment is being done for, an extra argument is passed to the payment/contribution url. We using a hook to make all the checks and link the payment to the applicant.
• Scheduling appointments :
  Once the application is complete and payment is made (if needed), parent can schedule a child visit or a parent interview. A school tour could be booked at any stage of the process.

Following some issues to integrate drush and making civicrm upgrade process accessible from script, I started looking at drush on how we can take advantage of it for civicrm, and was surprised with the ease I was able to reuse drush code to add few utilities for civicrm. Some of the utilities currently implemented are:

The team is excited to announce the release of CiviCRM 3.1 Stable. You can download the release AND / OR try it out on our demo sites.

The version number for the initial stable release is 3.1.1. There was an invalid 3.1.0 distribution on Sourceforge for a few hours. If you downloaded that version, please discard and re-download 3.1.1.

v3.1 includes several COOL new features:

CiviCRM 3.0.beta5 is out and available for download. You can also try it out on our sandbox site. Please remember it’s a beta release and it shouldn’t be used on production sites. The next release is 3.0 stable, so get set ready, and if you haven’t yet checked whether your favorite (old and new) CiviCRM features work the way you expect, it’s a very good time to do it.

We’re happy to announce that CiviCRM 3.0.beta4 is now available for download. You can also try it out on our sandbox site. Please remember it’s a beta release and it shouldn’t be used on production sites. The next release could be 3.0 stable, so if you haven’t checked whether your favourite (old and new) CiviCRM features work the way you expect, it’s a very good time to do it.

The team has released version 2.2.9 today with around 13 bug fixes and improvements. Critical fixes include:

• Migration to a new host
• Standalone deadlocks with secure URLs
• Free event confirmation email

You can review a complete list of 2.2.9 changes on the issue tracker.

Download

A Make It Happen to move this into core for CiviCRM is currently running for v4.1. You can help make it happen by contributing here

Discounting events has been requested on the forums a few times. It also popped up both on IRC yesterday and was also needed on civicrm.org for our upcoming UK Training Camp. We decided to see if we could implement this via hooks and minimal / no changes to the core code. Turned out we can implement this this feature using three civicrm hooks and a helper fuction. We improved the core a wee bit by allowing the buildForm hook to inform the tpl system of any form elements added. The tpl then places these form elements at the top of the form. An event can have zero or more coupons. Coupons for an event are stored in the option group / value table. Each coupon code is a string (chosen by admin) and can be used a certain number of times. Coupons can also be used forever. A valid coupon gives the user a percentage discount on the event. Giving the coupon a 100% value basically gives the user a free registration. Coupons can be sent in via the URL or can be entered into the registration form.

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.

CiviCRM India team had an opportunity to attend the OWASP-conference, New Delhi. It was a two day conference but we - Kurund, Sunil & I decided to attend the second day training/workshops just to stay away from theoretical lectures. We landed in Delhi on day-1 evening to avoid any last minute rush. And we realized the temperature in Mumbai was much better and Delhi being a bit hot. We had a booking in Ginger Hotel - value for money i must say :).