22 December, 2008
By shot
Filed under v2.3, Architecture

As the various localisations of CiviCRM get traction, the first localised versions of documentation pages begin to show up – and this brings us to the issue of how to internationalise these of the CiviCRM strings (texts) that contain links to documentation pages so that when a given string is translated to, say, German, it also refers to the German version of the documentation page (if such is present).

For previous and current CiviCRM versions (including the upcoming CiviCRM 2.2), when we internationalised a string, we wanted to leave the link to the documentation page outside of the string, like this: {ts 1=http://wiki.civicrm.org/…}Read more at %1{/ts}.

This approach has two major benefits:

  • The translators are not bothered to retype the link letter-to-letter in their translations (any errors here would mean that the link stops working), and
  • if the link ever changes, the string (‘Read more at %1’) doesn’t, and...
Read more
05 December, 2008
By michal

It's that time of year again!

No, not what you think. :-) It's the time of year when new a CiviCRM version is behind the door, and it has cool new features. Code freeze is going to be introduced any day now - and we'll move on to quality assurance, alphas, betas and other equally exciting stuff.

Let me briefly introduce you to two new 2.2 features: one of them already mentioned here and there - Personal Contribution Pages (PCP), and a "last minute" addition - Soft Credits.

To present one of the aspects of usefulness of PCP, let me tell you about my approach to personal involvement with social campaigns... There are some that I personally would like to get involved with a bit more than just donating money. I would like these campaigns to grow, get the largest outreach possible and I'm even willing to put some personal time into it. However, I usually do not have enough of it to volunteer. CiviCRM's new Personal Contribution Pages (PCP) feature can be helpful in...

Read more
02 November, 2008
By lobo
Filed under v2.2, Architecture, CiviCRM

The CiviCRM core team is currently meeting in San Francisco. We tend to meet 2-3 times a year. These meetings help us crank out a few large projects as a group and also help improve our communication when we return to our respective home bases. The focus of the San Francisco meetup has been on CiviCase, US PIRG projects and a few features from the 2.2 roadmap.

Our group (kurund, yashodha and me) have been working on extending custom groups with two new features. In 2.2 a custom group can be designated to hold multiple values. This allows a contact (or relationship/group/activity) to have a 1 to n relationship with a custom group. One use cases for this is storing educational history of a contact. A custom group with...

Read more
27 October, 2008
By lobo
Filed under Architecture, CiviCRM

Implementing support for multiple organizations with hierarchy is one of the main themes of the phase 2 part of the CiviCRM / The Public Interest Network (PIN) project. PIN has a fairly complex structure. It is a federation of organizations which include US PIRG, Environment America and others. It is made up the National PIN organization and has a number of child organizations at the National Level. One of them is Environment America (EA). The org chart of EA can be found here.

EA National has a few groups at the national level (EA National Members, All Online Activists, Other Aggregate Groups). It also has a lot of sub organizations ( EA California, EA Colorado and approx 30 other state organizations). Each State Chapter has a few groups at the state level (EA California Members...

Read more
19 October, 2008
By kurund
Filed under v2.2, Architecture

Lately there has been lot of confusion using Name, Title/Label and Value. There is also a lot of inconsistency in code and database, hence we are planning to fix it in CiviCRM v2.x release.

Lets take an example of Participant Status, 'Registered'. In this case Name will be 'Registered', value will be an integer from 1..N (this depends on each install) and Label/title can be "Registered" or "I will come" etc. (or a localized version of the word/phrase).

Basic rules are:

  • Name: This is fixed value and cannot be changed by user. This is used internally in the code base to do certain actions. This will typically be in english.
  • Title/Label: This is user editable field and can be translated. This will be displayed in the system.
  • Value: Actual value that is stored in database.

There are few tables where we have adopted correct approach, like "civicrm_option_value". In this table we have separate fields name...

Read more
19 July, 2008
By lobo
Filed under v2.1, Architecture, CiviCRM

Integrating CiviCRM with an email client (specifically Outlook) has been a long requested feature. Unfortunately we dont really have any internal windows expertise to make this happen (for now). For now, we've built some code for the HRD project that attaches incoming email as an activity to the contact record of emails that are in the from / to / cc / bcc fields (we create a contact record if not found)

We are currently using ezComponents Mail library to read and process incoming emails. If possible i'd like to transition this to using the Zend Framework, since that will be our basic library framework for CiviCRM v3.0.

The current approach is file based. The...

Read more
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
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