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

Deprecate creating partially paid contributions, other than by partially paying a contribution. #15855

Merged
merged 1 commit into from
Jan 7, 2020

Conversation

eileenmcnaughton
Copy link
Contributor

Overview

Adds deprecation noise when an attempt is made to set a contribution to partially paid other than by adding a payment (using Payment.create). This is necessary not only because we have a preferred flow but because setting to PartiallyPaid doesn't actually create the financial_trxn that is required if done via Contribution.create flow

Before

Calling Contribution.create with status of 'Partially Paid' quietly does a bad job of creating the appropriate financial records

After

Calling Contribution.create with status of 'Partially Paid' noisily does a bad job of creating the appropriate financial records

Technical Details

As #15706 signposts - creating a contribution with a status of 'Partially Paid'
is not actually a valid thing to do. There are no created financial_trxns & the balance is wrong. In some places the code does
this in conjunction with some parameters. These don't really work either. We need to deprecate & eliminate this flow.

I'm expecting some tests to fail & need fixing before this passes

Comments

@civibot
Copy link

civibot bot commented Nov 15, 2019

(Standard links)

@civibot civibot bot added the master label Nov 15, 2019
@eileenmcnaughton eileenmcnaughton force-pushed the test_dep branch 2 times, most recently from 859618c to 7e4aefe Compare November 15, 2019 20:54
eileenmcnaughton added a commit to eileenmcnaughton/civicrm-core that referenced this pull request Nov 16, 2019
We want to deprecate this as it doesn't work properly. In this case there is no need to test
it as it's not really valid & hopefully soon it would trigger a deprecation notice

Test that will work when we can deprecate civicrm#15855
@eileenmcnaughton eileenmcnaughton force-pushed the test_dep branch 2 times, most recently from 796e805 to 076dcc3 Compare November 21, 2019 07:59
…lly paying a contribution.

As civicrm#15706 signposts - creating a contribution with a status of 'Partially Paid'
is not actually a valid thing to do. There are no created financial_trxns & the balance is wrong. In some places the code does
this in conjunction with some parameters. These don't really work either. We need to deprecate & eliminate this flow.

I'm expecting some tests to fail & need fixing before this passes
@eileenmcnaughton
Copy link
Contributor Author

@seamuslee001 looks like this is mergeable now

@@ -141,14 +140,19 @@ public static function add(&$params, $ids = []) {
$params['creditnote_id'] = self::createCreditNoteId();
}
}
if (empty($params['contribution_status_id'])) {
$contributionStatusID = $params['contribution_status_id'] ?? NULL;
Copy link
Contributor

Choose a reason for hiding this comment

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

Forgive my ignorance, but I don't see what conditions would lead the '?? NULL' to change the value of $contributionStatusID. Whatever is in $params['contribution_status_id'] will be assigned, whether it is NULL or not, regardless of the Null coalescing operator, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it gets populated down on line 155

Copy link
Contributor

Choose a reason for hiding this comment

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

So it will be set to NULL if for some reason $params['contribution_status_id'] is not set and seems sensible here

if (empty($params['contribution_status_id'])) {
$contributionStatusID = $params['contribution_status_id'] ?? NULL;
if (CRM_Core_PseudoConstant::getName('CRM_Contribute_BAO_Contribution', 'contribution_status_id', (int) $contributionStatusID) === 'Partially paid' && empty($params['is_post_payment_create'])) {
CRM_Core_Error::deprecatedFunctionWarning('Setting status to partially paid other than by using Payment.create is deprecated and unreliable');
Copy link
Contributor

Choose a reason for hiding this comment

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

If a contribution with completed status is edited so that the total amount increases, then the status is supposed to change to partially paid. So in that use case I think this error message is inappropriate.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@JoeMurray we have quite a lot of testing on editing values and this line is never hit or the test would fail.

Copy link
Contributor

Choose a reason for hiding this comment

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

@JoeMurray this seems safe to me as the changes that happen here https://github.com/civicrm/civicrm-core/pull/16218/files#diff-0474c991325eed0cec87e8240916ef79R507 which cause the total amount of a contribution linked to an event do not trigger this

@@ -183,9 +187,10 @@ public static function add(&$params, $ids = []) {
if ($contributionID && $setPrevContribution) {
$params['prevContribution'] = self::getOriginalContribution($contributionID);
}
$previousContributionStatus = ($contributionID && !empty($params['prevContribution'])) ? CRM_Core_PseudoConstant::getName('CRM_Contribute_BAO_Contribution', 'contribution_status_id', (int) $params['prevContribution']->contribution_status_id) : NULL;
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't really follow if there is a functional change here or not. From a code readability perspective, I like the creation of the $previousContributionStatus variable even if it is only used once. But it's a bit more complicated how you are doing it. Is the reason for only checking the previous contribution status if there is a contribution and a previous contribution mainly to improve performance? Or is there a possible error that's being avoided? Sorry, I'm trying to help with a review but I'm struggling a bit.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's primarily about making the IF lower down readable in this case.

@seamuslee001
Copy link
Contributor

@eileenmcnaughton @JoeMurray I have reviewed this and concluded it is a sensible move. In regards to your concern Joe, I added in some more assertions into the changed fee selection tests #16218 which demonstrates when an event fee selection is changed such that the total amount increases then the contribution is correctly set to Partially Paid

if (CRM_Core_PseudoConstant::getName('CRM_Contribute_BAO_Contribution', 'contribution_status_id', (int) $contributionStatusID) === 'Partially paid' && empty($params['is_post_payment_create'])) {
CRM_Core_Error::deprecatedFunctionWarning('Setting status to partially paid other than by using Payment.create is deprecated and unreliable');
}
if (!$contributionStatusID) {
Copy link
Contributor

Choose a reason for hiding this comment

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

@JoeMurray So if $params['contribution_status_id'] was set to NULL contribution_status_id key was not included then we should get the contribution status Id here

@seamuslee001
Copy link
Contributor

Jenkins re test this please

@seamuslee001
Copy link
Contributor

Adding merge on pass as it reads fine to me and we have reasonable test coverage in this area

@seamuslee001 seamuslee001 merged commit ae0f40d into civicrm:master Jan 7, 2020
@seamuslee001 seamuslee001 deleted the test_dep branch January 7, 2020 01:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants