Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CRM-20610: 'Edit Contribution' backoffice improvements #10386

Closed
wants to merge 3 commits into from

Conversation

monishdeb
Copy link
Member

@monishdeb monishdeb commented May 20, 2017

@@ -4145,6 +4146,27 @@ public static function getPaymentInfo($id, $component, $getTrxnInfo = FALSE, $us
}
$paidByLabel .= " ({$creditCardType}{$pantruncation})";
}

// show payment edit link only for payments done via backoffice form
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: do any online payment processor plugin currently support changes to the value of a transaction, @eileenmcnaughton ? If so, we should allow those payments to be editted. JMA is aiming to support this for Authorize.net this summer assuming client funding comes through.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Smart debit for direct debits in the UK certainly supports changing the value of the transaction via the API, it's not really being used yet on the civi side, but you can do it via the "Update billing details" link.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mattwire So at present there is no support for this within CiviCRM, correct?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JoeMurray Not as far as I know :-)

@@ -1507,6 +1513,18 @@ protected function submit($submittedValues, $action, $pledgePaymentID) {
if (!empty($this->_payNow)) {
$this->_params['contribution_id'] = $this->_id;
}
// since we are hiding the payment details block in edit mode it
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please remove 'it' from end of line. Thx.

@@ -96,7 +96,7 @@ public function getPaymentFormFields() {
// Really we should render check_number here, but we need to review how we edit
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that we are going to be rendering check number properly on payment area of pages, not in overal contribution area. Since we are addressing the implied To Do of this comment, let's remove the comment.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually that change is doing the reverse of what you say Joe & I think it may be a mistake / in conflict with changes & approach in other PRs

{/if}
{ts 1=$entity}No payments found for this %1 record{/ts}
{/if}
{include file="CRM/Contribute/Form/PaymentInfoBlock.tpl"}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. Thanks for this cleanup.

<tr id="checkNumber" class="crm-contribution-form-block-check_number">
<td class="label">{$form.check_number.label}</td>
<td>{$form.check_number.html}</td>
<div class="crm-accordion-wrapper crm-accordion_title-accordion crm-accordion-processed payment-details_group">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice cleanup. thx.

@monishdeb monishdeb added the needs-work-not-review-ready Submitter required to take action, will be closed after 1-2 weeks in this state label Jun 16, 2017
@monishdeb monishdeb force-pushed the CRM-20610 branch 5 times, most recently from a3b9e13 to ae9fb83 Compare June 16, 2017 21:46
@monishdeb monishdeb removed the needs-work-not-review-ready Submitter required to take action, will be closed after 1-2 weeks in this state label Jun 17, 2017
Copy link
Member

@colemanw colemanw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested this out. In the issue it says "On Edit Contribution, freeze/disable CC fields for contribution paid by using payment processor via online contribution page or CC"
However after trying this PR the form looked like this:
cc-test
Both CC type (icon) and last-4-digits are editable fields. However CC type does not appear to show the card type as selected. Changing it has no effect. But the last-4 field is editable. Not sure what effect editing it has, or why you'd want to do so.

@monishdeb
Copy link
Member Author

@colemanw
I am getting expected result and the CC fields were freezed/readonly for online contribution. These are the steps I used to replicate:

  1. Created a online contribution (using contribution page - 'Help Support CiviCRM')
  2. Edit the created contribution

On backoffice form:
screen shot 2017-06-29 at 8 19 35 pm

@colemanw
Copy link
Member

colemanw commented Jun 29, 2017 via email

@monishdeb
Copy link
Member Author

monishdeb commented Jun 29, 2017

@colemanw yes I did that before testing

Monishs-MacBook-Pro:civicrm monish$ git fetch upstream master
git pull --rebase upstream master
remote: Counting objects: 58, done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 58 (delta 32), reused 52 (delta 28), pack-reused 1
Unpacking objects: 100% (58/58), done.
From github.com:civicrm/civicrm-core
 * branch            master     -> FETCH_HEAD
   5daede3..d5ce186  master     -> upstream/master
Monishs-MacBook-Pro:civicrm monish$ git pull --rebase upstream master
From github.com:civicrm/civicrm-core
 * branch            master     -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: CRM-20610: 'Edit Contribution' backoffice improvements
Applying: IIDA-84: add trxn_date in payment details block
Applying: QA fixes and revert standalone payment-edit implementaion
Monishs-MacBook-Pro:civicrm monish$ 

Also in your screenshot there is no transaction ID set, seems like the contribution is created via backoffice form not via contribution page or via 'submit credit card card contribution'. So the CC fields are expected to be editable.

@monishdeb
Copy link
Member Author

monishdeb commented Jun 29, 2017

NOTE: The CC field value will be readonly if contribution created via any contribution page or via 'submit credit card card contribution'. The CC fields will be editable ONLY if contribution are created via backoffice form. And the browser cache need to be cleared to resolve any js glitch related to CC-type.

After doing contribution via backoffice form :
screen shot 2017-06-29 at 8 48 31 pm

@eileenmcnaughton
Copy link
Contributor

Isn't this back to going down the path I refused to merge :-) I think I was committed to not overloading the edit transaction form with editing (potentially one of many) transactions & instead we were going to have a display of the transactions & links to edit them.

I guess I haven't been prepared to put the hours into reviewing this so I'd better leave it in @colemanw 's capable hands.

@monishdeb
Copy link
Member Author

monishdeb commented Jun 30, 2017

@eileenmcnaughton the changes were made in accordance with IIDA needs. I don't think we are overloading or showing any extra fields rather than rendering the same set of payment method fields (checkNumber / CC-type and pan_truncation) that we are already featuring on backoffice form for creating a new contribution. So on edit mode, I have ensured that the these payment fields are readonly screenshot ) for contribution done using payment processor or else editable if payment made via backoffice form i.e. using manual payment processor.

In addition to that this PR contain other improvements like:

  1. Showing check_number upon selecting Check PI.
  2. Adding transaction_date.
  3. Moving recieve_date between contribtution status and revenue date.

@JoeMurray
Copy link
Contributor

@Eileen could you remind me of your preferred approach to the UI for this? It sounds like a list of payments that could be individually edited is the direction of your thinking.

@JoeMurray
Copy link
Contributor

@eileenmcnaughton ^

@pradpnayak
Copy link
Contributor

Tested. The patch works fine

On Edit screen Credit card type and Last 4 digit credit card number are allowed to update and also updated in financial trxn when saved in case of payment not done via payment processor. But incase of payment done via payment processor this fields are freezed on edit screen of contribution.

However i found a bug, Payment Instrument is stored wrong when Submit Credit Card Event Registration is done.

@eileenmcnaughton
Copy link
Contributor

@JoeMurray - yes - I think when we last discussed this the idea was that on the tab view of payments there would be a link to pop up an edit and that same code snippet (the list of payments with the action link to edit) would also show up on the view & edit views of a contribution.

The key thing for me here is the lack of a one-to-one relationship causes complexity on an already complex form

@JoeMurray
Copy link
Contributor

@monishdeb @pradpnayak I agree with the direction of @eileenmcnaughton's thinking: we should not be editing those fields on contribution edit, but on payment edit. On contribution with multiple payments by backend credit card, we wouldn't know which should be used. Please revert from contribution edit and add to payment edit.

@monishdeb
Copy link
Member Author

Marking with [wip] as the changed spec need approval first, as discussed with @JoeMurray

@monishdeb monishdeb added the needs-work-not-review-ready Submitter required to take action, will be closed after 1-2 weeks in this state label Jul 12, 2017
@JoeMurray
Copy link
Contributor

@monishdeb would it be better - I'm not sure - to close this and open a new PR given the significant UI changes? The downside is that we lose the connection to the comments here

@eileenmcnaughton
Copy link
Contributor

@JoeMurray @monishdeb I think opening a new PR & linking here for reference is better than changing this PR to be something substantially different to what the comments are discussing

@monishdeb
Copy link
Member Author

@eileenmcnaughton agree, created separate PR #10729

Closing it now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
master needs-work-not-review-ready Submitter required to take action, will be closed after 1-2 weeks in this state
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants