Blogs

Batch entry of gifts (checks, cash, etc.) is a much requested "missing feature" in CiviCRM. Thanks to a generous sponsorship commitment from the Electronic Frontier Foundation, we are about to launch a Make-it-Happen campaign to implement this feature for the next release (4.2). We've spent some time discussing requirements with folks at EFF and several other organizations, and we've reviewed analogous functionality offered by several of the proprietary donor management products. The purpose of this post is to share the draft specifications for the feature and solicit feedback from others in the community.

Overview

The goal is to provide a streamlined interface for data entry of batches of contributions and membership payments. A simple batching concept will be introduced to provide verification of count and totals. The feature will use a grid-style input form with the columns controlled by a selected profile. This will allow sites to add or remove non-required fields in the grid (e.g. add custom contribution fields, add or exclude premium fields etc.). The current plan is to have a separate flow / input grid for batch entry of contributions vs. membership signup / renewal payments. This will help reduce the number of columns required for each type of input.

Basic Workflow 1. Create a New Batch

Users add a new batch by entering the following: batch type-contributions or memberships for now (required), batch name (required), description (optional), number of items (optional), batch total amount (optional). A default unique batch name is provided ("Batch N" + open date). The batch open date is assigned automatically. Users select the profile they want to use for the input grid

2. Enter Contributions or Memberships (check, cash, EFT)

For each row, you can select an existing contact using the auto-complete widget OR create a new contact (using the pop-up New Contact profile form). If contact information such as phone number or email address are included in the grid profile - those values will be populated for an existing contact and can be updated as needed in the row. Support for assigning a Soft Credit will be included. Rows will be saved as they are recorded to prevent data loss. A running count and total for the batch will be displayed on the screen. Client side field validation will be used as much as possible.

3. Verify Batch Totals / Close Batch

Users can enter all transactions for the batch in one session, or simply log-out and complete input at a later time. When all transactions are entered, the user clicks "Close Batch". If a transaction count and total have been recorded for the batch, the user will be alerted when closing if the count or total don't match. In this case, they can return to the batch's transactions to check for input errors, missing and or duplicate transactions. Or they can override the entered count and total (in which case the batch values are updated to match the transactions in the batch).

Additional Functionality Working with Existing Batches

Users can return to an open batch to continue adding or editing transactions in the batch. For open batches, they can also edit name and description of batches, modify the expected number of transactions, and batch total, and set the batch status to closed. Batches may only be deleted if they have 0 transactions assigned to them. Administrators may have permission to re-open a batch that has not been exported, in which case the batch close date is set to null. Once the the batch is exported it cannot be changed. (NOTE: Batch export is not in scope for this project, but is scheduled to be included in CiviAccounts development.)

Reporting

Minimally the batch name should be added to the Contribution Detail report as a column and as a filter. If time permits, one or more "Batch Reports" may be implemented.

It's the code sprint next week here in London, at CAN in Old Street, and hopefully we'll have quite a few people coming along to join in for all or some of it. Lobo and Kurund are coming over, which we're excited about :) On Thursday, after a hard day's sprinting, we'll be rolling round the corner to The Book Club for a bit of a hang out.
 
Everyone is welcome. You don't have to be a developer or a Civi expert, it's just a chance to meet other people in the community. In fact, it's not a Civi-focused event, it's a social thing, and if we can bring ourselves to - we'll be talking about things other than Civi! 
 
We'll be there from 6, so pop in for a drink, some food, or just to say hi. See you there :) 
 
Katy J
Third Sector Design

A way to free yourself of Groundhog Day

The CiviCRM community has been working on a new website for civicrm.org. As part of the civicrm.org redesign-launch Emphanos has been working on a producing a set of 3 to 4 medium length (5 to 10 min) screencasts to complement the launch of the re-branded CiviCRM.org website. We've worked out a lot of the technical and production issues surrounding the production of a clean, professional looking screencast. We've surveyed the field and researched the best practices in the subject matter and have learned some key lessons which we've incorporated in our learning video production pipeline.

  Current state of CiviCRM screencasts for redesign-launch

We have created a total of 4 screencast scripts. One of those we have fully revised and edited to create an "overview-informational" screencast on "The Basic Contact Record" and produced a full screencast in draft video form. The scripts were conceived by Kevin Krupp, edited by Dave Greenberg and Young-Jin. Take a look at our first finished video here:

                          http://screencasts.emphanos.net  based on Script 1 available here

Let us know what you think. The current video is revision 3, we expect to have 1 more revision cycles based on feedback from the community for this screencast on "The Basic Contact Record".   We premiered this particular screencast at our January Chicago CiviCRM meetup to great effect for newcomers; they immediately understood the power of seeing all past interactions on a single unified summary screen and were impressed by the scope of CiviCRM's capabilities, all this within less than 10 minutes of watching the video. We might be able to use screencasts as intro materials for our meetups to quickly on-board and educate newcomers about CiviCRM, in the vein of "Hello Meetup-attendee, meet CiviCRM on the screen, then show up to our meetup to meet us in person"

 

 

Screencast Lessons Learned thus far...

1. Screencast scripts need to be edited, reviewed and vetted ahead of recording [this is the most time consuming part of the process! But it is also the most readily crowd-sourced component!]

2. Three distinct narrative styles exists and should be employed for different purposes: A) story-based approach, B) overview-informational, C) task-oriented how-to  [A) long --> B) medium length --> C) short]

3. Consistent look and feel through the use of standardized call-out boxes, highlights, overlays, key-frames to create a coherent visual style maximizes comprehension

4. Audio quality is very important and should be recorded separately from the on-screen interactions

5. Video quality is close second, but the overall user experience mostly hinges on audio quality (i.e. suppressing noise, pops and hisses for the audio track)

  We firmly believe that having professionally looking, informative screencast that showcase the flexibility and power of all of the built in functions within CiviCRM will go a long ways of promoting the product and making it speak for itself. The current distinct lack of compelling screencasts is hurting us as a community. Luckily we now have all the tools in our arsenal to change that and we think we've come up with a very streamlined production pipeline that will get us from nearly zero to a basic library by launch time.

 

Where we need community support moving forward Here's what is currently missing and we'll need the community to help us with (in order of importance):

• Review and edits on the other 2 remaining draft scripts for "Contacts: Search and Find" and "Events: Setup a free event" which are both story-based. We've setup a Google Doc to collect comments on the current scripts http://goo.gl/Skm0d
• Additional tailored "story-based" scripts for different target audiences (tire-kickers, marketing towards an untapped niche vertical, improving broader public user-base understanding of core functionality and features)
• Intro & Outro matching the new brand identity of the relaunch (Rayogram is working on these)
• Financially sustainable backing through a screencast MIH campaign that will enable us to produce up-to-date screencasts to highlight each new feature for a given new release of CiviCRM to stay current with fresh screencasts at all times (major features would be covered in a overview-informational screencast, improvements in UI and UX covered in task-oriented how-to screencasts)
• Conceptual roadmap for future screencasts based on your implementer's point of view of the needs in our client community (prospects, existing clients, general public)
• A set of story-based narrative frameworks [fictional recurring characters with distinct functional roles, e.g. Linda Hamilton, the development director at Large-Do-Good NPO] that correspond to a given target market vertical, e.g. membership based association, call-to-action advocacy group, small starting NPO, large established NPO
• Potentially an intro soundtrack (strictly optional), we've identified some royalty and license free music (see here for a sample track: http://goo.gl/XcwGl)

  Don't repeat yourself (DRY for marketing)

As a nice-to-have would be an animation or infographic based approach to the following questions that we all have to answer to potential clients, which would greatly help educate our client base ahead of choosing open source over the increasingly consolidated single-vendor (see recent Blackbaud acquisition of Convio) proprietary solutions:

 

