E-mail
Case Configuration - Property Tree
- Case Type Name - linkage to DB case type option value record (use option_value.name column - which is untranslated)
- Activity Types - which types are allowed for this case type
- Activity Type
- Key Name - linkage to DB activity type (civicrm_category) record (use category.keyname column - which is untranslated)
- Max instances - How many times can this activity occur in a case. Omit this element if no maximum is needed.
- Actions/triggers - Extend/override core activity preprocess, form building and validation, postprocess. Examples are listed below. These behaviors may be handled completely programmatically (e.g. not configured via XML).
- Named Activity Sets - sets of activities used to populate the case timeline OR for "reporting and case reviews"
- Activity Set
- Set Name (untranslated) and Label (for user display)
- Standard timeline? (true/false) - if true, this set is used to auto-populate activities when a case is created (or when case_type is changed)
- Activity Type - Referenced by keyname
- Reference Activity - Schedule this activity N interval (i.e. days) after the reference activity (where N = Reference Offset). If NULL, then reference point is date when timeline begins or is reset from.
- Reference Offset - Interval after reference activity to schedule this activity. NOTE: Initially, the interval will always be expressed in days, and we'll use the interval code spec'd in PHP's date_add function - e.g. '5D' = five calendar days. We can potentially add support for weeks, months, and potentially "business days" using other suffixes if and when needed.
- Reference Activity Selection - Which reference activity to pick if there's more than one instance in the case. Valid values are "newest" OR "oldest".
- Activity Set
- Activity Type
- Case Roles - valid relationship types for this case type (used to auto-populate the case's relationships when a case is created or case_type is changed
- Relationship Type
- Relationship Type ...
- Activity Types - which types are allowed for this case type
Sample Case Configuration XML File
Sample activity types 1.2
Activity Type "Actions" - Examples
Open Case
- Requires: Case Type
- Form actions
- Start with the CiviCase "version" of the Activity edit form template
- If no contact ID is passed, replace the "Client" (e.g. "With Contact") field with a "New Client" fieldset (profile driven or hard-coded set of contact fields, e.g. First, Last, Email, Phone).
- Inject "Case Subject" field
- Inject custom fields if any are configured for this activity type
- Post Process
- Create new contact record (for "no contact ID" condition)
- Create new case record - set start_date, subject, case_type, status_id
- Create activity record
- Create case_activity record
- Create relationships as configured for the case type
- Create auto-populated activities as configured for the case type ("standard timeline activity set")
Breaks in Case Timelines Activities like "Reopen Case" (when a case is suspended / on hold) create breaks in the case timeline. These activities can be configured to trigger an invite to the user to reset the timeline. Timeline activities which should be scheduled relative the "beginning" of a case OR the resetting of the timeline can be flagged by having the "Reference Activity" value be NULL. Alternatively, we can simply allow multiple "Open Case" and "Close Case" activities in the case. Timeline activities scheduled relative to the opening or re-opening of a case use the "newest" open case instance to rebuild the timeline when requested to do so.
Change Case Type
- Requires: Existing Case
- Form actions
- Start with the CiviCase "version" of the Activity edit form template
- Inject "(New) Case Type" field
- Inject "Reset Case Timeline?" field. Yes/No radio button. Default = Yes.
- Inject conditional "Restart Timeline On" field. Date select. Default = today. Show this field when Reset Case Timeline = Yes.
- Inject "Reset Case Roles?" field. Yes/No radio button. Default = Yes.
- Inject custom fields if any are configured for this activity type
- Post Process
- Update civicrm_case.case_type_id
- If "Reset Case Roles" = TRUE, then
- Delete existing relationships for the case where the "case role" is unassigned (e.g contact_id_b is NULL)
- Create relationships as configured for the NEW case type
- If "Reset Case Timeline" = TRUE then
- Delete existing case activities where is_auto = TRUE
- Create auto-populated activities as configured for the NEW case type ("standard timeline activity set")
Current Prescribing Privileges
- Requires: Existing Case
- Form actions
- Start with the CiviCase "version" of the Activity edit form template
- Inject custom fields if any are configured for this activity type
Change Case Status
- Requires: Existing Case
- Form actions
- Start with the CiviCase "version" of the Activity edit form template
- Inject "Case Status" field
- Post Process
- Update civicrm_case.status_id
- If new status = "Closed", then set civicrm_case.end_date = current date
Closed cases can have scheduled activities
A case might be "closed" (I hate that word!) and still have scheduled activities. In the return to work case, it could be that the case is under appeal, or sometimes if they didn't return to full duties there might still be monthly meetings to re-assess the tasks they can do. In some of the other P.H.P. types it might be that there's a followup scheduled to make sure things are ok.
Case Reporting
Notes on CaseReport.xml formatting
- This file is now stored in our svn repository. Please do not edit the attachment on the wiki. Make all changes to the svn file
- Current use case is to support one <ActivitySet> per "report" (i.e. per output file). However the XML structure can support multiples.
- Dates will be output in ISO 8601 format: YYYY-MM-DDThh:mm:ss (no time-zone offset will be included for this phase as we don't have user-preference support and server-based timezone may be misleading)
- A data type will be provided for each field-level element: <Type>String</Type>. We'll use the same type options as used in our custom fields data_type column: String', 'Int', 'Float', 'Money', 'Memo', 'Date', 'Boolean', 'StateProvince', 'Country', 'File', 'Link'
Reference Spreadsheets
| PHP-BC has assembled several spreadsheets which cover the metadata that will be needed to configure their installation. Some of these listings are relatively complete, others provide a representative "chunk" of data. The listings are useful in deciding on architecture / metadata storage methods, as well as scaling issues we might encounter. |
Activity Types and Requirements by Case Type
Relationship Types by Case Type
Activity Types with Activity Categories and Custom Fields 1.1 (See the attachments for the 1.2 version.)
1 Comment
Hide/Show CommentsNov 13, 2008
D D
We've recently been discussing removing the category field from the activity type.
I never actually thought about how the "categorization" in our Safety Net system came to be, because we don't actually call them categories, but here's what seems to have evolved in Safety Net:
1) There are lots of activities (milestones) since there are multiple organizations using the same dataset and they each have their own needs (but share many). So when you are entering an activity, the list from which you choose the type is categorized, to make it easier to locate the type. In CiviCase, there's the autocomplete field that makes categorization unnecessary. (Although I don't see a way currently in CiviCase to see the entire list - for novice users?)
2) On the reporting side, on a per report basis (actually a per "SLA item" basis), you can assign a category for the item so that they can be separated in the report. Since this is defined independent of the activity type, again it implies the categorization on the activity type definition itself is unneeded in CiviCase. Other reports that use milestones are usually highly customized and specific to a certain business question, so categorization isn't needed there either.