Activities in 1.8 has been implemented in quick way. During 2.0 activities schema change, I've commented out most of code which is related to cases, but is present in Activity classes. Proper way to implement cases would be to assume two basic rules:
- cases themselves are basic "scaffolding" for grouping and ordering activities, therefore all the possible logic for cases should be in classes/files/namespace separate from activity code. This approach would make it possible to extend case logic further and develop it to be fully blown case management functionality with time.
- second rule is in slight opposition to first one: cases are closely tied to activities, so we cannot avoid some "tangled" code. At the first (and second) sight, it seems that we should be able to get away from that problem applying one simple practice: any cases related code in activities should be enclosed in a condition, which checks if cases have been enabled in system wide preferences. There are practically only two places where this should be necessary: case adding/editing/displaying screens and templates (making "case subject" field available) and Activity BAO, where we need to explicitly call functions from case BAO (also enclosed in proper if condition!).
Please avoid any operations on database directly in Forms/Pages, etc.
Also, please stay in close touch with me while implementing this issue.