• What does it mean to adopt a community supported open source product or daily use? (explain difference in licensing model, hosting requirements, consultant ecosystem, flexibility to adapt and change code base etc.)
• How is CiviCRM supported? What are the various levels of support? Where is it hosted?
• How can we implement it at our organization? (describe the full spectrum of implementation styles ranging from self-install & self-instructed, assisted implementation with training to "soup-to-nuts" professional deployment by consultants)

  We as consultants have to address the above questions reminiscent of scenes from the movie "Groundhog Day" nearly every time we meet with a prospect. Having prospects and decision makers come prepared to the table would help us speed up the conversion and get to the implementation phase faster. More implementations, more community, more stable future! A compelling example of an animation based videos is this Salesforce.com marketing collateral http://youtu.be/ae_DKNwK_ms explaining the advantages of software as a service in the cloud.   YouTube Direct a window to user stories and case studies: We've recently done work with YouTube Direct (http://youtu.be/tgGxi3hiOnY) that would lets us as a community solicit and curate CiviCRM related video content on a centralized Youtube channel dedicated to all things CiviCRM. In short Youtube Direct let's community members become the reviewers for video submissions that we can then collect into one giant river of videos for user stories, case studies and mini-how-to's. We now have considerable experience in getting YouTube Direct set up and have created a specification to fully integrate YouTube Direct with Drupal 7, i.e. solicit "user story" videos from within Drupal 7, enable upload to YouTube Direct, approval and syncing of video content back to Drupal 7 site for embedding using the media module. Here's an example youtube channel (likely utilizing YouTube Direct) by our friends over at Blackbaud:  http://www.youtube.com/user/blackbaudinc   We hope this email inspires you to help in our efforts to get videos explaining the power of CiviCRM to the rest of the community and gives you a sense of what is possible with the upcoming re-branding of civicrm.org and new ways using videos to effectively promote CiviCRM.   Feedback always welcome,   Young-Jin and Kevin from the Emphanos Team

 

If you've recently upgraded to CiviCRM 4.1, you'll need to upgrade your webform_civicrm as well. Versions 2.3 and below are not fully compatible with Civi 4.1. Version 2.4 is, and will be released in the next couple of days, especially if I get a few comments on this post from people who have sucessfully tested it! The latest -dev is stable and working, so please feel free to download it and try it out on your 4.1 site!

Note: webform_civicrm 2.4 is not backwards-compatible with older versions of CiviCRM, and should only be used with 4.1.x

New Features In webform_civicrm 2.4

• Adds contact image and language pref fields
• More options for matching/updating existing activities
• Support for new multi-valued contact sub-type
• Improved group and tag fields
• Can include the entire webform submission in the activity details, as well as an edit link
• Can generate a contact checksum for use in webform-generated emails
• Supports cid1=0 in URL, so the "not you" link no longer logs you out
• Support custom data for cases

This version also has some behind-the-scenes enhancements to improve efficiency, compatibility, and pave the way for future improvements. As always, Drupal 6 and 7 are both supported :)

If you have a look back over the documentation (previously book sprint) blog tag, you'll see that over the past few months we have been making slow and steady improvements to our documentation.  We've moved the books over to CiviCRM.org and clarified the relationship between the book and the wiki.  It has been pretty fun so far, but there is still lots to do, one of which is a decent review of the user and admin guide...
After the last book sprint we realised that we have come to a point where, in order to be really effective at a book sprint, we need to have a solid understanding of the state of the current book before we start.  In earlier sprints, this wasn't such a big deal as we could just get together and pump out the content, but now that our book is over 300 pages and pretty comprehensive (toot toot!) we need to do the prep, have the long discussions and debates, get clarity, etc. before the sprint, so that when it comes to the sprint, we can concentrate on writing quality documentation.
I'll blog a bit more about our plans for the book sprint closer to the time, but right now I wanted to draw people's attention to the book review and invite you to get involved.
We still love the Wiki, and to show our love, we're writing the review of the writing the review of the user and admin guide book review on a wiki page.  Everything you need to know is on that page, but to summarise, we want to:

• Work out what parts of CiviCRM we haven't covered
• Work out where the poor quality content is
• Agree on any high level changes to the structure of the book

This is interesting stuff (well I think so anyway!) and it would be great to get your feedback and thoughts the book as it stands.  Have you read the book (or parts of it) and thought that you could do better? Have you been meaning to read or review a section and not found the time? Now would be a great time for you to do that.
The bottom half of the wiki page is a list of book sections where the review is starting to take shape.  As you can see we've made a decent start already with a fair number of contributions for different community members.  Now it is time to ramp up the process and make sure we've covered all the sections in time for the next book sprint (early April).  Please take a section, read it, and add your thoughts on that page.  Ideally, you should take a section that no one has covered yet, but feel free to read a section that has already been reviewed - the more voices the better.
Once we've done a section-by-section review, we'll look at the bigger picture and see if and how we can shift stuff around, refactor it, etc. to make it more accessible and easier to understand.
So what are you waiting for? Get stuck in and/or tell your friends and colleagues to do the same!
Oh, and one last thing. I also wrote this page on http://civicrm.org/documentation as a starting point for people who want to understand where our documentation is and also those who want to help writing it - it would be good to get your thoughts on that as well.

The team is excited to announce the first stable release of version 4.1  - with support for Drupal 7, Drupal 6, Joomla 1.7/2.5, and Wordpress 3.3. You can download the release now from Sourceforge.

We strongly recommend that you upgrade a test copy of your site and review your critical workflows before upgrading your production site. You can also test-drive the release on each platform using the public demos:

• CiviCRM 4.1 on Drupal 7
• CiviCRM 4.1 on Drupal 6
• CiviCRM 4.1 on Joomla 1.7
• CiviCRM 4.1 on Wordpress

