Ginkgo Street Labs is pleased to announce the availability of CiviVolunteer 2.2.

Two themes are evident in this release: improving stability and furthering the multi-tier use case. The increased adoption of CiviVolunteer as a multi-tier system, where one organization facilitates the volunteer programs of partner organizations, has necessitated improvements to permissions granularity as well as streamlining of interfaces. Improvements in CiviVolunteer 2.2 include:

• Version 2.1 introduced settings for volunteer project defaults under Volunteers > Configure Volunteer Settings. Version 2.2 builds on this work, adding the ability to set defaults for a project's manager, beneficiary, and other relationships.
• New permissions Edit Volunteer Project Relationships and Edit Volunteer Registration Profiles provide an easy way for site administrators to simplify the volunteer project creation workflow for partner organizations or less technical staff. Users who don't have these permissions won't see the relevant configuration options during project creation/edit; their projects will use the site-wide defaults for these configurations.
  
• Fifteen bug reports were closed in the production of CiviVolunteer 2.2, and lessons learned in the adoption of the Angular paradigm applied under the hood, to improve system reliability. VOL-267 is a particularly nasty bug that can result in accidental mass deletions of project data; upgrading to CiviVolunteer 2.2 is strongly recommended to eliminate this possibility.
• Increased support for using custom fields as columns and filters in the volunteer report.

Notes for Developers

• CiviVolunteer 2.2 changes the return of api.VolunteerUtil.getsupportingdata; the array relating to project relationships is structured differently, significantly simplifying the code required to consume it on the client side. We don't expect this API was being used downstream, so it is unlikely this change will have practical implications for anyone.
• The result of api.VolunteerProjectContact.get previously included a flag can_be_read_by_current_user for each contact. This has been removed.
• api.VolunteerProject.create now creates a flexible need for new projects. Previously this required a separate call to api.VolunteerNeed.create. To mitigate problems for downstream developers expecting to need to make this call, api.VolunteerNeed.create now throws an exception if the call would result in the creation of a second flexible need for a given project. More details in VOL-269.

Installation

CiviVolunteer can be downloaded from the CiviCRM extensions directory or installed from within CiviCRM from the Administer menu, under System Settings > Manage Extensions (some systems may have it under Custom Data and Screens > Manage Extensions). You'll also need to install version 1.0.1 or later of Angular Profiles– a utility extension which helps the Angular and Backbone JavaScript frameworks play nicely together – in order for CiviVolunteer to function properly. If you're currently using CiviVolunteer, the new version should be available as an update on the Manage Extensions page.

Thanks

Thanks to everyone who has contributed to CiviVolunteer through financial support, code, bug reporting, testing, and documentation.

This little story about financial transactions has a couple of objectives:
1. share what we want to do for the benefit of each and everyone
2. find out if there are more organisations out there that would be interested
3. even better, organisations out there that want to co-fund and influence!

If you are interested and want to co-contribute, drop either Björn (endres@systopia.de) or me (erik.hommel@civicoop.org) a mail!

At the moment CiviCRM allows for the linking of a financial account to the financial type as a basis for data exporting to whatever software you are using for accounting. You can also attach an asset type financial account to a payment instrument. When creating, updating, cancelling or refunding a contribution the financial 'traffic' between the configured financial accounts is nicely recorded in the financial transactions table. We are not sure yet if changing the payment instrument also create nice financial transactions. All good stuff when exporting your financial transactions to accounting!

However, at Amnesty International Vlaanderen we do not have an account per financial type. We have income accounts per financial type/payment instrument/campaign. And we have cost accounts that go even a level deeper: they also look at the timeframe (so a different cost account (cocoa) when a campaign acquisition is in the actual acquisition year of the campaign or later. So the core CiviCRM functionality is not enough, although it is a good start. We need to be able to generate financial transactions at a more detailed level to be able to use the accounting batches in CiviCRM.

Youth for Christ UK has a similar problem. Here the correct financial account is determined mostly by a contribution's campaign – with a few exceptions. And the original account is not only determined by the payment instrument, but also the bank account involved.

So we want to develop something that will allow us to:

• disable the creation of financial transactions completely. In a lot of cases there will be CiviCRM customers that do not use the financial transactions at all, and at the moment CiviCRM will then do a lot of creation and use system resources for absolutely nothing. So I should be able to switch it off. I should also be able to say I only want it to process for certain financial types, campaigns, payment instruments etc.
• create some kind of hook or something that allows me to replace the 'standard' calculation of financial transactions based on financial accounts linked to financial types to a customized calculation and configuration.
• configure the accounts in a way required for Amnesty International Vlaanderen. So I should be able to link a P/L account, a cost account for the acquisition year and a cost account for the following years to a campaign.
• create financial transactions based on this specific account configuration. As CiviCRM uses contributions as the key financial item (for donations, membership payments, event payments and if I would create an extension that allows the selling of promotional items I would probably add a contribution of a specific financial type too) I would create those financial transactions whenever a contribution is added, updated or deleted.

This mainly details the Amnesty requirement, but Youth for Christ UK has very similar needs and will contribute to the development budget! As can be expected, that is why that will be a specific extension for each case :-). We want to have as little impact on core as possible, and enable everybody to create their own flavour!
 

Techy stuff

