Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-12-07T01:43:54Zhttps://lab.civicrm.org/dev/core/-/issues/3453Afform - relationships fill from other entity2022-12-07T01:43:54ZsamuelsovAfform - relationships fill from other entityFollow-up from https://github.com/civicrm/civicrm-core/pull/23296#issuecomment-1119014194
Let say we want to do a form that allow an employer to update :
- the main contact of the organization
- all the employees
Thanks to https://lab....Follow-up from https://github.com/civicrm/civicrm-core/pull/23296#issuecomment-1119014194
Let say we want to do a form that allow an employer to update :
- the main contact of the organization
- all the employees
Thanks to https://lab.civicrm.org/dev/core/-/issues/3117 it's now possible to do a form that will allow to create in one step :
- the organization
- the main contact as Individual 1 with a relationship between the organization and Individual 1
- the employees as Individual 2 with a relationship between the organization and Invividual 2 (which is multiple)
However, there is no way to have an edit mode for such a form. It's possible to add the organization id as an argument but we also need a way to pre-populate the main contacts / list of employees as an option based on the relationships definition.colemanwcolemanwhttps://lab.civicrm.org/dev/financial/-/issues/150civicrm/payment/form url got empty currency argument in backoffice live CC form2021-07-07T08:47:08ZMonish Debcivicrm/payment/form url got empty currency argument in backoffice live CC formThis affects iATS Payments ACH/EFT payment processor which renders the payment block based on currency chosen. Here are the steps to replicate:
1. Install and enable [iATS paymentextension](https://github.com/iATSPayments/com.iatspayme...This affects iATS Payments ACH/EFT payment processor which renders the payment block based on currency chosen. Here are the steps to replicate:
1. Install and enable [iATS paymentextension](https://github.com/iATSPayments/com.iatspayments.civicrm)
2. Add and configure an iATS Payments ACH/EFT payment type payment processor.
3. Enable USD and CAD currencies
4. Go to 'Submit Credit Card Contribution' backoffice form
5. Choose payment processor created at step 2
Issue:
1. Payment block renders payment block with check template
2. Switching currency doesn't update the payment block.
For more detail discussion on MM - https://chat.civicrm.org/civicrm/pl/ixxrxhxs43r4mfyjpnf6tnwnnc
ping @KarinG @eileen @JoeMurray @seamuslee5.31.0Monish DebMonish Debhttps://lab.civicrm.org/dev/wordpress/-/issues/45Apply for listing in WordPress directory2023-12-11T12:27:09Zjoshjosh@civicrm.orgApply for listing in WordPress directoryIssue to track progress and outstanding issues related to listing CiviCRM in WP directory.Issue to track progress and outstanding issues related to listing CiviCRM in WP directory.https://lab.civicrm.org/dev/financial/-/issues/82Develop getter & setter structure for Payment classes2021-05-31T22:31:04ZeileenDevelop getter & setter structure for Payment classesI don't think anyone designing Payment Processing subsystem would include the spec that you pass an undefined set of parameters to the 'doPayment' method, but that is how ours grew up.
This has caused us issues with inconsistencies arou...I don't think anyone designing Payment Processing subsystem would include the spec that you pass an undefined set of parameters to the 'doPayment' method, but that is how ours grew up.
This has caused us issues with inconsistencies around how payment processors determine variables. It also makes it really hard to clean up the code that interacts with payment processors as the code spends a lot of time buying arrays which go off into the void.
I'm pretty sure that if we were designing from scratch we would make it look much more like
```
$paymentObject = $this->getPaymentObject();
$paymentObject
->setContributionID(5)
->setContactID->(6)
->setAmount(50)
->setInvoiceID('xyz')
->setRecurringFrequency(1)
->setRecurringUnit('week')
....
->doPayment();
$feeAmount = $paymentObject->getFeeAmount();
```
We might provide some helpers etc but that seems much more inline with modern coding conventions and with our desire for standardisation.
I believe we should start adding getters & setters & encouraging payment processors to use them. The getters would do any normalisation of parameters (I'm looking at you currency vs currencyID).
It would be quite some time before this usage has 'flowed through the system' & we switch to relying on it when making payments but I think that adding this structure sets us up well for the future.
See PR for proposed change - which will not ACTUALLY change anything other than make these methods available in the first instance
https://github.com/civicrm/civicrm-core/pull/15509
@artfulrobot @KarinG @adixon @mattwire @andrewhunt
(Payment\PropertyBag)