18 June, 2008
By lobo
Filed under v2.1, Architecture, CiviCRM
From a forum post by Chris Burgess (with Green Party NZ). A related blog post is: Another approach to ACL and permissioning for hierarchical organizations Our (Drupal5+CiviCRM2.0) site needed a regional ACL implementation in order to give us the ability to easily grant access for our internal staff to contacts in their geographic region. Because we have staff at a provincial, regional and branch level, we needed to be able to configure permissions for each level. We did this by implementing code which overrides the ACL implementation in CiviCRM. I'd appreciate any input and suggestions on our methodology - it's a work in progress, but it's working well for us so far. I haven't tested this with Joomla, but I hope that my notes below help someone roll a similar implementation there.


Read more
17 June, 2008
By lobo
Filed under v2.1, Architecture, CiviCRM
CiviEvent is one of the more popular components in CiviCRM (followed by CiviContribute, CiviMember and CiviMail). We have improved CiviEvent significantly in the past few releases and more improvements are slated for CiviEvent in v2.1. With this increased usage, we've seen more folks using Price Sets. Briefly, price sets gives admins the option to break an event into smaller pieces and charge for each selected piece. Price Sets was one of the first significant of code contributions to CiviCRM (thanx to Ideal Solutions and Marshal Newrock). We were planning to restructure this code in 2.2, but there were two missing features which came up a few times with some of our 'regular' users. The first missing feature was that two options in a price set item could not have the same amount. In order to include meals on multiple days with the same price, you would have to separate... Read more
16 June, 2008
By sunil
Filed under v2.1
The Google Chart API is so simple yet so powerful that can give you some amazing features:
  • Create charts simply by using URL with some parameters
  • Inserting the chart is as simple as you would be inserting an image
  • The chart is created on the fly dynamically
  • No need of server side coding
  • No need of JavaScript to code or view your chart
  • Any resolution of the chart with only a change in URL parameters
  • Manipulating the parameters of the URL would change the chart
  • A variety of styles to choose as per your tastes.

Lets take a simple case study for our chart. Suppose you are showing Contribution to orgnization using monthly and yearly basis and instead of showing the data in tabular format you could show the data with some visual cues. Charts are the perfect way...

Read more
15 June, 2008
Filed under v2.1, Training
If you were thinking of participating in the proposed Philadelphia Boot Camp, tomorrow is your last day to let us know (by sending an email to me - dave at civicrm dot org). We are still a few folks short of the number we need to run the camp - so if we don't hear from you tomorrow - we'll have to cancel this session. We're still planning to hold another camp in the fall on the West Coast - details to follow - but feel free to drop me an email if you're interested in that session. Meanwhile - on the new development front, the 2.1 release is coming along nicely. As of today there are only Read more
10 June, 2008
By lobo
Filed under v2.1, CiviCRM, Joomla

We've had the ability to add one/more CiviCRM Profiles to the drupal registration page since the first release (thanx to the flexibility of Drupal hooks). This was not possible in Joomla 1.0.x and we hoped the 1.5.x series might help solve this issue and be more open. While Joomla 1.5 is a major step forward in multiple aspects, it did not address this issue. So to some extent we were stuck. I was hoping for someone in the community to step up and do the needful. But that did not seem to be happening either :(

After yet another forum post on this topic, i decided to take a look at the code and figure out what needs to be done. We had abstracted most of the pieces from drupal already, so we just need to make a few function calls at the right places. I started looking for an example component that does something similar, that I could base my work on. Had heard good things about...

Read more
08 June, 2008
By lobo
Filed under v2.1, CiviCRM
03 June, 2008
By lobo
Filed under v2.1, Architecture, CiviCRM
So while doing the custom data hook, CRM-1594, I also implemented a hook for setting the default values of a 'Form' in CiviCRM, CRM-3176. So now we have a defaults and validate hook for the form object. The two missing hooks are for buildQuickForm and postProcess, which I'm planning to implement in the next couple of days. This coupled with template customization will allow developers to inject form elements and save them to the database (similar to drupal hook_form_alter). I'm also planning to implement the ACL improvements as an ACL related hook (along with a sample implementation). These new features should give CiviCRM developers more power and flexibility... Read more
02 June, 2008
By lobo
Filed under v2.1, Architecture, CiviCRM
With the new custom data model in 2.0, it seemed a good time to allow developers to add columns to a custom group that are computed rather than entered. Some examples of this is computing the GPA of a student given the student's individual grades, computing the age of a contact given his/her birthday. This has been an outstanding issue, CRM-1594, for quite some time. We went down the path of describing an interface and making the admin implement the interface, similar to what we do with custom search. The admin would need to add the class implementing the interface to the group settings file. After implementing this, i could not articulate when we use an interface vs using a hook. I decided to implement it as a new "civicrm_custom" hook and it seemed a lot easier and also more inline with some of our other hooks. I did not introduce a specific "php code" data type. I chose to give the custom field a new property called "... Read more
28 May, 2008
Filed under v2.1
As part of the 2.1 release cycle, we are working hard to simplify and streamline the codebase wherever possible. The intent is to increase performance, reduce the number of bugs and make the code easier to understand and maintain. As part of this effort, we are considering the elimination of two "features" which create (potentially) unnecessary complexity in the code, AND which we believe to be infrequently used...

Store Data for Multiple "Domains" in a Single Database

The current data model allows you to create and maintain separate "data silos" ("domains") in a single CiviCRM database. This concept was derived from Drupal's multi-site table-prefixing model - although it uses foreign keys instead to link each domain's dataset. Over the past few releases, we have seen quite a few use cases where larger hierarchical organizations want to control access to subsets of their data - based on a user's departmental or regional affiliation and/or role. However - the current... Read more
26 May, 2008
By shot
Filed under v2.1

The new dedupe engine and UI landed on trunk (development part of our code repository) last week, and we’d be more than happy if you gave it a try on our CiviCRM 2.1 sandbox and let us know how it works for you.

The new dedupe, besides the engine changes described earlier, sports a new user interface. Navigate to Administer CiviCRM → Find and Merge Duplicate Contacts and check out the new admin screens.

Since 2.1, you are not limited to editing the three rule groups (one per contact type), but can create your own. The change that lets you use various dedupe rule groups for a given contact type without having to redefine them is accompanied by two new properties – ‘defaultness’ and level, explained below.

Another change in CiviCRM 2.1 is that the dedupe engine is used for contact matching through the whole application. For this, the two ‘fuzziness...

Read more