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] Move wrangling of Front end form contribution param for autoRenew back to form #15927

Merged
merged 1 commit into from
Dec 9, 2019

Conversation

eileenmcnaughton
Copy link
Contributor

@eileenmcnaughton eileenmcnaughton commented Nov 22, 2019

Overview

Refactoring towards cleaning up processAmount function

Before

$component is a param that is code for 'add autoRenew elements to the array'

After

$component is no longer a param. The places where this is needed are now calculated on the form

Technical Details

The processAmount function is really problematic because it's trying to do several disparate things & is called from
all over the place with unclear intent. From looking at it I see it does a few things. It reformats line items,
it does some obscure & likely flawed filtering, it generates a total cost & a tax cost and it generates a very
specifically formatted array of autoreneal properties,

The way I see this going is

  1. Move the formatting of the autorenewal back to the calling form (this PR) & simplify it
  2. Split out the foreach so it goes through once & formats - this can be shoved out to a separate function
  • and then it goes through the formatted array & calculates total_amount & tax_amount - we should
    have a wrapper function that just returns these & we might see that is most of what is needed
  1. Move all that awful partial_payment_total stuff back to the event form. Note that we are working
    to entirely remove that from here are it makes so much less than no sense.
  2. Calculates amount_level text - that should have it's own function.

It worth noting all of this does very little intensive work - a DB lookup or 2 that could be cached & an iteration
through a very small array so it would be fine to have 3 functions -

  • getAmountTotal
  • getTaxTotal
  • getAmountText

that each go through the same process of generating a formatted array from price_x => 5 etc rather than trying
to pass the array around for 'performance' or to 'save work'.

From previous refactorings I would suggest we add an Order class such as eileenmcnaughton@6d60f4f where by you set the price fields
& then you can call 'getLineItems' - but that is a few steps after this....

Comments

@seamuslee001 @monishdeb @mattwire I'm hoping some combination of you can help work through this with me. I think that once we have a function to getTotalAmount from a set of price set params we'll be in a much better place to clean up a bunch of code. The confusion around passing things like line item by reference & why we have to pass in 'fields' & where that comes from has been holding us back IMHO

@civibot
Copy link

civibot bot commented Nov 22, 2019

(Standard links)

@civibot civibot bot added the master label Nov 22, 2019
…ew back to form

The processAmount function is really problematic because it's trying to do several disparate things & is called from
all over the place with unclear intent. From looking at it I see it does a few things. It reformats line items,
it does some obscure & likely flawed filtering, it generates a total cost & a tax cost and it generates a very
specifically formatted array of autoreneal properties,

The way I see this going is
1) Move the formatting of the autorenewal back to the calling form (this PR) & simplify it
2) Split out the foreach so it goes through once & formats - this can be shoved out to a separate function
- and then it goes through the formatted array & calculates total_amount & tax_amount - we should
have a wrapper function that just returns these & we might see that is most of what is needed
3) Move all that awful partial_payment_total stuff back to the event form. Note that we are working
to entirely remove that from here are it makes so much less than no sense.
4) Calculates amount_level text - that should have it's own function.

It worth noting all of this does very little intensive work - a DB lookup or 2 that  could be cached & an iteration
through a very small array so it would be fine to have 3 functions -
- getAmountTotal
- getTaxTotal
- getAmountText

that each go through the same process of generating a formatted array from price_x => 5 etc rather than trying
to pass the  array around for 'performance' or to 'save work'.

From previous refactorings I would suggest we add an Order class where by you set the price fields
& then you can call 'getLineItems' - but that is a few steps after this....
@eileenmcnaughton
Copy link
Contributor Author

@mattwire @seamuslee001 @monishdeb it would be nice to get this clean up merged - it does help simplify a rather nasty function

@seamuslee001
Copy link
Contributor

This looks right and i think the code change makes sense to me and seems a sensible consolidation and we have plenty of tests i believe covering auto renew so i think we can merge this based on the tests passing

@seamuslee001 seamuslee001 merged commit c03df98 into civicrm:master Dec 9, 2019
@seamuslee001 seamuslee001 deleted the event_form branch December 9, 2019 02:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants