Blogues

The Nonprofit Technology Network (NTEN) published the results of it's first-ever Donor Management Software (DMS) Satisfaction Survey last week. Nearly 1,000 people participated in the survey - whose goal was to help nonprofits "find the DMS that is best for your organization". Regulars readers of this blog will recall that we were quite disappointed when the survey was announced - due to the fact that CiviCRM was NOT INCLUDED In the list of Donor Management Software solutions in the survey. The good news is that folks in our community stepped up nicely. Despite being a "write-in candidate" CiviCRM got the fourth highest number of respondents to the question "Please select the product that you consider your PRIMARY donor management system."

CiviMail is getting another major upgrade in 2.2. Some of the features coming in 2.2 include: PHP return channel solution. This feature should enable more folks to install and run CiviMail. This will obsolete our amavisd return channel solution. No perl or sys admin / root access expertise needed any more :) Adding CiviMail as an "action" to search results. This feature will allow folks to send a mailing to a "dynamic smart group" and alleviate the need to create multiple groups just for civimail purposes. Thus if you want to send a targeted mailing to all the folks in the 94135 zip code in your "we want more green trees" group, you enter the relevant search parameters (check the group and type the zip code), do the search and invoke the "Send Bulk Email" action. You can read more about this issue here Adding token hooks and ability to send "templatized" emails. This is described in more detail below

Over the last week or two a growing number of folks have been discussing improvements to the REST API. Several months back I wrote a small patch that opened the experimental REST interface to the whole API of the system. When that happened a few other people started to show some interest in what could be done with this new functionality.

There are a couple changes being worked on, and several more proposed for future work.

Our global meeting resulted in some new features being added to 2.2. Our team worked on a new jQuery based country/state selector and incorporating hook(s) to the "amount" functionality of online contribution and event registration pages. I'll give a brief description of the feature set and functionality of these projects New jQuery based State Country widget Our previous widget was a dojo based combo box widget. Both the country and the state were ajax based combo boxes. The state combo box was dependent on the value chosen in the country combo box. This implementation was quite complex and not easily replicated (hence u did not see the widget in many places). For 2.2 we took a slightly different approach: The country field is a simple html select box (the values are restricted by the countries configured in the admin area). The state selector is now dynamic and refreshed with new values whenever the country is changed. We took inspiration and borrowed a fair part of the code from: Simple chained combobox plugin for jQuery.

Looking for an opportunity to network and share expertise with other folks in the non-profit technology eco-system? The Nonprofit Dev Summit takes place in Oakland, California next week - November 17-19. Depending on attendee interest, I'm prepared to facilitate several CiviCRM-related sessions - as well as a few training modules (intro, advanced and/or developer oriented). I'm also planning on sharing a first look at the upcoming CiviCase case management module. And... there are lots of cool-sounding session on topics ranging from cloud computing to security audits and hosting. You can browse the current list of proposed sessions on the Aspiration wiki. "The 2008 Nonprofit Software Development Summit will be the second annual convening of people and organizations developing software tools, web applications and other technology to support social justice causes. Bringing together a diverse range of developers, technologists, managers, eRiders, integrators, users and other practitioners who self-identify under the umbrella of roles around “developing nonprofit software”, the 2008 DevSummit will provide an opportunity both to gather as a community and to take stock of the field, while building connections and capacity." It would be great to have a solid group of CiviCRM community members at this summit - so check it out and join us if you can.

One of the mini-projects that we worked on during our San Francisco meetup / code sprint was improving the way name and address data is handled during payment transactions (e.g. online contributions, membership signup and event registration). Our goals were: Prevent name, email address and postal address information collected during a payment transaction from over-writing existing "non-billing-related" data. Store the billing name and address info for EACH transaction - so that it can be retrieved for audit / reconciliation purposes. Set a foundation for a more "shopping-cart" style interface where logged in users can select from a set of previously used billing locations.

As I've said elsewhere, it's been a real pleasure working closely with the CiviCRM team on the CiviCase project. The work we're doing is exciting, and has at least a hope of offering some efficiency to the large number of service providers whose work is organized into "cases", however that term is locally defined.

CiviCase is a new component for CiviCRM targeted at organizations who provide case management services. It is being developed In partnership with the Physician Health Program of British Columbia (PHP-BC). In addition to providing funding for this project, PHP-BC is providing invaluable domain expertise and the current plan is for their staff to start using CiviCase in January 2009. You can learn more about how this project got started and the project goals from these blog posts and the requirements overview. CiviCase Phase 1 is a major part of the upcoming 2.2 release - and several members of the core team are gathered in San Francisco this month working on bringing it to life. Last week we had a two day "in-person" meetup with PHP-BC folks (Andrew Clarke, Claire Sauve, and Dave D) where we reviewed work in progress and got detailed feedback on the basic workflows and screens, as well as the data model and configurability of the component. That meeting resulted in some key refinements and additions to the phase 1 specification - and provided a good reality-check for the project!

The idea of creating a Drupal block containing a subscription form for a specific CiviMail mailing list (or for all of them) comes regularly on the forum, so I decided to try out how much work would it be to create one. It turns out this task is fairly simple, if one knows the proper URLs for CiviMail subscription pages. The URLs are of the form …civicrm/mailing/subscribe?reset=1 (for all mailing lists) and …civicrm/mailing/subscribe?reset=1&gid=X (for a mailing list with group id of X). For example, these two URLs point to subscription pages on our Drupal demo installation: http://drupal.demo.civicrm.org/civicrm/mailing/subscribe?reset=1 (all mailing lists), http://drupal.demo.civicrm.org/civicrm/mailing/subscribe?reset=1&gid=2 (the Newsletter Subscribers list). If having a separate page is not really the best outcome, there’s a possibility of creating similar Drupal blocks. The simplest(?) way of doing this is to look at the sources of the above pages, strip them down as much as necessary and then create an HTML Dupal block from the resulting code.