Details
Description
This issue describes the modifications needed to the "Core" activity form elements, validation and post-process for activities which belong to a Case.
New Activity
==========
For phase 1, we will always link to CiviCase's New Activity form from the View Case screen. The user will select an "activity type" from the list of types valid for that case's case type. The following params are available to the form when it loads:
- case Id
- activity type
- target contact id
- default source contact id (user's contact id)
Form Fields
==========
Activity form for CiviCase will have the following elements ( corresponding DB field shown in [square_brackets] );
- Client [target_contact_id] - Frozen, Display Name of target contact (this replaces "With Contact" field - since target is not modifiable in this form)
- Activity Type [activity_type_id] - Frozen field displays civicrm_category.label
- Reported By [source_contact_id] - This is the existing "Added By" dojo comboBox field with a new label. Defaults to logged in user, but any other contact can be selected.
- Case Role [relationship_id] - If this user has 0 relationships to this case, omit the field. If this user has 1 relationships to the case - frozen field displaying that relationship type b_a_name. If this user has > 1 relationship to case - HTML <select> with the relationship types. Not required - so select should include NULL option (' - select role - ').
- Assigned To - (no change)
- Subject [subject] - NOT required, default to Activity Type label
- Medium [medium_id]- <select> field with values from 'Encounter Medium' option group, required
- Due Date [due_date] - date time with calendar widget
- Actual Date [activity_date] - new label for the existing "Date and Time" field
- Duration [duration]
- Status [status_id]
- Details [details]
- ( custom fields as configured for the activity type ) - NOTE: We may want this <div> moved up higher in the form - we'll discuss with the client.
- "Send Copy To" - This is a new section of the form which allows user to send an email containing all actiivty data to one or more contacts who have a relationship to this case. UI is a grid with a header row and one data row for each existing relationship for this case. Grid has 4 columns:
- checkbox (indicates "send to this contact")
- Case Role (relationship_type.name_b_a)
- Display Name for related contact
- Primary email address for the related contact
[ ] ----- Case Role ------- Name --------------- Email
-----------------------------------------------------------------------------------
[ ] Case Coordinator – Dr. Jane Smith — jane.smith@foo.org
Checkbox in header row does "check all" / "uncheck all" as in our standard selector interface.
Row-level checkbox is DISABLED if the contact doesn't have a valid email address.
- Attachments (fieldset)
Form Validation
============
Changes to existing activity form are:
- Subject = not required
- Medium = required
- Either Due Date OR Actual Date is required - but not both
PostProcess
==========
1.1 Insert Mode
---------------------
Use DB defaults for is_auto (0) and is_current_revision (1)
original_id is NULL
1.2 Edit Mode (revisioning) Logic
--------------------------------------------
If is_auto = 1 (logic for auto-created activity which hasn't been modified by a user yet):
- Update existing record with form values
- Set is_auto = 0
If is_auto = 0 (logic for activity which has been created or modified by a user):
- For the record requested for edit, the only update we do is set is_current_revision = 0
- Insert new activity record with updated form values and ...
-> Set is_current_revision = 1
-> Get original_id value for new record:
== > First revision case: If existing record original_id is NULL, use existing record id as original_id for new record
== > Subsequent revisions: existing record original_id is NOT NULL, use this value as original_id for the new record
2. Insert civicrm_log record for the activity (e.g. store the created / edited by contact id and date for the activity)
3. If $send_copy array is not empty, format and send email message to each recipient. We'll need a new TPL for this - SendActivity.tpl - which
should contain the following elements:
Client: $displayName
Case Type: $caseType
... and all activity fields from the form with their values
After sending the email(s), add a tracking record for this to civicrm_log. log.description should contain "Sent copy to: $list_of_recipient_email_addresses". entity_id is the activityID value, modified_id is the activity record creator.
NOTE: Not sure how the logic to check for / invoke activity-type-specific PHP files fits into the general postProcess ??