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.
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. I suspected this would be a fairly quick project. It boggles my mind as to how wrong I was on this count.
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. As with most of CiviCRM features, we decided to introduce merging functionality incrementally, so we can get the basic merge screen as soon as possible and then add more features based on the feedback we get.
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. A related issue is Add a config option to set which fields should appear in the address form.
Here in CiviCRM land we are hard at work making progress with v1.8. We are knocking off a fair number of issues from the issue queue on a weekly basis. You can check the current open issue list here and the v1.8 feature set here. At this point we have posted all the outstanding issues to the issue tracker. We will release a schedule for v1.8 in the next week or so.
Those of you who've been using CiviCRM for a while and/or following the progress of the project already know that there's never a dull moment around here. It's only a few days after the release of 1.7 stable - and we're well into work on the NEXT release (1.8).
- When do we drop support for PHP 4.x?
- When do we drop support for MySQL 4.1
- PayPal has a much richer and more well thought out SDK. They do quite a few things right from a developers perspective, primarily allowing the code to set various defaults (like the return url)
- Have the Google Checkout folks tried to use the sandbox with the awful "sandbox" background that they use. Makes it fairly hard to read and navigate the site