Introduction

This extension is really usefull when you have donors who pay every month and or when you have direct debits with those donors. This extension let you set up an recurring contribution where you can decide if this contribution should recur every month, every year, every week. The actuall contributions are created 30 days in advance by a cron job and after a new contribution is created the next scheduled date for the recurring payment is set to the next date. You can then use those contribution to sent to your bank for direct debit, or you can use them to verify that commitments are met e.g. when someone has made a commitment to give every 20th day of the month you can see then if they have paid on the actual date.

Documentation **

Functionality ****

Code QA ***

Ease of use ***** 

Overall 

Despite having enough on their plate with a few billion kids worth of presents to build, and with Rudolfs unfortunate flu (well why else would he have a red nose?), Santa's little elves over in the UK have been working hard to also bring you a brand new CiviCRM extension/module - CiviBooking! Having now been extensively tested for sleigh management purposes we're really pleased to announce the first stable release available now from the extensions directory.

Yup, that's right folks, worried about what to get the wife for Christmas? We'll you don't need to be anymore, fire her up a copy of Civi and head over to the extensions directory and follow the 2 click install for v1.0 (Stable) CiviBooking and you're sorted... (Assuming she runs a non-profit organisation with rooms and resources that need to be rented out for a fee - otherwise probably best to go with flowers or purfume).

More deets below.

Happy Holidays everyone.

Team Compucorp

...................................................................................................

What is CiviBooking?

Are you a non profit with Rooms or Resources that you think you could raise money by renting out? Or are you a community center or voluntary service looking to manage your resources better? Sick of spreadsheets, emails and that Google calendar that no one keeps up to date? Then CiviBooking is the extension for you!

v1.0 (stable) is now available and can be downloaded from your in Civi extensions menu through a few quick clicks. Grab it whilst it's hot!

For those of you who have been living under a rock for the last few months and are asking... what does CiviBooking do... well...in a nutshell:

• You can create a list of resources which are available to be booked (we call these limited resources as once their booked, they're gone!)
• These are shown in a fancy calendar type screen so you can see what’s available super easily.
• Contacts in the database can book one of more of these by using the booking wizard.
• Contacts can add unlimited resources to the bookings (tea's, coffee's, solar energy...)
• Contacts can add additional charges, discounts and calculate a price based on what’s booked.
• You can make provisional bookings and come back and edit them later.
• You can cancel bookings, applying a cancellation charge if necessary.

Oh and of course everything integrates super nicely with search, contact tabs, CiviContribute for payments and some other tricks and tweaks along the way.

Requirements:

CiviBooking requires CiviCRM 4.4+.

It's platform independant so Joomla, Wordpress and Drupal.

Bugs or issues?

Please post on the Compucorp CiviBooking Github page:

Here

User guide:

Coming soon!

I've been recommending the services of iATS for most of my clients' payment processing since way back in 2007, when I wrote a CiviCRM payment plugin processor for it: http://homeofficekernel.blogspot.ca/2007/12/iats-and-civicrm.html

That was a long time ago (CiviCRM version 1.8), and I've been promising myself and others that it's high time to rewrite it, because:

1. CiviCRM now has an excellent extensions architecture.

2. iATS has a new richer SOAP-based API to interact with it.

With some help from my colleague Karin and iATS themselves who helped fund it, I'm happy to report that it's now ready for public testing, at 

https://civicrm.org/extensions/iats-payments

The two things that make this more than a technical rewrite, and worth upgrading to when it's ready, are:

1. Better recurring contribution support. The old api was a "throw it over the fence and cross your fingers" kind of interface, like most of them out there today. In iATS' case, there was no reporting back of any recurring transactions, so only the first transaction got recorded in CiviCRM, and languished there in a pending state unless you manually edited it and imported any recurring transactions. The new method now captures a client token during the initial transaction, and then CiviCRM makes the recurring contribution requests using that token, as a system job. This means the subsequent transactions are better controlled and logged (e.g. changing the frequency and amount can be managed directly from CiviCRM without any access to the payment processor's interface).

