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

[REF] extract internals of Payment.create into function on BAO class. #13370

Merged
merged 1 commit into from
Dec 31, 2018

Conversation

eileenmcnaughton
Copy link
Contributor

@eileenmcnaughton eileenmcnaughton commented Dec 30, 2018

Overview

Code cleanup - move code from api to the BAO

This is a partial of #13330 - trying
to separate out the main code move from the changes.

This is a preliminary cleanup

Before

Code chunk on api

After

Code chunk in BAO.

Technical Details

My only change was to move the code & in terms of difference in approach I changed the name to
addPayment since that is what we are doing but here are some additional thoughts.

  1. I'm inclined to put the class onto a new pseudo-bao CRM_Finanial_BAO_Payment. We already have this
    pseudo-entity on the api level & it gives us a way to build up a place for the functions we are migrating
    towards.

  2. I think we should consider changing the input parameters to this function to be

  • contributionID, total_amount & line_items or in some way limiting the parameters tha
    t get passed through. We have historically gotten ourselves in trouble by
    having people hacking in another parameter to go through whereas the strength of the api
    is clear inputs & outputs. I note the api will need to support
    'is_email_receipt' as will this fn & the CRM_Contribute_Form_AdditionalPayment::emailReceipt
    should be moved off the form layer - possibly to our new BAO
  1. I think the exceptions need to be CRM_Core_Exceptions if thrown in the BAO although this is kinda cosmetic

Comments

@jitendrapurohit @monishdeb I'm proposing that we do the code move first before any other changes. I did a rebase of #13330 over this & pushed it up to github & it makes it clearer the actual changes that have been made to the code currently in the api to make this work - and I think we should then work through why we are making those changes

I've added a few thoughts on that commit -

570243c#diff-7a5b0e2d131dabc49178460fc63328c0R4495

But I think it makes sense to agree whether we want a new class for our new 'reviewed & preferred' payment functions first - e.g CRM_Financial_BAO_Payment as a pseudo class or we could call it something else.

@eileenmcnaughton
Copy link
Contributor Author

test this please

This is a partial of civicrm#13330 - trying
to separate out the main code move from the changes. My only change was to change the name to
addPayment since that is what we are doing but here are some additionaly thoughts.

1) I'm inclined to put the class onto a new pseudo-bao CRM_Finanial_BAO_Payment. We already have this
pseudo-entity on the api level & it gives us a way to build up a place for the functions we are migrating
towards.

2) I think we should consider changing the input parameters to this function to be
- contributionID, total_amount & line_items or in some way limiting the parameters tha
t get passed through. We have historically gotten ourselves in trouble by
having people hacking in another parameter to go through whereas the strength of the api
is clear inputs & outputs. I note the api will need to support
'is_email_receipt' as will this fn & the CRM_Contribute_Form_AdditionalPayment::emailReceipt
should be moved off the form layer - possibly to our new BAO

3) I think the exceptions need to be CRM_Core_Exceptions if thrown in the BAO although this is kinda cosmetic

Change-Id: Ib5caf0d878e9c5cc735cb1a20c640f61da2dbfc6
@seamuslee001
Copy link
Contributor

Adding merge on pass based on doing an eye by eye line check of the code confirming that it is just whole extracted and looks sensible

@seamuslee001
Copy link
Contributor

Merging

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.

2 participants