Development issueshttps://lab.civicrm.org/groups/dev/-/issues2021-12-16T14:06:16Zhttps://lab.civicrm.org/dev/core/-/issues/1933Failed scheduled reminders should log message somewhere more useful2021-12-16T14:06:16ZAndy ClarkFailed scheduled reminders should log message somewhere more usefulOverview
----------------------------------------
A failed schedule reminder should log the error in a place that the end user can see why it failed.
Example use-case
----------------------------------------
A schedule reminder is set u...Overview
----------------------------------------
A failed schedule reminder should log the error in a place that the end user can see why it failed.
Example use-case
----------------------------------------
A schedule reminder is set up to send an SMS to a contact with a bad phone number. The reminder will fail, and a message will be added to table civicrm_action_log. The user who set up the reminder will not know whether it failed, or why, since they cannot view database tables.
Proposed behaviour
----------------------------------------
I propose a couple of alternatives:
1. The error message should be logged as an activity, either against the creator of the schedule reminder or the target. Then the user can check for this.
Or
2. The error message should be written to the system log, so at least someone with the 'Log Viewer' extension could see it.
Comments
----------------------------------------
My preference would be the first of the alternatives. There are a number of questions on SE about analysing failed Schedule Reminders - this would be a help with that.5.46.0https://lab.civicrm.org/dev/core/-/issues/3259Add the possibility to use the hook_civicrm_alterReportVar('sql') in all reports2022-04-22T15:53:00ZrubofvilAdd the possibility to use the hook_civicrm_alterReportVar('sql') in all reportsSome reports have rewrited the method "buildQuery" from class CRM_Report_Form. Not in all reports is included the line to launch the hook `hook_civicrm_alterReportVar` -> `CRM_Utils_Hook::alterReportVar('sql', $this, $this);`
Example
h...Some reports have rewrited the method "buildQuery" from class CRM_Report_Form. Not in all reports is included the line to launch the hook `hook_civicrm_alterReportVar` -> `CRM_Utils_Hook::alterReportVar('sql', $this, $this);`
Example
https://github.com/civicrm/civicrm-core/blob/abc4afe890add20796585a2a997bc3d832815abe/CRM/Report/Form/Member/ContributionDetail.php#L552https://lab.civicrm.org/dev/core/-/issues/1932Upgrade fails for 4.6 => 5.29 during status-check2020-08-06T22:56:32ZtottenUpgrade fails for 4.6 => 5.29 during status-checkOverview
----------------------------------------
New upgrade error when going from 4.6=>5.29.
Reproduction steps
----------------------------------------
1. Install Civi 4.6 from git. (Requires temporarily setting up PHP 5.6.)
1. Swit...Overview
----------------------------------------
New upgrade error when going from 4.6=>5.29.
Reproduction steps
----------------------------------------
1. Install Civi 4.6 from git. (Requires temporarily setting up PHP 5.6.)
1. Switch to Civi 5.29 from git. (Requires switching back to PHP 7.1+.)
1. *Note: The codepath depends on the status-check timer. It arose organically for me, but to reproduce reliably, you may need to coerece `CRM_Utils_Check::CHECK_TIMER` to a low value like `1`.*
Current behavior
----------------------------------------
The problem is that `civicrm_status_pref` didn't exist in 4.6, and we haven't run the upgrader yet.
![Screen_Shot_2020-08-06_at_12.05.47_AM](/uploads/461ae861dbffaf47f8b0216ba58b7435/Screen_Shot_2020-08-06_at_12.05.47_AM.png)
Guess: Perhaps the try/catch block from https://github.com/civicrm/civicrm-core/commit/185a0768689374ce2d2703875a855d990c197728 was also handling the case of the non-existent table?
Expected behavior
----------------------------------------
Status check fails gracefully.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __CiviCRM:__ 5.29
* __PHP:__ 7.1
* __CMS:__ WP
* __Database:__ _MySQL 5.65.29.0https://lab.civicrm.org/dev/user-interface/-/issues/26Replace entity icons2022-06-13T16:12:02ZAndie HuntReplace entity iconsOne of the most prominent remaining areas of image icons is the icon for each entity that appears in the recent items block and next to contact names. These are also among the more hideous icons.
There are three parts to this: identify...One of the most prominent remaining areas of image icons is the icon for each entity that appears in the recent items block and next to contact names. These are also among the more hideous icons.
There are three parts to this: identifying replacement icons in Font Awesome, providing for configuration of contact subtype icons, and replacing the mechanism of providing and displaying the icons.
## Identifying replacement icons
This might be tricky given the limited set of icons in Font Awesome 4.7, but it's self-explanatory. A good first start would be to use the icons on the tabs in the contact record.
## Providing for configuration of contact subtype icons
Site admins can pick an icon image for contact subtypes, or by default they appear as grey versions of the corresponding contact type. I don't think it's realistic to retain the images, but it will be important to offer site admins the opportunity to pick an icon. A natural way might be an icon picker similar to the ones that appear elsewhere.
## Replacing the mechanism of providing and displaying the icons
[CRM_Utils_Recent::add()](https://github.com/civicrm/civicrm-core/blob/03cc26c372316bd708271e3ea12646ff718d38de/CRM/Utils/Recent.php#L84) adds things to the stack of recent items. Among them is an `$others` array that has details like the image URL.
It's called from places like [here](https://github.com/civicrm/civicrm-core/blob/03cc26c372316bd708271e3ea12646ff718d38de/CRM/Contact/Page/View.php#L187) where the contact type icon's image URL is pulled [from `CRM_Contact_Page_View::getContactDetails()`](https://github.com/civicrm/civicrm-core/blob/03cc26c372316bd708271e3ea12646ff718d38de/CRM/Contact/Page/View.php#L160) which, in turn, calls [`CRM_Contact_BAO_Contact::getDisplayAndImage()`](https://github.com/civicrm/civicrm-core/blob/03cc26c372316bd708271e3ea12646ff718d38de/CRM/Contact/BAO/Contact.php#L513).
Most of these functions will need to be reworked to pull the icon class name and pass it along. In the meantime, `CRM_Contact_BAO_Contact::getDisplayAndImage()` should probably be reworked to use the API since it's just getting basic things.https://lab.civicrm.org/dev/wordpress/-/issues/70Broken update from 5.27.3 to 5.27.4 Wordpress2020-08-06T15:20:11ZjonathandhnBroken update from 5.27.3 to 5.27.4 WordpressWordpress is 5.4.2 <br />
PHP is 7.4.8 fpm behind apache2
___ Using Web __
DB unknown ERROR
___ Using CV ___
`cv upgrade:db `
```
Found CiviCRM database version 5.27.3.
Found CiviCRM code version 5.27.4.
<div id="crm-container" cla...Wordpress is 5.4.2 <br />
PHP is 7.4.8 fpm behind apache2
___ Using Web __
DB unknown ERROR
___ Using CV ___
`cv upgrade:db `
```
Found CiviCRM database version 5.27.3.
Found CiviCRM code version 5.27.4.
<div id="crm-container" class="crm-container" lang="fr" xml:lang="fr"><br />
<style type="text/css" media="screen"><br />
@import url(https://x-x.x/wp-content/plugins/civicrm/civicrm/css/civicrm.css);
@import url(https://x-x.x/wp-content/plugins/civicrm/civicrm/css/crm-i.css);
@import url(https://x-x.x/wp-content/plugins/civicrm/civicrm/bower_components/font-awesome/css/font-awesome.min.css);
</style>
<div class="messages status no-popup"> <i class="crm-i fa-exclamation-triangle crm-i-red" aria-hidden="true"></i>
<span class="status-fatal">Désolé, à cause d'une erreur, nous ne sommes pas en mesure, pour le moment, de satisfaire votre requête. Nous vous invitons à contacter votre administrateur système ou votre fournisseur de service en lui fournissant plus de détails sur l'action que vous étiez en train de réaliser quand cela est arrivé.</span>
<div class="crm-section crm-error-message"></div>
<hr style="solid 1px" />
<div class="crm-section crm-error-message">DB Error: unknown error</div>
<p><a href="https://x-x.x/" title="Menu principal">Retourner à la page d'accueil.</a></p>
</div>
</div>
<script language="JavaScript">
function toggle( element ) {
var parent = element.parentNode;
var className = parent.className;
if ( className == 'crm-accordion-wrapper collapsed crm-fatal-error-details-block') {
parent.className = 'crm-accordion-wrapper crm-fatal-error-details-block';
} else {
parent.className = 'crm-accordion-wrapper collapsed crm-fatal-error-details-block';
}
}
</script>
```https://lab.civicrm.org/dev/core/-/issues/1930Contact merge form moves unchecked related entities2020-08-06T02:48:40ZPatrick Figelpfigel@greenpeace.orgContact merge form moves unchecked related entitiesWhile reviewing [this PR](https://github.com/civicrm/civicrm-core/pull/17981), I noticed that on latest master, the contact merge form moves related entities (e.g. contributions) even if the corresponding "Move related..." checkbox is un...While reviewing [this PR](https://github.com/civicrm/civicrm-core/pull/17981), I noticed that on latest master, the contact merge form moves related entities (e.g. contributions) even if the corresponding "Move related..." checkbox is unchecked.
I was able to reproduce this with all entities other than memberships (which has some special handling in the code, IIRC).
Not sure when exactly this regressed, but I was able to confirm it worked on 5.24.6.5.28.0https://lab.civicrm.org/dev/core/-/issues/1929Custom field values not showing in Drupal 7 Views filter2020-12-07T19:29:15Zaydunsaidan.saunders@squiffle.ukCustom field values not showing in Drupal 7 Views filterOverview
----------------------------------------
When a custom field is created with a specified `column_name`, the field does not work correctly when used as a Drupal 7 Views filter.
Custom fields created via the UI, or by API when th...Overview
----------------------------------------
When a custom field is created with a specified `column_name`, the field does not work correctly when used as a Drupal 7 Views filter.
Custom fields created via the UI, or by API when the `column_name` is not specified all work as expected.
Reproduction steps
----------------------------------------
1. Create a Custom Field via API extending Contact, type Select (drop-down) and set the `column_name`. Create a few option values.
1. Set up system for Views (copy from `Administration > System Settings > CMS Integration` etc)
1. Create a View based on Contacts, add a Filter and select the custom field
1. Note an AJAX error including ```Unsupported operand types in views_handler_filter_in_operator->value_form()```
For the same problem but using a different handler, repeat with Checkbox type.
Current behaviour
----------------------------------------
Error shown and no filter values shown.
Expected behaviour
----------------------------------------
No error, filter values shown
Environment information
----------------------------------------
* __CiviCRM:__ _Master_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->aydunsaidan.saunders@squiffle.ukaydunsaidan.saunders@squiffle.ukhttps://lab.civicrm.org/dev/core/-/issues/1928Collapsed custom field set for activities with a required radio makes case ac...2020-09-18T15:11:46ZDaveDCollapsed custom field set for activities with a required radio makes case activity buttons seem disabledMight be from the recent jquery radio validation update. Haven't followed it through yet. Not even sure if it's specific to radio yet.
1. Create a custom fieldset for activities.
1. Make it apply to all activity types (not relevant just...Might be from the recent jquery radio validation update. Haven't followed it through yet. Not even sure if it's specific to radio yet.
1. Create a custom fieldset for activities.
1. Make it apply to all activity types (not relevant just makes this quicker).
1. Make it collapsed by default.
1. Add a radio field.
1. Make it required.
1. Administer - Customize - Display Prefs - Turn off popups (near the bottom). (Only relevant because then you can see the issue for all case activities - when it's on you only notice it for open case/creating a case.)
1. Create a case.
1. Fill out the client, subject, and case type but leave the collapsed custom field section collapsed.
1. Click Save. It appears as though nothing happened, but if you open the custom fieldset you can see why.5.29.0https://lab.civicrm.org/dev/core/-/issues/1927upgrade to 5.28.beta1 fails2020-08-05T01:07:06ZPradeep Nayakpradpnayak@gmail.comupgrade to 5.28.beta1 failsWith Contact types shown in below screenshot the upgrade fails with below error
![Screen_Shot_2020-08-04_at_23.55.00](/uploads/ff0affbc704cfabe4a4fea2b7f379161/Screen_Shot_2020-08-04_at_23.55.00.png)
```
Aug 04 23:51:52 [error] $Fat...With Contact types shown in below screenshot the upgrade fails with below error
![Screen_Shot_2020-08-04_at_23.55.00](/uploads/ff0affbc704cfabe4a4fea2b7f379161/Screen_Shot_2020-08-04_at_23.55.00.png)
```
Aug 04 23:51:52 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => exceptionHandler
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_info] => ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comment 'Internal name of Contact Type (or Subtype).' [nativecode=1138 ** Invalid use of NULL value]
[type] => DB_Error
[user_info] => ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comment 'Internal name of Contact Type (or Subtype).' [nativecode=1138 ** Invalid use of NULL value]
[to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comment 'Internal name of Contact Type (or Subtype).' [nativecode=1138 ** Invalid use of NULL value]"]
)
Aug 04 23:51:52 [debug] $backTrace = #0 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Core/Error.php(937): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(922): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#2 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/packages/DB.php(998): PEAR_Error->__construct("DB Error: unknown error", -1, 16, (Array:2), "ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comme...")
#3 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-1, 16, (Array:2), "ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comme...")
#4 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -1, 16, (Array:2), "ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comme...", "DB_Error", TRUE)
#5 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/packages/DB/common.php(1925): PEAR->__call("raiseError", (Array:7))
#6 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/packages/DB/mysqli.php(936): DB_common->raiseError(-1, NULL, NULL, "ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comme...", "1138 ** Invalid use of NULL value")
#7 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/packages/DB/mysqli.php(406): DB_mysqli->mysqliRaiseError()
#8 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/packages/DB/common.php(1231): DB_mysqli->simpleQuery("ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comme...")
#9 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Utils/File.php(350): DB_common->query("ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comme...")
#10 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Upgrade/Form.php(155): CRM_Utils_File::runSqlQuery("mysql://root:root@127.0.0.1:3306/civi_dru_crm?new_link=true", "-- https://github.com/civicrm/civicrm-core/pull/17579\nALTER TABLE `civicrm_n...", NULL)
#11 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Upgrade/Form.php(350): CRM_Upgrade_Form->source("-- https://github.com/civicrm/civicrm-core/pull/17579\nALTER TABLE `civicrm_n...", TRUE)
#12 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Upgrade/Form.php(384): CRM_Upgrade_Form->processLocales("/Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Upgrade/Increm...", "5.28.alpha1")
#13 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Upgrade/Incremental/Base.php(66): CRM_Upgrade_Form->processSQL("5.28.alpha1")
#14 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Queue/Task.php(74): CRM_Upgrade_Incremental_Base::runSql(Object(CRM_Queue_TaskContext), "5.28.alpha1")
#15 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Queue/Runner.php(202): CRM_Queue_Task->run(Object(CRM_Queue_TaskContext))
#16 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Queue/Page/AJAX.php(36): CRM_Queue_Runner->runNext(TRUE)
#17 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Queue/ErrorPolicy.php(90): CRM_Queue_Page_AJAX::{closure}()
#18 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Queue/Page/AJAX.php(38): CRM_Queue_ErrorPolicy->call(Object(Closure))
#19 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Core/Invoke.php(278): CRM_Queue_Page_AJAX::runNext()
#20 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Core/Invoke.php(68): CRM_Core_Invoke::runItem((Array:13))
#21 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:5))
#22 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/drupal/civicrm.module(454): CRM_Core_Invoke::invoke((Array:5))
#23 /Users/pradeep/Sites/civi-drupal/includes/menu.inc(527): civicrm_invoke("upgrade", "queue", "ajax", "runNext")
#24 /Users/pradeep/Sites/civi-drupal/index.php(21): menu_execute_active_handler()
#25 {main}
Aug 04 23:51:52 [info] $CRM_Queue_Page_AJAX_runNext_error = PEAR_Exception: "DB Error: unknown error"
* ERROR TYPE: DB_Error
* ERROR CODE: -1
* ERROR MESSAGE: DB Error: unknown error
* ERROR MODE: 16
* ERROR USERINFO: ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comment 'Internal name of Contact Type (or Subtype).' [nativecode=1138 ** Invalid use of NULL value]
* ERROR DEBUGINFO: ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comment 'Internal name of Contact Type (or Subtype).' [nativecode=1138 ** Invalid use of NULL value]
#0 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(922): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#1 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/packages/DB.php(998): PEAR_Error->__construct("DB Error: unknown error", -1, 16, (Array:2), "ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comme...")
#2 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-1, 16, (Array:2), "ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comme...")
#3 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -1, 16, (Array:2), "ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comme...", "DB_Error", TRUE)
#4 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/packages/DB/common.php(1925): PEAR->__call("raiseError", (Array:7))
#5 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/packages/DB/mysqli.php(936): DB_common->raiseError(-1, NULL, NULL, "ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comme...", "1138 ** Invalid use of NULL value")
#6 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/packages/DB/mysqli.php(406): DB_mysqli->mysqliRaiseError()
#7 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/packages/DB/common.php(1231): DB_mysqli->simpleQuery("ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comme...")
#8 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Utils/File.php(350): DB_common->query("ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comme...")
#9 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Upgrade/Form.php(155): CRM_Utils_File::runSqlQuery("mysql://root:root@127.0.0.1:3306/civi_dru_crm?new_link=true", "-- https://github.com/civicrm/civicrm-core/pull/17579\nALTER TABLE `civicrm_n...", NULL)
#10 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Upgrade/Form.php(350): CRM_Upgrade_Form->source("-- https://github.com/civicrm/civicrm-core/pull/17579\nALTER TABLE `civicrm_n...", TRUE)
#11 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Upgrade/Form.php(384): CRM_Upgrade_Form->processLocales("/Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Upgrade/Increm...", "5.28.alpha1")
#12 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Upgrade/Incremental/Base.php(66): CRM_Upgrade_Form->processSQL("5.28.alpha1")
#13 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Queue/Task.php(74): CRM_Upgrade_Incremental_Base::runSql(Object(CRM_Queue_TaskContext), "5.28.alpha1")
#14 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Queue/Runner.php(202): CRM_Queue_Task->run(Object(CRM_Queue_TaskContext))
#15 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Queue/Page/AJAX.php(36): CRM_Queue_Runner->runNext(TRUE)
#16 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Queue/ErrorPolicy.php(90): CRM_Queue_Page_AJAX::{closure}()
#17 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Queue/Page/AJAX.php(38): CRM_Queue_ErrorPolicy->call(Object(Closure))
#18 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Core/Invoke.php(278): CRM_Queue_Page_AJAX::runNext()
#19 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Core/Invoke.php(68): CRM_Core_Invoke::runItem((Array:13))
#20 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:5))
#21 /Users/pradeep/Sites/civi-drupal/sites/all/modules/civicrm/drupal/civicrm.module(454): CRM_Core_Invoke::invoke((Array:5))
#22 /Users/pradeep/Sites/civi-drupal/includes/menu.inc(527): civicrm_invoke("upgrade", "queue", "ajax", "runNext")
#23 /Users/pradeep/Sites/civi-drupal/index.php(21): menu_execute_active_handler()
#24 {main}
```
Caused problem from PR https://github.com/civicrm/civicrm-core/pull/17570
`ALTER TABLE civicrm_contact_type CHANGE name name varchar(64) not null comment 'Internal name of Contact Type (or Subtype).';` is executed from 5.28.alpha1.mysql.tpl just before populateMissingContactTypeName() is called in [upgrade_5_28_alpha1()](https://github.com/civicrm/civicrm-core/blob/master/CRM/Upgrade/Incremental/php/FiveTwentyEight.php#L89)5.28.0https://lab.civicrm.org/dev/user-interface/-/issues/25Unable to delete file with brackets in filename via ckeditor/kcfinder2021-01-06T21:32:13ZPhilipp MichaelUnable to delete file with brackets in filename via ckeditor/kcfinderIf you try to delete a file inside ckeditor via kcfinder you get an "Unknown error." if the file name contains brackets. Those brackets are generated during upload if a file with the same name already exists (e.g `foo(1).jpg`).
Steps to...If you try to delete a file inside ckeditor via kcfinder you get an "Unknown error." if the file name contains brackets. Those brackets are generated during upload if a file with the same name already exists (e.g `foo(1).jpg`).
Steps to reproduce:
1. Open a form which contains a text field with ckeditor (e.g. create an event)
2. Click on the link button of the ckeditor toolbar
3. Click on "Browse Server" to open kcfinder
4. Download a file via its context menu
5. Upload this downloaded file again
6. Note that the file is uploaded with brackets in its name
7. Try do delete this file via its context menu
8. Note message "Unknown error." and that the file has not been deleted
So in short you can not delete files which were renamed during upload because of already existing file names.5.34.0https://lab.civicrm.org/dev/drupal/-/issues/131Error: Class 'CRM_Upgrade_Incremental_General' not found in Civi\Install\Requ...2020-08-05T11:04:31ZRob_SError: Class 'CRM_Upgrade_Incremental_General' not found in Civi\Install\Requirements->checkMysqlVersion()Hi, I am getting this error message with Civi installed on a Drupal 8 site:
Error: Class 'CRM_Upgrade_Incremental_General' not found in Civi\Install\Requirements->checkMysqlVersion()
(line 294 of [path]/vendor/civicrm/civicrm-core/Civi/...Hi, I am getting this error message with Civi installed on a Drupal 8 site:
Error: Class 'CRM_Upgrade_Incremental_General' not found in Civi\Install\Requirements->checkMysqlVersion()
(line 294 of [path]/vendor/civicrm/civicrm-core/Civi/Install/Requirements.php)
I'm currently on 5.26.2. The problem happened a couole of upgrades back - sorry I cannot remember what versions I was upgrading from and too, but it is kept up to date.
The problem only really manifests when I run the Drupal update.php script (essential after upgrading core and modules), plus also on other rare occasions like once when I had to rebuild the permissions.
I have checked and the CRM_Upgrade_Incremental_General class is there, and the file permissions look ok, so I am guessing the problem is with the class loader, but I do not have any experience of how this works. I would be greatful if someone could give me a tip on how to fix this?
I can get round it for now by putting a 'return' statement at the beginning of the relevant function in the Requirements.php file, so can run the upgrade script, so it is not urgent.5.28.0https://lab.civicrm.org/dev/core/-/issues/1925Sortable select2 settings2023-04-11T05:03:20ZeileenSortable select2 settingsI want to make a setting Select2+ sortable (in an extension in this case). We enable that for checkboxes (as used by advanced search) - I think it would be good to broaden this - but not too sure how. If it's just adding a class I can't ...I want to make a setting Select2+ sortable (in an extension in this case). We enable that for checkboxes (as used by advanced search) - I think it would be good to broaden this - but not too sure how. If it's just adding a class I can't find it
@colemanw this is mostly a question for you in the first instancehttps://lab.civicrm.org/dev/core/-/issues/1924Group organization no longer an option2022-07-16T20:31:54ZandyburnsGroup organization no longer an optionIt used to be possible to tie a group to an organization. This shows in civicrm_group_organization table. Now I do not see this as an option. Was this an intentional change? Testing on 5.29
![image](/uploads/749d2063e383bb4dbee65e52389d...It used to be possible to tie a group to an organization. This shows in civicrm_group_organization table. Now I do not see this as an option. Was this an intentional change? Testing on 5.29
![image](/uploads/749d2063e383bb4dbee65e52389d654d/image.png)https://lab.civicrm.org/dev/core/-/issues/3560CiviMail flagged URI_WP_HACKED_2 by SpamAssassin2024-01-29T09:58:35ZbrendanspaarCiviMail flagged URI_WP_HACKED_2 by SpamAssassinOverview
----------------------------------------
CiviCRM emails were reported as going to the Spam folder in Gmail. I did some digging with mail-tester.com and found that SpamAssassin is dinging my mailings -1.629 points for the code UR...Overview
----------------------------------------
CiviCRM emails were reported as going to the Spam folder in Gmail. I did some digging with mail-tester.com and found that SpamAssassin is dinging my mailings -1.629 points for the code URI_WP_HACKED_2.
I did some more digging and found this is likely caused by the WP REST API that was integrated into Civi in 5.25. I'm currently running 5.27.0.
Things I have done that have not resolved the issue:
- I have installed the cv-rest-mailing plugin located here: https://develop.tadpole.cc/plugins/cv-rest-mailing
- I have also ran my site against MalCare which returned a Clean rating.
- I have disabled the plugin WP Mail SMTP.
- I have disabled tracing of opens and click throughs.
I have confirmed that this is occurring on 3 of my clients sites all running Civi 5.27.0 with Mosaico.
I have confirmed this on sites that are running gSuite as their email provider as well as sites that are running a local mail exchanger.
The following two Stack Exchange questions are open with no resolution. I confirmed with Heather O. that she is still facing difficulty.
- https://civicrm.stackexchange.com/questions/35064/civimail-tracked-links-in-wordpress-site-are-marked-down-by-mail-tester?r=SearchResults&s=3|14.7395
- https://civicrm.stackexchange.com/questions/36244/spamassassin-marking-mailings-as-compromised-wordpress-site?r=SearchResults&s=1|42.5634
Reproduction steps
----------------------------------------
1. Create a new group called SpamTesting
2. Create a new individual named Spam Tester
3. Add Spam Tester to the Group SpamTesting
4. Give the individual Spam Tester the email address corresponding to https://www.mail-tester.com/
5. Create a new mailing or reuse an existing mailing.
6. Add SpamTesting as a recipient group.
7. Send the mailing immediately
8. Click check your score on Mail-Tester.com
Current behaviour
----------------------------------------
Many CiviCRM mailings are going to spam after upgrading to 5.27.0. Please see attached image.
![KrY6G_1_](/uploads/9e3ce80bac221077adffbf7380dd8434/KrY6G_1_.png)
Expected behaviour
----------------------------------------
Emails should not be getting flagged as a hacked WordPress site.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Mail Server__ : gSuite
* __Browser:__ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36
* __CiviCRM:__ _Master/5.27.1
* __PHP:__ 7.3.14
* __CMS:__ WordPress 5.4.2
* __Database:__ _MySQL 8.0.18
* __Web Server:__ _Apache 2.4.41
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/3590Email to activity processing - creates duplicate contacts where verp is present2024-01-29T09:59:12ZeileenEmail to activity processing - creates duplicate contacts where verp is presentWhen contacts reply to a civimail from mail@domain.com they use the verp reply to - eg.
mail+r.2057.84206.03323c082c189038@domain.com
The address mail@domain.com exists in the db but a new contact is created rather than matching themWhen contacts reply to a civimail from mail@domain.com they use the verp reply to - eg.
mail+r.2057.84206.03323c082c189038@domain.com
The address mail@domain.com exists in the db but a new contact is created rather than matching themhttps://lab.civicrm.org/dev/core/-/issues/3550Email to activity processing: New feature to make the creation of new contact...2022-06-11T14:50:44ZJamie Novick - CompucoEmail to activity processing: New feature to make the creation of new contacts "optional"**User story:**
- As an administrator
- When filing inbound emails
- I would like to configure whether CiviCRM will create a new contact where a contact does not already exist within the system
- So that I can ensure that new contacts a...**User story:**
- As an administrator
- When filing inbound emails
- I would like to configure whether CiviCRM will create a new contact where a contact does not already exist within the system
- So that I can ensure that new contacts are not created in the system when filing an email.
- In the situation of a case email where the email has a valid Case ID or Case token in the subject line the email should still be filed to a case, even if no contacts are matched.
**How it works currently:**
Currently, when CiviCRM performs email to activity processing, Civi will search CiviCRM for a contact with the relevant email address in the From / To / CC fields and then assign the created activity accordingly.
When CiviCRM cannot find a contact with a relevant email address, it simply creates a new "stub" contact with the email address.
**The problem**
For multiple reasons this is might not be desirable behaviour:
This is a security risk, as in most cases CiviCRM email-activity processing works off a mailbox, that might need to be public. As such it is possible that an unscrupulous third party may chose to spam your mailbox and thus spam your CRM with unwanted emails and content. Whilst this can be mitigated by having your automated filing on a separate mailbox, it might be preferable to simply only file the emails for contacts who already exist in your system, and to selectively add the rest.
Also, from a GDPR perspective it may not be desirable to hold the details of the persons who sent an email, whilst the contents of the email might be important (i.e. the attachments) especially in a casework context.
**Proposed solution:**
Add an additional option to the email to activity processing configurations (civicrm/admin/mailSettings?action=add&reset=1)
- When "Used For?" = Email to activity processing
- Show an additional option:
- "Do not create new contacts when filing emails"
- Checkbox
- Default null
- Help:
- If this option is enabled, CiviCRM will not create new contacts when filing emails.
- The email should also always be filed as an activity.
If checked:
- When CiviCRM checks for a matching contact, if no matching contact is found it will not create one and the email is skipped
- unless the email has a valid Case ID or Case token in the subject line, in which it will still be filed against the case, but no contacts will be linked to the email.5.31.0https://lab.civicrm.org/dev/core/-/issues/3581Email to activity processing: New feature to skip emails which do not have a ...2022-06-11T14:54:48ZJamie Novick - CompucoEmail to activity processing: New feature to skip emails which do not have a Case ID or Case token- As a CiviCRM administrator
- I would like to configure whether CiviCRM will process emails without a case ID (or case “token”) in the subject line
- so that I can ensure that emails which do not have a case ID are not filed on the con...- As a CiviCRM administrator
- I would like to configure whether CiviCRM will process emails without a case ID (or case “token”) in the subject line
- so that I can ensure that emails which do not have a case ID are not filed on the contact record outside the case by accident.
**How it works currently**
For those a little less familiar with email to activity processing:
CiviCRM will connect to a users MS exchange mailbox and create the following folder structure:
- Inbox
- /CiviCRM
- //CiviMail
- ///ignored
- ///processed
Notes:
- Users simply copy or move emails into the /civicrm folder in their inbox. CiviCRM has a scheduled job that can be configured to run periodically (say every hour) and poll the mailbox folder (Civimail) by IMAP in order to read and process the emails.
- By default CiviCRM will match any email from, to, cc fields to contacts in the CRM and file the email as an activity against those contacts (including recording any attachments as files).
- If however there is a case ID in the subject line (or a case ID "token"*) then CiviCRM will instead file the email straight onto the case itself. The format is: [case #1234] (see: https://issues.civicrm.org/jira/browse/CRM-21446)
- If the email is processed successfully it will be moved to the processed folder.
- If for any reason CiviCRM cannot file the email it will be moved to the ignored folder. This normally happens if the email address is invalid for some reason (please note: emails that are sent internally between staff on exchange server can sometimes have this problem as exchange doesn't always use the external email address but instead uses some local username/domain combination - this maybe something to test and see if it maybe a problem for NEU).
- Note: *When sending out emails from CiviCRM from CiviCase it appends a case ID token - which is a string of characters and not the exact Case ID. This is done to obscure the case ID number in the email. In effect you can have either this token or the case id in the subject line and CiviCRM will file the email correctly.
- More background: https://docs.civicrm.org/sysadmin/en/latest/setup/civimail/inbound/#autofiling-email-activities-via-emailprocessor
**Problem**
For multiple clients they want to use email to activity processing for their casework teams. However sometimes they forget to add the case ID to the subject line of the email and the system incorrectly files the email outside the case - which is a "security" risk as the emails can be sensitive.
As such they would like to be able to specify that the emails being filed from the casework team inbox will only be filed if there is a valid Case ID in the subject line and are skipped if not, and hence there is no risk of the email being filed outside of the case.
**Proposed improvement**
Approach:
When "Used For?" = Email to activity processing
Show an additional option:
- Skip emails which do not have a Case ID or Case token:
- Checkbox
- Help text:
- CiviCRM has functionality to file emails which contain the Case ID or Case Hash in the subject line in the format [case #1234] against a case record.
- Where the Case ID or Case Hash is not included CiviCRM will file the email against the contact record, by matching the email addresses on the email with any email addresses of Contact records in CiviCRM.
- Enabling this option will have CiviCRM skip any emails that do not have the Case ID or Case Hash so that the system will only process emails that can be placed on case records.
- Any emails that are not processed will be moved the ignored folder.
- Default null
- If checked:
- Emails which do not have a valid case ID or case token should be moved into the “ignored” folder. (See folders above) after processing and no Activity should be created.
Would be great to know if we can get the magical "concept approved" flag.
We need to work on this quite urgently so if there are no great concerns that would be much appreciated...5.31.0https://lab.civicrm.org/dev/core/-/issues/1923CiviMail flagged URI_WP_HACKED_2 by SpamAssassin2020-08-03T22:16:31ZbrendanspaarCiviMail flagged URI_WP_HACKED_2 by SpamAssassinOverview
----------------------------------------
CiviCRM emails were reported as going to the Spam folder in Gmail. I did some digging with mail-tester.com and found that SpamAssassin is dinging my mailings -1.629 points for the code UR...Overview
----------------------------------------
CiviCRM emails were reported as going to the Spam folder in Gmail. I did some digging with mail-tester.com and found that SpamAssassin is dinging my mailings -1.629 points for the code URI_WP_HACKED_2.
I did some more digging and found this is likely caused by the WP REST API that was integrated into Civi in 5.25. I'm currently running 5.27.0.
Things I have done that have not resolved the issue:
- I have installed the cv-rest-mailing plugin located here: https://develop.tadpole.cc/plugins/cv-rest-mailing
- I have also ran my site against MalCare which returned a Clean rating.
- I have disabled the plugin WP Mail SMTP.
- I have disabled tracing of opens and click throughs.
I have confirmed that this is occurring on 3 of my clients sites all running Civi 5.27.0 with Mosaico.
I have confirmed this on sites that are running gSuite as their email provider as well as sites that are running a local mail exchanger.
The following two Stack Exchange questions are open with no resolution. I confirmed with Heather O. that she is still facing difficulty.
- https://civicrm.stackexchange.com/questions/35064/civimail-tracked-links-in-wordpress-site-are-marked-down-by-mail-tester?r=SearchResults&s=3|14.7395
- https://civicrm.stackexchange.com/questions/36244/spamassassin-marking-mailings-as-compromised-wordpress-site?r=SearchResults&s=1|42.5634
Reproduction steps
----------------------------------------
1. Create a new group called SpamTesting
2. Create a new individual named Spam Tester
3. Add Spam Tester to the Group SpamTesting
4. Give the individual Spam Tester the email address corresponding to https://www.mail-tester.com/
5. Create a new mailing or reuse an existing mailing.
6. Add SpamTesting as a recipient group.
7. Send the mailing immediately
8. Click check your score on Mail-Tester.com
Current behaviour
----------------------------------------
Many CiviCRM mailings are going to spam after upgrading to 5.27.0. Please see attached image.
![SpamAssassin Score](/uploads/baf70930c9fbbe231d8a3db44e5e19fa/KrY6G.png)
Expected behaviour
----------------------------------------
Emails should not be getting flagged as a hacked WordPress site.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ Mail Server: gSuite
* __Browser:__ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36
* __CiviCRM:__ _Master/5.27.1
* __PHP:__ 7.3.14
* __CMS:__ WordPress 5.4.2
* __Database:__ _MySQL 8.0.18
* __Web Server:__ _Apache 2.4.41
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/1922Downloaded Invoice activity attaches non wkhtmltopdf invoice2020-09-02T17:39:25ZDevAppDownloaded Invoice activity attaches non wkhtmltopdf invoiceWhen using wkhtmltopdf as the PDF engine, the invoices are emailed / printed correctly.
However, when an invoice is downloaded, it creates an activity against the contact with a copy of the invoice attached to the activity. This invoic...When using wkhtmltopdf as the PDF engine, the invoices are emailed / printed correctly.
However, when an invoice is downloaded, it creates an activity against the contact with a copy of the invoice attached to the activity. This invoice appears to not use the wkhtmltopdf engine, so the copy displays wrong.
When I turned off wkhtmltopdf, the invoice then appears the same. Bug appears to be downloaded invoice activity isn't using the wkhtmltopdf engine when specified.
![invoice_-_printed_emailed](/uploads/cc3ed15c0470d91f8ba57a187221f0bc/invoice_-_printed_emailed.png)
![invoice_-_downloaded](/uploads/646eef8b8a96949d8fbafd7a1df10290/invoice_-_downloaded.png)
![invoice_downloaded_activity](/uploads/049377a00c4c67db09b6b41f75a8002d/invoice_downloaded_activity.png)5.29.0https://lab.civicrm.org/dev/core/-/issues/1921Remove unneccessary isoToDate function2023-03-20T01:39:56ZeileenRemove unneccessary isoToDate function**[CQ] Let's celebrate the recent 6 year anniversary of making isoToData unnecessary by getting it out of the code**
Prior to July 2014 the following would fail
```
$contribution->fetch();
$contribution->save();
```
because the fetch ...**[CQ] Let's celebrate the recent 6 year anniversary of making isoToData unnecessary by getting it out of the code**
Prior to July 2014 the following would fail
```
$contribution->fetch();
$contribution->save();
```
because the fetch format for dates was invalid for save.
However, that all changed once this was merged https://github.com/civicrm/civicrm-packages/commit/283da6111677fc2b0176902b4c9a5cbcf668a258
Except for the bits that provide handling for it still litter our code