25 June, 2007
Filed under v1.8, CiviCRM
UPDATED: July 24th (slipped beta by a few days and final by a week) Here is a tentative release schedule for v1.8. As in any software project, these dates are tentative and subject to delays. However, based on past history they should be pretty close. Check out the 1.8 Release Roadmap for a summary of features and improvements. We'll be looking for lots of volunteers to start pounding on the Alpha Sandbox next week - announcement to follow shortly.
DateActivityNotes
June 18thCode and Schema FreezeAll major features coded, branch for v1.8
June 18thRegression TestingEngineering team tests all 1.6 and 1.7 resolved issues. Run unit and selenium tests
July 2ndIssue TestingEngineering team...
Read more
12 June, 2007
By idealso
Filed under v1.8, CiviCRM

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.

With price sets, you can have any number of fields, each with any number of options. Each field is either a text input (for if you want a certain quantity of something), a select box, radio buttons, or checkboxes. Each option, of course, also has an associated price. When a form with a price set is submitted, a summary of prices is displayed on the confirmation screen, and also on the thank you screen and email...

Read more
10 June, 2007
By lobo
Filed under v1.8, Architecture, CiviCRM

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. A look at the Fisheye revision history gives you a better idea of how extensive those changes were. We are still wrapping this up and need to do a bit more extensive QA before resolving the issue.

I'm glad we took this on and cleaned up the code. We made things more configurable and...

Read more
06 June, 2007
Filed under v1.8, CiviCRM

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.

We've continued to get a few bug reports each week on 1.7 - but these have generally been edge cases or part of advanced developer features like hooks - so most are being addressed as part of 1.8 development. This reflects our general approach of NOT porting bug fixes to the current stable release UNLESS they are critical and affect commonly used parts of the application. The primary reason for this is that bug "fixes" can potentially introduce new bugs - so it is preferable to make fixes in code which is pre-production and which will be subjected to a full internal QA cycle along with our usual Alpha and Beta...

Read more
31 May, 2007
By shot
Filed under v1.8, CiviCRM

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.

The merge screen introduced in CiviCRM 1.8 consists of two columns with selected data from the two contacts to be merged: the main contact and the duplicate one. For every pair of data the ability to overwrite the main contact’s value with the duplicate contact’s value is provided.

Choosing which data to display (and in what manner) was not obvious. For CiviCRM 1.8 we ended up displaying a merge option for each of the general data fields (like names, prefixes, privacy options,...

Read more
28 May, 2007
By lobo
Filed under v1.8, CiviCRM

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.

For v1.8 we have implemented site level preferences only. User level preferences will be implemented in a later version, but the database schema and code has been designed to make user level preferences a fairly easy addition. The screens which can be customized include: Contact View, Contact Create / Edit, Advanced Search, User Dashboard and the Address fields. It was a pleasant surprise to see that most of the work...

Read more
25 May, 2007
By lobo
Filed under v1.8, CiviCRM

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.

As a reminder, v1.8 does not have many new features, but a few important ones (de-dupe, civireport) and a host of improvements. We'd like this last version 1 release to be stable and long lived (supported till end of year). Both CiviReport and de-dupe are making excellent progress and we'll have blog entries on their status and capabilities in the near future. This will be the last release that supports PHP 4.x and MySQL 4.x

Having...

Read more
08 May, 2007
Filed under v1.8, CiviCRM

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).

We are working on a compressed timeline for 1.8 - targeting beta in June - so we've had to take a hard look at what we can and can't accomplish. We've postponed several of the larger and more complex items to 2.0 - where we will be able to take advantage of PHP 5 features. That said, there are quite a few cool features in progress. Check out the latest 1.8 Roadmap here.

If any of your "mission critical" issues have been bumped to the "postponed" section of the roadmap - please consider whether your organization is in a position to contribute engineering or financial resources to help make them happen sooner. We're super excited about the...

Read more
29 March, 2007
Filed under v1.8
With version 1.7 "almost" out the door, the CiviCRM planning team spent most of this week's team meeting evaluating potential "big ticket" items for 1.8 and discussing future platform requirements for CiviCRM. The platform issues are:
  • When do we drop support for PHP 4.x?
  • When do we drop support for MySQL 4.1
There are compelling technical and management arguments for requiring PHP 5.x and MySQL 5. On the management side, we estimate that it costs the project approximately 4-6 person-weeks of extra time to code, test and debug the PHP 4 version. As the codebase grows - this cost of supporting two very different programming models grows. These are resources that we'd prefer to use improving the overall functionality, usability and quality of the software. On the technical side, PHP 5 has performance and security improvements , along with more advanced programming features which we'd like to take advantage of. At the recent OSCMS conference, Rasmus... Read more
22 March, 2007
By lobo
Filed under v1.8, CiviCRM
We've integrated support for Google Checkout in CiviCRM v1.7. This was primarily on the initiative and lead of Deepak, part of our awesome India developement team. This also allowed us to compare the ease of use and integration between the two transaction providers. Here are some things we found:
  • 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
  • PayPal is a lot more consistent and symmetrical with the urls and images between the sandbox and development environment. Google Checkout is not symmetrical
  • PayPal gives u a much better unified testing environment. You have multiple test accounts under one large sandbox account. With Google you have to create multiple google...
Read more