Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-04-28T01:39:33Zhttps://lab.civicrm.org/dev/core/-/issues/31Cancelled auto-renew membership and scheduled reminders don't play nice2023-04-28T01:39:33ZkonadaveCancelled auto-renew membership and scheduled reminders don't play niceRecently upgraded a site from 4.6.21 to 4.7.27. Payment processor is iATS Payments, if that makes any difference.
When an auto-renew membership is cancelled, the contribution_recur_id field in civicrm_membership for that membership is l...Recently upgraded a site from 4.6.21 to 4.7.27. Payment processor is iATS Payments, if that makes any difference.
When an auto-renew membership is cancelled, the contribution_recur_id field in civicrm_membership for that membership is left as is.
Stated using scheduled reminders after the upgrade, and have one set up to send an email to auto-renew memberships one week in advance of their renewal so they're not surprised when their credit card is charged. Cancelled auto-renew memberships are receiving this reminder.
I honestly don't have time to do any testing or going exploring through code at the moment. For all I know this has been reported previously and is already fixed. But if it hasn't, I'm thinking that contribution_recur_id should be cleared when the recurring contribution is cancelled, or scheduled reminders should make sure the contribution_recur_id is not cancelled.https://lab.civicrm.org/dev/core/-/issues/3539When communcating with external network services, detect transient failures a...2024-02-12T13:57:20ZmfbWhen communcating with external network services, detect transient failures and queue for retryFor improved resiliency, CiviCRM should detect transient failures when communicating with external network services and queue for retry. e.g.
* Transactional email: Queue for sending rather than sending during the request process?
* Bul...For improved resiliency, CiviCRM should detect transient failures when communicating with external network services and queue for retry. e.g.
* Transactional email: Queue for sending rather than sending during the request process?
* Bulk mail: Catch transient failures and ensure that they are retried. PRs: https://github.com/civicrm/civicrm-core/pull/11838 https://github.com/civicrm/civicrm-core/pull/11840 (and there are additional failure scenarios possible)
* ...https://lab.civicrm.org/dev/core/-/issues/24Passing an array for contact_id/client_id to Case.Create API when updating an...2023-06-23T17:54:22Zmattwiremjw@mjwconsult.co.ukPassing an array for contact_id/client_id to Case.Create API when updating an existing case causes case to be "reassigned"The contact_id/client_id for the case supports multiple ids. It can be passed to the case.create API either as a single value or as an array. However, the code is inconsistent in it's handling of contact_id and expects it to be both an...The contact_id/client_id for the case supports multiple ids. It can be passed to the case.create API either as a single value or as an array. However, the code is inconsistent in it's handling of contact_id and expects it to be both an array and a single value. The result is that if an array is passed in it will fail to detect that an existing case contact_id already matches and it will "reassign" the case to the default contact id (1). This issue was identified because of inconsistent behaviour when submitting case/activity updates via webform_civicrm.
The proposed solution is to ensure that contact_id is always an array, and then check the first element against the original contact id.https://lab.civicrm.org/dev/core/-/issues/20Can't place a contribution widget on a Contribution Page2023-11-23T07:47:01ZJonGoldCan't place a contribution widget on a Contribution PageWhen you attempt to place a contribution widget on its own contribution page in the "Inroductory Message" section, you get the error:
`Illegal characters in input (potential scripting attack)`
I confirmed this is a regression by replica...When you attempt to place a contribution widget on its own contribution page in the "Inroductory Message" section, you get the error:
`Illegal characters in input (potential scripting attack)`
I confirmed this is a regression by replicating the problem on the Drupal demo site (4.7) and confirming it didn't exist ion the Joomla site (4.6). I'm pretty sure it didn't happen earlier in the 4.7 cycle either.https://lab.civicrm.org/dev/translation/-/issues/7Update Localizing Documentation (Drupal configurations)2019-01-14T15:52:50ZshaneonabikeUpdate Localizing Documentation (Drupal configurations)There is some special mapping configurations for multilingual Drupal sites to map the proper languages between Drupal and CiviCRM. Is there a way I could update the existing documentation?
https://docs.civicrm.org/user/en/latest/the-civ...There is some special mapping configurations for multilingual Drupal sites to map the proper languages between Drupal and CiviCRM. Is there a way I could update the existing documentation?
https://docs.civicrm.org/user/en/latest/the-civicrm-community/localising-civicrm/
`"Inherit CMS language" and regional translations (ex: fr_CA)
If you have a multi-lingual site and you are using the "inherit CMS language" configuration option, but wish to, for example, use fr_CA instead of the default fr_FR (for French), you can define a constant in your "civicrm.settings.php" to override the default behavior.
See CRM-9558 for more information.
define('CIVICRM_LANGUAGE_MAPPING_FR', 'fr_CA');
`
From https://wiki.civicrm.org/confluence/display/CRMDOC/i18n+Administrator%27s+Guide%3A+Using+CiviCRM+in+your+own+languagehttps://lab.civicrm.org/dev/core/-/issues/13rare recurring error: CiviMail will not send an empty mail body, Skipping2023-06-23T17:54:21Zmfbrare recurring error: CiviMail will not send an empty mail body, SkippingIt appears in a tiny fraction of mailing recipients (less than 0.01%), we are not sending the mailing because contact details are empty. The contact details contains custom tokens that we have added, but no actual core contact data, e.g...It appears in a tiny fraction of mailing recipients (less than 0.01%), we are not sending the mailing because contact details are empty. The contact details contains custom tokens that we have added, but no actual core contact data, e.g. preferred_mail_format (which is required to compose a message). To be clear, no contact data is present, it's not that preferred_mail_format is NULL.
Perhaps this is caused by a failed db query somewhere along the way. Will require further debugging to get to the bottom of it.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.https://lab.civicrm.org/dev/core/-/issues/4Link to css is hard-coded to the resource url link - problematic for server-s...2023-12-12T17:23:45ZeileenLink to css is hard-coded to the resource url link - problematic for server-side rendering with firewall or htaccess in playIn a few places in the code we add the print.css url with a section like this:
```
<head>
<title>{$pageTitle}</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<base href="{crmURL p="" a=1}" /><!--[if IE...In a few places in the code we add the print.css url with a section like this:
```
<head>
<title>{$pageTitle}</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<base href="{crmURL p="" a=1}" /><!--[if IE]></base><![endif]-->
<style type="text/css" media="screen, print">@import url({$config->userFrameworkResourceURL}css/print.css);</style>
</head>
```
That works fine from print.tpl & presumably the place in CiviCase where it is used but is problematic in CRM_Utils_PDF_Utils
When a pdf is being rendered internally & a firewall or htaccess is in play this css cannot be retrieved via http.
I also encountered someone struggling on chat the other day due to the print.css link written into a report instance being wallopped by the hard coded one when printing a CiviReport - going through that class.
@totten @bgm just trying to figure out the best way to handle this. I feel like in the pdf class it should try the file location FIRST if it does not appear to be customised - I think there might be some handy functions for that?
In the case of the report I think it's a bit trickier - we would need to figure out if a stylesheet is specified & only add one if not - or simply not add the <head> section. (I don't need to solve this but was thinking about it at the same time)
NB - this is the first issue I have logged in gitlab...https://lab.civicrm.org/dev/release/-/issues/2Brainstorm: Little Ideas for QA2018-04-19T03:15:34ZtottenBrainstorm: Little Ideas for QAThis issue is an experiment. The goal -- brainstorm for Little Ideas that will improve the quality-assurance regime. I'm not looking to replay past discussions -- if something was controversial before, it's probably still controversial. ...This issue is an experiment. The goal -- brainstorm for Little Ideas that will improve the quality-assurance regime. I'm not looking to replay past discussions -- if something was controversial before, it's probably still controversial. For purposes of this issue, humor me. Suppose there's a realistic budget -- like a week of senior developer/designer/documenter/administrator time. What process change could they perform that might make a dent at improving QA? Perhaps something that makes PR review more thorough? Or perhaps it improves engagement with RCs? Or perhaps it lowers the barrier to testing?
Please post one idea per comment. If you like or dislike an idea, put a thumbsup or thumbsdown emoji on the comment. To discuss the idea in more depth, ping the commenter on Mattermost (https://chat.civicrm.org under `dev`).
------
Emojis:
* :thumbsup_tone1: - Good idea. Simple, clear steps. Would probably improve quality. Achievable within budget.
* :thumbsdown_tone1: - Bad idea. Wouldn't improve quality.
* :8ball: - Don't really want to judge. It sounds good, but it's not simple enough or not clear enough or too long. Maybe if the idea was refined more.
* :baby_chick: - The comment is conversation.https://lab.civicrm.org/dev/translation/-/issues/1Distribution and management of l10n/xx_YY/settings.default.json files2020-08-11T11:18:57ZbgmDistribution and management of l10n/xx_YY/settings.default.json filesNow that CRM-16395 has been merged, we can provide localised setting files for supported languages.
Now we need to:
* [x] decide where to store (in the 'l10n' git repo) the settings files
* [x] bundle those json files in civicrm-5.x.xx...Now that CRM-16395 has been merged, we can provide localised setting files for supported languages.
Now we need to:
* [x] decide where to store (in the 'l10n' git repo) the settings files
* [x] bundle those json files in civicrm-5.x.xx-l10n.tar.gz
* [x] document the process by which people can send/update setting files
* [ ] update the documentation about non-English installation?
Example:
https://github.com/civicrm/civicrm-core/files/305643/settings.default.json.txt