CRM-2988 Merge "Record Offiline Contribution" and "Submit Credit card" forms

    Details

    • Type: Improvement
    • Status: Done/Fixed
    • Priority: Major
    • Resolution: Fixed/Completed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.1
    • Component/s: CiviContribute
    • Labels:
      None

      Description

      Merged "Record Offiline Contribution" and "Submit Credit card" forms.

      • Add another dojo tab "Credit Card Information". It will have cc block and billing address block. You should build this tab based on same logic that is used for showing "Submit Credit Card" link

      =====================================================================
      New and Edit Contribution Forms - Move Transaction ID field out of Additional Information fieldset and into main part of the form
      =====================================================================

      As pointed out on the forum post below, many users recording "offline" contributions will want to record a check #. Currently, the Transaction ID field is hidden in the Additional Information (collapsed) fieldset.

      Move the Transaction ID field into the main fieldset - to the right of the "Paid By" field in the New / Edit Contribution form
      (civicrm/contact/view/contribution?reset=1&action=add&cid=103&context=contribution)

      NOTE: Remember that this field is NOT exposed for editing in Offline.php (/civicrm/contribute/offline?reset=1&cid=103) - since this form is used for submitting credit card transactions. We automatically populate that field with data from the payment processor.

        Attachments

          Activity

          [CRM-2988] Merge "Record Offiline Contribution" and "Submit Credit card" forms
          David Greenberg added a comment -

          Temporarily assiging all back-office payment-related form changes to lobo for re-factor evaluation.

          Kiran Jagtap added a comment -

          -Fixed in r - 14754

          David Greenberg added a comment -

          The merged form is confusing since it mixes fields / blocks needed to record a received cash or check contribution with fields/blocks needed when submitting a credit card contribution via processor. We'll retain the "merged form" approach, but link to the form from two different button links and pass a GET param to differentiate between the two "modes".

          The following changes and fixes are needed:
          1. Replace the current button link - "Record Contribution" with TWO buttons - link text as follows:

          • "Record Contribution (Check, Cash, EFT ...)"
          • "Submit Credit / Debit Card Contribution"

          The second button is only displayed when at least one non-IPN processor is configured and enabled. (This is the same logic as we used in 2.0 to determine whether that action-link was displayed.)

          2. Establish a GET param which differentiates between the two "modes". We also need a GET param which sets _mode to LIVE vs. TEST. Currently this is hard-coded to TEST. Potentially use mode= as param and have 3 modes - one for "Record Contribution" mode (no payment submitted to processor), one for "Submit CC - Live" and one for "Submit CC-Test". As before, the Submit CC mode default is LIVE and the "test" mode is not exposed as a link in the UI. (Also fix TPL where it displays whether submitted contrib is live or test - so that it uses this mode variable (currently looking at $action which I think is always 'add').

          3. When we are in "submit cc" mode, Transaction ID field is hidden (currently it is available for input which is wrong since we're going to write the processor returned value there).

          4. When in "record contrib" mode, the Credit Card Info pane is NOT included.

          5. Misc fixes:

          • ISSUE: Currently, the contributor's Email field is shown when a Pay Proc is available, and not when there is no processor? Not sure why this is. Do we need this field on the form at all? If anything, it should be shown when below "Send Receipt" when that field is checked - so user can control which email the receipt goes to.
          • BUG: Status msg said "...receipt was sent to ..." when I did NOT check "Send Receipt". (It also correctly gave me that status when I checked Send Receipt and the receipt was sent).
          • BUG: Receipt is missing Billing Name / Address and Credit Card blocks. This should be included when we're in "submit credit card contribution" mode
          Kiran Jagtap added a comment -

          reassigning to dgg for QA

          David Greenberg added a comment -

          Testing exceptions r15311:

          • is_test flag in civicrm_contribution is set to 0 even when I'm using mode=test (s/b 1)

          (we properly hide the "Send Receipt" checkbox in this case, but need to fix the jscript error)

          Also, when the selected contact doesn't have an email, the Contributor field (frozen element in top of form) which is supposed to display the current contact's Display Name is blank.

              • The behaviors related to including an Email Address field on this form are too messy and I don't think it's worth fixing them at this point (For example we're currently over-writing an existing primary address if I change the value on this form - which is incorrect.) Make the following changes:
                1. Remove Email address field from the form in ALL modes. Receipt is always sent to the primary email address.
                2. If contact does NOT have an email address, put the following "status message" (yellow block) in a div at the top of the form:
                "You will not be able to send an automatic email receipt for this contribution because there is no email address recorded for this contact. If you want a receipt to be sent when this contribution is recorded, click Cancel and then click Edit from the Summary tab to add an email address before recording the contribution."
                3. If the contact does NOT have an email, hide the "Send Receipt" checkbox. Otherwise, show the email address that the receipt will be sent to.
          • The other Receipt-related field behaviors should be the same for ALL modes (offline, live and test):
            • "Send Receipt" is shown if contact has an email address.
            • "Receipt Date" field is shown unless "Send Receipt" is checked (then it's hidden)
          • Check for required Live vs. Test payment processor values before displaying the form in either mode=live or mode=test. This is the same as what we do prior to displaying an Online Contrib form (e.g. Main.php). If the required values are missing for that mode, throw the corresponding fatal error msg.
          David Greenberg added a comment -

          all exceptions tested ok r15436

          Shailesh Lende added a comment -

          Tested and verified for v2.2 r-18854.

            People

            • Assignee:
              Shailesh Lende
              Reporter:
              David Greenberg

              Dates

              • Created:
                Updated:
                Resolved: