Today is the last day of the Bristol code sprint, which was a great experience! Lots done, climbed the Cheddar Gorge and tasted Kurundś famous lamb.... I will also always remember it for finding out I was part of the API team :-)
On a serious level, it is a good idea to have a team of people that take care of the API's. And taking care I think involves:
Today at the Bristol Code sprint a few of us made a concerted effort on getting making Giftaid 'plug and play' for Civi.
Our starting point is code written by Millertech and our aim is to get it into a state that we can package it as a Drupal module. Once we've done that, we're hopeful that we'll be able to package it for Joomla also.
A couple of blog entries back (http://civicrm.org/blogs/mbriney/contacts-erd-v31 to be precise) Matt Briney was kind enough to share the contacts ERD with us! I promised to put some more on. The entire CiviCRM ERD is too big and complex to be useful in this format, but I have just created one for the location point of view.
Hi all,
For the training in london, we wanted a simple example that illustrates how to customise and improve civicrm for specific usages using the ajax interface. I'm sharing the result with you, hoping you will find it useful.
One common workflow we have is to change the status of an activity from "scheduled" to "complete". The default way is to click on edit, go to the full form, change the status, save, and go back to the list of activities
We are going to improve it with a "one click click complete": on the list of activities, we transform the status column into an action (when "scheduled"), and when I click on it, it changes it to Completed, without changing screen. For that, we are using the ajax interface and the activity api. Copy the template templates/CRM/Activity/Selector/Activity.tpl into your override directory, and add a few lines of jQuery at the top:
{literal} <script> jQuery(function ($){ $("td.crm-activity-status_1") .attr("title","Change the status to completed") .css("cursor","pointer") .click (function () { aid=$(this).parent("tr").attr('id'); var activity_id = aid.replace("crm-activity_", ""); cj().crmAPI ('activity','update',{id:activity_id,status_id:2}, {callBack: function(result,settings){ if (result.is_error == 1) { $(settings.msgbox) .addClass('msgnok') .html(result.error_message); return false; } else { $('#crm-activity_'+activity_id) .removeClass('status-overdue') .find('td.crm-activity-status_1') .removeClass('crm-activity-status_1') .addClass('crm-activity-status_2') .html("Completed"); } } }); }); }); </script> {/literal} Oh, it's magic! What does it do in detail ? Well, you should attend a developer training, you will discover it, and way more ;) X+Following the great response from OpenCamp and the recent Dallas Drupal User group meeting, the Dallas / Fort Worth CiviCRM Meetup is a reality!
Slight change in plans - I was promising the recipe on packaging payment processors, but we'll do custom reports first. They are second in the hierarchy of complexity after custom searches, and they smoothly introduce small new concept that will be described below.
We are extending the 3.3 deadline to the 3rd of October to make one last push towards getting more of the initiatives into 3.3 and after that the focus will move to trying to get some more momentum for 3.4. Personally I would LOVE to see the dedupe exception table item get some funding. Anyone who has done deduping themselves will understand why!
Continuing the series, let's look at packaging payment processors. Before digging in the text below, make sure you're up to date with previous blog posts: on info file format and on packaging custom search.
As promised previously, here is the first recipe for creating your own CiviCRM extension. We'll start with the easy one - let's create an extension providing a custom search.
First, you obviously need to create your custom search, as described in documentation. Once you have the PHP class and the template, you can start packaging it. Let's say you will be doing an activity search. You need to prepare the info file as per description in previous blog post. Please note some details around info file has changed a bit since it was originally published - that's caused by integrating some of the feedback from blog comments. The info file structure shown that blog post has been updated and reflects the current structure.
