-
-
Notifications
You must be signed in to change notification settings - Fork 827
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
Extract getDiscountID()
#27049
Extract getDiscountID()
#27049
Conversation
Thank you for contributing to CiviCRM! ❤️ We will need to test and review the PR. 👷 Introduction for new contributors
Quick links for reviewers |
93a1743
to
13fc461
Compare
getDiscountPriceSetID()
getDiscountID()
3f0689a
to
afb392b
Compare
This is part of a general cleanup to stop passing the form into functions & then checking the form for a possible property. Instead each form that calls the function has a consistent (publicly supported) getDiscountID() function that it calls & discountID is passed in. Note I was actually trying to give getPriceSetID this treatment but discountID was in the way. In general I'm trying to make some consisent public functions available on forms for retrieving relevant entity IDs rather than the current property / form variable patchwork
afb392b
to
cd6e40b
Compare
$this->_discountId = CRM_Core_DAO::getFieldValue('CRM_Event_DAO_Participant', $this->_id, 'discount_id'); | ||
if ($this->_discountId) { | ||
if ($this->getDiscountID()) { | ||
// This doesn't seem used.... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed that this doesn't seem to be used anywhere. Seems like the previous logic was to get the discount ID from the participant, but as it is here we'd be getting the discount ID from the event itself. Is that always the same? Not sure. (I was reading this wrong). Maybe cleaner just to get rid of it, since it does nothing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we can just get rid of the the whole getting the discount ID from the participant thing entirely. It doesn't seem to do anything at all. Then we can simplify getDiscountID().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@larssandergreen I was referring to the set
not being used - I think loading it from the participant makes sense in edit mode
@@ -390,4 +407,23 @@ private function emailReceipt(array $params): void { | |||
CRM_Core_BAO_MessageTemplate::sendTemplate($sendTemplateParams); | |||
} | |||
|
|||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like $this->_eventId would always be defined, so do we need to have a method to get it here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or if there is a reason to have it, I think we can just have it return $this->_eventId
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SO where I am going with these is the idea that you should be able to call getEventID()
& similar get
functions at any point & they don't rely on some order of events where things are set
first, but you would always get ... the event ID.
Also - I've marked as supported for external use - with the goal of providing some consistency to extensions wanting to access basic information about what is being processed (without directly accessing the properties which could be inconsistent)
@@ -1436,8 +1436,8 @@ public function buildEventFeeForm($form) { | |||
|
|||
//retrieve custom information | |||
$form->_values = []; | |||
CRM_Event_Form_Registration::initEventFee($form, $event['id'], FALSE); | |||
CRM_Event_Form_Registration_Register::buildAmount($form, TRUE, $form->_discountId); | |||
CRM_Event_Form_Registration::initEventFee($form, $event['id'], FALSE, $form->getDiscountID()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eileenmcnaughton this function doesn't seem to have a 4th function param
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added these to https://docs.civicrm.org/dev/en/latest/hooks/#pitfalls-of-hooks |
Builds on #27049 to extract getPriceSetID()
Overview
Extract
getDiscountID()
Before
CRM_Event_Form_Registration::initEventFee()
does some weird magic checking if the property discountId is configured on the form & using that, if the property exists. This is a pretty clear code smell that we should pass in the value rather than have the function find it on the form.CRM_Event_Form_Registration::initEventFee()
is called from 3 places in universe :CRM_Event_Form_ParticipantFeeSelection::buildQuickForm()
(non-static, called only from the form)CRM_Event_Form_Registration::preProcess()
(non-static, called only from the form)CRM_Event_Form_Participant::buildEventFeeForm()
This last one was made static/public to be used in unit tests. There are no core tests that do this anymore but @mlutfy wrote a test
CRM_Taxcalculator_BackendEventWebinarTest
that calls it from an extension. That test would be as likely to work after as before but it follows a pattern we ditched in core tests.The function only handles one form
CRM_Event_Form_Participant
- and this is the only form that would ever have the$_discountId
propertyAfter
Each of the forms above
CRM_Event_Form_Registration::initEventFee()
@api
calledgetDiscountID()
Technical Details
This is part of a general cleanup to stop passing the form into functions & then checking the form for a possible property.
I'm also trying add consistent functions to retrieve ids from the various forms and to support those functions for extension users (where we can be confident the value would have a consistent meaning over time - even if we changed the internals of the function at some point).
Note I was actually trying to give getPriceSetID this treatment but discountID was in the way so I've done it first...
In general I'm trying to make some consisent public functions available on forms for retrieving relevant entity IDs rather than the current property / form variable patchwork
Comments