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...
- 3 comments
- Log in or register to post comments
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:
- ...
- 2 comments
- Log in or register to post comments
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 more- 3 comments
- Log in or register to post comments
Given 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...
- 18 comments
- Log in or register to post comments
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...
- 4 comments
- Log in or register to post comments
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- 2 comments
- Log in or register to post comments
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:
- be present in the API forum, trying to help people, share ideas, discuss suggestions etc
- maintain a Wiki page devoted to the API's with to do list, wishes for the next release, conventions, tutorials etc.
- fix reported bugs for the API's that need fixing on a core level
- standardize the API's to follow the conventions as much as possible
Lobo explained yesterday that we have 3 members at the moment: Xavier, Eileen and me. (Xavier and Eileen, were you aware of this :-)) And we recruited Coleman Watts yesterday, so that makes 4. Do we have more volunteers?...
Read more- 5 comments
- Log in or register to post comments
check_permissions setting in $params – if it’s set and true the permission check is performed, otherwise it’s skipped. Later in the code cycle we’ll also add ACL checks (next to the general permission checks).
The civicrm_api_check_permission($api, $params, $throw = false) method located in api/v2/utils.php will either return a predicate whether the given call (with the given params, to be used in the future…) is allowed – or, if $throw is... Read moreToday 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.
We're having to make a few improvements to Civi's hooks, and some modifications to the existing functionality to enable us to package it up, but the benefits are obvious: much easier installation and thus wider uptake of the module, and thus higher CiviCRM adpotion in the UK :)
We spent most of the morning familiarising ourselves with the code and discussing the necessary changes we would need to make. This threw up some difficult problems (I'll spare you the details) but the result was this outline of...
Read more