2. ACH/EFT. Credit card transactions will typically cost 2-4% to the mechant in transaction processing just to the credit card company, not withstanding any additional costs of the payment processor. This can add up to quite a lot, especially for recurring transactions, so many of my clients use direct bank transfers. The challenge with these has been that they've been a manual labour-intensive process, and depend on the bank you use. But now iATS offers a service that works similarly to the credit card processing, but doesn't include that credit card company cost.

iATS services Canada, US and the UK, so testers are encouraged from all those regions. The UK does not work in the 1.1-beta1, but it looks relatively straightforward to implement - please contact me if you're interested in either testing or in sharing development and maintenance of that part of the code.

We've marked a new release of civix. Notable changes/improvements:

• generate:case-type - Add a new command to generate skeletal CiviCase XML files. (As usual, the new command is documented in the wiki page, "Create a Module Extension".)
• generate:module - Add support for generating license metadata by passing parameters "--license", "--author", and "--email". The information will be propagated to info.xml and LICENSE.txt.
• generate:module - Add hook stub for hook_civicrm_alterSettingsFolders so that files in "settings/*.setting.php" are automatically loaded.
• generate:module - Add hook stub for hook_civicrm_caseTypes so that files in "xml/case/*.xml" are automatically loaded.
• Add documentation links for hooks (using "@link").
• Reformat civix's internal source code based on CiviCRM's coding conventions.

To download the latest version of civix, grab the tarball from https://sourceforge.net/projects/civix/files/ or update your civix git repository.

v14.01 introduces some changes to the templates. Previously-created extensions will continue to work without modification, but some new features may not work unless you update the code in your extension. For instructions, see UPGRADE.md.

Please feel free to report any issues with the new release.

eWay is an australian payment processor that provides a seamless connection with many banks and allows for recurring payments, token payments etc.

CiviCRM has had a one off payments processor for eWay for a long time, but has lacked one for recurring payments and now it is finally here!

This payment processor has had a long history and there are many people to thank in it’s evolution.

I started the process several years ago, creating a processor that scraped emails checking for sucseful recurring payments. This work was undertaken with Community Builders for Voiceless initially.

It was then refactored into using eWay’s token based recurring payments API by Henare Deegan.

Finally, to make it work for all users and not just hard coded to work for specific clients I undertook another update to the code (also making it compatible with several versions of CiviCRM) with sponsorship from RIGPA.

There is more work to be done with this extension, but it should work reasonably well, as this involves payments, you should do your own testing before using it live.

Instructions for installation are to be found on the module page and in it’s read me file.

Download here and let me know your feedback.

Did that get your attention?

Unfortunately it's not as simple as just coming up with ideas and waiting for a check from Google. As a community, CiviCRM has to apply to even be part of the program. We are still looking for both more project ideas and more mentors to include in CiviCRM's application to be a mentoring organization in Google Summer of Code 2014. At this point in the process we are trying to make CiviCRM appealing to both potential students and Google. Several months ago we started updating the wiki of project idea and potential mentors that Xavier Dutoit started for CiviCRM's application to be a Google Summer of Code (GSoC) mentoring organization in 2013. That year, CiviCRM was not selected to be part of the program. I'm hoping to change that this year by bringing some insights into how the program works from my experience as a mentor with Drupal projects. The application deadline is quickly approaching for 2014. The process CiviCRM must follow to have Google pay students ~$5000 to work on a CiviCRM related project for a summer has been discussed thoroughly in this forum thread, but here is a rough summary of the process:

1. Members of the CiviCRM community interested in participating as mentors and/or organizations with a project idea, add the information to the Google Summer of Code 2014 Wiki
2. Two Organization Administrators (Xavier and I) submit the Organization Application
3. If approved, on Feb 24 students will start asking about existing project ideas and suggesting additional project ideas looking for potential mentors
4. Students begin officially applying to Google between March 10-21 by by submitting a full project proposal based an existing project idea or their own idea
5. A group of approved CiviCRM mentors review and rank student proposals
6. Google approves a specific number of project slots for each mentoring organization using a process that isn't public so it isn't gamed

