While we were working hard on a number of applications for free and open source market one of the application which was released by us was the CiviSync Mobile app for Android. You can download it from Google Play on your phone or here.
The App currently only supports read only mode and allows you to check your contacts, organisations, households, activities and groups. The app is developed using PhoneGap and hence it is easy to convert the app to an iPhone, Windows Mobile or Blackberry app when the need or the requirement comes from the market.
Once again the first version relied a bit on our extended API provided by CiviSync CMS component for Joomla and Drupal but in the next version we have moved away from using CiviSync CMS and towards using the native API for the search results.
In order to use CiviSync Mobile you need the following details:
Hey All, Thanks for your patience and putting up with the delays in the release of CiviSync Outlook. CiviSync Outlook is the much awaited Outlook integration plugin for CiviCRM. It allows information sync between CiviCRM and Microsoft Outlook. CiviSync Outlook uses CiviCRM API. Due to some restrictions with API; at one stage we decided to use our own version of the API but it's not something we would like to run with in long term and hence dropped it fairly quickly.
CiviSync now uses the native API. A detailed user manual in creation but in the meantime Target Integration's wiki page will give you some information on how to install and use it on your installation of Outlook.
Don't forget you need four things to login to a CiviCRM instance using REST API:
- API Key for the user who is trying to login. You don't need the...
Many CiviCRM customizations have been packaged and distributed as Drupal modules. This can be desirable when a customization delves into both the CMS and CRM functionality, but -- when a customization focuses only on CiviCRM -- Drupal modules are a drag: they need to be patched for CMS upgrades (D6/D7) as well as CRM upgrades (Civi 2.x/Civi 3.x), and they don't work with CiviCRM's other CMS's (Joomla and WordPress).
Fortunately, dlobo has been making progress on support for native modules (built around the "CiviCRM Extension" system) in 4.1 and 4.2. An example module is here:
Of course, this still poses a challenge: a native module needs to use native tools for packaging code, adding new web pages, developing templates, etc. -- and all those tools come with a learning curve. To improve the learning curve, I've taken a...Read more
Although the API changes in 4.1 are not as obvious as took place in 3.4/4.0 there have been quite a few changes under the hood. This is a fairly detailed explanation of what's going on inside the API wrapper.
The way in which required fields & default values are set has been changed to be more consistent and to be self documenting.
For example if you look at the auto-generated (PHPDOC) documentation for Note API you will see that entity_id & note are marked as 'required' and that the default value for 'entity_table' is civicrm_contact. The default value for modified_date is 'now' (the api accepts 'now' along with other relative dates for date fields).
The code sprint in London has finished yesterday. It's always a pleasure to see old civi friends and meet new ones. Thanks to Michael and Katy to have organized it. Time for a quick update of what I've been working on with the most obscure title I could find. My focus has been on usuability to make civicrm easier and faster to use.
To make our crm more user friendly, we need to make the pages more "application like", where you can add, edit remove and reorder from the same page without having to switch and go to more pages with forms to fill and save. And load. And wait. And save, and load and wait more...
For instance -and that will be a make it happen that we launch next week to improve- creating a survey today means you have to go to visit a different page to create the survey, the profile, for each field you add in the profile, for each custom field you need to...Read more
Thanks to a successful Make-it-Happen campaign the 4.1 release comes with a much improved and super flexible approach for running Civi's critical back-ground processing tasks. These tasks include keeping membership statuses up to date and sending renewal reminders, sending scheduled CiviMail mailings, sending pledge payment reminders, and more. I've spent the past 10 days testing and documenting the new "consolidated cron" functionality, and the good news is that I think it fulfills the promise of providing a convenient and friendly way to administer and run all the required tasks for a site.
The "bad" news is that these improvements are NOT backward compatible. The set of PHP scripts which were previously used to run these tasks have all been deprecated (and moved to a 'deprecated' directory). This means that all CiviCRM-related cron jobs will stop working as soon as any site is upgraded to 4.1...Read more
Notice to non-developers: This post is about how some functionality in 4.2 will be implemented in code and in the database, with very minor changes to anything visible through a browser. If you're not a developer, it probably won't interest you.
Simplifying the Codebase
As part of the CiviAccounts project we are looking to redo some of the implementation of the configuration and processing of payments for contributions, memberships, and events. Currently the processing for each of these three types of objects has two paths: one for a simple configuration of the objects, and one using price sets. This means there is more code, more complexity, more possibility of errors, more work when making changes, and more need for testing.
As we refactor the existing code we're looking at keeping the simplified UI for configuration and administration, but implementing everything under the hood using price sets. Before going ahead with that, we wanted some...Read more
This month we did a fairly complex migration for a customer of about 90,000 contacts to CiviCRM. I have been using Migrate module to do migrations for a while now but this time for the first time I used version 2 of the migrate module. I put up a how-to-blog on our site just before Christmans but Fen has inspired me to get on with sharing it more widely.
Migrate allows you to run a specific number of items, to roll back or update items and is primarily intended to be used by drush. Data can be adjusted on the way in if you add a 'prepare' function and you can use the...Read more
I think there were few discussion in the forum about adding 'Custom Data Group' with multiple records in a profile. We wanted the same for one of our clients, who wanted an Application Form in which they wanted to collect Qualifications and Experience, which obviously is multi-record custom data against contact. As they needed it in a very short period of time, we managed to do a work around to accomplish this. As usual, the wonderful CiviCRM API version 3 and hooks come to the rescue.
So the aim was to expose the fields under the multi-record custom group in the contribution page(using buildForm hook) and allow the users to enter multiple rows and save it against the contact(using API).
We created a drupal module which does the following
- Allows admin to set the custom data group, for which the fields can be exposed to the contribution page. View Screenshot...
I've just released a new version of the CiviCRM Webform Integration module for Drupal 6 and 7.
This module provides a flexible and powerful way to create forms linked to the CiviCRM database. Version 2 of the module is built for CiviCRM 3.4/4.0, and can create and update contacts, group subscriptions, tags, relationships, cases, activities, event participants, and custom data.
New in 2.3:
- Contact Clone Feature - a real timesaver for multi-contact forms
- Now works with event registration limits
- Improves Group Subscriptions
- Deduping works with shared addresses
- Better and more consistent performance with Country/StateProvince chainselect
- Other minor bug fixes
If you're interested in the future of this module, check out ...Read more