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:
Blogs
Keep up-to-date with blogs from the core team, working groups, developers, users and champions worldwide. Subscribe to our newsletter to receive regular updates by email. We also have an RSS feed.
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.
The next meet up for the UK usergroup will be at Drupal for NGOs, an event organised by Rob Purdie of Important Projects on Tuesday 10 June from 6pm-8pm. It's a Drupal as opposed to CiviCRM focused event, but there should be lots of overlap.
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.
Greetings everyone,
My name is Jon and you'll be seeing quite a bit of me this summer. I was accepted into Google's Summer of Code and I'll be working with CiviCRM. My proposal, titled "CiviCRM: Aesthetics and Usability" is available at the above link (on the CiviCRM wiki).
Who am I? I am 29 years old and live in the Seattle, WA area. I am finishing coursework in Software Testing currently. I am very excited to be part of the CiviCRM team.
Here's a description I first wrote a few months ago when I was tossing back and forth ideas to build this kind of system in a different context. I've adapted it a bit to suit the current terminology. I originally posted it in the forum, which is where I'd invite you to put your comments.
A case management system is basically a big table of activities, which come from various sources. The sources might include:
humans entering them into a web form
Being one of the CiviCRM developers for the past three years, the community/boding period in my case went pretty nicely. :) As part of my regular CiviCRM activities, through most of the past month I’ve been working on the new dedupe engine, and I’m really happy with the results – but it’s high time now to concentrate on my Summer of Code activities.
Being one of the CiviCRM developers for the past three years, the community/boding period in my case went pretty nicely. :) As part of my regular CiviCRM activities, through most of the past month I’ve been working on the new dedupe engine, and I’m really happy with the results – but it’s high time now to concentrate on my Summer of Code activities.
Based on the success of the previous trainings/boot camps, we’d like to schedule our first training on the US East Coast: July 23rd-24th in Philadelphia. We’d like to host people from three / four different organizations (around twelve participants) and conduct the sessions as a mix of advanced user training, developer training, design and coding, based on the interests of the attendees.
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 domain model does NOT address this issue - since data in each domain is completely separate and there is no concept of hierarchy, inheritance of permissions etc.
