In the thick of CiviCase pre-alpha

As I've said elsewhere, it's been a real pleasure working closely with the CiviCRM team on the CiviCase project. The work we're doing is exciting, and has at least a hope of offering some efficiency to the large number of service providers whose work is organized into "cases", however that term is locally defined. Designing for the variety of different potential uses for the case module is quite a challenge. Although the first release of CiviCase has to meet our immediate needs at the Physician Health Program of BC, we would be quite disappointed if it turned out to be extremely difficult for other case management groups to understand how they could implement it to meet their own needs. So I've been spending quite a bit of thought energy trying to prevent this from happening. We think we've solved a number of important issues that have arisen in other case management systems I've used, but certainly we haven't covered them all just yet. Also, we need to take what we've got and try it out a bit before we can understand the issues we might have created as we try to solve others. This is the joy of "Agile" or iterative development. We know we can't get ALL the specs 100% right the first time. We're ok with that. One thing we're just starting to think about is a way to integrate all the externally developed standardized vocabularies that people need to associate with cases. We have a few that crop up in the case types we deal with, and other people will have entirely different ones. Right now we're looking at a way to suggest something for 2.3+ that might make integrating these vocabularies less cumbersome than it seems to be now in many instances. Meanwhile, I'm just personally looking forward to getting my hands on the alpha release of CiviCRM 2.2, which will include CiviCase. It's going to be good!

Comments

Hi,

Albeit not specifically for case, I've had to create some identical tags/groups/custom attributes list of values/type of relations... between different sites.

It'd be great to be able to import/export these lists, and provide them as file somewhere (eg. in the wiki).

X+

P.S. Right now, tend to hammer that at the php/sql level as soon as they are "enough". Not the most elegant solution, but less painful that having to create them by hand...

2.2 will include command-line feature to export custom field "definitions" from an install (to an XML format), and import the same. However not a complete "configuration" dump. You can check out the in-progress code for this in svn at bin/migrate/import.php and export.php.