CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-03-15T18:12:06Zhttps://lab.civicrm.org/dev/core/-/issues/470Current employer dissapears when disabling expired relationships2024-03-15T18:12:06ZfrancescbassasCurrent employer dissapears when disabling expired relationshipsOriginal issue: https://issues.civicrm.org/jira/browse/CRM-21851
Affected versions: at least from 5.0.0
---
How to reproduce:
1) Create a current relationship on individual A as *employee of* organization B and mark as *current emplo...Original issue: https://issues.civicrm.org/jira/browse/CRM-21851
Affected versions: at least from 5.0.0
---
How to reproduce:
1) Create a current relationship on individual A as *employee of* organization B and mark as *current employer*
2) Create a past relationship on individual A as *employee of* organization B without marking as current employer
At this point on summary tab of individual A appears organization B as his Employer.
3) Run *Disable expired relationships* cron job
At this point on summary tab there is no organization at Employer field although there is one active employee relationship and past relationship was disabled.5.17.0https://lab.civicrm.org/dev/core/-/issues/411Default currency shown on forms if payment is made with different currency2023-11-23T07:47:00ZjitendraDefault currency shown on forms if payment is made with different currencyDefault currency shown on View participant and contribution page if payment is made with different currency
Steps to reproduce -
- Create a priceset with some price fields.
- Create a contribution page with currency = EUR or any other ...Default currency shown on View participant and contribution page if payment is made with different currency
Steps to reproduce -
- Create a priceset with some price fields.
- Create a contribution page with currency = EUR or any other currency other than the default USD.
- Create a payment by submitting the contribution page.
- The payment shown on the contact summary page stated in USD even though it should have been taken in EUR.
Similarly, default currency is shown for participants registered for the event using EUR.
---
There are still 102 matches found where similar formatting is done.
```
$ grep -irn "crmMoney}" templates/ | wc -l
102
```
We need to fix all instances in core.
Ref https://github.com/civicrm/civicrm-core/pull/12875 for the first fixjitendrajitendrahttps://lab.civicrm.org/dev/core/-/issues/224Event confirmation emails do not populate guest details when payment is confi...2023-06-19T04:25:50ZJKingsnorthEvent confirmation emails do not populate guest details when payment is confirmed by IPN (API)This issue occurs with:
* Paid events, using an IPN payment gateway, or delayed payment
* On events that can have 'additional participants' (guests)
In this case, the event confirmation emails are missing:
* The names of additional part...This issue occurs with:
* Paid events, using an IPN payment gateway, or delayed payment
* On events that can have 'additional participants' (guests)
In this case, the event confirmation emails are missing:
* The names of additional participants
* Any custom 'participant' fields associated with the additional participants
Detailed steps to recreate:
* Create custom fields assigned to the 'Participant' entity, add them to a profile
* Create a free event with online registration, allowing multiple participants, and add the profile with custom fields to it, enable confirmation emails
* Register for the event, with an 'additional participant'
* Notice that the confirmation email contains the 'name' of the additional participant, and also the custom fields associated with their registration
* Create a paid event, with the 'pay later' option (otherwise the same options as above)
* Register for the event, with an 'additional participant' (pay later)
* Now use the Contribution - completetransaction API call to 'complete' the payment (this is the process that would happen if the IPN was triggered).
* Notice that the confirmation email does not contain the name of the participants, and any custom participant fields for the additional participants are NOT included.
Issue cause:
Information from the 'form' submission is passed into the email template when it is triggered for a free event. This information is not populated when the \CRM_Event_BAO_Event::sendMail method is called from the 'completetransaction' API call. Some information is assigned in \CRM_Event_Form_Registration_Confirm::buildQuickForm and includes the $part variable, which is assigned to the template, and subsequently used in the 'online event registration' email template. The custom fields for additional participants are also assigned to the template, based on the form (https://github.com/civicrm/civicrm-core/blob/694ccbf41adc31bce4d056fcc46930ba9c2e15e5/CRM/Event/Form/Registration/Confirm.php#L311), which is also missing from the 'completetransaction' route.
Our solution:
The code around this area of the system was quite spahettified, so we have solved this issue using a custom hook: https://gist.github.com/JKingsnorth/4d233df13a0f6493c44f69d81fa5f27a - although this isn't a great approach (in terms of being able to commit it back to core) - it does seem to resolve the issue.https://lab.civicrm.org/dev/core/-/issues/5CiviMail Mailing Accounts allow duplicate names, but breaks processing.2023-06-23T17:54:21ZjohnffCiviMail Mailing Accounts allow duplicate names, but breaks processing.If two CiviMail Mailing Accounts have the same name, even if they have different roles, only the first will be used in either case.
The offending line of code is somewhere in the path of: CRM_Utils_Mail_EmailProcessor::_process -> CRM_M...If two CiviMail Mailing Accounts have the same name, even if they have different roles, only the first will be used in either case.
The offending line of code is somewhere in the path of: CRM_Utils_Mail_EmailProcessor::_process -> CRM_Mailing_MailStore::getStore.
To replicate (Drupal, 4.7.27):
1. Create two mailing accounts.
The first one should be "Email to Activity" and have no username / password settings
The second should be "Bounce processing" and have username / password settings
(order of creation is important, and give them both the same name)
2. Run the scheduled job "fetch bounces".
3. In watchdog, observe the error "could not connect" using the credentials of email to activity processor, even though it should use the Bounce Processing one.
4. Clear the watchdog logs.
5. Rename them to have different names, then retry
6. Check the watchdogs, and observe no error.