Like many others who have no doubt gone before me, I found myself spending a large chunk of time this week finding and merging duplicate contacts. Civi's deduping UI has gotten a lot better lately, and I love having the ability to go through it more quickly than before. But deduping is only as good as the queries it runs, and of course prevention is better than cleanup.
Here are some observations of how all those dupes in my DB got created:
One of the items we didn't get to at the code sprint was a quicksearch by id that bypasses search results pages and takes you directly to the page in question, e.g. a case id or a contribution/invoice id.
We've been having a great gathering and an incredibly productive code sprint at wonderful Cawthorpe, UK. Thanx to Dave Moreton from Circle Interactive for organizing the logistics and making this event possible.
Over the past few weeks, at least 6 people have asked a very similar question on the forums. I want to extend the results from the Contact / Contribute / Member search form and display these fields instead of my least favorite fields. For example, users want to see the organization and job title of their contacts in the search form instead of country and post code. Or the total amount someone has contributed to the organization as part of the contribution search results. We had a few ways of doing this, but not very elegant.
I wanted to address and solve this during the code sprint. I looked at the code and initially came up with two hooks: one for the search headers and one for the search results. In a conversation with Kurund, we figured that one hook was a lot easier for downstream developers. I took a closer look and found an even better place to introduce the new hook: hook_civicrm_searchColumns. This will be part of 3.4.6
Basically, in the hook you modify the headers and values and inject / modify both the arrays as you see fit. The search templates currently are hard-wired to what it is going to display. So in some cases you might need to customize the search template also. You can work around this if you are keeping the same columns and overwriting the values in the array.
After a big conversation at the coding sprint, we seem to be in consensus about transitioning CiviCRM's revision control system from using subversion to using git.
If you are a user or integrator that installs CiviCRM by downloading the zip or tar ball from the CiviCRM site, this transition won't affect you in any way.
Several CiviCRM users have expressed an interest in managing CiviCRM activities with a smooth, interactive calendar screen. Since calendaring can be a complex topic, we've put together a basic, working calendar to facilitate discussion. The prototype resembles the calendar included in other relationship-management tools:
If you've ever configured a schedule task (aka cron job) for CiviCRM, you know the routine. You have to look up the username and password for a user in your database that has database permissions, you have to find a really long mess of characters known as your site key, you have to find the proper name of the job you want (like UpdateAddress.php or civimail.cronjob.php) and then you must string them all together in precisely the right way to make the cron job.
What a tedious drag.
