CiviCRM is helping us serve member-based community organizing groups across the
U.S. to keep better track of their events, fundraising, and membership data. It's helping our community to aim higher in terms of what kind of questions they should be asking and what kind of data they should be collecting. We chose CiviCRM because it's the best all-around tool to do what our groups need, AND because it's open source.
Over the past 15 years I've been involved in several open source communities.
CiviCRM is without any doubt the one that has the strongest focus in welcoming "newbies" and letting everyone feel at home here. Another impressive feature is the focus on shipping. No matter what you think of CiviCRM today, you are almost sure that there will be a newer and better version in a few months.
CiviCRM helps us help non profits to do fantastic things with their data.
Being closely involved with the developers and documentation team on a daily basis ensures that we can give our clients the best and most up to date advice on how they can use CiviCRM to meet their needs.
We use CiviCRM for our Membership and Supporters system. We're committed to using Open Source solutions and are keen to expand the variety and success of our member recruitment and fundraising efforts.
It is super important for non-profits, advocacy and related groups to take charge of their destiny. Having control of your data is a good start. The crowd-sourced nature of an open source project in so in line with the co-operation and principles of most non-profits
CiviCRM is a project that strives to make the above possible. It is FREE as in kittens.
I've been working with CiviCRM since 2006 or thereabouts. The community is outstanding in providing support and sharing expertise, which combines with a strong product to enable me in turn to deliver better results for the organisations that I work with. I only hope that over time I will be able to repay the debt by supporting other newcomers to CiviCRM.
CiviCRM is a powerful tool that could be really useful for many non-profits in Mexico.
Unfortunately the community is very small in my country. I hope that in the next years the community expands around Latin America.
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.
Submitted by Dave Greenberg on June 15, 2008 - 19:42
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.
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 :(
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.
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.
Submitted by Dave Greenberg on May 28, 2008 - 14:21
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.
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.