We just completed a CiviCRM Code Sprint in NY. A big tip of the hat to Rayogram for providing the space and coordinating the logistics, especially to Kyle Jester. Thanx to Chang and Matt from emotive LLC for providing breakfast and lunch during the sprint.
We had 14 folks on Saturday and 12 folks on Sunday. It was an incredibly productive sprint with lots of great presentations and a fair amount of code and improvements towards 3.3. The main goal was to improve some features in CiviCRM and incorporate some of the work done by the community. Here is a recap of some of the things we accomplished during this sprint:
- Lanette M started work on a document for someone who is trying to migrate data from disparate sources into CiviCRM. She hopes to produce a set of checklists and a list of things for people to think when planning such a migration. She hopes to re-use and bring together some of...
As hinted in the blog post on upcoming features, CiviCRM 3.3 will ship with the first cut of database-level logging.
This feature was first discussed alongside contact undelete (introduced in CiviCRM 3.2) and specified further on the wiki, and after running some tests the current idea of the implementation follows quite closely what was discussed and – especially – speced there (so do check the wiki for details).
The general idea is that every CiviCRM table that we’ll want to log will acquire a counterpart log table (e.g., civicrm_contact_log will be introduced to track civicrm_contact changes) that will be append-only (and so use the ARCHIVE engine). The log...Read more
This blog post is outdated. For latest information about how to create extension, please refer to Extensions Wiki Page.
It had to happen sooner or later - CiviCRM is growing with with variety of functionality, where people can plug in their own, custom pieces and make CiviCRM more tailored to their needs. Most prominent examples at the moment include payment processors, custom searches and custom reports. Don't confuse it with "larger scale" customisation, like writing Drupal modules which - using API and hooks - modify CiviCRM behaviour. We're talking about well defined, self-contained pieces of code which throw in some useful functionality into your existing installation. As of now, it's a bit of a hassle to install them - you need to put files in proper places, register them using administrator section and so on: nothing...Read more
- Adding a "private" indicator to allow notes to be visible only to the note author (or otherwise limited based on logic within a hook).
- Allowing comments to be attached to a note.
- Extending Address inheritance from Organization to an Individual (or from any contact to any other contact - TBD).
- Building Advanced Reports...