Unused Field in civicrm_case table

[jmturner]

I'm new to civicase and I am really excited about it.  I do have a couple of questions:

1) What are the purposes of the subject and detail fields in the civicrm_case table?

2) How come when I create a new case the values I enter into the subject and details fields don't show up there?  

3) How come after I create a new case when I'm viewing the case the subject and the details of my case don't show up at the case level, but rather at the Open Case activity level?  

4) How do I modify the details of the case that are applicable at the case level rather than at a specific activity level or is this not something that is possible?

It seems as if the database architecture doesn't match up with the application architecture and I'm having trouble wrapping my head around the disconnect.

Thanks in advance!

[Dave Greenberg]

Hi Jim - Your confusion is understandable :-). The subject and details columns in civicrm_case are "legacy artifacts" from an early implementation and we haven't quite decided to remove them until we get a bit further down the road w/ a larger variety of sites / use cases.

The 1,000 foot view summary is: "Cases are simply containers for relationships ('Case Roles') and interactions ('Activities'). Pretty much all "attributes" of a case are determined during an interaction - and should be recorded as an interaction - including opening and closing a case, changing case type, etc."

Some good background reading to help wrap your head around the architecture:
- http://civicrm.org/node/354
- http://wiki.civicrm.org/confluence/display/CRMDOC/CiviCase+Configuration

Feel free to post back w/ specific use case-related questions.

[jmturner]

This is very helpful thanks.  

I could see scenarios when it may be useful to have additional details and someday custom fields that are unique to specific cases.  An overview of why a specific case was opened to begin with being visible at the case summary level, rather than buried in the Open Case activity.

I've heard rumors that support for Prospecting is underway, but I was hoping that I might be able to utilizes the Case feature set to mimic features needed to support prospecting.  It would be great for instance, if I could attach a subject and description for each case indicating what we are currently pursuing a given contact for as far as a dollar amount or campaign effort.  It would be desirable to have this information at the case level so it can always be seen regardless of the specific activities that are taken in pursuit of the ask and securing the donation.  The the subject and details fields got me hopeful, but the more I read, the more it seemed that Cases were intended for a different purpose.

Any thoughts or information are more than welcome.

[Dave Greenberg]

Jim - CiviCase is still a "young" component and I think we are all open to exploring / expanding requirements and functionality as more use cases are brought to bear. Physician Health Program has a list of Feature Candidates for Phase 3 (currently scheduled to be part of the 3.2 release cycle - first part of 2010):

http://wiki.civicrm.org/confluence/display/CRM/CiviCase+-+Phase+3+Candidates

One of the top priority items would likely handle your requirement for exposing selected data at the case level:

"Summarize selected fields from case activities on the Manage Case screen (see item 28 in CiviCase - Phase 3 Candidates)"

So with this functionality in place, folks could enter "what we are currently pursuing a given contact for as far as a dollar amount or campaign effort..." in the Open Case form (activity) and configure CiviCase to include that in case summary. Some details are TBD (as to where in the UI the fields are exposed).

I think we're also open to a discussion about exposing those case record-level fields for direct input / output on a configurable basis.

[jmturner]

That sounds fantastic.  That would do what we need it to do for the short term for sure.  Please let me know if I can be of any help when it comes time to testing that feature set.

Thanks for the great explanation and for taking the time to understand our needs!

[Andrew Clarke]

It's great to see some enthusiasm for the feature set that's already there, and some appreciation for the ideas we have for improvement.  Also great to have another person/organization with an entirely different set of envisioned uses for the component who is willing to test features against your stream of evolving requirements.

I think that we've definitely found a common ground about the amount of "case level" information that needs to be displayed persistently for reference.   We also seem to be in agreement that those data elements should probably be configurable because of the diversity of uses to which this component might be put.

My role in this discussion has so far been to support the extremist position of "everything is an activity, and should be represented as such".   I can see how some folks might really really want to go in and edit directly what they perceive to be an attribute of a "case" (like your example of a contribution dollar amount target field).   So I think the compromise position that occurs to me would be to allow that, but to auto-create an activity in the stream when that happens: something like "James update the contribution target field from 5,000 to 10,000 on 2009-01-03 at 14:25" .   

Just rambling for the moment.  These traces of discussion will become very helpful when we get down to business in planning the next release cycle and prioritizing the feature queue.   Thanks for your interest and participation!

[demeritcowboy]

I agree with Andrew and I'll even state that in a theoretical software design I wouldn't model a case as a table. Rather, case is a view on the activities. There are some ways to do that, one being to define a case as a set of criteria, like in a rules engine. While it would allow for some neat kinds of automation, it would be extremely tedious and complicated to set that up. Another way is to define a type of activity that the user can create to identify which of the activities in the system collectively comprise a given case. There's even a couple different ways to do that, but the question is is it necessary to have it all be theoretically neat and tidy to do what you need.

Once you make case a table then it becomes arbitrary where you stop putting things in the case table. But it seems like a good compromise to get it done.

The open case activity was itself a compromise, because activities are actually sets of smaller activities themselves, and we considered wizards and such, but since it was quickier/easier to put some custom fields together we went that route in phase 1.

And I think Dave G is right that the summary feature will help in this case, no pun intended.