Thanks to the folks who expressed interest in attending a CiviCRM Boot Camp in Philadelphia this summer. Unfortunately we didn't get a sufficient number of signups to justify the expense of running the session (given that we'd be covering airfare, housing expenses etc.) - so we are forced to cancel the session.
Blogues
Restez à l'affut des dernières nouvelles de CiviCRM avec les billets de blogue de développeurs et d'utilisateurs de partout dans le monde.
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.
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 them into different items. Price Sets did not allow an amount of 0 either in an option. Fixing this was relatively easy, we just shuffled around a few fields that we used in the civicrm_option_value table to fix the above problems.
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
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.
As the Summer of Code coding phase got rolling, I started looking at the tasks I listed in my original description of the project.
As the Summer of Code coding phase got rolling, I started looking at the tasks I listed in my original description of the project.
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.
With Blackbaud's acquisition of Kintera, there has been some talk of what this means for the nonprofit sector. This along with Convio's acquistion of GetActive last year reduces the options available for the medium-large size NPO's. This is not a bad thing for us, since it makes open source software like Joomla, Drupal and CiviCRM a more attractive option.
On that line, I started thinking about some of the big holes in the CiviCRM feature set / ecosystem. Here's my current list:
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 in tailoring CiviCRM to their specific needs without hacking core.
