We received quite a lot of interest and feedback on our initial release. We're happy to announce that most of the requests have been resolved and the extension is ready for production use.
Some of the quality improvements / fixes that been made are:
If you’ve ever wanted to setup a repeating event in CiviCRM, for example weekly church groups, then you’ll know thats its not the most straightforward task in CiviCRM at the moment, requiring large amounts of manual labour to get the desired end result. Up steps the Zing funded MIH with a large dose of user input from Lindsey @ Woodlandschurch and others who fed back on the wiki.
After my previous blog post, i have been working on making progress on working model w.r.t NoSQL and config. Starting with civicrm cache was a good idea. Keeping in mind NoSQL, new config system and what Eileen has already done with settings, here is what i planned and accomplished :
Placed cache and cache-type (mongodb) settings file on disk with default values
As part of my course i have been doing research on what would it require plug an external storage engine into CiviCRM, and how other open source systems doing it. Answer lies in a better config system which allows doing it in a scalable pluggable manner. As i make progress i'll be showing more reasons to get excited and curious about building a better config system. Drupal 8 has spent a fair bit of time on configuration management to make things easier. And we shouldn't shy learning from them and others.
CiviCRM team is pleased to announce the next stable release of version 4.1 - with support for Drupal 7, Drupal 6, Joomla 1.7/2.5, and Wordpress 3.3. You can download the release now from Sourceforge.
We strongly recommend that you upgrade a test copy of your site and review your critical workflows before upgrading your production site. There have been significant (~107) bug fixes since the first stable release of 4.1. You can also test-drive the release on each platform using the public demos:
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.
- 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:
v3.1 includes several COOL new features: