26 September, 2012

Extensions are a growing part of the CiviCRM way of doing things. We need to develop a process and toolset to facilitate getting them translated and making those translations easily installable. This post is intended to lay out some issues and a potential approach in order to generate discussion.

Here are some assumptions and suggestions I have:

  • Extension developers should be responsible for coding their extensions with ts(), and can be expected to do things like extract strings from their extension and upload somewhere for translation.
  • Transifex is the tool used for translating CiviCRM strings. It has a team for each language translation, who do the translations. This approach is working fairly well. Having extension strings presented for translation in the same space, and displaying percent translated for them, etc. would be ideal.
  • Translations are done in spurts and at somewhat unpredictable times, depending on the interest and...
Read more
22 July, 2012
By totten

Brian Shaughnessy (lcdweb), who has been working with the New York State Senate's CiviCRM project, recently raised the issue of simultaneous editing: What happens when two users simultaneously make changes to same contact record?  We've held a few discussions on IRC to examine the issue and draft some solutions.  We would appreciate further feedback and ideas on how to address the issue.

The Problem

As described by Brian:

The issue is that if you and I get into the same record around the same time, and you save the record first, when I save, it will overwrite your changes.  So let’s say you add a middle name, and I get in and add a birthdate.  The data is not in conflict, and both changes should be preserved, but they aren’t -- when you save the birthdate (where the edit form was loaded before I saved the middle name), the empty middle name overwrites the value I had saved. 


Read more
27 March, 2012
By totten
Filed under API, Architecture, Extensions

Many CiviCRM customizations have been packaged and distributed as Drupal modules. This can be desirable when a customization delves into both the CMS and CRM functionality, but -- when a customization focuses only on CiviCRM -- Drupal modules are a drag: they need to be patched for CMS upgrades (D6/D7) as well as CRM upgrades (Civi 2.x/Civi 3.x), and they don't work with CiviCRM's other CMS's (Joomla and WordPress).

Fortunately, dlobo has been making progress on support for native modules (built around the "CiviCRM Extension" system) in 4.1 and 4.2. An example module is here:

Of course, this still poses a challenge: a native module needs to use native tools for packaging code, adding new web pages, developing templates, etc. -- and all those tools come with a learning curve. To improve the learning curve, I've taken a...

Read more
26 March, 2012
By Eileen
Filed under Architecture, Sprints

Last week I wrote a blog about technical debt (comparing it to keeping a kitchen in order). I got a lot of feedback - most of it constructive. I'm going to resist belabouring the whole metaphor & limit this blog to a quick summary of some of the discussion that came out of it.


It's about making it better

There is such a thing as code without technical debt. It is found in textbooks & outputs the words 'hello world'. Code that is actually used has technical debt. Technical debt is a natural by-product of writing code without unlimited resources & time. So, while addressing technical debt is a good thing - saying that CiviCRM has technical debt is like saying CiviCRM is software.


On the flipside, it's important to note that CiviCRM is a remarkable piece of software & it represents a remarkable commitment by...

Read more
19 March, 2012
By Eileen
Filed under Architecture

Do you like to whinge about CiviCRM code? Have you sat through others doing having a rant? I've certainly done both. Being in the drupal world people often like to compare CiviCRM code with drupal & CiviCRM usually comes up a bit short. I think that's like comparing my kitchen with Bill Gate's kitchen. There are a few good reasons why my kitchen is not as nice as his. However, should I look at his kitchen (in a magazine) then I might glean a few good ideas that I could use in designing my own. (Copying the colour scheme would be in my budget :-))


To continue the metaphor, Bill Gates gets to rip his kitchen out & put a new one in whenever it's getting a bit tatty whereas I have to patch mine up & incrementally improve it. Unfortunately, each time I get a new whiz-bang gadget I find it harder & harder to get the cupboard door to shut. And then I can't find anything or open the door without everything falling out.


Read more
03 March, 2012
By xavier


The code sprint in London has finished yesterday. It's always a pleasure to see old civi friends and meet new ones. Thanks to Michael and Katy to have organized it. Time for a quick update of what I've been working on with the most obscure title I could find. My focus has been on usuability to make civicrm easier and faster to use.


To make our crm more user friendly, we need to make the pages more "application like", where you can add, edit remove and reorder from the same page without having to switch and go to more pages with forms to fill and save. And load. And wait. And save, and load and wait more...


For instance  -and that will be a make it happen that we launch next week to improve- creating a survey today means you have to go to visit a different page to create the survey, the profile, for each field you add in the profile, for each custom field you need to...

Read more
28 September, 2011
By totten

CiviCRM 3.4.x and 4.0.x introduced API v3, a more consistent set of interfaces for integrating with CiviCRM using PHP, Smarty, Javascript, and REST. Building on this consistent core API, recent CiviCRM updates have introduced even more ways to manipulate your data -- such as chaining and CSV batch importing.

Thus, functions implemented according to the API v3 conventions can be invoked several different ways. If you would like to leverage this infrastructure for use with a new or customized API call, then download the latest release. With 3.4.6/4.0.6, external developers can expose API functions for new entities, new actions, and even generic actions.

This would, for instance, allow you to create an API that returns the top donations of a person, grouped by contribution...

Read more
19 September, 2011
By lcdweb
Filed under Architecture

CiviCRM 3.3 introduced a new hook that allows you to interact with and alter dedupe queries. Unfortunately, it was something of a "hidden hook" as it lacked documentation for quite a while. But it can be quite useful and powerful, and thus deserving of a review.
In version 3.3 and 3.4/4.0, the dedupe tools in CiviCRM received several notable improvements, including a restructuring of how the dedupe queries are built to improve performance, and the introduction of a paginated display with table caching that significantly improves the dedupe review and merging process. However, running a rule can still take quite some time on a large database (250k+ contacts), and the matching mechanism is quite basic -- simply comparing field data with field data.
That's where the dedupe hook can come into play.

The dedupe hook allows you to rebuild the queries to improve performance, and add additional logic and comparison intelligence to increase successful matching. Working...

Read more
31 May, 2011
By brylie

Imagine for a moment that CiviCRM is a garden. In all its object oriented complexity lie bugs and weeds that need to be effectively discovered and managed. Managing a garden the size of CiviCRM is a daunting task for one individual, and even a team of developers along with a community of end-users and testers still need help. There is indeed help to be found! 

Garden GnomeMost gardens have a gnome or two. CiviCRM has dozens. Our little army of workers were deployed from the xUnit, a top secret, multi-lingual consortium who's primary concerns are the sanity of software developers and confidence of end-users. These assertive xUnit workers diligently patrol the garden for problems. When a problem is found, the local worker will switch xe's hat from green to red in order that...

Read more
13 May, 2011
By xavier
Filed under API, Architecture


Some improvements on permissions and the API are landing on 3.4.2 and 4.0.2.

On the previous versions, the permissions where not enforced (on php and smarty) and checked on the same permission "access civicrm" for the rest and ajax no matter the operation and entity.


As API v3 is exposing more and more entities, it became necessary to control better what could be accessed. We re-used the permissions has defined on drupal for the menues, but instead of applying them to a path (in order to access civicrm/admin/event  the user need the priviledge "access CiviEvent"), we applied them to the entities and action (in order to create an event using the api, the user need the priviledge "access CiviEvent").


We realised there isn't a perfect match between these two logics "protect what pages and form you can access" vs. "protect what type of content and action...

Read more