This process is like a dating service where both the student and the mentoring organizations are reviewing the potential date/project and Google is the acting like a match maker. Students can propose several dates/projects to the same mentoring organization or multiple organizations, but ultimately only one date/project is approved by Google. We can only take the date analogy so far without getting creepy since there is money changing hands.

• Students are paid $5,000USD for the summer
• Mentoring Organizations are paid $500 per approved slot
• Individual mentors get $0, but other, non financial benefits

This is a great opportunity to subsidize the development of new features or overhaul critical, low level functionality in CiviCRM as well as grow the number of developers contributing to CiviCRM. While not every student who participates in GSoC continues contributing, the Drupal community has had great success finding key contributors through this program. Angie Byron (@webchick) got her start in Drupal as a student in the 2005 GSoC. For those of you who don't know, Angie is the Director of Community Development at Acquia and a Drupal core co-maintainer. I mentored Janez Urevc (@slashrsm) in 2012 on the Media Derivatives project. Janez now works for Examiner.com and is leading the drive for better Media integration in Drupal 8.

My personal experience mentoring students as part of GSoC has been extremely rewarding and required very little actual development work on my end. Most of the work for me happened during the initial planning phase of the projects. The students selected to participate in GSoC are extremely bright and motivated. My role was often to scale the scope of the project so what was developed was a solid foundation that allowed additional features to be easily, worked in several configurations, and was well documented vs. a dozens of poorly written features that would only work on the student's test site.

I've been really lucky to mentor some truly great developers. Your millage may vary. Every year there are students that disappear for several weeks and return with incredible tales of why they should be given an extension. This is frustrating, but even these provide a bit of amusement when they are shared on the mentor list. As a mentor, you are required to provide a "midterm" grade. If the student has not made what you consider enough progress to complete the project, you can fail them at this point. If failed, the student doesn't get paid anything… which is a powerful motivator to make substantial progress by the mid term. What we as a community will do to prevent student disappearances and engage the students is part of the Mentor Organization Application.

When volunteering to mentor, be aware that GSoC is open to students all over the world so confirm that you and the student speak a common language and can coordinate meetings that work for both timezones. When I mentored Janez, he was living in Slovania. Since the time difference made real time communication difficult, he was required to commit all code to Drupal.org's git repo, blog weekly about his progress, and meet every other week with me via Skype to discuss any issues. Janez original proposal was to create a universal File Derivatives API for Drupal that code not only convert an .flv -> H.264, but a .xls -> .ods. As a mentor, I'm expected to know about dependencies that could cause a project to fail and scope the project for the best chance of success. I convinced Janez that considering the current state of Drupal 7's Media module and lack of quality documentation for that code, just creating an engine to create media derivates was going to be a summer's worth of work. In addition to scoping the project, I introduced Janez to other developers working on specific media modules allowing him to skip the "I'm a new developer working on X" phase and get right to the technical details he was having issues with. The most time consuming part of being a mentor for me was reviewing Janez's code, testing the configuration myself, and convincing other developers to test and provide feedback. I'm hoping that by pairing a development mentor with an organizational mentor, we help keep that part of mentoring to a reasonable number of hours.

What we really need right now are more potential mentors, more project ideas, and more outreach so everyone knows about this opportunity.

• If someone tells you at a CiviDay Event that it would be great if CiviCRM did X, point them to the wiki.
• If you know of a student who'd be interested in participating in GSoC, encourage them to consider applying for a CiviCRM project
• If you know someone at an organization who's been a mentoring organizations for GSoC in the past, please ask them to vouch for CiviCRM on this year's application

I'm happy to answer any questions anyone has about GSoC, help refine project ideas, and help match potential mentors w/ potential projects.

