28 October, 2007
By lobo
Filed under v2.0, CiviCRM
We have had a few requests from folks to extend the search code with their own SQL queries while taking advantage of the tasks available with search (print, mailing labels, export, smart groups, adding to group etc). This has been on our list of things to do, but we had not made any progress. Some example where this would be useful are:
  • Give me the set of all household's who have a household member residing in district X. More details here. The search form can be set to just include a text box for the household name and a multi-select element for the district to restrict the search criteria
  • Give me the set of contact(s) who have donated more than an input amount in this date range.
  • Various combinations of AND/OR/NOT which civicrm search does not handle.
The original goal was to splice in pieces of user sql with the query generated automatically from form values. I prototyped... Read more
28 August, 2007
By lobo
Filed under v2.0, CiviCRM

We've had captcha support for some time in CiviCRM. This is not a very popular feature since getting it to work properly is not trivial (you need the right PHP libraries and the path to the a ttf font on your server)

This post by Gordon Heydon, pushed me to investigate ReCAPTCHA, which has a cool tagline: Stop Spam, Read Books. I've seen a few sites in the recent past that have been powered by ReCAPTCHA.

This seems something cool, gives us integration with yet another web service (oh what a tangled web we weave, hopefully the internet will not crash anytime soon) and avoids the whole image / font issue which we have had in the past. We also get rid of some code from the package (always a good thing!)

I'll probably hack this in when i have some free time over the next few weeks for 2.0.

In the meantime, i'm having a fair bit of fun with the new custom group / custom...

Read more
19 August, 2007
By lobo
Filed under v2.0, CiviCRM

The last few weeks of a release is always quite frustrating. The team is itching to get started with new development and get on with the next version. However, users are testing the beta release and filing new issues and bugs, few tweaks need to be done etc. So overall, things are in a neither here nor there status. However, once we mark a release as stable, we move most of the development team onto the new release and things get more exciting.

CiviCRM v2.0 is a big release for us internally. The current feature list for v2.0 is here. I think it will have very few bells and whistles, but will have a much improved schema and a more extensible core. Drupal has shown us the benefits of building an extensible system. I think we still have a few more revisions to go before we get there, but we are headed in the right direction. Here are some of the things that are exciting about v2.0 (IMO)

  • ...
Read more
10 August, 2007
Filed under v2.0, CiviCRM
Activities and Activity History records are a critical part of the CRM equation. They allow organizations to get a detailed snapshot of the interactions with their constituents. As part of our 2.0 data model overhaul, we are planning major changes to the Activities data model. These changes are designed to:
  • Simplify the data model for activities by merging activity-related tables into a consolidated Activity table. Meeting, Phonecall, Activity History, Email History and SMS History will all be merged and dropped.
  • Replace the use of entity_table/entity_id model with explicit foreign keys to the Contact table to improve performance on queries.
  • Allow activity "creators" to assign the activity to someone else, and integrate changes made for Frontline to support multiple "assignees" for a single activity.
  • Migrate useful features from the Task object into Activity - specifically the ability to set a Priority and a Due Date for an Activity.
... Read more
01 August, 2007
By lobo
Filed under v2.0, Architecture, CiviCRM

Wes Morgan and the team at Code for change have decided to tackle something that is fairly important to quite a few medium - large sized organizations. Having support for this in CiviCRM would be really cool and we need your comments and feedback fairly quickly. Wes and team move at a very rapid pace, so please head over to the wiki page and give them and us feedback on the model and implementation. Here is the email Dave Greenberg sent to the dev list a few minutes ago:

As noted in Daniel Frishberg's post earlier today, USPIRG is kicking off a project aimed to adding features to support multi-chapter organizations. This functionality should also be applicable to hierarchical advocacy / political campaigns (national -> state -> local ... segmentation).

I'd like to strongly encourage anyone who is interested in making CiviCRM a more useful tool for multi-chapter / distributed organizations to add your questions, requirements, and any other feedback to the...

Read more
26 July, 2007
Filed under v2.0, v1.6, CiviCRM
This is Part 3 of my series on Writing Components For CiviCRM. Part 1 discussed what a component is, and what it does. Part 2 explained how to use CiviCRM's XML-based data definition language to define your tables. But while your tables may now be in place, CiviCRM doesn't know what to do with your data. We'll need to do a bit of editing on CiviCRM Core in order to hook up your data in CiviCRM, and I'll briefly describe some of the places we will need to "hack" core so that your data will appear in the UI. So what do I mean by "hooking up data"? CiviCRM needs to know when to load your code so that users of your components can do things like:
  1. View your data via the contact view page.
  2. Edit your data in contact edit pages.
  3. Search for contacts using your data as keys.
  4. Access your data via Drupal modules or similar external code.
  5. Import and export data that...
Read more
14 July, 2007
Filed under v2.0
One of our primary objects for the 2.0 release is to find ways to simplify the way data is stored and retrieved in order to make querying data from the DB easier and more scalable/efficient. We're questioning a number of different pieces of the current data model - and one big area is storage of address, email and phone data. Part of this process also involves identifying areas where the data model is "out of touch with reality" (i.e. it imposes unrealistic or artificial constraints on the data). Our current approach for handling address, email and phone info is to "group" these fields into Locations - each of which is assigned a location type (Home, Work, etc.) . Locations can belong to contacts (people, organizations, households) - but they can also belong to Events and to the organization which owns a CiviCRM installation (the "Domain"). Each contact can have one-or-many locations - and each location has an address and one-or-many phones and emails. This approach... Read more