Details
-
Type: Improvement
-
Status: Done/Fixed
-
Priority: Major
-
Resolution: Fixed/Completed
-
Affects Version/s: 2.2.2
-
Fix Version/s: 3.0
-
Component/s: CiviContribute, CiviEvent, CiviMember
-
Labels:None
Description
Contribution status change should propagate to the related pariticipation/membership. If done via a batch action, it should happen automatically; if done by hand (single case), the user should be asked whether the status change should propagate.
Likewise, participation/membership status change should propagate to the related contribution. If done via a batch action, it should happen automatically; if done by hand (single case), the user should be asked whether the status change should propagate.
==== Spec update 7/30/2009 =====
This change affects two workflows:
- Update Pending Pay-later event registration from Participant form
- Update Pending Pay-later membership from Membership form
However, I think the form rules and processing below works equally for Add mode (e.g. new participant or new membership with payment recorded).
1. In order to handle form input properly for updates done via the Membership and Participant forms, we need to use a new separate function called from these forms postProcess() to handle the related contribution record update and receipting (rather than the shared BaseIPN function). This new function allows us to fix the two bugs described in this comment: http://issues.civicrm.org/jira/browse/CRM-4395?focusedCommentId=28499&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_28499
1.1 Build form change:
- UNSET the following contribution statuses from the select array in both forms (they are only used for pledges and pledge payments): In Progress, Overdue
1.2 Participant form only - add Jscript warning (confirm dialog) on form submit:
- If contribution status = Completed and participant status = Pending pay later, put up confirm() dialog: "The Payment Status for this participant is Completed. The Participant Status is set to Pending from pay later. Click Cancel if you want to review or modify these values before saving this record."
1.3 Additional form (validation) rules:
- If contribution status is "Failed" on form submit - throw validation error: "Please select a valid contribution status before updating". NOTE: We're not unsetting this status in 1.1 because the record my have that status set during initial online transaction processing.
1.4 Post process:
- Post process should generate a complete receipt (if send_receipt true) - including the form values for Paid By, Check # (if present), etc. For Membership, the user supplied receipt_text should be included.
- For the Participant form we can use the supplied form values in updating the participant and contribution records
- For the Membership form, use these rules to set Membership status:
- If contribution status = Completed, use membership status rules to set membership status (join date = today()). So for default status rules - membership status would be 'New'.
- If contribution status = Cancelled, set membership status to Cancelled