[REF] extract internals of Payment.create into function on BAO class. #13370
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
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.
I think we should consider changing the input parameters to this function to be
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
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.