This time we had a look at the Extended Mailing Stats extensions, that was contributed by Andrew MacNaughty. The extension is used by the Australian Greens (http://greens.au.org). More information on the extension can be found on https://civicrm.org/extensions/extended-mailing-stats. And a big thank you to Andrew and the Australian Greens for sharing this extension!

As the extension is marked as "No, this Extension Release is not ready for automated distribution" we will make comments but not score this extensions. Only extensions marked as "Yes, this Extension Release is ready for automated distribution" are scored.

What does it do

The extension extends the information available on the standard CiviCRM mailing report with additional tracking information that can be quite useful for organizations that use CiviMail. The extension enables a CiviCRM report template, allowing the user to create a report based on the template. One detail we found interesting is how much donations are made within 48 hours after the mailing has been send.

Documentation

First of all a round of applause at how much is documented on Github. Really good, covering all aspects. We do have some comments on individual point, but all in all well documented. Our comments:

• the Github clone example uses Andrew's Github account, we would prefer git clone https://github.com/mc0e/civicrm-extendedmailingstats.git to the mentioned git clone git@github.com:mc0e/civicrm-extendedmailingstats.git au.org.greens.extendedmailingstats

• we would prefer the cron job as a scheduled job within the extension, but that was probably not available at the time of creation of the extension. However, now there is a need of a little more explanation as to how to set up a cron job, assuming an intelligent user should be able to configure the extension

Functionality

Straightforward, but definitely quire useful information. Two glitches we had: the report showed an unsubscribe that did not originate from the mailing, and counted two mails sent where only one was sent from the mailing job. Obviously there are some assumptions used in collecting the data for the report, we recommend mentioning these assumptions as they will quite logically explain why some stuff is showing.

Code

Code looks pretty decent, could do with a few more comments. Also, we would prefer to store the functions in a separate class rather than in the 'main' file. So we would probably store all the _extendedmailingstats functions in a separate class called ExtendedMailingStat and called them statically where required. But arguably that is just a question of taste?

Ease of use

As mentioned the git clone does not work if you copy it from the documentation, and the cron job would be easier as a scheduled job. This is what we have done to get it to work:

You have to uncomment line 79 in the code which is

function _extendedmailingstats_cron($params) {

// _extendedmailingstats_cron_db_setup($params, 1);

_extendedmailingstats_cron_mailing($params); // needs to be done at the start

This should be:

function _extendedmailingstats_cron($params) {

_extendedmailingstats_cron_db_setup($params, 1);

_extendedmailingstats_cron_mailing($params); // needs to be done at the start

This will create the neccessary tables in your database.

After that you should run the cronjob to collect the neccessary data for the report.

Overall

Good extension to share, really cool if community members share the specific reports they use and have a generic character! We applaud :-)

Jaap and Erik (http://www.civicoop.org)

We are reviewing the extension Relationship Permissions as ACLs, which has been made available by Eileen McNaughton from Fuzion (http://fuzion.co.nz/). Kudos to Eileen and Fuzion for sharing the extension!

What does it do

The extension sets permissions for contacts based on the relations permission.It is a bit complicated......did we get it correctly Eileen?

When you want be able to have the permissions on relationship going one level further then the standard CiviCRM level.
This extension is useful in the following example where you have the following contacts:

Bookshop (Local department)

• Johnson – Manager of local department, a permission relationship for Johnson to the bookshop (Johnson is allowed to view and edit the bookshop)
   
• Betty – Volunteer at the local department, a permission relationship for the bookhsop to the volunteer (the bookshop is allowed to view and edit Betty)
   
• Joe – Another volunteer at the local department, a permission relationship for the bookshop to the volunteer (the bookshop is allowed to view and edit Joe)
   

All persons have a relationship with a local department. But when Johnson logs into CiviCRM he is only allowed to see and edit the bookshop. This is standard CiviCRM behavior. What we want is that he will also see and is allowed to edit the volunteer. We can achieve that by using this extension. Because this exentions gives Johnson the same permissions to contacts as the bookshop has. (or all contacts which he is related to with permissions to view and edit).

Documentation ***

Three out of 5 stars. The documentation on the extensions page is there, and explains what it does in broad strokes. From our point of view a little example would have been nice so the not-so-experienced CiviCRM user also understands what it is going to do as it can be really useful! And perhaps a little technical documentation would help also.

Functionality *****

Although the functionality of this extension might not be applicable to every CiviCRM customer, it is pretty vital and really cool if you are in a situation where you need someone to be able to access all contacts of an organization. So full marks here!

Code****

The code is structured and follows the CiviCRM standards. The only comment we could find that it looks as if a table is created for every user in the database? Perhaps it is also possible to have one generic table and use views?

Ease of Use *****

The extension can be downloaded, functions straightaway and as could be expected. Full marks.

Overall ****

Our verdict (for what it is worth) is that this is a well produced and extremely useful extension. We feel anyone who contributes an extension deserves applause and beers, we think Eileen deserves an additional warm beer (or f.. w...?) for this extension!

Jaap and Erik (http://www.civicoop.org)

This weekend I pushed out version 1.3 of CiviVolunteer. It contains a handful of bugfixes (check out the commit history for more on that) and a new feature that is the subject of this post.

CiviVolunteer 1.3 introduces the concept of "project beneficiaries." This release allows admins to specify a contact which benefits from or is the target of a volunteer project. For organizations which broker volunteers as a service to other organizations, this feature facilitates recording and reporting the number of volunteer hours provided to each partner org. Organizations with a chapter structure will find the project beneficiary useful as well, as service or volunteer hours often have implications on funding from the umbrella group.

I've prepared a quick screencast to demonstrate how CiviVolunteer 1.3 approaches beneficiaries. This is our first pass at supporting project beneficiaries, so we'd love to hear your reactions to what we've got so far and your ideas as to where we should go next. The comment section below is probably a good place to start the conversation. Thanks!

Have you ever needed to send an email from CiviCRM that includes a list of upcoming events? Then you know how much fun the copy/paste effort this entails, especially if you want to use a checksum in the links to register. Plus you know you get to repeat the whole exciting process for the next newsletter the following week or month. Or if you have someone else you need to train on this task, try explaining to a non-technical person how to hand-edit the URL query string to include the checksum paramaters. (is the contact ID query string param name "cid=x" or "id=x", well that depends....)          And even if you do not deal with events, you can have the same fun teaching someone else to properly use checksums when you need to include a hyperlink to a contribution page or a stand-alone profile.  

If you want a much easier process for listing upcoming events with links to register, including links to contribution pages and stand-alone profiles, then try out the new extension called "Fancy Tokens" https://civicrm.org/extensions/fancy-tokens.    That page also includes more details about how to use the new tokens. I have tested this with versions 4.3 and 4.4. Since this is a native CiviCRM extension, it works with WordPress, Drupal and Joomla.

Never used checksums before? Then you are missing out on a great (but previously hard to use) feature of CiviCRM. Checksums give each recipient a unique URL that will be preloaded with the recipient's contact data (such as email, first name, last name or whatever data you are collecting.) The use of checksums saves time for the recipient when filling in your contribution pages, event registrations, and stand-alone profiles.   It may also reduce the chance of duplicate contacts in your database due to poor data entry habits of your recipients. 

Technical Note:  I had to include the .tpl file "/CRM/Mailing/Form/InsertTokens.tpl" within this extension  because the core version of this file has a hard-coded width for the token dialog window that is too narrow to display longer token names.  If this file can be eliminated, then this extension would work with more versions of CiviCRM.  

-Sarah Gladstone

http://pogstone.com

Once upon a time there was a circus who was a visitor to both the lands of Xero and CiviCRM. This circus liked Xero and wanted contributions created in CiviCRM to be sent to the land of Xero. In the land of Xero these contributions would be called invoices and they would be matched with payments. Upon their return to CiviCRM all would know about their paid status and events would be confirmed and emails would go out and all would be be well. They spake with a mighty sorceress from the far-away do-ocracy of Fuzion and verily this came to pass.

At this time the wizard of Xero was little known and although others came seeking the path they found it tortuous, hard-coded and drupal 6 specific. But, as the prowess of Xero grew, more came seeking. Enter the Circle - a brave gladiator called Andy from Circle Interactive set out on the quest of building a bridge for users of Drupal 7 to the growing kingdom of Xero. Like many brave adventures this charted new territory and widened the path for others to follow. And back Fuzion marched into the fray. Building on the original ideas and new ones from Andy's and making it greater and re-writing the code as an ...... an extension!

Yes, those trepdid adventurers have created a new path for seekers of Xero - CiviXero as an extension. Those who seek wisdom, screenshots and explanation should read the scroll here

Practictioners of the dark-arts of coding may be able to read the secrets extracted from it & encoded below

- CiviXero extension requires CiviAccountSync to track the synchronisation

- CiviXero uses api & scheduled jobs to run the sync

- CiviXero is extendable via hook (& generally some customistaion if required)

The path to the land of Xero is not for the faint hearted but on the other side lies the reward of having payments magically encoded into a system of accounts. Some may live happily ever after.....

The planning of this is an outcome of the unconference we had in Januari in London, with LLR, Amnesty Flanders, MAF Norway, Decaid Consulting and CiviCooP. The aim for this sprint, which last for only one week, is to create a trigger/action functionality for civicrm. E.g. we want a trigger that a donor becomes a member of a group of its total contributions are more than 25.000 euro's. Or when a contribution is completed we want to sent out a thank you message based on the communication preferences (e.g. e-mail, sms, postal mail).

What we have done today is to brainstorm on how we want to setup the extension for the trigger and actions. We have created a data structure and started working on the first draft of the user interface. In this blog I want to introduce and explain the data structure and the working of the triggers. 

Internal working

The internal working of the trigger action extension is based on three components:

1. A trigger (e.g. amount of total completed contribution is more than 25.000 euros)
2. An defined action (e.g. add contact to a  specific group)
3. Trigger-Action definition. This is combining a trigger with an action and adding information on when to do the processing (e.g. every morning, always, weekly).

The Trigger-Action mechanism will be checked with a regular cron job. So that the triggers and actions can be delayed/processed at a specific time and so that they don't block the user interface.

Data structure

The data structure for the extension follows the internal working except that another tabel is added. So we and up with four tables

1. civicrm_trigger_rule - the trigger (description of the entity e.g. contribution)
2. civicrm_trigger_condition - the conditions for the triggers (e.g. sum of total amount of contributions, e.g. only contribution with status complete). Multiple conditions can be combined for a trigger
3. civicrm_action_rule - the definition of what to do, which consist of the api parameters, api entity and api action. This way we make it possible to define every action which is possible through the api
4. civicrm_trigger_action - linking of triggers and actions together with a schedule parameter

The data structure might change during the week so for a more actual description of the data structure see the documentation of the extension on GitHub: https://github.com/CiviCooP/org.civicoop.triggers/blob/master/docs/dataStructure.md

For developers: The trigger extension and its documentation can be found at https://github.com/CiviCooP/org.civicoop.triggers so if you want to contribute feel free to fork and do pull requests of this repo.

Yesterday I wrote a blog about the first day in the sprint for the donor journeys. I have discussed that we are focussing on a trigger/action extension to automate most of the donor journeys. I wrote a bit about the internal working and the data structure of this extension. 

Today we have finsished the internal working of the system. It is now possible to define triggers and actions. Right know you can enter those only in the database. We have made a start with the user interface and we continue to developer the user interface tomorrow. So that a user can enter a set of triggers and actions. In this blog post I want to show you how you can enter the trigger and actions in the database. The reason is that this will show in more depth how the extension works.

To explain how the extension work let me first explain which trigger/action I will use in this example.

Example: add every John to the group Johns

For every contact which first name is equal to John we want them to be added to the group 'Johns'. This group has id 6.

Trigger Rules

The trigger rules and the condition determine which entities to match for triggering

ID: 20

Label: When firstname = John

Name: firstname_john

Entity: Contact

Trigger conditions

ID: 30

Trigger rule id: 20

Field: first_name

Value: John

Operator=

Aggregate function:

Grouping field:

Action rules

The action is the action which is executed on a found entity. The action consist of calling the civicrm api.

ID: 40

Label: Add contact to group John

Name: add_to_group_john

Entity: GroupContact

Action: Create

Parameters: group_id=6&contact_id={contact.id}

The API parameters can contain *tokens* which consist of curly brackets around them and the entity name with a dot for the field of the entity. e.g. {contribution.total_amount}

Trigger actions

A trigger/action pair is a combination of a selected trigger with a selected action.

ID: 50

Trigger rule ID: 20

Action rule ID: 40

Schedule: Tomorrow

Is active: 1

Start date:

End date:

The schedule parameter is a php relative date format see http://www.php.net/manual/en/datetime.formats.relative.php for this fornat specification.

Hooks

The extension for the triggers has two hooks

• hook_civicrm_trigger_condition_parse This hook is used for parsing condition and adding where and having clause an entity DAO. E.g. a where clause to match contributions for this trigger
• hook_civicrm_trigger_action_parse_params Every action results in an api call and with this hook you can pass parameters additional parameters to the call

See for more detailed description of the hooks https://github.com/CiviCooP/org.civicoop.triggers/blob/master/docs/hooks.md

Today a new blog post about the progress of the implementation of Donor Journeys into CiviCRM. The route we are taking is that we want to create a trigger/action extension for civicrm because most the donor journey automation is based on a trigger/action. e.g. payment coming in resulting in a thank you SMS a day later. 

In our earlier blogs about donor journeys (Donor Journey Sprint Day 1 and Donor Journey Sprint Day 2) you could read about the internal working and the data structure of the trigger extension.

Yesterday and today we have been working on refactoring the extension to meet the requirement of combining multuple triggers and having the possibility to have condition on custom fields as well. So we have decided to let go the trigger action table/structure and have decided that we have a rule_schedule table and a rule_schedule_trigger table. In the rule_schedule we decide when to run this rule. And in the rule_schedule_trigger table we add triggers to the schedule.

Another thing we came across during the implementation of the condition on custom fields is that it was hard to join the civicrm_value_* tables in the DAO. Because there is no core DAO for such tables. So we decided to make our own query builder, which will then result in an SQL statement we could use. Another advantage of building our own QueryBuilder was that we could then easily add more triggers to one SQL statement as well. 

Tomorrow is our last day we are working on the trigger/action extension so that MAF Norge can start using the extension in a test environment and start building their donor journey into CiviCRM. What we have now looks very promissing for them to start implementing Donor Journeys.

A final blog about our Donor Journey sprint with Steinar and Helen from MAF Norge. Or I should really say our sprint on CiviCRM Trigger Action. We set out to at least create the first basic version of the engine to automatically do stuff based on stuff in CiviCRM :-) Some kind of mechanism that would allow MAF Norge to automatically move donors into specific groups once they have contributed for the first time or set up a recurring payment for example. I feel we have made a good really start on the engine, for more technical details read the previous blogposts by Jaap Jansma (jaapjansma in Civispeak). The first test was quite successfull, and going through the list of triggers with Steinar worked pretty well. As we expected we did make one of the most unsexy things ever, which is a nightmare to configure. So even though Helen and Steinar can work with it, it is not something I would hesitate to hand out to everyone...but it is freely availabe on GitHub obviously (check https://github.com/CiviCooP/org.civicoop.triggers if you are interested). Enough left on our wishlist for more sprints on the Donor Journey stuff, hopefully there will be other parties in the CiviCRM community interested enough to contribute and/or fund :-) If we manage to build on this as a community I am confident we can make CiviCRM an even more wonderful tool for fundraisers!

I want to close the week by telling you a little bit about the longer term dream that I gathered from Ilja de Coster from Amnesty International Flanders. He is a passionate fundraiser AND a passionate data miner. His dream is to be able to combine the transaction data from CiviCRM with other data sources in his datamining utility RapidMiner, do some magic analysis in to classify donors and then move it back into CiviCRM for automatic processing. So based on the donor payment history, the weather forecast, the geographical areas and age differentation CiviCRM automatically sends out a mailing or contacts the call centre with a target list. We believe that we can and will get there using CiviCRM. Using the engine we just started to create. Probably establishing a link between the donor status in the datamining toolset and CiviCRM group membership. Being part of making that dream happen was and will remain incredibly exciting! I just love CiviCRM and the CiviCRM community....:-)

One of the requirements in a project I am working at the moment was that the client wanted to enter when an adress becomes active. E.g. a member says he is moving by the 1st July 2015 (which is in the future). From that moment the member should be contacted by that address and till that moment the old address is the active address.

I have created an extension which achieve this. This extension is in beta and can be found on (https://github.com/CiviCooP/org.civicoop.futureaddress).

I will put this extension into the extension directory later on, when my client has finished testing this extension.

How does this extension work?

As a user you enter a future address by adding a new address on a contact and you set two things:

1. You enter a location type which is a future one
2. You enter a change date (the date when this address is changed)

This extension checks daily for any addresses with a location type in the future (see later on what this is). And it will then check the date for the change of this address and if the date has passed then the old address is archived (see later on what I mean by this) and the future address will be changed from the future location type to the current location type.

Future location types

Future location types are location types with a name which starts with "new_" followed by the name of the location type in which this changes. E.g. for a future home address you enter the name new_Home the display name of the location type could be something which explains it to your user. In this case it could be something like Future home address.

Archived addresses 

An acrhived addresses is saved as a Address Change activity at the moment the address is changed. This way you can find back the old address information in your system. For developers you can disable or change this behaviour quite easily, see herefore the documentation at github.

Setup

The only thing you have to do is to set up location types for future addresses. E.g. create a new location type for a future billing address with the name new_Billing.

I think I saw the first demo of the CiviCRM extension dataviz after the post-CiviCon London sprint. Xavier Dutoit had been working real hard on this, and Hannelore and me were very impressed! The possibilities are great, and data visualization is IMO so much better than numbers on a report! Data becomes so much more alive.

I immediately thought it would be a great topic for a webinar. Last month I spent a co-working day with Xavier and we installed dataviz on the development server of MAF Norway and they were suitably impressed too! On top of that, the data visualization will be part of the Google Summer of Code (see https://civicrm.org/blogs/kreynen/gsoc-meet-the-students).

As we want everyone to be able to see what CiviCRM dataviz can do for them, we scheduled a webinar! On 27 May 2014 at 17.00 CET (checkhttp://http://www.timeanddate.com/worldclock/meeting.html for your local time) Xavier Dutoit will show you what he has done with dataviz, I will take you through some contribution analysis and Siddharth Gupta will assist us where necessary.

The webinar will be held on Google Hangout, please let me know if you want an invitation! Mail me at erik.hommel@civicoop.org. A recording of the webinar will be posted on this blog after the event.

Please note that to take part in a Google Hangout you will have to make sure that:

• you have a Google+ account
• you add me to your circles on Google+
• you let me know by mail you would like an invite to the Hangout on Air
• if you just want to view, you should always be able to do that once you found the webinar (find me on Google+ and you should see the hangout!

If you want an impression on possibilities, check http://www.score-ep.org/

Erik

Last week I have been working for MAF Norge to connect CiviCRM to their SMS Gateway (PsWinCom) so that they can send and receive SMS from within CiviCRM. In addition PsWinCom offered a the possibility to send SMS which will charge the receiver an amount of money. This way MAF Norge used to receive SMS donations. Now they can do that from within CiviCRM.

This done by two components, one is the PsWinCom SMS Provider and the other a newly developed SMS Autoreply extension. 

SMS Autoreply extension

The SMS Autoreply extension does sends auto replies to incoming sms-es. It is triggered by a keyword in the incoming sms. E.g. when a user send MAF Fuelsponsor it will receive automaticly an answer saying 'Hey Jaap thank you for becoming a fuelsponsor'. Also it possible to setup an amount to charge. E.g. this way MAF can send an SMS saying 'Hey Jaap do you want to donate 100KR send MAF DONOR 100 to 2377' as soon as the user sends MAF DONOR 100 to 2377 the reply will cost 100kr and can be like 'Hey Jaap thank you for donating 100KR' 

This will end up in CiviCRM as a contribution of 100KR. 

I have just finished the development of a new extension for PUM (http://www.pum.nl - thank you!!) to be able to add a coordinator (with start and end date) to a tag. I have added the extension to the extension directory (https://civicrm.org/extensions/enhanced-tags). The extension is also availalbe on GitHub where you can find a little more documentation: https://github.com/CiviCooP/org.civicoop.enhancedtags.git