Please report any bugs or issues on the appropriate forum board (what to do if you think you've found a bug).

  What's new (highlights)

Here's a quick list of some of the many cool and useful new features and improvements in this release:

• Extended support for Drupal 6
• WordPress 3.3 integration
• Personal Campaign Pages for events - CRM-8534
• Scheduled Reminders for events - CRM-8669
• Social Networking plugins (Facebook "like", Tweet ...) for event and contribution pages - CRM-8737
• Support for case custom fields - CRM-8508
• Simplified Administrator menus - CRM-9059
• Assign multiple contact subtypes and change subtypes  - CRM-8357
• Consolidated cron provides a single interface for configuring the automated scripts- CRM-8358. Heads-up sys admins - existing cron jobs will need to be reconfigured.
• Find duplicate contacts has been optimized when using the  reserved dedupe rule
• Limit contact reference custom fields by group - CRM-8536
• Unlimited Profiles for event registration forms
• CiviReport - save report instance as a new report and permissioning by role - CRM-8562
• Event info pages include links to configure the event, and to view registered participants - CRM-8707
• Register, and Confirm buttons now appear on TOP and bottom of public event info and register forms

 

Want to learn more? Check out the complete list of new and improved functionality on the issue tracker.

 

Step up and help out with documentation updates

New releases provide a great opportunity to get involved in the CiviCRM documentation community. Many of the new and improved features in 4.1 are not yet reflected in the User and Administrator Guide, and Developer Guide. You can get an account to edit and update the books here.
 

Downloads

You can download the release from SourceForge. The filenames include the 4.1.0 labels, e.g. civicrm-4.1.0-drupal.tar.gz or civicrm-4.1.0-joomla.tar.gz or civicrm-4.1.0-wordpress.tar.gz. Make sure you're downloading the correct version: for Drupal or Joomla or WordPress.

 

New Installations

If you are installing CiviCRM 4.1.0 from scratch, please use the corresponding automated installer instructions:

• Install CiviCRM 4.1 on Drupal 7
• Install CiviCRM 4.1 on Drupal 6
• Install CiviCRM 4.1 on Joomla 1.7/2.5
• Install CiviCRM 4.1 on Wordpress 3.3

 

Upgrading to 4.1.0

The procedure for upgrading is described in following documents:

• Upgrade Drupal 7 / CiviCRM 4.0 Sites to 4.1
• Upgrade Drupal 6 / CiviCRM 3.x sites to 4.1
• Upgrade Joomla Sites to 4.1
• Upgrade WordPress Sites to 4.1 (from 4.1 alpha or beta)

We will continue to include automated upgrades for subsequent stable releases of 4.1 - so you should be able to upgrade your site easily over the course of the release cycle.

 

Contributors

Community support and engagement is the force that sustains and drives CiviCRM forward. This release would not have been possible without the incredible contributions of these people and organizations:

Adam Wight, Andrew Harris, Andrew Perry, Alice Aguilar, Andre Gurgel, Brian Shaugnessy, Coleman Watts, Dave D, Dave Moreton, Eileen McNaughton, Erik Brower, Erik Hommel, Henry Bennett, Jamie McClelland, Jim Taylor, Jonathan Mark, Joe Murray, Marianela Zucotti Bozzano, Michael McAndrew, Steve Colson, Stuart Gaston, Tim Otten, Tom Kirkpatrick, Xavier Dutoit.

AGH Strategies, Amigos Library Services, Association for Learning Technology, Attendee Management, Benton Consulting, Circle Interactive, CivicActions, Community Builders, EE-atWork, Fuzion (NZ), Giant Rabbit, Kindling Trust, Korlon, International Mountain Biking Association, International Society for Bayesian Analysis, Josiesque Designs, Michigan Parents for Schools, New York State Senate, Nonprofit Association of Oregon, Nonprofit Solutions, Powered by Action, Progressive Technology Project, Resolutions Northwest, River Pool at Beacon, Rooty Hollow, San Francisco Baykeeper, Scotland's Colleges, Switchback, System Seed, Tech to the People, The San Francisco Orff-Schulwerk, Third Sector Design, Voluntary Action Westminster, Vpod Schweiz, Woven.

There have been several hook() or Drupal module based solutions for "members only" pricing for events or for other 'discounts' related to memberships.

 

I take a different approach by using only jQuery and blocks in Drupal 6.  For those who use Drupal 7 you can adapt this code with Drupal 7's new javascript namespace and Joomla folks could even make use of this in custom TPL files.

 

The whole concept of this code is that any 'member only' fee label must contain a specific word or phrase, in my example this word is "Member".  Staff must be trained to do this - it is relatively simple to do so.

 

How it works:

1. Place this code in a block, selecting "full HTML" or "unfiltered" input type, and assign the block to an inconspicuous region in your theme

2. Show the block only on certain pages, such as: civicrm/event/register

3. Show the block only to anonymous users in the block visibility settings

 

That's it!  Fee levels containing the word "Member" will be hidden.

<script> cj(document).ready(function() { cj("input[name=amount]").each(function() { var thisPrice = cj(this).attr('id'); cj("label[for='"+thisPrice+"']:contains('Member')").hide(); cj("label[for='"+thisPrice+"']:contains('Member')").prev("#"+thisPrice).hide(); }); }); </script>

Ways you can customize and enhance this

1. Change the word "Member" to a phrase of your choosing

2. Hide only the radio button, not the label, to 'entice' people to join. Delete the first line with hide() at the end

3. Activate this code only on certain pages by placing the unique id of the page in the if() statement near the top. That would look like this:

<script> cj(document).ready(function() { // add the id numbers of the pages you want below if ( document.location.href.indexOf('id=1') > 0 || document.location.href.indexOf('id=2') > 0 ) { cj("input[name=amount]").each(function() { var thisPrice = cj(this).attr('id'); cj("label[for='"+thisPrice+"']:contains('Member')").hide(); cj("label[for='"+thisPrice+"']:contains('Member')").prev("#"+thisPrice).hide(); }); } }); </script>

4. Show the member pricing not simply to authenticated users, but to only users who are memembers

• Activate the CiviMember > Roles Sync script
• Change the visibility settings of the first block to be seen by all, thus hiding member pricing for everyone
• Make a second block with visibility settings only for your exclusive Member > Roles
• Copy and paste the same code, but change hide() to show(), thus re-showing member prices only to members
• Place this second block just below the first block

Hi,

So as every consultant, there is a bit of new projects, maintenance, stuff you do for free for the community, new ideas, meetings, pre-sales, funky developments & the dreaded admin part (invoicing/timesheet).

 

As any consultants, we are trying to get an overview on what are the issues, where we spend the time, who's involved and what has to be invoiced. For what I've seen for the past 20 years, the choice seems to be between separate tools that work well but don't talk to each other and one big ERP that tries to do everything but does it badly and that no one uses without cursing.

 

As all our contacts are in civi and that it also can track activities, was wondering if some of you are already using it as part of that combination and hopefully not turned it into a clunky 'ERP'?

 

We have started with Andreas, Tamsin, Julian & Cristel with some civi/drupal tools and Civi, but are in the middle of the road and wanted to brainstorm with you, see how/if we can get something that make sense. I was discussing it with michal and some other consultants, thought might be useful to put it in one place.

 

Logging issues & discussions

For each project, they are tasks/issues and discussion about them. This is usually done by email (with an empty subject line and a body "The page on the site doesn't work.").

For each project, we have a organic group and with og_mailinglist we have an email "projectA@my.org". Each new email starts a new issue, each reply is a comment. It mostly work, beside the odd new task "So, what's going on about the things of last week".

The views are usually good enough to see what's going on for any project or our workload across them.

 

Activities & Cases

The Civi way would be to have a case per project and one activity by task. As it matches the project/issues, we have written a module that creates a case for each new project and a new activity (type task) for each issue. We don't create comments in civi, as they are mosly discussions are not useful to get the bigger pictures (knowing how many times you have been asked to increase the size of the logo is better kept in the comments ;)

 

It works, but doesn't bring a lot of new features to the chain by itself, beside linking it to the contacts (that might be useful when you have lots of people involved on a project), but that's the needed part to make civi more integrated and....

 

Timelog

Logging time on a website has always been a weak point. The interface is not user friendly enough, needs to re-enter info about the clients & projects & tasks that are already elsewhere... and you might be working offline or with a flacky internet connection.

 

Lately, we have been using hamster, a timetracker that integrates well and is easy enough to use. It is able to understand some commands so "writing the blog about civiproject @civi" would create a new task (or update an existing one) in the project civi.

 

Andreas has coded a tool that takes the timelog (the complete db) that you can upload to the server and match to the tasks/issues.

It mostly works, but right now that's done by uploading the sqlite db hamster uses. To make it really practical, it would be needed to automatically create the projects & issues on hamster when they are added on the web.

(shouldn't be complicated, a local script using the api), and upload the timesheet using the API too.

 

Right now, we are storing it on separate tables, but if we were to use civi, each worked timeslot could stored as a sub activity of civi.

 

Reporting & Invoicing

In our cases, the reporting is either internal (to see where we are on a project) or for the customer (on maintenance/per hour). the reporting functions of hamster are good but the export isn't, and anyway you'd want to be able to easily mix hours spent by various people.  This part is still too manual and involves excel, csv, sql commands and in general is not a pleasant experience.

We have all/most of the data on our server, but we aren't sure if we should develop reportings outside of civi (using views) or try to integrate them into civi & use it for reporting.

 

What's missing

That's very likely that we won't all use the same tool to track time and that it should be eas(ish) to import from a lot of various formats (eg meetings from a calendar, logs from the PBX, timesheets generated from various providers...). Right now, matching the different ways people name the same task/project is painful, not quite sure how to create a common taxonomy or tools to easily convert my project "Civi" with the project "civicrm" or the project "civicrm 4.0".

The next step would be to be able to add categories to the tasks, and see how much of the project is spend on pre-sale, brainstorm, coding, debuging, specification, testing... and let my inner data nerd have fun with that and do nice data visualisation.

Personally, I'm very keen on pushing our civibot (miss moneypenny) -that allows me already to interract to civi via my chat client- a bit further so I can chat "punchin writing the blog about civiproject @civi" that would create the tasks directly, with the added benefit of having the bot keeping a timelog already of when I'm online/away. This is another discussion probably ;)

 

How are you using it?

Are you already using civi for your project? How do you track time and what are your tools of choice? Do you think it makes sense to use civi to manage a consultancy shop?

 

 

 

 

 

 

 

The meetup was hosted at techhub, in London’s “Silicon Roundabout”, Old Street. Our host for the evening was Michael McAndrew of Third Sector Design, a company specialising in CiviCRM based in techhub.
Meet-ups are free and a great way to get to learn more about CiviCRM and are suitable for those that are new to CiviCRM as well as people that have been using it for years. There were two presentations, a mingle session and a case study report from a charity that’s successfully implemented CiviCRM.

CiviCRM in 2012
The keywords for 2012 are: mobile, scalable, community.
A code sprint (?) scheduled for later this month in London will be focusing on CiviMobile. CiviCRM for mobile devices includes iPhone, Android, iPad, Blackberry and more. This version will include the ability to view/search contacts and see most of the details of each contact. It will also allow users to create/edit contacts, and handle event attendee check-in. Several core developers will be in town and any developers are welcome to join.
CiviCon is taking place in San Fransisco on 2nd April. CiviCon is THE annual event bringing together the people who use, develop, design and implement CiviCRM. Good news for us in the UK though, a CiviCon Europe is planned for Autumn, although dates and location have not yet been finalised.

CiviCRM 4.1 News

• Beta release for WordPress – along with Drupal and Joomla, CiviCRM will now work within WordPress. WordPress has emerged from it’s blogging roots to become one of the most widely used content managment systems in use today, powering an amazing 14% of the web.
• Social plugins (Facebook, Twitter etc).
• Better cron (simple for admins to setup).
• Personalisation of campaign pages for events (think JustGiving).
• Improvement to admin menu.

A couple of UK specific projects were mentioned, with a call for some help from developers or sponsors to get them completed. These are Direct Debit integration and Gift Aid. The Direct Debit integration is a “make it happen” project, which basically is a call for funding, and the Gift Aid module needs a bit of development help to fix some not too tricky bugs.

CiviCRM Marketing

 

Dave Moreton, from Bristol based Circle Interactive, talked to the group about improving the marketing of CiviCRM. It’s apparent that next to the giant forces of SalesForce, Microsoft Dynamics etc, CiviCRM has a much lower profile. It’s also true that it’s a very different product. That said, the non-profit, membership, civic sector are often unaware of the existence of CiviCRM and end up using a commercial-focused CRM system that is less than ideal. David’s talk was about efforts within the CiviCRM community to increase awareness, talk up it’s successes and provide comparisons and marketing material for system integrators to use. He finished by showing us a sneak peak at the new CiviCRM website, which of course aims to solve these issues.
If you are interested in helping, there are occasional IRC meets, an online group at civicrm.org/groups/marketing and PDFs, Powerpoint and how-to material at Spreadtheword

CiviCRM Case Study
Finally we heard from Leukaemia & Lymphoma Research (LLR). Parvez Saleh from Veda Consulting, talked us through the tasks that were needed for migrate in just 2 hours a complete legacy system to CiviCRM.

 

LLR went from a system that was used by just a few users which specialist knowledge (and lots and lots of spreadsheets), to a website-integrated CiviCRM system that can be accessed by 80+ users, speeds up the financial reporting functions and will save the charity tens of thousands over the next few years, as well as enabling increased fundraising. LLR are now holding a “spreadsheet amnesty” to move all data onto the system.

Successful Event
The event was attended by around 50 people. Most were new to CiviCRM but we also met with system integrators, developers, current users and administrators. The user group meeting showed that there is an established infrastructure of support for CiviCRM here the UK, and organisations considering it for themselves can be confident they will get the support they need.
 
Author: Rex Wickham
Company: 2020Media.com
This article appeared first on the 2020Media Blog
2020Media provides complete hosting packages for CiviCRM
 

Okay, I'm double-posting today in case you don't find this buried in the forum.  My forum posting contains all of the details regarding a custom hack written for a client to automate 7 renewal email reminders based on expire date.
 
I do hope you find this useful.  http://forum.civicrm.org/index.php/topic,6176.msg98034.html#msg98034
 
- Annalee

Hey gang sorry it's taken me so long to get back to you but we've been busy slogging through a few outstanding issues.  For those of you who are currently in the throes of your data conversion here are a few quick words of advice.

1. Set up a local site for your data conversion so you don't run into any restrictions on how many records you can import at one time on your server, otherwise, you will spend a lot of time creating many, many small text files.

2. Learn as much as you can about the database tables and how many tables make up a single transaction. You will not be able to import all of your transaction data through the admin interface alone.  I will explain about this in detail further.

3. In order to convert past events you must create separate event records for every event. There is no way to get around this that I can see. We tried to avoid this when we converted to Kintera only to be faced with it again upon converting to CiviCRM.  We did the homework this time and now they can see what events folks attended all the way back to 2005.

4. Membership data is tricky to convert and we had a combination of several years of fixed membership data versus one year of rolling membership data. Add to this, trying to launch a seven effort renewal reminder program and I have a few more gray hairs than before.

5. Be careful about using Kintera's transaction id as your transaction key.  It will work except when you have multiple registration amounts within a single transaction, e.g., a member brings 2 non-member guests.  The transaction id will be the same for all pieces of this transaction.  You need to sum the amount by transaction for the contribution table and create a translation table for the parts of the transaction to create the right label for the event record.

6. Do use transaction id as a key for all straightforward single transactions.  I put this id in the source field for both the contribution record and the matching event or membership record.  I imported the records using the interface and then dumped out the civicrm_contribution and civicrm_membership or civicrm_participant tables.  In MS-Access, I matched the records up by transaction id and created a table with civicrm_contribution_id and civicrm_participant_id or civicrm_membership_id and then appended these records to the corresponding civicrm_membership_payment or civicrm_participant_payment table.  This is how you link the contribution records to their membership or event record.  It would be nice to be able to do this in the interface.  Idea off top of my head.  Add a key field to all tables so you would not have to use source which is used in other ways.  Import both halves of the transaction in via the interface, then run a process to find the matching records and create the appropriate payment records.

7.  For the event records, this was a bit trickier when someone paid for multiple tickets or levels.  In this instance, the contribution record stores the total amount paid but the detail of exactly what was purchased is saved in a text label in the civicrm_participant record.  Also, there is a specific separator that looks like a bunch of 000s and a 1 that you must use in this field and you must also update a table via PHPMYAdmin called civicrm_line_item.  This contains all of the detail of the # of items purchased which links back to the civicrm_participant table.

More to come as I find the time....as always feel free to contact me directly if you are faced with a specific timely issue.  Will provide whatever guidance my memory can recall..:-)

Hi All
Here at The Leukaemia & Lymphoma Research charity, a lot of events have participants who may be children or where a team leader is booking for all team members. The current implementation of CiviCRM insists on the inclusion of an email address for all participants, which is a problem in the two scenario's. Some of the teams are quite large and each team member has specific settings which need to be captured, such as t-shirt size, route etc.
We've been talking to Lobo & co and have determined that the following change would be improve the event registration process.
CiviCRM should be amended so that instead of adding the single email address field into the form it adds a reserved system profile which contains an email address ONLY IF the profile(s) associated with the registration form do not already contain either an email address OR first + last name fields.
Any feedback/suggestions would be much appreciated, this development is underway so please be quick!
JIRA Issue is registered here http://issues.civicrm.org/jira/browse/CRM-9587
 
Parvez
www.vedaconsulting.co.uk

We have continued the research to see how often someone tweeted about organisations that happen to use CiviCRM. We analysed 5988 tweets by 3478 users about 574 sites.

our twitter bot from TTTP (tweet civi) and and some new skills on R allowed us to get more graphs and updated information.

Although we've had impressive numbers in 2011, I'm not too happy with the result. Luckily, you can help me fixing it easily.

What have they tweeted about?

Since last quarter the percentage of donation has increased, this is due to a small number of highlighy visible sites. On average, each site has 10 tweets about it (median is 3).

 

When have they tweeted ?

So definitely less tweets during the week-end than the rest of the week still.

 

Which sites?

Looking at the TLD, that's mostly .org domain names, but as well some geographical ones (ca, nz, fr, eu, de ...). However, the vast majority of the sites seems to be for US organisations.

 

 

The next version of civicrm will make it easier to promote your civicrm powered activities on twitter.

if you use civicrm and twitter and organise events, do fundraising or have a petition, please could you be sure:

• you tweet about your events and activitites with a link (at least from time to time)
• you put in your profile the same domain name as where you host the site?

  Community, we need to talk

If you look at the list of users, you see an amazingly diverse community working to support almost every environmental or humanitarian rights cause, cultural or educational organisations, loads of sports organisations, faith-based organizations, as well as a wide range of other advocacy topics. However, it would be great to see that same diversity on Twitter.

Part of the difficulty to mesure properly who's using our crm is that our biggest users like wikipedia use civicrm "behind the scenes" and they have custom urls for their donation pages that don't indicate they are using civi, so we can't guess simply by looking the links on the tweets.

What can you do to fix this? In the longer term, tweet about your events, donations, petitions or newsletter and ask your supporters to do the same. In the short term, pick-up any organisation you like on this list, find a current event or donation campaign (anything powered by civicrm) and tweet about it.

If you really want to do something useful now and make me happy, please tweet and donate to the ada initiative  that is just short of $30,000 in their latest fundraising round that finishes today. With your help we can have them as the 3rd most visible civicrm user according to twitter too :)

 

What words?

These are the most common words in the tweets.

 

 

 

And, of course, the mandatory message about how you should

 

 

The team is excited to announce the third beta release for 4.1 with support for Drupal 7, Drupal 6, Joomla 1.7/1.6, and the integration with Wordpress 3.3 (wohoooo!!!).

 

Please remember this is a BETA release and it should NOT be used on production sites - however, we  strongly encourage everyone upgrade a copy of your current site(s) on a test server and let us know about any bugs or problems.
 

You can also test drive the release on each platform using the public sandboxes:

• CiviCRM 4.1 on Drupal 7
• CiviCRM 4.1 on Drupal 6
• CiviCRM 4.1 on Joomla 1.7
• CiviCRM 4.1 on Wordpress

Please spend some time running through your critical workflows on these sandboxes, and report any bugs or issues on the release testing forum board.

  What's new?

Here's a quick list of some of the cool new features and improvements in this release:

• Personal Campaign Pages for events - CRM-8534
• Scheduled Reminders for Events - CRM-8669
• Social networking plugins (Facebook "like", Tweet ...) for event and contribution pages - CRM-8737
• Support for case custom fields - CRM-8508
• Simplified Administrator menus - CRM-9059
• Assign multiple contact subtypes and change subtypes  - CRM-8357
• Consolidate CiviCRM Cron to provide a single interface for configuring the automated scripts- CRM-8358

Want to learn more? Check out the complete list of new and improved functionality on the issue tracker.

 

Step up and help out!

The moment of releasing CiviCRM 4.1beta3 is a great occasion to get involved in CiviCRM community. There are many ways you can help make this release better and bug free.
 

• Log in to the one of the sandboxes and try out the features you or your clients use regularly. If you find a problem, first check the open issues list on the issue tracker to see if it's already been reported. If not, please report it on the appropriate forum board. Remember that sandbox data is periodically reset.
• Download the tarball and upgrade a copy of your site to 4.1 - let us know if you encounter any problems. This is an especially valuable contribution since we need to have the upgrade process tested on different sets of data. After you've done this, play around with your favorite features, with your local data. Problems appearing? Use the CiviCRM 4.1 release testing board on the forums to discuss problems and find answers!
   
• If you're a developer and have PHP skills, we strongly encourage you to develop and attach a code patch AND a unit test along with any bug you report through our issue tracker. Ping us on IRC if you need help figuring out how to do this.

 

Downloads

You can download the release from SourceForge - select from the civicrm-latest section. The filenames include the 4.1beta3 labels, e.g. civicrm-4.1beta3-drupal.tar.gz or civicrm-4.1.beta3-joomla.tar.gz or civicrm-4.1.beta3-wordpress.tar.gz. Make sure you're downloading the correct version: for Drupal or Joomla or WordPress.

 

New Installations

If you are installing CiviCRM 4.1beta3 from scratch, please use the corresponding automated installer instructions:

• Install CiviCRM 4.1 on Drupal 7
• Install CiviCRM 4.1 on Drupal 6
• Install CiviCRM 4.1 on Joomla 1.7
• Install CiviCRM 4.1 on Wordpress

 

Upgrading to 4.1.beta3

The procedure for upgrading is described in following documents:

• Upgrade Drupal 7 / CiviCRM 4.0 Sites to 4.1
• Upgrade Drupal 6 / CiviCRM 3.x sites to 4.1
• Upgrade Joomla Sites to 4.1

We will continue to include automated upgrades for subsequent beta releases of 4.1 - so you should be able to upgrade your test site easily over the course of the release cycle.

 

Contributors

Community support and engagement is the force that sustains and drives CiviCRM forward. This release would not have been possible without the incredible contributions of these people and organizations:

Adam Wight, Andrew Harris, Andrew Perry, Alice Aguilar, Andre Gurgel, Brian Shaugnessy, Coleman Watts, Dave D, Dave Moreton, Eileen McNaughton, Erik Brower, Erik Hommel, Henry Bennett, Jamie McClelland, Jim Taylor, Jonathan Mark, Joe Murray, Marianela Zucotti Bozzano, Michael McAndrew, Steve Colson, Stuart Gaston, Tim Otten, Tom Kirkpatrick, Xavier Dutoit.

AGH Strategies, Amigos Library Services, Association for Learning Technology, Attendee Management, Benton Consulting, Circle Interactive, CivicActions, Community Builders, EE-atWork, Fuzion (NZ), Giant Rabbit, Kindling Trust, Korlon, International Mountain Biking Association, International Society for Bayesian Analysis, Josiesque Designs, Michigan Parents for Schools, New York State Senate, Nonprofit Association of Oregon, Nonprofit Solutions, Powered by Action, Progressive Technology Project, Resolutions Northwest, River Pool at Beacon, Rooty Hollow, San Francisco Baykeeper, Scotland's Colleges, Switchback, System Seed, Tech to the People, The San Francisco Orff-Schulwerk, Third Sector Design, Voluntary Action Westminster, Vpod Schweiz, Woven.

Thanks to a successful Make-it-Happen campaign the 4.1 release comes with a much improved and super flexible approach for running Civi's critical back-ground processing tasks. These tasks include keeping membership statuses up to date and sending renewal reminders, sending scheduled CiviMail mailings, sending pledge payment reminders, and more. I've spent the past 10 days testing and documenting the new "consolidated cron" functionality, and the good news is that I think it fulfills the promise of providing a convenient and friendly way to administer and run all the required tasks for a site.

 

The "bad" news is that these improvements are NOT backward compatible. The set of PHP scripts which were previously used to run these tasks have all been deprecated (and moved to a 'deprecated' directory). This means that all CiviCRM-related cron jobs will stop working as soon as any site is upgraded to 4.1. (Yes, a loud warning will appear on the screen at the end of the upgrade process.)

 

Although you'll still have the option of configuring separate cron jobs to trigger each of these tasks - many of you will want to take advantage of the ability to use the new administrative interface to enable the jobs you need, and configure run frequency for each job. Then you can configure a single "master" cron task to trigger ALL enabled CiviCRM jobs whose next run is due. For example, you may want to run the CiviMail mailing scheduler every time your master cron task runs (which might be once a minute). However, you only want the Address geocoder job to run once a day. You can enable both jobs, and set the run frequency for the mailing scheduler to "Every time cron job is run", while setting the frequency for the Address geocoded to "Daily".

 

You can also use the Scheduled Jobs interface to run specific jobs on an ad hoc basis. For example, you probably only need to run the "Set Renewal Reminder Dates" after making changes to the renewal reminder settings for a membership type. Although you can do this from the command-line, it's probably easier to just navigate to Administer > System Settings > Scheduled Jobs and click "Execute Now" for that job.

 

So … in the interest of helping us make sure things are working properly in YOUR environment, and helping you prepare for the upgrade I strongly encourage you to do a test upgrade on a copy of your site. You can then walk through the process of evaluating the new options for running scheduled jobs and configuring your cron task(s). If you hit any issues during testing, please post a detailed report to the 4.1 testing forum board.

 

Take some time to review the detailed list of the available Scheduled Jobs and the syntax for running all jobs OR a specific job. The documentation covers both the PHP CLI method, as well as the URL method (invoked using 'wget' or 'curl').

 

SAFETY TIP - Several of the scheduled jobs which you may be using in production involve sending email to your constituents. Obviously you want to ensure that this does NOT happen from you test site. You can ensure that NO emails are actually sent from any CiviCRM site by adding the following line to your civicrm.settings.php file:

 

define( 'CIVICRM_MAIL_LOG', 1 );

 

Kudos to Eileen McNaughton for pushing and prodding this much needed improvement along, to everyone who contributed to the MIH, and to Eileen, Jamie McClelland, Tim Otten, Xavier Dutoit and Michal Mach for the hard work and creative thinking that went into the design and implementation.

Notice to non-developers: This post is about how some functionality in 4.2 will be implemented in code and in the database, with very minor changes to anything visible through a browser. If you're not a developer, it probably won't interest you.

Simplifying the Codebase

As part of the CiviAccounts project we are looking to redo some of the implementation of the configuration and processing of payments for contributions, memberships, and events. Currently the processing for each of these three types of objects has two paths: one for a simple configuration of the objects, and one using price sets. This means there is more code, more complexity, more possibility of errors, more work when making changes, and more need for testing.

As we refactor the existing code we're looking at keeping the simplified UI for configuration and administration, but implementing everything under the hood using price sets. Before going ahead with that, we wanted some feedback from developers in the community.

Price sets are now supported for contributions, events, and memberships. You can use them to sell individual or multiple tickets at a time, items along with memberships and subscriptions, or allow contributors to determine how much to give / buy using text/numeric fields, select widgets, radio buttons, or checkboxes. Support for contributions on the same form the same as ticket purchases, and for contributions along with membership purchases is facilitated with price sets. They will be a good way to implement a page that allows people to get a discount on their annual membership if they buy a ticket to an event, though I haven't seen that yet.

One change that CiviAccounts will be making to price sets is allowing each option to be associated with a different general ledger account. This would allow, for example, revenue for one type of ticket to go into one account while revenue for a different type of ticket would go into a second account in your bookkeeping system.

The downside of price sets is that they are time consuming to create, and can be confusing for non-techies or new admins. First the price set needs to be created; then each of the fields within it; and within some file types, options can be specified. Lots of steps, clicks, page refreshes, and not intuitive how it will turn out for many CiviCRM admins.

By contrast, it's possible to enter the Fixed Contribution Options directly on the Contribution Amounts tab when configuring a Contribution Page, or select the Membership Types to sell on a page in the Membership Settings tab.

 

The Regular Fees section on the Fees tab when configuring an Event is just as simple. These simple configuration pages are equivalent to specifying a radio widget option field in a price set, without the complexity or flexibility provided by certain options.

 

We think it would be good to allow admins to continue to use the simplified interfaces and have the option of the power and flexibility that comes with the complexity of the full price set UI.

Proposed UI Change

In addition, we think it _might_ make sense to allow admins to switch from the simple configuration of a page to editting that information via the more complex price set configuration forms. But not the other way - going from complex to simple.

What's this mean in practical terms? Once any change has been saved to a configuration as a price set, even one that includes only one radio button field, the simple configuration approach for the contribution page or event would not be available for editting it. This would prevent confusion in various ways, e.g. from not seeing in the simplified form a change on the complex forms that was changing the behaviour of the field behaviour. Of course, you could turn off the price set you just created, and go back to the simplified UI and start configuring it from scratch again.

Proposed API

We would expect the price set api to follow our existing structure with an API to get, delete, create each of the Price set entities – Price sets, fields, values and for hooks to be called PRE & POST the main CRUD functions on these entities. The buildForm hook & validate hook are already available for editing price sets. We would probably discontinue the buildAmount.
For API users the change is beneficial with regards to interacting with events. At the moment it is extremely difficult to create events through the api as you also have to create an option group & option values to go with it. More problematically you can’t re-use the same event prices to create a new event via the api so this makes api creation of events much easier (and the eventual implementation of a front end event import option.) It is also currently hard to GET event prices through the API. This is likely to still require the use of API chaining but the chain will be a little more intuitive. Contribution Pages do not yet have an API & the issues are likely to be similar but most sites seem to create many events but only a few contribution page so the relevance is more for events.

Feedback?

Comments or concerns about these change would be appreciated.

The first North of England meetup took place on the 12th of January 2012. It was really well attended with fifteen attendees. The attendess consisted of people interested in CiviCRM, users, implementers and developers. Some of these people had travelled quite a long way to get there and we were really pleased to see them.
 
The focus of the meetup was to start to create a community of people interested in CiviCRM across the North of England and secondly to create a forum by which those looking at using CiviCRM can come along for practical advice.
 
The meetup icebreaker went really well (we struggled to stop people talking!) and this was followed by two demonstrations. The first one was a demo of CiviCase using a real world example. The second demo looked at CiviEvent and how this can be integrated into a Drupal public website.
 
We also got plenty of feedback on the format which we will be taking into account for the next meetup. Personally I think it was fantastic to see so many keen people there and I'm really looking forward to the next meetup in three months time. If you would like us to let you know when the next one is taking place please get in touch
 
Oliver Gibson, GMCVO, oliver.gibson@gmcvo.org.uk

For anyone who is using pricesets and/or automated recurring contributions with a payment processor, you will probably enjoy the 3 custom searches that you can download here
 
Custom search "Recurring Billing":  This was designed to help the administrative/financial staff review and reconcile all their automated recurring contributions in one place. It works no matter which payment processor(s) you are using. However, the layout of the columns is designed to match the layout of the ARB report within the Authorize.net system.   The expected workflow is that the staff would run the ARB report at authorize.net, then run this new custom search in CiviCRM and verify that the total number of subscriptions matches accross each system.    If the total number does not reconcile, then this new custom search can be used to help identify the disconnect.
 
Custom search "AdvancedPriceSet": This is designed for event organizers who make use of pricesets for various sessions being offered. If an event has a priceset field called "session wanted"  with choices being "session A", "session B", and "session C", then the event organizer can use this new custom serach to create a participant list for each session.   It will also list the name of the person who registered the participant, such as a wife who registered their husband.   Note: This search can only be used against pricesets used within event registrations.
 
Custom search "AdvancedPriceSetContributions":   Same idea as "AdvancedPriceSet" described above, however this custom search can only be used with pricesets that are tied to CiviContribute pages/contributions.
 
- Sarah Gladstone
pogstone.com
 
 

div.code {max-height:200px; overflow:auto; border:1px solid gray; margin:.5em; background-color:#eee; color:#333;}

One of my favorite features in CiviCRM 4.1 is the improved support for custom tokens via hooks. It's really opened up the possibilities for building some great functionality and new workflows in CiviCRM. If you already know what tokens and hooks are, skip down to see some cool examples.

Wait a minute, what are hooks and tokens?

When composing a mass-email, letter, etc. you can personalize it with tokens. Tokens are little placeholders that can get replaced with something different for each contact. Traditionally a token is simply a field in the database, so if you start your letter off with "Dear {contact.first_name}" it will become "Dear Robert" when sent to Bob. But as we will see, you can do a lot more with tokens than just pull a single contact field.

That's where hooks come into play. Hooks are opportunities CiviCRM gives you to inject your own functionality during certain tasks, adding-to or modifying whatever it was doing. Let's see how a hook can improve the above example:

Some "OR" Logic

Say you're composing a mass-email, and two of the recipients are Bob and Coleman. In the database, Bob's first name is Robert, and Bob is his nick name. You want to send a nice, friendly letter, so you compose your message thusly:

"Dear {contact.nick_name}, have you seen our blog lately?"

The message sent to Robert will replace the token with his nick-name, and it will say:

"Dear Bob, have you seen our blog lately?"

Awesome, but since Coleman doesn't have a nick name, his message will say:

"Dear , have you seen our blog lately?"

Oops. No name got printed. Wouldn't it be nice if that token could have defaulted to first_name if nick_name was missing? There's also the case of a contact that didn't have a first name or a nick name (sometimes happens with newsletter sign-ups, when all we get is an email address). In that case it would have been nice to say "Dear Friend." Enter hook_civicrm_tokenValues to the rescue! Here's some code that does just that:

function hook_civicrm_tokenValues(&$values, $cids, $job = null, $tokens = array(), $context = null) { $contacts = implode(',', $cids); $tokens += array( 'contact' => array(), ); // Fill first name and nick name with default values if (in_array('first_name', $tokens['contact']) || in_array('nick_name', $tokens['contact'])) { $dao = &CRM_Core_DAO::executeQuery(" SELECT first_name, nick_name, contact_type, id FROM civicrm_contact WHERE id IN ($contacts)" ); while ($dao->fetch()) { $cid = $dao->id; if (!($values[$cid]['first_name'] = $dao->first_name)) { $values[$cid]['first_name'] = $dao->contact_type == 'Individual' ? 'Friend' : 'Friends'; } if (empty($values[$cid]['nick_name']) || $dao->contact_type != 'Individual') { $values[$cid]['nick_name'] = $values[$cid]['first_name']; } } } }

A couple things to notice in this code: Prior to version 4.1 the first two params ($values and $cids) were the only ones available. The biggest shortcoming of that was that it was impossible to know if particular tokens were even called for. Now we have the $tokens param which tells us exactly what tokens are in the message. That's critical for allowing us to do fancy things with tokens only when needed, without bogging down every single message the system ever sends! You'll also notice that we were able to process all the contacts in bulk with a single query - much faster than calling the api once per contact! And since large mailings are prone to timeout anyway, it's important to not add any unnecessary overhead.

Beyond Existing Tokens

Just because core CiviCRM tokens are all database fields doesn't mean yours have to be. Here's a simple example of tokens for today's date (useful for form letter templates). First define your new tokens with hook_civicrm_tokens, then fill their values with hook_civicrm_tokenValues:

function hook_civicrm_tokens(&$tokens) { $tokens['date'] = array( 'date.date_short' => 'Today\'s Date: mm/dd/yyyy', 'date.date_med' => 'Today\'s Date: Mon d yyyy', 'date.date_long' => 'Today\'s Date: Month dth, yyyy', ); } function hook_civicrm_tokenValues(&$values, $cids, $job = null, $tokens = array(), $context = null) { // Date tokens if (!empty($tokens['date'])) { $date = array( 'date.date_short' => date('m/d/Y'), 'date.date_med' => date('M j Y'), 'date.date_long' => date('F jS, Y'), ); foreach ($cids as $cid) { $values[$cid] = empty($values[$cid]) ? $date : $values[$cid] + $date; } } }

That was really easy since we neither had to look anything up in the database, nor give each contact a different value. But it can also get way more complex.

Advanced Usage: Contribution Thanks

It always felt like there was a missing piece in CiviCRM in terms of a workflow for sending thank-you letters for donations. Thanks to some fancy custom tokens, I've finally plugged that leak. Here's my new flow:

1. Use advanced contact search to find all contacts who have donated but haven't yet been thanked
2. From the search results, choose "PDF letter"
3. Compose a message (using that nice "date" token at the top, and our smart name token)
4. Insert another token at the bottom which generates a table of recent (unthanked) contribuions
5. Generate a test letter. If I'm happy with it, I'll add a final token which updates those contributions and sets their thank-you date to today

Here's the code for those new tokens:

function hook_civicrm_tokens(&$tokens) { $tokens['donor'] = array( 'donor.unthanked' => 'Donations: To Thank', 'donor.set_thank_you' => 'Donations: MARK AS THANKED', 'donor.clear_thank_you' => 'Donations: CLEAR TODAYS THANKED', ); } function hook_civicrm_tokenValues(&$values, $cids, $job = null, $tokens = array(), $context = null) { // Dontation info for contact and spouse if (!empty($tokens['donor'])) { $spouses = array(); $contacts_and_spouses = $cids; $dao = &CRM_Core_DAO::executeQuery(" SELECT contact_id_a, contact_id_b FROM civicrm_relationship WHERE relationship_type_id = 2 AND is_active = 1 AND (end_date IS NULL OR end_date > CURDATE()) AND (contact_id_a IN ($contacts) OR contact_id_b IN ($contacts)) "); while ($dao->fetch()) { if (!in_array($dao->contact_id_a, $contacts_and_spouses)) { $contacts_and_spouses[] = $dao->contact_id_a; } if (!in_array($dao->contact_id_b, $contacts_and_spouses)) { $contacts_and_spouses[] = $dao->contact_id_b; } if (in_array($dao->contact_id_a, $cids)) { $spouses[$dao->contact_id_b] = $dao->contact_id_a; } if (in_array($dao->contact_id_b, $cids)) { $spouses[$dao->contact_id_a] = $dao->contact_id_b; } } $contacts_and_spouses = implode(',', $contacts_and_spouses); // Clear today's thank-yous (a kind of crude UNDO) if (in_array('clear_thank_you', $tokens['donor'])) { CRM_Core_DAO::executeQuery(" UPDATE civicrm_contribution SET thankyou_date = NULL WHERE is_test = 0 AND contribution_type_id = 1 AND contribution_status_id = 1 AND DATE(thankyou_date) = CURDATE()" ); } if (in_array('unthanked', $tokens['donor'])) { $dao = &CRM_Core_DAO::executeQuery(" SELECT cc.contact_id, cc.total_amount, cc.receive_date, cc.check_number, con.display_name, hon.display_name as honoree, pi.label AS payment_instrument, ht.label AS honor_type FROM civicrm_contribution cc INNER JOIN civicrm_contact con ON con.id = cc.contact_id LEFT JOIN civicrm_contact hon ON hon.id = cc.honor_contact_id LEFT JOIN civicrm_option_value ac ON ca.account_18 = ac.value AND ac.option_group_id = 103 LEFT JOIN civicrm_option_value pi ON cc.payment_instrument_id = pi.value AND pi.option_group_id = (SELECT id FROM civicrm_option_group WHERE name = 'payment_instrument') LEFT JOIN civicrm_option_value ht ON cc.honor_type_id = ht.value AND ht.option_group_id = (SELECT id FROM civicrm_option_group WHERE name = 'honor_type') WHERE cc.is_test = 0 AND cc.contribution_type_id = 1 AND cc.contribution_status_id = 1 AND cc.contact_id IN ($contacts_and_spouses) AND cc.thankyou_date IS NULL ORDER BY cc.receive_date" ); $header = ' <table class="donations"> <thead><tr> <th>Date</th> <th>Donor</th> <th>Amount</th> <th>Paid By</th> <th>Notes</th> </tr></thead> <tbody>'; while ($dao->fetch()) { $cid = $dao->contact_id; $row = ' <tr> <td>' . date('m/d/Y', strtotime($dao->receive_date)) . '</td> <td>' . $dao->display_name . '</td> <td>$' . $dao->total_amount . '</td> <td>' . ($dao->payment_instrument ? $dao->payment_instrument : 'In Kind') . ($dao->check_number ? ' #' . $dao->check_number : '') . '</td> <td>' . ($dao->honoree ? "<br />{$dao->honor_type} {$dao->honoree}" : '') . '</td> </tr>'; if (in_array($cid, $cids)) { $values[$cid]['donor.unthanked'] = woolman_aval($values[$cid], 'donor.unthanked', $header) . $row; } if (isset($spouses[$cid])) { $values[$spouses[$cid]]['donor.unthanked'] = woolman_aval($values[$spouses[$cid]], 'donor.unthanked', $header) . $row; } } foreach ($cids as $cid) { if (!empty($values[$cid]['donor.unthanked'])) { $values[$cid]['donor.unthanked'] .= '</tbody></table>'; } } } if (in_array('set_thank_you', $tokens['donor'])) { CRM_Core_DAO::executeQuery(" UPDATE civicrm_contribution SET thankyou_date = NOW() WHERE is_test = 0 AND contribution_type_id = 1 AND contribution_status_id = 1 AND contact_id IN ($contacts_and_spouses) AND thankyou_date IS NULL" ); } } }

Notice that the code actually takes it a bit farther and also looks up the person's spouse, if they have one, and their donations, so that we can send one thank-you letter to a couple instead of two. We have our postal greeting populated with both names (thanks to, you guessed it, another hook), which makes it easy to address a letter to a couple without having to mess with households.

Updating your database with a token is maybe not the best all-around practice, but I liked the simple elegance of having donations marked as thanked upon printing a thank-you letter. Also notice that I created a third token to clear all thank-you dates which were set to today, a kind of undo in case something goes wrong and the letters need to be reprinted.

The List Goes On

We're also now using these hooks to:

• Create a "formatted address" token, also great for form letters
• Print a student's transcript - generating a table with a row for each course - from a multi-valued custom fieldset
• Create a token for "parents names" "parents addresses" and "emergency contact" pulling the relevant info from related contacts
• Lookup and print the dates a student attended our school and their graduation status

You can do just about anything with custom tokens. Use your imagination!

CiviCRM had a very successful year in 2011. The project grew significantly in different areas and we made progress on a few long standing issues. The biggest change in our opinion is the increase in community involvement across all aspects of the project.

 

• We had 1 major release  which supported Drupal 6, Joomla 1.5 (v3.4) and Drupal 7, Joomla 1.6 (v4.0). We also had 13 minor releases in 2011. A chart of the types of organizations using CiviCRM can be found here along with the usage of various components.

• We held the 2nd North America CiviCon in Chicago which was organized by Young-Jin Kim from  Emphanos. The 1st CiviCon Europe was held in London and organized by Michael McAndrew, Third Sector Design and David Moreton, Circle Interactive. Each of the conferences had 100+ attendees. We also held user and developer training, and code sprints around these conferences

• We held 9 book, code and test sprints in 5 countries: US, Canada, UK, Netherlands and Belgium. We had more than 100 participants that attended and contributed at the sprints. A significant percentage of sprint participants have become engaged as code contributors with bug fixes and enhancements.

• We raised more than USD 100,000 from the community for various CiviCRM Make It Happen campaigns. This resulted in significant usability and scalability enhancements to the core as well as to Membership, Event and Contribution modules.

• In 2011, we got foundation support from Open Society Institute - OSI, Yellow Dog Foundation and Chintu Gudiya Foundation.

• We had a total of 63 events (sprints, meetups and trainings) coordinated at civicrm.org across North America, Europe and Asia. A large part of these events were community organized meetups. Meetups were held in multiple cities in the US and UK.

• We updated the FLOSS Manuals CiviCRM User and Administrator  Book to match the latest release. We also published a new book in collaboration with FLOSS Manuals: CiviCRM developer guide. A commercial book: Using CiviCRM was published by Packt publishing.

• We added WordPress integration to CiviCRM in v4.1. This helps us with expanding our target audience. WordPress is the most pervasive and fastest growing open source CMS.
• Idealware and NTEN Donor Management Study recognized CiviCRM as a Top 10 Solution for Nonprofits in their 2011 study: A Consumers Guide to Low Cost Donor Management Systems in 2011. We also got a good rating in NTEN’s 2011 Nonprofit Data Ecosystem Report. Idealware is a 501(c)(3) nonprofit, provides thoroughly researched, impartial and accessible resources about software to help nonprofits make smart software decisions.
• We had five active community led teams:

1. Documentation led by Michael McAndrew.
2. Marketing and Publicity led by David Moreton.
3. API Team led by Xavier Dutoit, Eileen McNaughton and Erik Hommel.
4. Views Integration led by Jim Taylor.
5. Webform Integration led by Coleman Watts.

• Members of the community also played a leading role in various other projects

1. Brian S and NYSS resulted in major new scalability, usability and stability improvements
2. Progressive Technology Project, Will Brownsberger and Xavier Dutoit  enhanced CiviCRM's support for campaigns, surveys and petitions.
3. Jane and Craig from Rayogram are helping with the launch of a new "user centric" website in early 2012

• The CiviCRM consulting ecosystem grew significantly in 2011.

1. We now have multiple hosting providers that are specializing in CiviCRM. CiviHosting in the US, Koumbit in Canada and CiviSites in the UK.
2. Progressive Technology Project supports 40+ installs on CiviCRM
3. The New York State Senate supports 62+ senators on their network
4. Electronic Frontier Foundation and Free Software Foundation are two prominent open source foundations that started using CiviCRM in 2011. They join the Wikimedia Foundation and Creative Commons.
5. CiviCRM is being used by a fair number of political campaigns at the national, state and local in the run-up to the 2012 US elections. In other countries, the Green Party, Democrats Abroad, Pirate Party and Socialist Party all continue to expand their usage of CiviCRM.