Blogs

The new de-dupe functionality, introduced in CiviCRM 1.8, is configurable under Administer CiviCRM → Duplicate Contact Rules. This post describes the meaning of the fields and the way their contents impact the de-dupe search engine.

The first decision to make after going to Administer CiviCRM → Duplicate Contact Rules is which rule to edit. For CiviCRM 1.8 we decided to allow one rule per every contact type (individual, organization and household); in future versions this can be extended to arbitrary list of rules.

Code for Change, a group internship program for computer science students, is working on adding several features to CiviCRM this summer. U.S. PIRG launched Code for Change this summer for several reasons:

Earlier today we saw our 10,000 th commit :) For the curious, michal mach was responsible for this commit and the changeset is here (yes, i agree quite a disappointing 10,000th commit). For the curious, the changeset for the very first commit is here. This comes out to an average of approx 10.5 commits for every day (or approx 15 commits if u ignore weekends and holidays).

In 1.7, event management was added to CiviCRM. The timing on this was good for us (Ideal Solution, LLC), and allowed us to use CiviCRM for a customer who primarily wanted to allow members to sign up for events, such as conferences. The difficulty was that conferences typically have multiple options, each with its own additional price: basic registration, meals, guests, etc. Each additional option increases the total number of possible combinations. Price Sets were added to manage this.

Our friends at US PIRG have just started work on the Code for Change program. You can follow their progress on the Code for Change blog. We will be working closely with Wes, Dan, Matt and Ann and hope to get many new improvements and extensions to CiviCRM via this program.

Based on some conversations on IRC with Marshall from Ideal Solutions LLC, I embarked on extending CiviCRM to allow different payment processors for different contribution/member/event pages. Our current restriction of just one payment processor for the entire system did not feel right and we had a few requests to extend this functionality. I took this opportunity to review parts of the code base that I was not familiar with and make a few improvements to CiviCRM in the process.

The entire team has been focused on getting the 1.8 open issues queue down to (almost) zero items by next week - which is our target for code freeze. As of this morning, we're down to 18 open issues - of which several larger items are just about ready for our QA cycle.

One of the main features of CiviCRM 1.8 is the ability to find duplicate contacts and merge them. The relevant spec of phase one is on our wiki, and in this post I’d like to quickly describe the merge screen.

One of the requested features in the recent past has been the ability to hide certain sections of various forms at the site level and the ability to modify this at a user level. I committed code that does this at the site level earlier this week. The issue is described as Site and User Level UI Configuration options (phase 1) in our issue tracker.