Anyone who has tried to login to their CiviCRM database via their phone knows the feeling: utter helplessness. You would even be forgiven for thinking CiviCRM is actively hostile to the small screen.
This initial experience of the un-initiated CiviCRM user on the phone will probably remain until the eventual adoption of the Bootstrap framework (a CSS framework with built-in mobile/responsive elements).
We recently had one of our groups report that merging data was resulting in data loss. Specifically, when they merged two records, they noticed that the contribution records on the record that was deleted were not carried over to the record that remained.
I investigated and found the culprit: we were missing a foreign key constraint between the contribution table and the contact table. In fact, we were missing a lot of foreign key constraints in this database.
The ability to create petitions in CiviCRM was a tremendous move forward for people using CiviCRM for political organizing. The petitions feature took another step forward with the Petition Email extension, that allows copies of your petition to be automatically sent by email to a given target. However, the holy grail of e-advocacy was still just out of reach: automatically sending your petition to the petition signer's elected official.
Now, CiviCRM will have it.
When generating mailing labels, CiviCRM users have the option of choosing the address to be used (e.g. you can select "Primary," "Home" or "Work") depending on where you want to reach your contacts.
CiviMail, however, does not provide this option. Instead, CiviMail automatically chooses the address for each contact - a process we can only control on a contact-by-contact basis by setting the "Bulk Mail" or "Primary" flags for each individual contact.
Have you ever completed a training a wondered whether usage of your CiviCRM database changed as a result? Have you ever wondered who were the major database users in your organization and who might need more prodding?
The Progressive Technology Project is please to announce that now, with the Database Health Report, you can find out.
PTP's first official contribution to the extensions repository is out: Summary Fields!
PTP folks and friends have been working hard to enhance the fundraising aspects of CiviCRM. We have big plans, and expect to release the bits and pieces as they are completed.
Summary Fields is the first to make it out. We've been testing it for a month or two now and, while it has a few quirks (particularly with large data sets), it's fairly stable.
With the 4.3 upgrade, the Progressive Technology Project has made a number of important steps toward breaking out our work into pieces that others can use on their sites. This blog will begin a series of (hopefully) weekly blogs outlining new functionality that others can use.
Our first blog features the civicrm_petition_email Drupal module. Thanks to the hard work of agh1, a Drupal 6 version of the module is available (https://github.com/agh1/civicrm_petition_email). We just finished porting it to Drupal 7.
Progressive Technology Project has released a new Drupal module called CiviCRM Cicero that integrates with the Cicero service from Azavea. If you are using CiviCRM with Drupal, you can now add legislative district and more information to your database.
As of the Bourne, UK sprints last August, bin/cli.php has been completely re-written for 4.1.
If you are an integrator or user, you might not have noticed this file. It used to be a PHP class that was used by many of the individual scripts in the bin directory.
Now, it's a command line program designed to be run directly.
With cli.php you can run any function defined in the API version 3.
If you run the script without any arguments, you'll get a usage statement explaining how it works: