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.
To lay the ground work for the Consolidated Cron Make it Happen, which will make all this much easier to setup, we're first doing some major re-organizing of the underlying code.
Currently, all of the code for running these tasks are independently stored in one-off scripts in the bin directory. This organization makes it very difficult to run the code in different contexts. For example, if you are using drush, it would be convenient to be...
Read more- 1 comment
On a system with roughly 25,000 activities, running on a dedicated server, the case dashboard would take over a minute to load. Other orgs have reported similar problems, and in at least two cases the consultants simply removed the upcoming/recent sections from the dashboard since it was just too slow.
Taking for example the upcoming section, on the server above the query would take about 26 seconds. With some optimization, it now takes less than 1 second.
In this query the issue is that we are trying to display some information from a specific activity (the next scheduled activity within 14 days) inline with case data, and you need to remove possible alternate possibilities from the results. Removing the duplicates means re-joining back onto the activity table. You also have to re-join a third time in order to get additional fields from the activity record, since if you try to do this at the same time as using group by, you potentially get fields returned from...
Read moreCode sprint is always fun. It's gives you great opportunity to meet fellow civi folks, collaborate and implement kool stuff :). Last few days has been very interesting. Besides some great meals we also managed to get some work done. ( If you still don't know, food is the most important part of CiviCRM Sprints )
- We started the sprint by converting getContactList(), function that is used in quicksearch into api v3. This will allow developers to build quicksearch like interface ( autocomplete ) on any civicrm forms using jquery or smarty. For eg: "Current Employer" field in profile can be converted into quicksearch autocomplete field...
We had a good discussion that came up because we were discussing a change being made to lower the barriers that currently exist for evaluators of CiviCase. We thought it would be good to write down some things:
- Regardless of where the data is stored, everybody wants a way to edit it through the admin pages.
- Files are useful because existing tools can be used to handle revisions, more easily manage staging and production differences, multiple items can be edited quickly, and configuration settings can easily be shared.
- Files can be a problem because you don't always have write access on the server, although this can be managed.
In terms of where we are now and where we could realistically get to by the end of the sprint, the options were:
- Remove the duplicated info that's in the database (case types, activity types, etc) and have the files be the sole source of configuration.
- Something...
If you are running Drupal, the process of configuring CiviCampaign will be a lot easier with the 3.4.6 release. The CiviCRM Engage Drupal module has always provided an xml configuration file which, if imported, setup many default custom fields designed to make CiviCampaign really shine. Previously, the process for importing it required looking up your site key, the absolute unix path to an xml file on the server, and your Drupal username and password. These pieces had to then be combined into an extraordinarily long and error-prone URL which you had to place into your browser. And, you also had to create several contact subtypes and fiddle with several other CiviCRM configuration settings. Now - all of these steps are done automatically by simply enabling the Civicrm Engage module from within Drupal. Furthermore, Eileen has exposed a number of ways to configure the behavior of the Walklist and Phonelist reports in the upcoming release - including the ability to:
- ...
As it is well-known, you can never have too many Dave's, so we've gathered three of the four Dave's here (Dave G, Dave J, and Dave D) along with some nice and smart people not named Dave (Tim O, Yashoda), and are working towards incorporating some community feedback into CiviCase. A list of improvements we're currently working on here at the sprint includes:
* Adding case id to the activity-related form hooks. This should make it easier to do conditional processing based on case type or other criteria. This might also set the stage for a more dynamic timeline, maybe via a hook to pre-create the next scheduled activity or some rules integration.
* Custom fields at the case level while still maintaining via activities the philosophy that such a value changes because of something that happened, and recording the story behind why and who is as important as the what.
* Filtering case role assignment and activity assignment by a group, and...
Read moreGiven that there's an upcoming code sprint in the UK where rumor has it there will be some work done to improve CiviCase, I thought I would put my wishlist out there and get the community's response. I'm a pretty frequent and detailed user of CiviCase, and although the majority of our actual service delivery is interactive, either on the phone or in person, we send and receive a lot of email correspondence, some of which ends up being relevant to one or more cases. So one category of improvements I'd like to see involve the email processor and its functions.
I wish the email processor would:
- allow me to select multiple activities at once to be filed on a case (perhaps with a checkbox interface similar to what appears in a contact search);
- allow me to delete activities that have been attached automatically to a contact, sometimes by mistake;
- allow me to see a reference in a user's activity stream after...
Imagine for a moment that CiviCRM is a garden. In all its object oriented complexity lie bugs and weeds that need to be effectively discovered and managed. Managing a garden the size of CiviCRM is a daunting task for one individual, and even a team of developers along with a community of end-users and testers still need help. There is indeed help to be found!
Most gardens have a gnome or two. CiviCRM has dozens. Our little army of workers were deployed from the xUnit, a top secret, multi-lingual consortium who's primary concerns are the sanity of software developers and confidence of end-users. These assertive xUnit workers diligently patrol the garden for problems. When a problem is found, the local worker will switch xe's hat from green to red in order that...
On Tuesday and Wednesday of this week we had the a CiviCRM Code Sprint in San Francisco. We had a total of 9 participants over 2 days: Arthur from the WikiMedia Foundation, Micah from Electronic Frontier Foundation, Coleman and Brylie from Woolman - Sierra Friends Center, Peter and Adam from Giant Rabbit, Stacy from elMobile and Dave and Lobo from CiviCRM. Here are a few things that we worked on during the sprint.
- Peter from Giant Rabbit gave a demo of the CiviCRM install for Compass Point and specifically the event management system. One of the requirements was the ability to allow multiple people to sign up for multiple events at the same time. They developed a new drupal module that interfaces with CiviCRM event api and database. You can...
The morning after....the API mini sprint in Brussels.....time for a blog post! I was getting ready for a developer camp, then getting ready to spend hours with Xavier coding like mad, and finally ended up with an API sprint with Luciano, Josh, Andreas, Hartmut and Xavier. Good fun, nice to once more appreciate the community I am part of. Xavier made me very happy with the api/ajax/doc, superb! Luciano contributed the Note API, Andreas was busy getting to grips with the API calls from the BAO, Hartmut dug into the unit tests and I had my satisfying progress with the XML part of the REST interface.
And on top of that Xavier and I took the decision to deprecate Location API and replace it with Address, Email and Phone API. I am not sure when this will be released, but I will get going with it straightaway. Good sprint, I love our community and I definitely prefer cold Belgian beer!!!!
Erik
Read more