CiviCase is a case-management system for tracking multistep interactions with constituents -- such as social support services, constituent services, and applications for employment. The CiviCase toolset enables organizations to provide a more consistent quality-of-service to their constituents by setting out a base timeline for the services to provide to each constituent. This is a powerful tool that can be adapted to a variety of organizations and requirements. Unfortunately, the initial configuration process for CiviCase currently requires some technical skill -- the site administrator must prepare an XML file, copy the file to server, test, and repeat until the XML file is just right. Thanks to the support of the National Democratic Institute, that's going to change -- we're going to make it easier for site administrators to setup CiviCase without requiring deep technical skills.
Did that get your attention?
Unfortunately it's not as simple as just coming up with ideas and waiting for a check from Google. As a community, CiviCRM has to apply to even be part of the program. We are still looking for both more project ideas and more mentors to include in CiviCRM's application to be a mentoring organization in Google Summer of Code 2014.
I've been told this blog post was too long. So the tl;dr summary is that organizations with project ideas and developers interested in mentoring a Google Summer of Code student should add their ideas and information to Google Summer of Code 2014 Wiki.
At this point in the process we are trying to make CiviCRM appealing to both potential students and Google. Several months ago we started updating the wiki of project idea...Read more
Fair warning, this post is intended to the technical part of our community, if you don't care about the architecture of civi, please skip this one, I'll come back to you soon with awesome datavisualisation and an interview of Micah about security and privacy (you'll like it).
And if you read anyway, I'm a bit of a drama queen and some of the mountains I describes are probably hills, at best.
As part of the Bristol Civi Sprint a proposed new layout has been suggested for the existing Find and Merge Duplicates page. The page is used to add / edit Duplicate Matching Rules for the individual, organisation and household contact types. This wouldn't involve changes to the way the Merge Rules work but the changes will make the page easier to use and understand.
This would include changing the use of the confusing terms 'Strict' and 'Fuzzy' to 'Front End' and 'Back End' respectively. On-screen help text will explain what the terms mean and how to use the page features. The names of the Rules would also be altered so they reflect the fields used to identify a matching contact.
A mockup of the proposed changes can be found here;
At our last big sprint there was some good discussion about ways to clarify the filtering conventions used on many of the search forms. One specific area that seemed to need "help" is the set of checkboxes for filtering on Pay Later, Recurring and Test contributions. Here's the current version of that section of the form:
With the checkbox interface, it's not obvious what effect checking the box has. Does it cause the search to ALSO include Test contributions (for example), or to ONLY include Test contributions?
Samuel Vanhove from Koumbit followed up by posting a suggested set of changes to the Find Contributions form recently here. Coleman and I discussed the proposed changes and came up with a few alternative approaches. Coleman also pointed at that the use of the word " - select - " on the dropdown filters was not...Read more
Brian Shaughnessy (lcdweb), who has been working with the New York State Senate's CiviCRM project, recently raised the issue of simultaneous editing: What happens when two users simultaneously make changes to same contact record? We've held a few discussions on IRC to examine the issue and draft some solutions. We would appreciate further feedback and ideas on how to address the issue.
As described by Brian:
The issue is that if you and I get into the same record around the same time, and you save the record first, when I save, it will overwrite your changes. So let’s say you add a middle name, and I get in and add a birthdate. The data is not in conflict, and both changes should be preserved, but they aren’t -- when you save the birthdate (where the edit form was loaded before I saved the middle name), the empty middle name overwrites the value I had saved.