-
-
Notifications
You must be signed in to change notification settings - Fork 825
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
Move assigning customGroup to offline participant template out of the form layer #27596
Move assigning customGroup to offline participant template out of the form layer #27596
Conversation
🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷 Introduction for new contributors...
Quick links for reviewers...
|
@larssandergreen I think this is the PR that has the fix for the e-notice you hit |
@eileenmcnaughton I had this one in the mix, still had those warnings. |
@larssandergreen hmm - ok will check - does that mean this one is tested? |
@eileenmcnaughton Not tested, but will do. |
@larssandergreen thanks - just checking the self transfer one on the other PR now |
I've just realised that without this change data would leak between participants - although I guess register participants only allows them to have all the same custom data values anyway |
This follows our historical practice of doing push receipts by - adding the relevant receipt to the array of template in the upgrade notification and - (optionally) noting deprecated params on CRM_Utils_Token::getDeprecatedTokens I didn't add lineItem to the deprecated array as it is pretty legit to assign that within a foreach loop. I also removed the assigns for the variables which are no longer relevant - this can be followed up with more tidy up (some of which resolves php8.x issues) Note that the template still uses $billingName & $address - resolved in civicrm#27692 $customGroup - resolved in civicrm#27596 (actually the variable remains but becomes non-leaky) $credit_card_date,$credit_card_type (I propose moving to a paymet token) $credit_card_expiry (I propose removing) $event.confirm_text - addressed in civicrm#27162
This follows our historical practice of doing push receipts by - adding the relevant receipt to the array of template in the upgrade notification and - (optionally) noting deprecated params on CRM_Utils_Token::getDeprecatedTokens I didn't add lineItem to the deprecated array as it is pretty legit to assign that within a foreach loop. I also removed the assigns for the variables which are no longer relevant - this can be followed up with more tidy up (some of which resolves php8.x issues) Note that the template still uses $billingName & $address - resolved in civicrm#27692 $customGroup - resolved in civicrm#27596 (actually the variable remains but becomes non-leaky) $credit_card_date,$credit_card_type (I propose moving to a paymet token) $credit_card_expiry (I propose removing) $event.confirm_text - addressed in civicrm#27162
This follows our historical practice of doing push receipts by - adding the relevant receipt to the array of template in the upgrade notification and - (optionally) noting deprecated params on CRM_Utils_Token::getDeprecatedTokens I didn't add lineItem to the deprecated array as it is pretty legit to assign that within a foreach loop. I also removed the assigns for the variables which are no longer relevant - this can be followed up with more tidy up (some of which resolves php8.x issues) Note that the template still uses $billingName & $address - resolved in civicrm#27692 $customGroup - resolved in civicrm#27596 (actually the variable remains but becomes non-leaky) $credit_card_date,$credit_card_type (I propose moving to a paymet token) $credit_card_expiry (I propose removing) $event.confirm_text - addressed in civicrm#27162
This follows our historical practice of doing push receipts by - adding the relevant receipt to the array of template in the upgrade notification and - (optionally) noting deprecated params on CRM_Utils_Token::getDeprecatedTokens I didn't add lineItem to the deprecated array as it is pretty legit to assign that within a foreach loop. I also removed the assigns for the variables which are no longer relevant - this can be followed up with more tidy up (some of which resolves php8.x issues) Note that the template still uses $billingName & $address - resolved in civicrm#27692 $customGroup - resolved in civicrm#27596 (actually the variable remains but becomes non-leaky) $credit_card_date,$credit_card_type (I propose moving to a paymet token) $credit_card_expiry (I propose removing) $event.confirm_text - addressed in civicrm#27162
This follows our historical practice of doing push receipts by - adding the relevant receipt to the array of template in the upgrade notification and - (optionally) noting deprecated params on CRM_Utils_Token::getDeprecatedTokens I didn't add lineItem to the deprecated array as it is pretty legit to assign that within a foreach loop. I also removed the assigns for the variables which are no longer relevant - this can be followed up with more tidy up (some of which resolves php8.x issues) Note that the template still uses $billingName & $address - resolved in civicrm#27692 $customGroup - resolved in civicrm#27596 (actually the variable remains but becomes non-leaky) $credit_card_date,$credit_card_type (I propose moving to a paymet token) $credit_card_expiry (I propose removing) $event.confirm_text - addressed in civicrm#27162
This follows our historical practice of doing push receipts by - adding the relevant receipt to the array of template in the upgrade notification and - (optionally) noting deprecated params on CRM_Utils_Token::getDeprecatedTokens I didn't add lineItem to the deprecated array as it is pretty legit to assign that within a foreach loop. I also removed the assigns for the variables which are no longer relevant - this can be followed up with more tidy up (some of which resolves php8.x issues) Note that the template still uses $billingName & $address - resolved in civicrm#27692 $customGroup - resolved in civicrm#27596 (actually the variable remains but becomes non-leaky) $credit_card_date,$credit_card_type (I propose moving to a paymet token) $credit_card_expiry (I propose removing) $event.confirm_text - addressed in civicrm#27162
This follows our historical practice of doing push receipts by - adding the relevant receipt to the array of template in the upgrade notification and - (optionally) noting deprecated params on CRM_Utils_Token::getDeprecatedTokens I didn't add lineItem to the deprecated array as it is pretty legit to assign that within a foreach loop. I also removed the assigns for the variables which are no longer relevant - this can be followed up with more tidy up (some of which resolves php8.x issues) Note that the template still uses $billingName & $address - resolved in civicrm#27692 $customGroup - resolved in civicrm#27596 (actually the variable remains but becomes non-leaky) $credit_card_date,$credit_card_type (I propose moving to a paymet token) $credit_card_expiry (I propose removing) $event.confirm_text - addressed in civicrm#27162
This follows our historical practice of doing push receipts by - adding the relevant receipt to the array of template in the upgrade notification and - (optionally) noting deprecated params on CRM_Utils_Token::getDeprecatedTokens I didn't add lineItem to the deprecated array as it is pretty legit to assign that within a foreach loop. I also removed the assigns for the variables which are no longer relevant - this can be followed up with more tidy up (some of which resolves php8.x issues) Note that the template still uses $billingName & $address - resolved in civicrm#27692 $customGroup - resolved in civicrm#27596 (actually the variable remains but becomes non-leaky) $credit_card_date,$credit_card_type (I propose moving to a paymet token) $credit_card_expiry (I propose removing) $event.confirm_text - addressed in civicrm#27162
@larssandergreen have you had a chance to test this one? Seems like a blocker to other work. |
@colemanw this does actually have specific test cover - I added it when I refactored the custom group stuff - this just moves it |
Ok well tests seem happy at least. |
Overview
Move assigning customGroup to offline participant template out of the form layer
Builds on #27552 & moves the determination of the custom fields out of the form onto the workflow template
Unit test for this functionality added in
https://github.com/civicrm/civicrm-core/pull/27552/files#diff-a22240af3e1461ef0bd11694690c6c356c26a09a025e6b9b0a0b64fcd0d47fa9R61
Before
the form determines the
customGroups
variable that is assigned to the offline_event workflow templateAfter
The workflow template does - with a good deal more commentary
Technical Details
Screenshots of the array from the form
from the trait
Comments