After some conceptual discussion (and Björn still working on the technical details and possibly changing everything again) we think we need to do only one core change at this point. This change will add a configuration setting to the CiviContribute Component settings generate financial transactions (name = generateFinancialTransactions) with the options:

• none (which should lead to no financial transactions being generated whatsoever)
• default (the default behaviour as we all know and love)
• customized (your specific generation, which should implement the post hook on Contribution)

In the specific extension we will implement the post hook, check if the entity is Contribution, check if the setting is 'customized' and do our stuff. Obviously, if the above setting is set to 'none', the extension  shouldn't create any transactions either.

Oh yes, we do have a basic GitHub fork where we will be playing around: https://github.com/systopia/civicrm-core/tree/dev_txhooks_4.6.24

• End users and site admins: easier to find, select, and install the right extension
• Extension developers: easier to publish extensions and set clearer expectations for support and maintenance, and easier to avoid duplicating existing extensions
• Community volunteers: easier to conduct extension reviews and help them get qualified for automated distribution

cv (https://github.com/civicrm/cv) and civix (https://github.com/totten/civix) are Unix/CLI tools for developers. cv provides access to your Civi site on the command line, and civix generates skeletal code for new extensions. We've had a few recent updates to each of these tools, so I wanted to introduce cv more formally and then recap some of recent improvements for each tool.

cv: Introduction

cv originated as part of the Testapalooza project which broadened support for automated tests in CiviCRM -- testing of CiviCRM extensions or external integration modules; testing with PHPUnit or Behat or Codeception; testing for headless scenarios or end-to-end scenarios; ad nauseum. In all of these cases, we start with some existing PHP tool (such as phpunit) and mix-in Civi+CMS.

For example, if you have cv installed, then your other PHP programs can start CiviCRM with one line:

eval(`cv php:boot`);

Overall, cv enables you to run PHP code in Civi using four different flows:

• Generate boot code (cv php:boot): Generate PHP code for booting your CiviCRM instance. You can use this code inside another script, such as phpunit or codecept.
• Evaluate PHP snippet (cv php:eval [snippet] aka cv ev [snippet]): Evaluate a small snippet of PHP code within your CiviCRM instance.
• Execute PHP script file (cv php:script [file] aka cv scr [file]): Execute any PHP script file within your CiviCRM instance.
• Interactive command line (REPL) (cv cli): Open an interactive prompt where you can enter several PHP statements. (This is based on the incredible Psysh tool.)

It also includes a few sub-commands which can be useful for writing tests:

• Call APIv3 (cv api): Execute an API call. Inputs and outputs may be encoded as JSON.
• Lookup a URL (cv url): Lookup the URL for any Civi page, with suitable adjustments to match the current CMS and domain.
• Export configuration (cv vars:show): Export data about the DSN, URL, and demo users.

cv is similar to drush, wp-cli, or joomla-console in that it provides CLI access to a CiviCRM installation. However, it differs in that:

• You don't need to know which CMS is being used.
• The sub-commands are focused on Civi features (such as APIv3 and extensions).

cv: Recent improvements

• Extension management: To administer CiviCRM extensions (e.g. downloading, enabling, disabling, uninstalling), use the new sub-commands like cv dl [extension-name]. See PR #4 for more complete details.
• Joomla support: cv should now work better with vanilla Joomla environments. Special thanks to Andrew Hunt for fixing and testing this.
• Verbose boot: If cv doesn't boot correctly in your environment, pass -vvv to display more verbose information. Special thanks to Erich Schulz for initiating this.
• NodeJS library: If you develop enhancements for CiviCRM using NodeJS tools such as grunt or protractor, then you may occasionally need access to CiviCRM paths, URLs, databases, or demo users. Instead of hardcoding these details, you can use the library civicrm-cv (https://github.com/civicrm/cv-nodejs) to get programmatic access.

civix: Recent improvements

• Joomla support and verbose boot: Some civix sub-commands use cv to access your local CiviCRM instance. The cv improvements initiated by Andrew and Erich also improve civix.
• Manipulate "info.xml": If your extension has a custom build process, then your build scripts might need to access the version, releaseDate, or other properties of info.xml. Use the new sub-commands civix info:get and civix info:set.
• Extension versions are domain-independent: The civix upgrader traditionally stored a version number in civicrm_setting. However, this did not work well in multi-domain configurations. The upgrader now tracks the version in civicrm_extension. Special thanks to Frank Gomez for initiating this.
• Smarty for SQL Upgrades: In CiviCRM core, SQL upgrades are processed via Smarty. This allows them to adjust dynamically and to handle multilingual schema. The civix upgrader now supports both static SQL files (executeSqlFile(...) or sql/auto_install.sql) and Smarty-based SQL templates (executeSqlTemplate(...) or sql/auto_install.mysql.tpl). Special thanks to Sunil Pawar for initiating this improvement.
• Multiple cleanups: Several templates have been updated to improve docs and code-style. These are non-functional changes and don't impact existing extensions -- but for new extensions, the code should validate better in civilint or Drupal coder. Special thanks to Coleman Watts for initiating these changes.

Note: If you'd like to upgrade an existing extension with newer templates from civix, see UPGRADE.md.

General notes

• Downloading: If you use buildkit, run civi-download-tools to get the latest releases. Otherwise, see download instructions at https://github.com/civicrm/cv and https://github.com/totten/civix.
• Built-in help: Both cv and civix have built-in help screens to list sub-commands and arguments.
• Only tested with Linux/OS X: Both cv and civix are command-line PHP tools. They are distributed as platform-independent executables (PHAR), but they are only tested in certain builds of Linux and OS X. They may or may not work well on Windows -- in either case, trying them on Windows will require more skills/experience with Windows PHP CLI. If you'd like to improve Windows support, please open a pull-request on Github.
• Only tested with basic civibuild configurations: CiviCRM can be deployed with many system configurations using techniques like symlinks, multiple URLs, dynamic database credentials, and so on. However, these techniques often impact the bootstrap process, and we cannot test every possible configuration. cv is only tested with the civibuild configurations like drupal-clean and wp-demo. If you'd like to improve support other configurations, please open a pull-request on Github.

JMA Consulting is pleased to welcome Jon Goldberg as our new Director of Operations effective today.

After a brief stint as a political organizer, Jon spent 13 years working in various capacities at a non-profit legal organization, primarily in IT.  In 2010 he co-founded Palante Technology Cooperative and started their CiviCRM department, where he worked for 7 years.  Outside of work, Jon can be found engaging in queer community organizing, (dis-)assembling electronics, and training parrots.

"I'm really excited to have Jon join us given his keen appreciation of how to help progressive organizations achieve their missions using CiviCRM. He's got a deep and wide knowledge of CiviCRM. I appreciate how he gives back to the community like through StackExchange, where he is the top ranked CiviCRM contributor," said Joe Murray, President of JMA Consulting and co-author of Using CiviCRM.

Jon's new role will include leading client engagements, developing standardized service offerings, overseeing internal business administration, and continuing to contribute to the CiviCRM ecosystem.

JMA Consulting is a leading provider of CiviCRM services including:

• CiviCRM for advocacy and donor management,
• software development for extensions and core CiviCRM,
• data migration from NationBuilder and other CRMs, and
• custom integrations with Drupal and Wordpress sites.

My clients regularly need to import data from sources such as Just Giving, CAF, and various other sources like Mailchimp downloads. The problem they had was that the data was a mix of contact and contributions, and some of the rows belonged to new contacts, others belonged to existing contacts. Sometimes they had a scrappy list of names and emails where the name was all in one field instead of split out. You know the sort of thing.

At the time (a few years ago) I knocked together a Drupal module to help pre-process this data so that it could be used efficiently with CiviCRM's built in import functions. I made it in Drupal because that was quickest for me to develop a solution and they used Drupal, but I've now re-written it as a native CiviCRM extension that should work for Drupal users, and the ever proud and cheerful (but wrong) Wordpress fans alike. Maybe even Joomla. ;-)

How does it help me?

It takes your spreadsheet (in CSV format), uses a mix of automated look-ups and human interaction to efficiently find the right contact for the rows, and returns a new CSV spreadsheet that now includes a CiviCRM Internal ID column at the start. The result of this is you have a new CSV spreadsheet that will feed really efficiently and accurately into CiviCRM's well-developed build-in import routines for Contacts, Contributions, Activities, and any others.

The tool groups the data received by names and emails, so for example if you have a spreadsheet with 100 records but there's only 20 different names used (such as several contributions from the same person), you'll only have to deal with 20 records.

Example screenshot:

Interested?

Well I've written full documentation including a worked example, so take a look. It's also listed in the CiviCRM extensions listings, although it won't appear in the one-click-installable extensions in your own CiviCRM installations yet because I don't want to call it 'stable' until it's had a bit more real-world use. The Drupal version has been in use for a few years, but this is a re-write and a lot has changed.

Backup your database before trying any new extension. This extension does not alter any existing data in CiviCRM, so it should be safe to play with, with the exception that if you click the "Create New Contacts" button, it will do just that.

If you get on with it, drop me a happy comment below - I'll release it as stable and make it available through the automated distribution thing (the one-click install extensions page) if/when it looks like it's working well. If you find a problem, please submit an issue. If you have a feature request or suggestion pls. see wishlist.

The CiviCRM extensions community is thriving. Presently there are 270 extensions listed in the Extensions Directory and countless more scattered around the Internet in GitHub repos and the like. Last year, 35 extensions were submitted for review in 2016, a 400% increase from 2015!

Unfortunately, only about 50 extensions are available for one-click installation within CiviCRM. The sharing of code is central to the ethos of our community, but our ability to reap the benefits of collaboration depends on our ability to communicate about our efforts. Increasing the number of extensions available for in-app installation will lead to:

• increased attractiveness of CiviCRM as a platform, since new functionality is just a click away (à la Wordpress); and
• less duplication of effort (last year I developed an extension that largely duplicated another partner's work because I didn't know their extension existed).

The Plan - i.e., How You Can Get Involved

Extension Developers

The volunteers who make up the Extensions Working Group have developed a process for requesting automated distribution of an extension. Extension developers, please make sure your request for review has been registered according to the new procedure.

Extension Reviewe​rs

The Extensions Working Group is just a handful of volunteers; we cannot satisfy all of the requests for review without your help. Many of the skills required to review extensions are the same ones needed to write them -- if you're an extension developer requesting a review, please consider becoming a reviewer yourself.

To do so, please contact me on MatterMost -- I'm GinkgoFJG -- and send me your Drupal and JIRA usernames. To take advantage of the synergy that comes from many people working on similar tasks at the same time, we will piggybacking on Stoob's idea of Community Fridays and organizing virtual extension review sprints on February 17th and 24th.

With enough volunteers, I'm confident we can clear the 2016 backlog of extension review requests this month.

Some of you will know, use and might even love the CiviRules extension. We certainly do! Quite a few of the organizations we support with their CiviCRM stuff use and love it, and judging by the question on StackExchange and issues and pull requests on GitHub quite a few more do too!

This is wonderful! But it also means that quite a few organizations are faced with the challenge of keeping CiviRules up to date with the latest CiviCRM versions. And want to make sure the functionality remains the same whenever new upgrades or little fixes to CiviCRM happen. So we think it would be nice if we were able to:

• ensure CiviRules is compatible with the latest and greatest core CiviCRM
• add a bunch of automated unit tests to CiviRules that would be run together with the core automated tests so we immediately know about bugs or software conflicts when something changes in core.

To make this possible we need funding. Initially some funding to make sure that CiviRules is 4.7 compatible and add a few unit tests, and ideally funding to continue doing this. We have contacted the organizations we know use CiviRules, and already have some commitment from a couple to start work on the 4.7 part. However, we know there are more CiviRules users out there! And there is a big chance you are interested in keeping CiviRules up to date and also in having it be part of the automated testing. And you might be willing to contribute to make this happen. If this is the case, drop either me (erik dot hommel at civicoop dot org) or Jaap (jaap dot jansma at civicoop dot org) a mail? Once we have an idea of the actual organizations interested we can plan ahead and think of ways of managing this (probably a fund that is administered by one of the interested organizations).

Before I started working as a CiviCRM consultant, I was a CiviCRM user at a small nonprofit. We got a large chunk of our revenue through grassroots donations, but we never had an opportunity to see how we compared to other organizations like ours.

(TL;DR – you should install the Individual Donor Benchmark Survey extension, run the report, and submit your survey response.)

Nowadays, some proprietary donor databases collect users’ data and publish reports, but besides being creepy, they can’t get good data without involving organizations directly. They also only cover users of a single software system.

Besides, how do you know the data covers organizations like yours?

The Individual Donor Benchmark Survey was developed by Third Space Studio to address these problems by producing a voluntary survey of nonprofit organizations in the United States with revenues under $2 million. The survey covers fundraising totals, offline vs. online giving, one-time and recurring gifts, and the organizations’ resources devoted to fundraising. (You can download last year’s report here.)

It is a lot of data, but we’ve got a tool to help.

AGH Strategies, a sponsor of the survey, has produced a CiviCRM extension that crunches the numbers for you, giving you all the survey answers that CiviCRM can provide. You only need to answer one question: which financial types count as donations as opposed to other revenue (such as grants or service fees).

When you complete the survey, you’ll be on the list to receive the report for this year, but that’s not all: you’ll be contributing to a resource for all small nonprofits to use, and you’ll help make sure CiviCRM is well-represented in the results.

Run the Individual Donor Benchmark Survey extension today to join in the effort!

CiviCRM Entity is a contributed module for tightly integrating and extending CiviCRM with Drupal. This module exposes CiviCRM API entities as proper Drupal entity types. This is HUGE as it allows you to make CiviCRM data available within your favorite Drupal tools such as Rules, Views, and EntityReference. I’d like to present another advantage of Drupal entity types, and that is Drupal fields.

By enabling CiviCRM Entity, you can add Drupal fields and associate with CiviCRM entity types such as Contacts and Events. In fact, any of the hundreds of Drupal field types can be used with CiviCRM Entity.  You may be asking yourself, “Shouldn’t I use a CiviCRM custom field? Why would you want to use Drupal fields?” The correct answer is, you should choose the right tool for the job.

CiviCRM is great at having the business logic and infrastructure to support event registrations. CiviCRM has price sets, price fields, and custom fields for collecting information from users when they register for events, as well as the logic and structure that goes with payment processing and financial accounting. You would want to use a CiviCRM custom field to collect data for a specific user. This will be helpful because they data can be accessed via Reports.

Drupal, on the other hand, is much better at organizing and presenting content than CiviCRM. There are tons of modules that can be leveraged to give you the functionality you desire. Need a mobile responsive slideshow? Add a Drupal Image field, configure it to work with Flexslider slideshow. Images are perfect example of picking the right tool for the job. The images in the slideshow for an event is not related to any data that someone may need for reporting, so there is no point to make it a custom field in CiviCRM, so let Drupal do what it does well, store and present this kind of data.

What do I get out of the box?

When you install CiviCRM Entity, you get Drupal based view page and edit forms for all exposed entities. We will limit our examples to Events in this article, but the same applies for all entity types. You can create, update, and display CiviCRM Events, and never leave Drupal. The view page has the path “<site_root>/civicrm-event/[id]” where [id] is the event id, and <site_root> is the base url of your Drupal website. The edit form is “/civicrm-event/[id]/edit” and new events can be created at “/civicrm-event/add”.

This view page and edit form are “standard Drupal”, meaning that all fields and properties that are displayed can be managed in typical Drupal fashion.  We highly recommend installing the Display Suite (DS) module, and its submodule Display Suite Forms to take full advantage of the possibilities, as you can configure field groups, layouts, and use the provided Display Suite field formatters for many of CiviCRM’s properties. With DS Forms you can also choose to hide properties from the edit form, although you will be forced to include any API required properties.

For more information on how to add and manage fields and managing the Display with CiviCRM Entity, please continue read the full article on Skvare.com.

Download CiviCRM Entity

CiviCRM Entity 2.0-beta7 has been released.

Pick it up now at the Drupal.org Project Page

Changes since beta6:

CiviCRM Entity is close to its stable, non-beta release.  We've had fewer and fewer bug reports each release, and only 1 found in the main module since beta6. Unless something is broken, 2.0 will be cut next.

Development sponsored by Skvare

Thanks to all our contributors and users!

As of CiviCRM Entity 2.0-beta4 the sub module called CiviCRM Entity Price Set Field provides a Drupal field type for the Event entity type.  In this article we’ll review the features of this submodule and discuss how to configure and customize it to fit your needs.

Event Registration on the Event view page

When configured to display on the Event view pages, this field generates a registration form that supports:

• Registering multiple Participants
• Uses the event’s price set and all price fields of any type
• Pay later or credit card transactions utilizing CiviCRM’s payment processing
• Profiles
• Default values for the profile fields corresponding to the logged in user’s contact information
• Customizable Ajax-fied confirmation and thank you panes
• Utilizes the event’s settings such as “Is paid event?” etc..
• Test or Live transactions

Field widget for the Event Edit Form

A “simple” field widget is provided by default for this module.  At the time of this writing, only the first price field can be edited via this widget.  

Getting Started

CiviCRM Entity and CiviCRM Entity Profile are dependencies for CiviCRM Entity Price Set Field. Go to the Drupal module page and enable all three modules and enable CiviCRM Entity Price Set Field, CiviCRM Entity, and CiviCRM Entity Profile.

Once enabled, you can add the Price Set Field to the Event Entity Type.

• Go to the Event Manage Fields form at “/admin/structure/civicrm-entity/civicrm_event”
• Scroll to the “Add New Field” section, enter a Label, and select the ‘CiviCRM Entity Price Set’ field type, for this example select the “Simple -- one price field” widget
• There’s no special field or field instance settings, so just click save until you’re back to the Manage Fields page
• Now go to the Manage Display Full Content form at “/admin/structure/civicrm-entity/civicrm_event/display/full
• Set the new field to display
• There is a field formatter setting to optionally submit test transactions
• Pat yourself on the back, you’re setup to take registrations from the Drupal based Event view pages at /civicrm-event/[id]

Please note that the registration form takes into account the different settings on the CiviCRM Event.  For instance it will only enable CC transactions and render a billing block if the “Paid Event?” checkbox is checked. The form conforms to registration start and end dates, only renders if Online Registration is enabled.  The form checks to see if Max Participants has been reached, even when adding additional participants. Additional participants can only be added if “Allow Multiple Registrations” is enabled.

To learn more about registration form, how transactions work with the Contribution API, and how it can be customized, please continue reading on Skvare.com.

CiviCRM Entity Reference Field is a submodule of the CiviCRM Entity project. One of the many advantages of installing the CiviCRM Entity module is the ability to use Drupal’s Entity Reference module to reference CiviCRM data from nodes, terms, or other entity types. Many people are using the Inline Entity Form module, which provides field widgets that allow you to create, edit, or delete a referenced entity from the parent form.

If you reference CiviCRM contacts via an Entity Reference field and use Inline Entity Form, you’ll often want to include the ability for the user to create or edit subsidiary CiviCRM entity types, such as the email, phone, and address entities. This can get tricky with CiviCRM integration. A regular entity reference field stores a target entity id in a Drupal field table of the Drupal database.  CiviCRM Addresses are stored in the CiviCRM database, and can be created by different types of users and in many different ways. In addition, Drupal and CiviCRM reference data in opposite ways.  Drupal’s field model, “forward references,”  which means the entity stores the ids of the child entities. CiviCRM generally uses “backreferences,” meaning the child entity will store the parent entity’s id.  To make the situation even more interesting, this pattern is not consistently followed in CiviCRM, and you’ll occasionally have a “forward reference”. For example, events store a location block id, and the location block references addresses.

We want the convenient and familiar interface of the Inline Entity Form/Entityreference combination, but we want to use the existing data from the CiviCRM tables, and not store target ids in Drupal field tables, while at the same time being flexible enough to go both ways. We want to make a square peg to fit into a round hole. What we needed was a “remote reference field”.

The Drupal Field API is very powerful, and it allows you to make field types that are disconnected from the standard Drupal field tables. The solution is CiviCRM Entity Reference Field, which adds a new field type that can be added to any CiviCRM entity type.

We’ve successfully used this module for a variety of use cases, including:

• Referencing emails, addresses, phones from contacts
• Referencing participants from events
• Referencing relationships from contacts
• Referencing activities from contacts
• Referencing contacts from activities
• Referencing contacts from relationships

It is also possible to have CiviCRM Entity Reference (CER) fields on entities referenced by CER fields. For example, In CiviCRM, Events reference location blocks, which in turn reference addresses. To edit profiles on Events, you need to reference UFJoin from Events.  The UFJoin entity type needs a UFGroup reference field which needs to reference UFField. That case is especially interesting as that “line of reference” runs both forward and backwards from the UFGroup entity.

That’s the what and the why, to see an example of how to use it, please continue reading this article on Skvare.com.

We’re pleased to announce that the Mosaico extension v2 is finally available to download!*

Mosaico enhances the existing CiviCRM Mailing module to simplify the email creation process by allowing you to use a simple drag and drop mailing editor to create your emails. The Mosaico extension will then produce a responsive (suitable for mobile) and perfectly formatted email for you!

How do I use the new Mosaico?

1.  Mailing

With Mosaico Integration enabled, you will be led to the screen below when you choose to create a new mailing:

Here has everything you need to tell Civi about the mailing you are creating. This includes:

- Mailing name: A name for the mailing so you can recognise it later

- From: this is the email address that is going to be shown as the sender in customer's' inbox

- Recipients: the list of customers you want to send this mailing to

- Subject: subject line of the emails. You can use tokens in this field

- (optional) Campaign: the campaign this mailing is for (if you have CiviCampaign enabled)

- (optional) Reply-to: the custom email address you want any reply to be delivered to (if you have custom reply-to enabled)

When everything is ready, click on 'Continue' to move the the next step.

2. Design

The second step is 'Design'. You can either select an empty template to start fresh with (or you can use a configured templates that you made in advance previously - see the Mailing templates section below). Once a template is selected, the Mosaico template editor will appear.

In the editor, there are a set of designed blocks that can be used to assemble your mailing content. You can change the text, add tokens, insert images, even modify the colour from the style button in the top left!and many more. You can see examples of using this in the animation below:

At any point of the design process, if you want to test the mailing in your actual inbox or preview the content in a web browser to test responsiveness, you can use the 'Test' button on the top of the editor. I t allows you to preview both HTML format and plain text format. You can also send a test mail to an email address or a list of email addresses.

Once hit 'Close' button, your design will be saved to the mailing and you can always come back to edit it or reset it.

3. Options:

This is the last step for creating a mailing. You will be choosing to send the mailing immediately or schedule it to be sent at a desired time and date. The attachments, responses, tracking, and publication options you may have seen in CiviMail are available in 'Advanced Mailing Options'.

If you want to review your mailing before sending it, you can always use the steps in the wizard header to navigate back to the previous steps.

Mailing templates:

For most organisations you will have several email “styles” that you may use for mass mailings such as Newsletters, Campaigns or Member alerts. Rather than needing to configure the look and feel of the email each time you create a new mailing, you can create Mailing Templates using the Mosaico Templates option from the link below:

Here you can select from one of Mosaico’s “base” templates to create your own standard mailing templates for use in your mailings.

Once you have created a template it will then be available for you to select when you go through the mailing wizard above.

The ability to create mailing templates is defined by a separate user permission so you can specify one user role (the administrator for example) who can create and edit the templates, where as the normal users can create mailings (i.e. use that template for a mailing only).

Now onto the techie bit… Installation!

How do I install the new Mosaico?

Requirements:

CiviCRM: Mosaico Integration requires CiviCRM 4.7.16+.

For those who are running CiviCRM 4.6, don't feel left out, there is also a small backport patch that you can apply which allows Mosaico to be used with CiviCRM 4.6.26+.

PHP-ImageMagick: this needs to be set up on the server that your CiviCRM instance is running on. This might require some more technical knowledge. There are many references out there with simple steps to set this up if you know your way around server. e.g. http://php.net/manual/en/imagick.setup.php

Installation:

To install Mosaico Integration, like any other extension, firstly you need make sure your CiviCRM extension directory is correctly configured. You can find some guidance here if you are new to CiviCRM.

If you have already configured the extension paths, simply download the latest versions of the three extensions below from CiviCRM.org Extension Directory into your extension folder and enable them in the following order:

Shoreditch theme**

Flexmailer

Mosaico CiviCRM Integration

(For those taking from github download or clone the latest master of all the above extensions for the latest stable versions).

If you followed the instructions above and have Mosaico Mailing wizard successfully running on your site, very well done! You can now start to create your emails!

One useful note is that you can always still use the old mailing interface if you would like. These can be found at the following urls:

civicrm/a/#/mailing/new/traditional (new mailing with template_type=traditional)

civicrm/a/#/mailing/new/mosaico (new mailing with template_type=mosaico)

civicrm/a/#/mailing/new (new mailing with the default template type; depends on the mix of extensions)

Any draft mailings created with the old mailer will still continue to use the old mailing interface.

We will also be making the extension available for automated download from within CiviCRM soon but the extension is currently in final beta and we welcome feedback and bug reports on the github: https://github.com/veda-consulting/uk.co.vedaconsulting.mosaico.

** The Shoreditch Theme

You probably also have noticed that Mosaico wizard has a slightly different visual style than the rest of Civi. This is because Mosaico is one of the first CiviCRM extensions to use the new Shoreditch Theme extension. This extension defines a new look and feel for CiviCRM which is mobile responsive and also akin to the design material design language (see here for more information about that (https://civicrm.org/blog/jamienovick/extreme-makeovers-civicrm-style-introducing-the-shoreditch-theme-civicrms-new-user).

Although you need the Shoreditch theme for Mosaico, you do not need to do anything more then download and enable the extension for the Mosaico extension to work. (You do not need to change any CSS settings as described on the Shoreditch extension readme for example).

In the future however you will be able to use the instructions as set out on the Shoreditch extension to switch the rest of CiviCRM over to the new “theme” but the work for this is still in heavy development at the moment and not ready for production use.

Coming soon

There’s a lot more coming on the Mosaico front including an RSS to email block and work on integrating it more fully to CiviCRM’s other email sending (A-B testing, scheduled reminders and system emails). There will be a “make it happen” (crowd funding) campaign coming soon, so if you’re finding the new Mosaico useful and want to see more please think about getting involved and contributing to future development by contacting me at jamie@compucorp.co.uk!

A big thank you to all those who have been a part of this project: the team from Veda Consulting who developed the original extension, Tim Otten from the core team who worked tirelessly to make this a reality, our client Healthwatch who patiently provided funding, testing and feedback and the rest of the team at Compucorp for the design, UX, styling and QA to bring it all together. This is great example of our diverse Open source community from several corners of the globe working together to create something fantastic.

Thanks for reading… and happy mosaico-mailing!!

*We’ve got a final beta out which can be downloaded from github and we will be making this available for automated download from inside CiviCRM soon!

I'm please to announce the release of a new Smart Debit extension for CiviCRM 4.7.

The new extension is based on the vedaconsulting (https://vedaconsulting.co.uk) extensions for previous releases of CiviCRM but is rewritten and includes a number of new features and enhancements.  Development and Testing has been funded by Circle Interactive (https://circle-interactive.co.uk) and implemented by MJW Consulting (https://www.mjwconsult.co.uk).

The new extension includes the following features and enhancements:

• Integrated reconciliation functionality - useful when smart debit and civicrm are not in sync (for example, you've been using smart debit before you integrated it with CiviCRM).
• Easy to use settings page with context help.
• Automated daily synchronisation with smartdebit for all successful/failed transactions.
• Supports both recurring and non-recurring transactions.
• Updated "Bank approved" direct debit mandate display in contribution confirmation pages.

The extension can be found here: https://github.com/mattwire/org.civicrm.smartdebit and documentation is available on the github wiki at https://github.com/mattwire/org.civicrm.smartdebit/wiki

The mandate looks like this:

Reconciliation looks like this:

At Wanna Pixel, Inc., we have been excited about Mosaico, a drag-n-drop email builder native to CiviCRM, for quite awhile. Most designers and nonprofit staff alike have struggled to use the CiviCRM mailing feature to create responsive email campaigns. Three years ago, I wrote an article about the responsive template I created for CiviCRM users, hoping to help ease this struggle.

Before Mosaico, there were two options for email building when using CiviCRM.

• Use responsive html templates and spend hours editing them whenever you wanted to make a change.
• Integrate with MailChimp and lose some data and token access.

CiviCRM Core Team, Veda Consulting, and CompuCorp worked together to create a beautiful extension for CiviCRM’s mailing feature which integrates with Mosaico, a drag and drop tool created by VoidLabs.

Our big question was: Will our creative and development team be able to use, recommend and train our nonprofit clients to create satisfactorily beautiful emails without having to integrate with a third party email builder such as MailChimp, or painstakingly editing raw HTML templates?

I have to admit, I’m impressed. Veda Consulting and CompuCorp have done an incredible job in creating this beautiful Drag and Drop extension for CiviCRM’s email tool.

We've written a blog post detailing how to use Mosaico to create beautifully responsive emails. Head over to the blog to check it out!

Here are some things we loved about Mosaico in our test run.

• You have access to all CiviCRM's native tokens.
• Your email content will be saved in your CiviCRM database.
• When you are in a design block in Mosaico, it is easy to toggle between global and local style settings. By contrast, in MailChimp, there is a lot of saving and exiting and navigating to your global styles. Then when you do navigate to global styles, it is divided up among things like page, content, body, etc. I’ve always found it a bit confusing and never can quite figure out where some of my styles are coming from. Mosaico makes this extremely simple, always keeping you inside of one panel.
• In Mosaico, you can edit all headings, links, and content in the WYSIWYG editor. In MailChimp, it always opens up a separate window to edit, adding one extra click and a slight delay as well.
• In short, Mosaico is simple, containing everything you need and nothing you do not need.

Ginkgo Street Labs is pleased to announce the availability of CiviVolunteer 2.2.2 for CiviCRM 4.7.21 and above. Site administrators maintaining an older version of CiviCRM should upgrade core before upgrading CiviVolunteer.

This release includes five bugfixes. The most substantial of these is VOL-310, which arose from changes introduced to CiviCRM core's Angular integration in version 4.7.21 and which resulted in a more or less complete breakage of the extension. Thanks to Bob Silvern for bug reports and patch testing; Travis Megee and Eric Goldhagen for patch testing; Agileware for patch testing, contributed code, and funding; Eileen McNaughton, Fuzion, and Tadpole Collective for funding; and Tim Otten for providing various technical signposts.

This is important enough that it bears repeating: users of CiviCRM 4.7.21 and above should use CiviVolunteer 4.7.21-2.2.2 or greater; users of any lesser version of CiviCRM should not upgrade past 4.6-2.2.1. The changes required to resolve VOL-310 could not feasibly be made in a backward-compatible fashion; installing the latest version of CiviVolunteer on an older system will completely break the extension. (Presently, CiviCRM doesn't have a way to support minor release compatibility checks -- though the extensions working group is working on it -- so for now this announcement is the best we can do.)

Installation

CiviVolunteer can be downloaded from the CiviCRM extensions directory or installed from within CiviCRM from the Administer menu, under System Settings > Manage Extensions (some systems may have it under Custom Data and Screens > Manage Extensions). You'll also need to install version 1.0.1 or later of Angular Profiles– a utility extension which helps the Angular and Backbone JavaScript frameworks play nicely together – in order for CiviVolunteer to function properly.

UPGRADING

If you're currently using CiviVolunteer, the new version should be available as an update on the Manage Extensions page soon. Some users have reported that their CiviVolunteer settings "disappear" after an upgrade. This is due to an issue with CiviCRM's extension system, but can usually be resolved by flushing CiviCRM's caches. For more information, see CRM-21210.

Greetings from Montréal!

We have officially released CDN Tax Receipts extension 1.4.0 for 4.6 / 4.7 : https://civicrm.org/extensions/cdn-tax-receipts

Current Features:

• single, aggregate and annual receipting
• one-off and bulk receipting
• email and print methods
• default layout (logo, watermark, authorized signature) and press-ready PDF template options - detailed reporting (receipts issued; contributions eligible but receipts not yet issued)
• uses non-deductible amount field
• uses financial_type -> is_deductible settings
• works for lineItems
• hooks: hook_cdntaxreceipts_eligible(); hook_cdntaxreceipts_eligibleAmount(); hook_cdntaxreceipts_writeReceipt();
• email tracked opening feature

We have worked with (and continue to work with) a BDO Tax Partner who has strong ties to both the NPO community and Tax Authorities (CRA).

In the works:

• adding multi-lingual capability [with samuelsovl]
• batching process [to prevent PHP time-outs for large receipt batches]
• adding receipt issued location
• options for numbering schemes: unique/contribution ID vs serial
• layout change: from tri-fold to new layout to free up space for new features [such as details of all contribution included on the tax receipt]

Greetings,

jake-mw & KarinG

Have you ever wondered whether those Event or Membership Reminders actually get delivered?

And what about those automatic Receipts that go out? Ever wished you could see what the heck was actually being sent?

Well now you can thanks to Fuzion's new extension for transactional mail.

With the help of funding from Agileware (Canberra, Australia), several Fuzion clients, and Fuzion's own contribution, we have put a couple of our extensions in to a single bundle to bring these goodies to a wider audience.

By default CiviCRM only performs bounce handling when sending via CiviMail, but not when sending transactional emails such as scheduled reminders, event registrations, contribution receipts and the like. This extension addresses that limitation.

How is this happening?

This extension creates a pseudo-CiviMail named "Transactional Emails" which transactional emails are attached to. 

Bounce reporting, delivery, open and click tracking should work as per regular CiviMails.

But wait, there is more.

Standard CiviCRM has no record of what was sent out. This extension now creates an Activity whenever a Receipt or Invoice is sent, so you have a  record, and you can track whether it was delivered or if the email address needs checking. 

Hope you find this useful.

Notes:

We welcome contributions and bug reports via the the nz.co.fuzion.transactional issue queue. Paid support is available if required - contact us.

Our new extension aims to enable charities/organisations to manage their supporters in a GDPR compliant manner. GDPR in itself does not introduce many new directives however it does make organisation appointed officials directly responsible for any breach in directive and therefore has a degree of responsibility which had been missing from previous iterations.

It’s important to understand that simply implementing an opt in process and assuming all contacts are opted out overnight is probably not what is best for your organisation, there are many factors to consider before determining that a formal opt in is required. For example a membership organisation is well within its rights to assume that member communications are assumed opt in unless the member explicitly opts out. Its also a fair assumption where contacts have been imported from third party fundraising systems, where they can represent your charity and they have stated they are happy to be contacted by the charity they are fundraising for. The overall aim of this extension is to help organisations navigate the journey to GDPR compliance without compromising their presence with and income from their existing supporters.

More details about GDPR and CiviCRM can be found at https://vedaconsulting.co.uk/GDPR

The first version of this extension does the following;

• Allow you to record the data protection officer for your organisation

• A new tab 'GDPR' in contact summary will display group subscription log for the contact

• Custom search 'Search Group Subscription by Date Range' which can be access from GDPR Dashboard

• Access list of contacts who have not had any activity for a set period of days from GDPR Dashboard

Future releases will include

• User friendly communication preferences, moving to explicitly worded opt in mechanisms.

• A forget me process - where a supporter has asked to be erased from the organisations CRM. We will introduce a button which will anonymise the contact without losing financial or any other history therefore keeping the performance history of the organisation in tact.

• Communication preference to include medium per group. Currently CiviCRM supports include or exclude from a group but it does not allow for the selection of the communication medium that should be used for example happy to receive email newsletters but please don’t send me any other emails.

GDPR comes into force in the UK on May 2018, we aim to complete the feature set of this extension by Feb 2018 and if you'd like to get involved please do feel to get in touch. We'd also like to take this opportunity to thank Paul Ticher (http://www.paulticher.com/data-protection) for coming on board with this project as a consultant and expert in the sector.