CiviCRM 201 - Getting the Most Out of the Platform

CiviCRM 201 Direction of project is toward sustainability models: expanding the base of people contributing code, documentation, testing, financial support. Looking to strengthen the Civi ecosystem.

4.1 release has 12 new features that were successfully funded. Long-term project: CiviAccounts, strengthening the accounting functions. Funded by several different organizations and being worked on by several consultancies outside the core team. Not meant to DO accounting but meant to track info that is granular enough to put into accounting programs, and also to support workflows that support more complex financial transactions. Also build out ability to track partial payments (use case: long term $1K membership that people pay for in chunks).

Long term project: aggregating folks into teams who then take responsibility for large parts of the infrastructure. Example: documentation. Through book sprints, three manuals have been produced and there is a team that takes ownership of that and the process of keeping it up to date. Also consolidating the documentation resources for Civi and bringing together administrator, user, and developer info and clarifying the roles of the wiki vs manuals. Wiki will be for more technical stuff and errata; there will be a sweep process to get things into the book that belong in the book. Also looking to make the work more distributed and less sprint based to enable more folks to be involved/get more done.

API team: re-engineered the API. API Explorer lets you select from record types and method types and lets you run an API statement. Making the API really consistent and producing self-documentation, ensuring proper levels of permissioning and security for balance of access and security.

Conference organizing: CiviCon London was completely organized by folks outside the core team.

Code sprints are making a big difference, it’s been a great way to teach other developers and integrate them into the project. More effective than previous developer trainings. Number of patches and code contributions coming from outside the core team has skyrocketed.

Other initiatives: - New website, a little stalled but now back on track; will be a good marketing tool for project: case studies, ways to find an expert, other resources. - More online tutorials (will be part of website) - Extensions framework/directory to include Drupal etc modules, payment processors, etc as extensions to make them more accessible to users. Not yet decided how curated this will be. Current thinking is a rating system. Extensions will be packaged to install so the core team will monitor. Things that are modules installed through the CMS will be more community curated.

Hard discussions re quality and stability over the last 3-4 months. People have been expressing concerns about bugs. Hope is that getting more folks involved in testing is the solution. Also in the past 6 months the core team has lost some discipline in holding new features to a high standard of quality. Some of this is funding pressure, the folks who have funded a feature need it NOW. The plan is to refrain from putting big new stuff into minor releases.

New Drupal developments: -Developing Drupal 6 connectors so that 4.1 will support Drupal 6. Just treating D6 as any other CMS since 97% of the code is the same. Hope is that D6 zealots will test the 4.1 release heavily and contribute patches back.

Website integration: No big changes in core about how integration works because it already works well. Having people keep their own info updated is just about creating a profile with that info and get people to log in and offering people that profile in the context of their account. Orgs for whom that’s a value will send an email blast on whatever schedule works for them. That mechanism can also work for people who resist having a login by using a checksum token. When you create the email asking people to update their info, you can use the token helper and add the checksum token to the link that they will be using to update their info. This will bring the user directly to their own profile without having to log in, using temporary authentication. The token is good for 7 days. This can also be used for event registration. This has been in place for quite a while.

Drupal module called Views which exposes blocks of info and there’s integration that allows you to use views with Civi—a little slicker than using the profile function in Civi, looks more native to your website. Good for event listings. Would be interesting to play with making them editable fields but as far as anyone on the session knows this has not been worked on yet.

Another integration module that has grown up a lot is the webform_civicrm module. You can use that to build more complex forms: multipage and editing different records (contact, event, activity, etc). Profiles are only single page, single object. Web form not CCK because we know where the data is and where it goes back, no new structure needed. Web forms meet more use case needs.

Rumors of mobile access. PTP wants to organize the building of this feature. Someone’s brother who is working on a degree computer engineering needs a big project to do and he is interested in working on it. This is not the way things are usually developed but it could be a good way to go in this case. This is being explored.

Other things going on with Events: -4.1 will have the ability to create scheduled reminders around events and integrate with CiviMail to send them out. Prescheduled communications directed at different roles/statuses (registered, speakers, etc) can go out. 4.2 will be extended to cover memberships.

-Having users edit registration data after they have registered is not there yet; this is particularly needed for group registrations. Waiting list and incomplete registration workflow is there. Mark has a client that needs this and is interested in working on it and pulling in some funding from there. Dave suggests exploring the web forms module to see if that functionality can meet the need. Mark will look into it and tell Dave what he finds.

-Someone had a need for personal campaign pages to interact with Events as well as Contributions and that code will be in 4.1. Use case: Event was mountain climb fundraiser. Only small number of participants, but many donors and so now they can be tracked to the event in addition to the donor. -Giant Rabbit built a cart-based registration center for Compasspoint and this will become part of 4.1 if it works. Will be a light-switch in CiviEvent to turn the cart system on and off. -3.4 release had the enhancement of adding price sets to membership. This is kind of a pseudo shopping cart approach.

A lot of work happening around cron jobs. Growing collection of scripts around Civi that do automated tasks; managing those for integrators and hosts has become more and more onerous. New in Civi 4.1 streamlines this and adds it to the API. Turn on the cron file and have a way of configuring. Should make it easier for people.

More stuff in new release: -WordPress integration -Improvements to Campaign interface and workflow.

4.1 will release in early January. It’s in code freeze now and will go to alpha shortly.

Questions: -Class series as events: want to be able to track attendance at individual classes in a series and whether they passed the class as a whole. Multiple session classes are still hard to do in Civi. Some folks are working around this but politics are difficult and it’s not clear what’s happening. Ways to contribute:

-Clients who need training can contribute to existing efforts to make video tutorials. PTP planning on doing screencast sprints