Development issueshttps://lab.civicrm.org/groups/dev/-/issues2019-01-14T15:52:50Zhttps://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/drupal/-/issues/15CiviCRM Member Roles Rules2020-07-16T17:23:38ZshaneonabikeCiviCRM Member Roles RulesWhen installing this module, on a multilingual site, and setup a rule I get the following error:
`INSERT INTO {civicrm_member_roles_rules} (rid, type_id, status_codes) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_inse...When installing this module, on a multilingual site, and setup a rule I get the following error:
`INSERT INTO {civicrm_member_roles_rules} (rid, type_id, status_codes) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2)
Error messagePDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'log_civicrm_member_roles_rules' doesn't exist: INSERT INTO {civicrm_member_roles_rules} (rid, type_id, status_codes) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => 5 [:db_insert_placeholder_1] => 1 [:db_insert_placeholder_2] => a:4:{i:0;s:7:"current";i:1;s:7:"expired";s:7:"current";a:3:{i:0;s:1:"1";i:1;s:1:"2";i:2;s:1:"3";}s:7:"expired";a:4:{i:0;s:1:"4";i:1;s:1:"5";i:2;s:1:"6";i:3;s:1:"7";}} ) in civicrm_member_roles_add_rule_form_submit() (line 459 of /civicrm_member_roles/civicrm_member_roles.module`
Looking at the install file of the module there is no log table ever created. As well, the code is actually not making a call to log so I'm at a loss on how to debug this?https://lab.civicrm.org/dev/core/-/issues/16Select "Enable multiple bulk email address for a contact", "hold_date" can no...2023-06-23T17:54:21ZLiyanaSelect "Enable multiple bulk email address for a contact", "hold_date" can not be updatedI have reported the bug at https://issues.civicrm.org/jira/browse/CRM-20189, and now I'll explain why the error occours only if you assign true to the variable civimail_multiple_bulk_emails.
( $result = civicrm_api3('Setting', 'creat...I have reported the bug at https://issues.civicrm.org/jira/browse/CRM-20189, and now I'll explain why the error occours only if you assign true to the variable civimail_multiple_bulk_emails.
( $result = civicrm_api3('Setting', 'create', array(
'civimail_multiple_bulk_emails' => 1,
));)
If civimail_multiple_bulk_emails is true, you have three options to select for "On Hold?" in your email edit block, see the file ".../CRM/Contact/Form/Edit/Email.php".
If you chose the "- select -", the value is "0", which data type String is, and in the function "holdEmail" (.../CRM/Core/BAO/Email.php) the condition "elseif ($email->on_hold == 'null')..." will not be filled, because a string '0' is not 'null'!
Steps to reproduce:
1. Open the page „Administer CiviCRM“ --> “CiviMail Component Settings”, and select the option “Enable multiple bulk email address for a contact”
2. Open a contact and set “on hold” to the email (i.g. select “On Hold Opt Out”), and check the hold_date with api, ), in my test the “hold_date” is “2017-02-22 09:27:56”, and “on_hold=2
3. On the page of contact, reset the “On Hold” and save it, and check the value with api, and the value of “on_hold” is 0, BUT the “hold_date” IS NOT CHANGED! The “hold_date” should be deleted, and set the current time for “reset_date”!
4. As a following error: the “hold_date” is the old one, not changed, if you set “on hold” to the email again (i.g. select “On Hold Bounce”). In my test the “hold_date” is still “2017-02-22 09:27:56”, and “on_hold=1https://lab.civicrm.org/dev/core/-/issues/17Convert Campaign Interview Task to use Pseudoconstant and remove PHP notices2023-06-23T17:54:21Zmattwiremjw@mjwconsult.co.ukConvert Campaign Interview Task to use Pseudoconstant and remove PHP noticesRemove deprecated CRM_Core_OptionGroup and replace with CRM_Core_PseudoConstant. Fix PHP notices.
Ref: https://github.com/civicrm/civicrm-core/pull/11809Remove deprecated CRM_Core_OptionGroup and replace with CRM_Core_PseudoConstant. Fix PHP notices.
Ref: https://github.com/civicrm/civicrm-core/pull/11809https://lab.civicrm.org/dev/core/-/issues/3624Additional Bounce Patterns according to SMTP status codes2022-06-11T14:57:20ZpbatroffAdditional Bounce Patterns according to SMTP status codesCurrently SMTP status codes are mostly ignored when processing and classifying mails for bounces. I wrote a [stackexchange](https://civicrm.stackexchange.com/questions/23091/bounce-pattern-smtp-error-codes) question to see if someone had...Currently SMTP status codes are mostly ignored when processing and classifying mails for bounces. I wrote a [stackexchange](https://civicrm.stackexchange.com/questions/23091/bounce-pattern-smtp-error-codes) question to see if someone had already implemented this.
Since I got no feedback, I did it myself and had promising test results with the additional pattern:
From a sample bounce pool of approx. 4500 Mails, ~1500 were classified as syntax bounce (read: unknown) with the default bounce pattern. With the new pattern that shrank down to 400. (With some custom German away messages not yet parsed, so results should be even better, around ~200 syntax bounces)
My question would be if a pull request on civicrm-core is preferred, or if I should build an extension managing additional bounce pattern? I realize that with only 10 classifications available in CiviCRM-Bounce Type Vs. 30-50 SMTP Error codes the mapping could be open for some discussion, but I think this is a good start.
See [here](https://www.usps.org/info/smtp_codes.html) for simple smtp codes and [here](https://www.usps.org/info/smtp_status.html) for enhanced status codes as reference according to the [RFC-5248](https://tools.ietf.org/html/rfc5248#page-5)https://lab.civicrm.org/dev/core/-/issues/18log tables for CiviCRM Drupal Modules can cause WSODs after running upgrades ...2023-06-23T17:54:21Zseamusleelog tables for CiviCRM Drupal Modules can cause WSODs after running upgrades when re-calculatingAfter every upgrade if you have detailed logging enabled then the log_tables are recalculated and any differences fixed up. This is to ensure that the triggers on the log tables work fine.
There is an issue with CiviCRM drupal modules ...After every upgrade if you have detailed logging enabled then the log_tables are recalculated and any differences fixed up. This is to ensure that the triggers on the log tables work fine.
There is an issue with CiviCRM drupal modules and it comes down to a miss calculation between the create schema for the intitial log table v the compare differences function.
An example is
```sql
CREATE TABLE civicrm_member_roles_rules (
rule_id int(11) NOT NULL AUTO_INCREMENT,
rid int(10) unsigned NOT NULL,
type_id int(10) unsigned NOT NULL,
status_codes text NOT NULL,
PRIMARY KEY (rule_id)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8
```
When the log table for that is created the AUTO_INCREMENT is correctly handled through https://github.com/civicrm/civicrm-core/blob/master/CRM/Logging/Schema.php#L709 However when the schema diff code runs. We only exclude the column `id` https://github.com/civicrm/civicrm-core/blob/master/CRM/Logging/Schema.php#L628 as we assume that the id column will always be the AUTO_INCREMENT column whereas in the member_roles_rules example the AUTO INCREMENT column is actually `role_id`seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/19disabled optionvalues are not shown in participant export2023-06-23T17:54:22ZJoostdisabled optionvalues are not shown in participant exporta participant field has a custom field containing option values. Participants choose one of these option values. The option value that the participants chose gets disabled after they chose it. In a participant export containing this cust...a participant field has a custom field containing option values. Participants choose one of these option values. The option value that the participants chose gets disabled after they chose it. In a participant export containing this custom field the participants who chose for the disabled option will have a blanc space in the table on that location. Expected is having the option they chose over there, all-tough it has been disabled, and isn't available to choose any more.
to recreate this on a demo site:
1. create a participant to the fall fundraiser dinner with a soup preference
1. go to custom fields and edit the food preference custom field
1. deactivate the soup selection you chose in step 1
1. find participants to the fall fundraiser dinner
1. select all participants and export them using 'select fields to export'
1. select the fields to export:
- individual - display name to find the person you gave the food selection to
- participant - food preference: soup selection the field we are interested in
1. open the exported file. The soup selection for the disabled field isn't in there. When there are participants who chose for a soup that is still active the soup selection is in there for themhttps://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/core/-/issues/21Regression: Public-facing contribution pages appearance changes on 4.7.312023-06-23T17:54:22ZJonGoldRegression: Public-facing contribution pages appearance changes on 4.7.31This is best expressed with screenshots. The first screenshot is 4.7.29 (sorry I don't have an easy 4.7.30 pic to show). The second screenshot is 4.7.31. This is replicable on the demo and I've noted the issue on Drupal, Backdrop and ...This is best expressed with screenshots. The first screenshot is 4.7.29 (sorry I don't have an easy 4.7.30 pic to show). The second screenshot is 4.7.31. This is replicable on the demo and I've noted the issue on Drupal, Backdrop and WP sites alike.
![Selection_428](/uploads/9511293346d743e242e48c10badb9478/Selection_428.png)
![Selection_429](/uploads/88d20617d122fe578bfa3087f6aead1b/Selection_429.png)https://lab.civicrm.org/dev/core/-/issues/22Unable to delete Smart Group2023-06-23T17:54:22ZKarinGUnable to delete Smart Groupcivicrm mysqli.php(933): DB_common->raiseError(-1, NULL, NULL, "CREATE TEMPORARY TABLE civicrm_temp_group_contact_cache1416 (SELECT 565 as gr...", "1139 ** Got error 'empty (sub)expression' from regexp")
post upgrade from 4.6 -> 4.7 -> ...civicrm mysqli.php(933): DB_common->raiseError(-1, NULL, NULL, "CREATE TEMPORARY TABLE civicrm_temp_group_contact_cache1416 (SELECT 565 as gr...", "1139 ** Got error 'empty (sub)expression' from regexp")
post upgrade from 4.6 -> 4.7 -> Smart Groups with Children are broken (can't view Contacts; can't Delete; can't edit Search Criteria); relevant part of the critical Error in ConfigAndLog:
#6 /var/www/civicrm/4.7/packages/DB/mysqli.php(933): DB_common->raiseError(-1, NULL, NULL, "CREATE TEMPORARY TABLE civicrm_temp_group_contact_cache1416 (SELECT 565 as gr...", "1139 ** Got error 'empty (sub)expression' from regexp")
Have advised client to recreate these Smart Groups; raising here for awareness;https://lab.civicrm.org/dev/core/-/issues/23Upgrade to version 4.7.31 seems to have broken DAO.PHP2023-06-23T17:54:22ZhetclubUpgrade to version 4.7.31 seems to have broken DAO.PHPVersion 4.7.31 was installed and now an hourly cron job is erroring like this:
"Parse error: syntax error, unexpected '[' in /.../administrator/components/com_civicrm/civicrm/CRM/Core/DAO.php on line 651.Version 4.7.31 was installed and now an hourly cron job is erroring like this:
"Parse error: syntax error, unexpected '[' in /.../administrator/components/com_civicrm/civicrm/CRM/Core/DAO.php on line 651.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/25Wrap split_jobs in a transaction2023-06-23T17:54:22ZseamusleeWrap split_jobs in a transactionThe split_jobs function should be wrapped in a MySQL transaction to ensure that no mailing can be delivered whilst we are still trying to populate the mailing_job table with all the necessary jobs.The split_jobs function should be wrapped in a MySQL transaction to ensure that no mailing can be delivered whilst we are still trying to populate the mailing_job table with all the necessary jobs.5.1.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/26On behalf form fails to create new organisation2023-04-28T01:39:32ZjitendraOn behalf form fails to create new organisationRelated SE - https://civicrm.stackexchange.com/questions/23137/existing-organization-getting-updated-instead-a-new-organization/24190
Steps to replicate -
- Set up Contribution page using 'on behalf of'
- Submit the form a first time,...Related SE - https://civicrm.stackexchange.com/questions/23137/existing-organization-getting-updated-instead-a-new-organization/24190
Steps to replicate -
- Set up Contribution page using 'on behalf of'
- Submit the form a first time, create your 'on behalf of' Org.
- Submit the form a second time for New Org, using new name/email
- Outcome the original Org now has the new email but the old name. Both contributions are on their record.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/27Move check for presence of the phone strip function to a Check (currently don...2023-04-28T01:39:33ZeileenMove check for presence of the phone strip function to a Check (currently done whenever a phone number is edited)5.40.0https://lab.civicrm.org/dev/core/-/issues/3568Improve process for creating plain text version of mailing2024-02-13T05:03:24ZMichael McAndrewImprove process for creating plain text version of mailing## Overview
Convert any html contained in tokens to plain text for plain text emails
## Before
HTML in tokens that contained HTML was being outputted to plain text versions of emails.
## After
HTML in tokens is converted to plain te...## Overview
Convert any html contained in tokens to plain text for plain text emails
## Before
HTML in tokens that contained HTML was being outputted to plain text versions of emails.
## After
HTML in tokens is converted to plain text.
## Technical Details
This issue is NOT about generating plain text and HTML versions of tokens. It is about converting an entire email from HTML to plain text when no plain text version is given. This conversion currently proceeds as follows:
1. Check to see if a plain text version has been submitted. If not
2. Convert the HTML to plain text
3. Do token substitution
The problem is that if the token contains html, that HTML persists in the email. The proposed solution is to do the conversion from HTML to plain text after token substitution, i.e.
1. Check to see if a plain text version has been submitted. If not
2. Convert the HTML to plain text
3. Do token substitution
This patch is split between [PR 12061 on core](https://github.com/civicrm/civicrm-core/pull/12061) and [PR 20 on flexmailer](https://github.com/civicrm/org.civicrm.flexmailer/pull/20).
The flexmailer patch will continue to report a single failure until the core patch is merged, at which point we can hopefully run the tests against flexmailer again and merge this patch.
@totten suggested defining tokens with TokenProcessor, whose tokens auto-convert from HTML to plain text and visa versa. However, I am not sure this is going to work for the following reason. When you convert from HTML to plain text (at least with the HTML to plain text converter that we are using) the structure of the text is altered and links appear at the bottom of the converted text. Therefore, if you run multiple conversions, you will get multiple lists of links scattered throughout the email. Best to do html to plain text conversion at the end of the process.
All this is not to say that one shouldn't define plain text and HTML versions of tokens. I think it is fine to do that if you want to. I just think that automatic conversion of HTML to plain text should happen one time only, after the entire email has been assembled.
Note that [PR 12061 on core](https://github.com/civicrm/civicrm-core/pull/12061) removes the check for nofollow in the email html output of the test CRM_Mailing_BaseMailingSystemTest::testHtmlWithOpenAndUrlTracking. The intent of https://issues.civicrm.org/jira/browse/CRM-21768 is not affected. nofollow still appears in the public view (e.g. http://example.org/civicrm/mailing/view) but it is not tested.
I would have added it to a test of civicrm/mailing/view but I could not find any tests there.
This issue was originally discussed here: https://issues.civicrm.org/jira/browse/CRM-21197 and a PR submitted here: https://github.com/civicrm/civicrm-core/pull/10998. But the PR was rejected because it caused issues with Flexmailer.
Also, on the seperate issue of click tracking plain text emails. @totten - you said [here](https://github.com/civicrm/civicrm-core/pull/10998#discussion_r158175327) that you thought it was a significant policy change. It isn't as significant as you think. *Links that are tracked in HTML continue to be tracked in plain text*. Links that are not tracked in HTML (because they were not in an `<a>` tag) are not tracked in plain text either. i.e. there is no significant loss of functionality.https://lab.civicrm.org/dev/core/-/issues/28For repeating Events, the absolute Registration Start / End date is transferr...2023-04-28T01:39:33Zjustinfreeman (Agileware)For repeating Events, the absolute Registration Start / End date is transferred to each of the repeated events which causes future events to be closed for sign-ups on creationFor repeating Events, the absolute Registration Start / End date is transferred to each of the repeated events which causes future events to be closed for sign-ups on creation.
The fields are:
Registration Start Date / Time
Registration...For repeating Events, the absolute Registration Start / End date is transferred to each of the repeated events which causes future events to be closed for sign-ups on creation.
The fields are:
Registration Start Date / Time
Registration End Date / Time
It makes more sense for repeating events, that these dates need to be set relative to the event date.
This could be an overall enhancement to make these date fields relative for all events, not just repeating. Which would make more sense. Especially since that applies also to copying an event as well as setting up a repeating event.
As it stands now, repeating events with Registration Start and Registration End need to be manually updated after creation. Otherwise, no one can register for those events.
Agileware Ref: CIVICRM-841https://lab.civicrm.org/dev/core/-/issues/29Joomla Menu Item - Event Registration - Unable to choose event2023-04-28T01:39:33ZADG CreativeJoomla Menu Item - Event Registration - Unable to choose eventWhen creating a Joomla Menu Item to point to an Event Registration page, the dropdown for choosing an event is empty although there are current active events that should be populating.
This is affecting version 4.7.31, our sites running...When creating a Joomla Menu Item to point to an Event Registration page, the dropdown for choosing an event is empty although there are current active events that should be populating.
This is affecting version 4.7.31, our sites running 4.7.30 are not encountering this problem.
Type Event Registration is the only one that seems to be having an issue, all other types work as expected.
Joomla Versions: 3.8.4, 3.8.6Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/30Exporting master address contact even if no master address contact is defined2023-04-28T01:39:33ZsamuelsovExporting master address contact even if no master address contact is definedExporting "Master address contact" should give the master contact only if there is a master_id defined for this address but currently, if there is no master_id, the first master address id found for this contact is used.
```php
class C...Exporting "Master address contact" should give the master contact only if there is a master_id defined for this address but currently, if there is no master_id, the first master address id found for this contact is used.
```php
class CRM_Contact_BAO_Contact extends CRM_Contact_DAO_Contact {
...
public static function getMasterDisplayName($masterAddressId = NULL, $contactId = NULL) {
$masterDisplayName = NULL;
$sql = NULL;
if (!$masterAddressId && !$contactId) {
return $masterDisplayName;
}
if ($masterAddressId) {
$sql = "
SELECT display_name from civicrm_contact
LEFT JOIN civicrm_address ON ( civicrm_address.contact_id = civicrm_contact.id )
WHERE civicrm_address.id = " . $masterAddressId;
}
// ==> is there any reason to do that ?
elseif ($contactId) {
$sql = "
SELECT display_name from civicrm_contact cc, civicrm_address add1
LEFT JOIN civicrm_address add2 ON ( add1.master_id = add2.id )
WHERE cc.id = add2.contact_id AND add1.contact_id = " . $contactId;
}
$masterDisplayName = CRM_Core_DAO::singleValueQuery($sql);
return $masterDisplayName;
}
```5.3.0