Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-03-17T18:15:55Zhttps://lab.civicrm.org/dev/core/-/issues/3112Regression on 5.48 upgrade2022-03-17T18:15:55ZeileenRegression on 5.48 upgradeNew upgrade bug ... - I got past it doing https://gerrit.wikimedia.org/r/c/wikimedia/fundraising/crm/civicrm/+/769796/1
- the item that it caught is further down
```
* ERROR USERINFO: SELECT `a`.`id` AS `id`, `a`.`option_group_...New upgrade bug ... - I got past it doing https://gerrit.wikimedia.org/r/c/wikimedia/fundraising/crm/civicrm/+/769796/1
- the item that it caught is further down
```
* ERROR USERINFO: SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`label` AS `label`, `a`.`value` AS `value`, `a`.`name` AS `name`, `a`.`grouping` AS `grouping`, `a`.`filter` AS `filter`, `a`.`is_default` AS `is_default`, `a`.`weight` AS `weight`, `a`.`description` AS `description`, `a`.`is_optgroup` AS `is_optgroup`, `a`.`is_reserved` AS `is_reserved`, `a`.`is_active` AS `is_active`, `a`.`component_id` AS `component_id`, `a`.`domain_id` AS `domain_id`, `a`.`visibility_id` AS `visibility_id`, `a`.`icon` AS `icon`, `a`.`color` AS `color`
FROM a
WHERE (`a`.`option_group_id` = "19") AND (`a`.`name` = "CiviGrant")
[nativecode=1146 ** Table 'civicrm.a' doesn't exist]
* ERROR DEBUGINFO: SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`label` AS `label`, `a`.`value` AS `value`, `a`.`name` AS `name`, `a`.`grouping` AS `grouping`, `a`.`filter` AS `filter`, `a`.`is_default` AS `is_default`, `a`.`weight` AS `weight`, `a`.`description` AS `description`, `a`.`is_optgroup` AS `is_optgroup`, `a`.`is_reserved` AS `is_reserved`, `a`.`is_active` AS `is_active`, `a`.`component_id` AS `component_id`, `a`.`domain_id` AS `domain_id`, `a`.`visibility_id` AS `visibility_id`, `a`.`icon` AS `icon`, `a`.`color` AS `color`
FROM a
WHERE (`a`.`option_group_id` = "19") AND (`a`.`name` = "CiviGrant")
[nativecode=1146 ** Table 'civicrm.a' doesn't exist]
#0 /srv/civi-sites/wmff/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(922): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#1 /srv/civi-sites/wmff/civicrm/vendor/pear/db/DB.php(997): PEAR_Error->__construct("DB Error: no such table", -18, 16, (Array:2), "SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#2 /srv/civi-sites/wmff/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-18, 16, (Array:2), "SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#3 /srv/civi-sites/wmff/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR->_raiseError(Object(DB_civirpow), NULL, -18, 16, (Array:2), "SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...", "DB_Error", TRUE)
#4 /srv/civi-sites/wmff/civicrm/vendor/pear/db/DB/common.php(1928): PEAR->__call("raiseError", (Array:7))
#5 /srv/civi-sites/wmff/civicrm/vendor/pear/db/DB/mysqli.php(936): DB_common->raiseError(-18, NULL, NULL, "SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...", "1146 ** Table 'civicrm.a' doesn't exist")
#6 /srv/civi-sites/wmff/civicrm/vendor/pear/db/DB/mysqli.php(406): DB_mysqli->mysqliRaiseError()
#7 /srv/civi-sites/wmff/drupal/sites/default/civicrm/extensions/rpow/DB/civirpow.php(66): DB_mysqli->simpleQuery("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#8 /srv/civi-sites/wmff/civicrm/vendor/pear/db/DB/common.php(1234): DB_civirpow->simpleQuery("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#9 /srv/civi-sites/wmff/civicrm/packages/DB/DataObject.php(2696): DB_common->query("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#10 /srv/civi-sites/wmff/civicrm/packages/DB/DataObject.php(1829): DB_DataObject->_query("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#11 /srv/civi-sites/wmff/civicrm/CRM/Core/DAO.php(468): DB_DataObject->query("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#12 /srv/civi-sites/wmff/civicrm/CRM/Core/DAO.php(1633): CRM_Core_DAO->query("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...", TRUE)
#13 /srv/civi-sites/wmff/civicrm/Civi/Api4/Query/Api4SelectQuery.php(167): CRM_Core_DAO::executeQuery("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#14 /srv/civi-sites/wmff/civicrm/Civi/Api4/Generic/DAOGetAction.php(113): Civi\Api4\Query\Api4SelectQuery->run()
#15 /srv/civi-sites/wmff/civicrm/Civi/Api4/Generic/DAOGetAction.php(101): Civi\Api4\Generic\DAOGetAction->getObjects(Object(Civi\Api4\Generic\Result))
#16 /srv/civi-sites/wmff/civicrm/Civi/Api4/Provider/ActionObjectProvider.php(69): Civi\Api4\Generic\DAOGetAction->_run(Object(Civi\Api4\Generic\Result))
#17 /srv/civi-sites/wmff/civicrm/Civi/API/Kernel.php(149): Civi\Api4\Provider\ActionObjectProvider->invoke(Object(Civi\Api4\Generic\DAOGetAction))
#18 /srv/civi-sites/wmff/civicrm/Civi/Api4/Generic/AbstractAction.php(234): Civi\API\Kernel->runRequest(Object(Civi\Api4\Generic\DAOGetAction))
#19 /srv/civi-sites/wmff/civicrm/api/api.php(85): Civi\Api4\Generic\AbstractAction->execute()
#20 /srv/civi-sites/wmff/civicrm/CRM/Upgrade/Incremental/php/FiveFortySeven.php(284): civicrm_api4("OptionValue", "get", (Array:2))
#21 /srv/civi-sites/wmff/civicrm/CRM/Queue/Task.php(73): CRM_Upgrade_Incremental_php_FiveFortySeven::migrateCiviGrant(Object(CRM_Queue_TaskContext))
#22 /srv/civi-sites/wmff/civicrm/CRM/Queue/Runner.php(215): CRM_Queue_Task->run(Object(CRM_Queue_TaskContext))
RAW Paste Data
* ERROR USERINFO: SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`label` AS `label`, `a`.`value` AS `value`, `a`.`name` AS `name`, `a`.`grouping` AS `grouping`, `a`.`filter` AS `filter`, `a`.`is_default` AS `is_default`, `a`.`weight` AS `weight`, `a`.`description` AS `description`, `a`.`is_optgroup` AS `is_optgroup`, `a`.`is_reserved` AS `is_reserved`, `a`.`is_active` AS `is_active`, `a`.`component_id` AS `component_id`, `a`.`domain_id` AS `domain_id`, `a`.`visibility_id` AS `visibility_id`, `a`.`icon` AS `icon`, `a`.`color` AS `color`
FROM a
WHERE (`a`.`option_group_id` = "19") AND (`a`.`name` = "CiviGrant")
[nativecode=1146 ** Table 'civicrm.a' doesn't exist]
* ERROR DEBUGINFO: SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`label` AS `label`, `a`.`value` AS `value`, `a`.`name` AS `name`, `a`.`grouping` AS `grouping`, `a`.`filter` AS `filter`, `a`.`is_default` AS `is_default`, `a`.`weight` AS `weight`, `a`.`description` AS `description`, `a`.`is_optgroup` AS `is_optgroup`, `a`.`is_reserved` AS `is_reserved`, `a`.`is_active` AS `is_active`, `a`.`component_id` AS `component_id`, `a`.`domain_id` AS `domain_id`, `a`.`visibility_id` AS `visibility_id`, `a`.`icon` AS `icon`, `a`.`color` AS `color`
FROM a
WHERE (`a`.`option_group_id` = "19") AND (`a`.`name` = "CiviGrant")
[nativecode=1146 ** Table 'civicrm.a' doesn't exist]
#0 /srv/civi-sites/wmff/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(922): CRM_Core_Error::exceptionHandler(Object(DB_Error))
#1 /srv/civi-sites/wmff/civicrm/vendor/pear/db/DB.php(997): PEAR_Error->__construct("DB Error: no such table", -18, 16, (Array:2), "SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#2 /srv/civi-sites/wmff/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-18, 16, (Array:2), "SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#3 /srv/civi-sites/wmff/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR->_raiseError(Object(DB_civirpow), NULL, -18, 16, (Array:2), "SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...", "DB_Error", TRUE)
#4 /srv/civi-sites/wmff/civicrm/vendor/pear/db/DB/common.php(1928): PEAR->__call("raiseError", (Array:7))
#5 /srv/civi-sites/wmff/civicrm/vendor/pear/db/DB/mysqli.php(936): DB_common->raiseError(-18, NULL, NULL, "SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...", "1146 ** Table 'civicrm.a' doesn't exist")
#6 /srv/civi-sites/wmff/civicrm/vendor/pear/db/DB/mysqli.php(406): DB_mysqli->mysqliRaiseError()
#7 /srv/civi-sites/wmff/drupal/sites/default/civicrm/extensions/rpow/DB/civirpow.php(66): DB_mysqli->simpleQuery("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#8 /srv/civi-sites/wmff/civicrm/vendor/pear/db/DB/common.php(1234): DB_civirpow->simpleQuery("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#9 /srv/civi-sites/wmff/civicrm/packages/DB/DataObject.php(2696): DB_common->query("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#10 /srv/civi-sites/wmff/civicrm/packages/DB/DataObject.php(1829): DB_DataObject->_query("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#11 /srv/civi-sites/wmff/civicrm/CRM/Core/DAO.php(468): DB_DataObject->query("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#12 /srv/civi-sites/wmff/civicrm/CRM/Core/DAO.php(1633): CRM_Core_DAO->query("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...", TRUE)
#13 /srv/civi-sites/wmff/civicrm/Civi/Api4/Query/Api4SelectQuery.php(167): CRM_Core_DAO::executeQuery("SELECT `a`.`id` AS `id`, `a`.`option_group_id` AS `option_group_id`, `a`.`lab...")
#14 /srv/civi-sites/wmff/civicrm/Civi/Api4/Generic/DAOGetAction.php(113): Civi\Api4\Query\Api4SelectQuery->run()
#15 /srv/civi-sites/wmff/civicrm/Civi/Api4/Generic/DAOGetAction.php(101): Civi\Api4\Generic\DAOGetAction->getObjects(Object(Civi\Api4\Generic\Result))
#16 /srv/civi-sites/wmff/civicrm/Civi/Api4/Provider/ActionObjectProvider.php(69): Civi\Api4\Generic\DAOGetAction->_run(Object(Civi\Api4\Generic\Result))
#17 /srv/civi-sites/wmff/civicrm/Civi/API/Kernel.php(149): Civi\Api4\Provider\ActionObjectProvider->invoke(Object(Civi\Api4\Generic\DAOGetAction))
#18 /srv/civi-sites/wmff/civicrm/Civi/Api4/Generic/AbstractAction.php(234): Civi\API\Kernel->runRequest(Object(Civi\Api4\Generic\DAOGetAction))
#19 /srv/civi-sites/wmff/civicrm/api/api.php(85): Civi\Api4\Generic\AbstractAction->execute()
#20 /srv/civi-sites/wmff/civicrm/CRM/Upgrade/Incremental/php/FiveFortySeven.php(284): civicrm_api4("OptionValue", "get", (Array:2))
#21 /srv/civi-sites/wmff/civicrm/CRM/Queue/Task.php(73): CRM_Upgrade_Incremental_php_FiveFortySeven::migrateCiviGrant(Object(CRM_Queue_TaskContext))
#22 /srv/civi-sites/wmff/civicrm/CRM/Queue/Runner.php(215): CRM_Queue_Task->run(Object(CRM_Queue_TaskContext))
```
```
Mar 11 00:32:00 [warning] Array
(
[entity] => Navigation
[values] => Array
(
[name] => Grant Status
[domain_id] => current_domain
)
)
Array
(
[checkPermissions] =>
[where] => Array
(
[0] => Array
(
[0] => name
[1] => =
[2] => Grant Status
)
[1] => Array
(
[0] => domain_id
[1] => =
[2] => current_domain
)
)
)
```5.47.2https://lab.civicrm.org/dev/core/-/issues/3107Upgrading from pre-5.47 to 5.48+ isn't re-runnable in certain situations2022-06-29T02:33:30ZDaveDUpgrading from pre-5.47 to 5.48+ isn't re-runnable in certain situations
Since sketching out the below, I think I can see there is a quick solution, but now that I've written the description already I'll still post the whole thing. Short version: This line should have a check that `is_autorun` exists in the ...
Since sketching out the below, I think I can see there is a quick solution, but now that I've written the description already I'll still post the whole thing. Short version: This line should have a check that `is_autorun` exists in the table before running the query: https://github.com/civicrm/civicrm-core/blob/88e3bfdfc52aa1e117160b6592597510af446d1a/CRM/Upgrade/Incremental/php/FiveFortyEight.php#L60
Problem
-------
Typical sysadmin: "Goin' to upgrade now. Let me make a backup... ok, done. Upgrade, and ... oh that failed. Ok let me reload my sql file and apply this patch and try again... Oh that failed - something about queues. Repeat. Fail again. Hmm."
For a dev doing testing this might not come up, because they might "start from scratch" when repeating (or use trickery like devs do).
The difference is the reload db, and in particular when upgrading pre-5.47 to 5.48+. And given the history to-date, that reload-and-try-again cycle is likely to come up more with 5.47 than usual.
In 5.47, the `civicrm_queue` table is created, but [ONLY if it doesn't exist](https://github.com/civicrm/civicrm-core/blob/88e3bfdfc52aa1e117160b6592597510af446d1a/CRM/Upgrade/Incremental/sql/5.47.alpha1.mysql.tpl#L3). I.e. as opposed to `DROP TABLE IF EXISTS civicrm_queue`, followed by the creation. Since this table might have long-term data, you don't want to drop it if an upgrade is being re-run some time in the future.
(Aside: That create table statement probably shouldn't enforce utf8mb4 yet, but that's separate.)
So now let's think about the sequence for the sysadmin:
* Before first attempt, civicrm_queue didn't exist.
* After first attempt, it now exists.
* Reload db. Note something important: The backup sql file does NOT have anything about civicrm_queue. There is no DROP TABLE statement for it. So after reloading the sql file, civicrm_queue DOES exist, which is different from before the first run.
* If you're the type of sysadmin who drops the whole db before reloading the sql file, you won't run into this. I don't know what percentage that covers.
So now, there's [an upgrade step](https://github.com/civicrm/civicrm-core/blob/88e3bfdfc52aa1e117160b6592597510af446d1a/CRM/Upgrade/Incremental/php/FiveFortyEight.php#L60) in 5.48 that assumes that the field `is_autorun` is going to exist. But it doesn't because civicrm_queue at this point is the already upgraded table.
SECONDARY ISSUE
---------------
There's another issue here too for similar reasons, but I haven't confirmed the specific problem, but at the moment I think there is one.
Something new in 5.47 is that civi will auto-install search kit and afform. These both create database tables. So you have a similar situation where after reloading the db, you have an already upgraded table present when it shouldn't be, so you get a similar problem when something tries to act on it in a way that isn't re-runnable.https://lab.civicrm.org/dev/core/-/issues/3104RC Error: Call to undefined method CRM_Contact_Page_View_Summary::addExpected...2022-03-13T10:28:32Zmagnolia61RC Error: Call to undefined method CRM_Contact_Page_View_Summary::addExpectedSmartyVariables()With the current RC (5.48 beta 1) I get the following fatal error when I want to view a contact record
`Error: Call to undefined method CRM_Contact_Page_View_Summary::addExpectedSmartyVariables() in CRM_Core_BAO_CustomGroup::buildCustom...With the current RC (5.48 beta 1) I get the following fatal error when I want to view a contact record
`Error: Call to undefined method CRM_Contact_Page_View_Summary::addExpectedSmartyVariables() in CRM_Core_BAO_CustomGroup::buildCustomDataView() (line 1986 of /var/www/vhosts/xyz/webroot/sites/all/modules/civicrm/CRM/Core/BAO/CustomGroup.php).`
- CiviCRM: 5.48.beta1
- CMS: Drupal 7.89
- PHP: 7.4.28 (fpm-fcgi)
- Database: 10.6.5-MariaDB-1:10.6.5+maria~bullseye-log engine: InnoDB 10 row format: Dynamic
- Webserver: Apache
- OS: Linux5.48.0https://lab.civicrm.org/dev/core/-/issues/3100Grant CiviReport menu inconsistencies2022-03-09T13:47:08ZDaveDGrant CiviReport menu inconsistencies1. On a brand new install without civigrant, there's an empty Reports - CiviGrant menu.
1. If you install civigrant or upgrade from a site that had civigrant, the CiviGrant menu is still empty, and the reports get put under Reports - Con...1. On a brand new install without civigrant, there's an empty Reports - CiviGrant menu.
1. If you install civigrant or upgrade from a site that had civigrant, the CiviGrant menu is still empty, and the reports get put under Reports - Contact Reports.
There's two things I think:
1. Some leftovers in the xml files from before. Should be an easy fix.
1. Even if that's fixed, where _should_ the extension's reports live in the menu?5.47.1https://lab.civicrm.org/dev/core/-/issues/3095Formatting shows Currency for samey-locales2022-03-05T14:09:10ZeileenFormatting shows Currency for samey-localesThe switch to BrickMoney has the positive impact of adding a currency for the non-site-default locale - so for a US site NZ donations would be prefixed with NZ.
However, it turns out it is pretty common for NZ sites to leave the site la...The switch to BrickMoney has the positive impact of adding a currency for the non-site-default locale - so for a US site NZ donations would be prefixed with NZ.
However, it turns out it is pretty common for NZ sites to leave the site language as en_US as no other English variants are offered without the translation install...
![image](/uploads/7a814b43db89c9c100b4cbd7c9ccd528/image.png)
We discussed this & think that the remedy is to add a new setting
format_locale
If set this will be used for money formatting INSTEAD of thousand separator and decimal separator - ie those will be determinted from the format_locale and we will hide those settings in the UI and deprecate them. Over time we will encourage people to switch. This setting can also be used for dates5.47.0https://lab.civicrm.org/dev/core/-/issues/3094Contribution view page crashes if you don't have event permissions2022-03-08T00:10:22ZDaveDContribution view page crashes if you don't have event permissionshttps://github.com/civicrm/civicrm-core/pull/22732 adds info about participants to the page but the api call throws an exception if you don't have permissions. I think I'll just put up a PR to wrap in a try/catch and then not display the...https://github.com/civicrm/civicrm-core/pull/22732 adds info about participants to the page but the api call throws an exception if you don't have permissions. I think I'll just put up a PR to wrap in a try/catch and then not display the participant stuff if error.5.48.0https://lab.civicrm.org/dev/core/-/issues/3093Upgrade error with civigrant - order of dependencies matters2022-03-07T22:15:00ZDaveDUpgrade error with civigrant - order of dependencies matters1. Install an older version of civi. Let's say 5.39 but I don't think it matters too much.
1. Enable the CiviGrant component.
1. **Don't** install search kit.
1. Upgrade. You'll see a message about "extension error" that looks like this....1. Install an older version of civi. Let's say 5.39 but I don't think it matters too much.
1. Enable the CiviGrant component.
1. **Don't** install search kit.
1. Upgrade. You'll see a message about "extension error" that looks like this. So far not a problem, but note the order of dependencies listed. The average person will now attempt to install `Form Core` first.
![Untitled2](/uploads/84a1e72d59998ab8fc392187e72a5d29/Untitled2.png)
1. NO! You must install search kit first. Otherwise you get `API error: API (SearchDisplay, create) does not exist (join the API team and implement it!) on SearchDisplay.create`.
Note that this is slightly different from https://lab.civicrm.org/dev/core/-/issues/3036 (PR https://github.com/civicrm/civicrm-core/pull/22623) which dealt with interdependence between form builder and search kit, and the order there doesn't matter.5.47.0https://lab.civicrm.org/dev/core/-/issues/3088Notice error on dmaster2022-04-13T23:35:48ZJoeMurrayNotice error on dmasterOn dmaster 5.48.alpha1. Administer > CiviContribute Component Settings. Check Always post to Accounts Receivable? and submit, then one sees:
Notice: Trying to get property 'info' of non-object in CRM_Admin_Page_Admin->run() (line 43 of ...On dmaster 5.48.alpha1. Administer > CiviContribute Component Settings. Check Always post to Accounts Receivable? and submit, then one sees:
Notice: Trying to get property 'info' of non-object in CRM_Admin_Page_Admin->run() (line 43 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Admin/Page/Admin.php).
Notice: Trying to get property 'info' of non-object in CRM_Admin_Page_Admin->run() (line 43 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Admin/Page/Admin.php).
I marked as regression but don't know when this appeared. If I had to guess it is related to PHP version rather than a code change.Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3087CiviGrant appears in admin menu twice2022-03-01T01:07:07ZDaveDCiviGrant appears in admin menu twiceI think it's maybe some leftovers in xml/templates/civicrm_navigation.tpl that need to be moved over/removed.I think it's maybe some leftovers in xml/templates/civicrm_navigation.tpl that need to be moved over/removed.5.47.0https://lab.civicrm.org/dev/core/-/issues/3084Backend membership with a price set will ignore the price field financial typ...2022-05-05T06:27:07ZherbdoolBackend membership with a price set will ignore the price field financial type, uses price set insteadOverview
----------------------------------------
Backend membership with a price set will ignore the price field financial type, uses price set instead. (This is a different problem from https://lab.civicrm.org/dev/core/-/issues/3083 t...Overview
----------------------------------------
Backend membership with a price set will ignore the price field financial type, uses price set instead. (This is a different problem from https://lab.civicrm.org/dev/core/-/issues/3083 though they should be consistent).
Related to https://lab.civicrm.org/dev/core/-/issues/3084, https://lab.civicrm.org/dev/core/-/issues/2414
Reproduction steps
----------------------------------------
1. Set up a price set to include memberships.
2. One price field should be membership of financial type Member Dues. The other Donation.
![2022-02-25_14.17.49_dev-cycleto.pantheonsite.io_edb775bf4afb](/uploads/baab97de74fc3910e4a016138db06c98/2022-02-25_14.17.49_dev-cycleto.pantheonsite.io_edb775bf4afb.png)
3. Make a backend membership purchase.
Current behaviour
----------------------------------------
The contribution will show that each line item gets the financial type from the price set and not from the price set field:
![2022-02-25_14.16.03_dev-cycleto.pantheonsite.io_372ee7ffbad1](/uploads/1f8a227ce02fb8c0d1b28a707ada8af0/2022-02-25_14.16.03_dev-cycleto.pantheonsite.io_372ee7ffbad1.png)
And it doesn't set the non-deductible amount properly. In fact, I don't think it's set either way. If I change the price set financial type to be Merchandise then it still doesn't set the non-deductible.
![2022-02-25_14.25.54_dev-cycleto.pantheonsite.io_ad7e30a61562](/uploads/4b22eafeeca74ee89f60918102bed234/2022-02-25_14.25.54_dev-cycleto.pantheonsite.io_ad7e30a61562.png)
Expected behaviour
----------------------------------------
Should use the financial type of the price set *field/option*. And it should set the non-deductible based on that. This is how it's working for a non-member price set: it will use the price field financial type and non-deductible amount regardless of what the price set is using.5.49.0https://lab.civicrm.org/dev/core/-/issues/3069Grant fields are included in exports in the Contact grouping2024-03-08T00:10:30ZDaveDGrant fields are included in exports in the Contact groupingGo to e.g. find contacts or find activities and from the results pick some or all and choose Export from the actions dropdown. Choose select fields for export. In the Contacts grouping, CiviGrant fields are being included there. I don't ...Go to e.g. find contacts or find activities and from the results pick some or all and choose Export from the actions dropdown. Choose select fields for export. In the Contacts grouping, CiviGrant fields are being included there. I don't remember seeing this before but will double-check if that's where they used to show up.5.47.0https://lab.civicrm.org/dev/core/-/issues/3063Foreign constraint violation on APIv3 contribution create if financial_type_i...2022-02-16T21:27:08ZIan WilsonForeign constraint violation on APIv3 contribution create if financial_type_id is numericOverview
----------------------------------------
We have a lot of numeric financial types. On the new ESR (and also the dmaster site), attempts to create contributions via APIv3 are failing.
Reproduction steps
-------------------------...Overview
----------------------------------------
We have a lot of numeric financial types. On the new ESR (and also the dmaster site), attempts to create contributions via APIv3 are failing.
Reproduction steps
----------------------------------------
1. Go to /civicrm/api3/#explorer
1. Select "FinancialType" for entity and "create" for action.
1. Fill in a numeric value (e.g. 1234) for Financial Type Value and click Execute.
1. Reload the page.
1. Select "Contribution" for entity and "create" for action.
1. Select your newly created Financial Type ID from the list and fill in anything for other values.
1. Click Execute.
Current behaviour
----------------------------------------
The financial_type_id parameter accepts the financial type name (e.g. "Event Fee"). However, if the provided value is a number, it appears that the resulting SQL query attempts to use the number directly instead of looking up the associated key.
On the dmaster website the following query (via APIv3 explorer):
```php
$result = civicrm_api3('Contribution', 'create', [
'financial_type_id' => 1234,
'receive_date' => "2022-02-08",
'total_amount' => 50,
'contact_id' => "user_contact_id",
]);
```
produces the following result:
```json
{
"code": -3,
"error_message": "DB Error: constraint violation",
"mode": 16,
"debug_info": "INSERT INTO `civicrm_contribution` (`contact_id` , `financial_type_id` , `payment_instrument_id` , `receive_date` , `total_amount` , `fee_amount` , `net_amount` , `currency` , `contribution_status_id` , `tax_amount` ) VALUES ( 204 , 1234 , 4 , 20220208000000 , 50 , 0 , 50 , 'USD' , 1 , 0 ) [nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`dmastercivi_g5lis`.`civicrm_contribution`, CONSTRAINT `FK_civicrm_contribution_financial_type_id` FOREIGN KEY (`financial_type_id`) REFERENCES `civicrm_financial_type` (`id`))]",
"type": "DB_Error",
"user_info": "INSERT INTO `civicrm_contribution` (`contact_id` , `financial_type_id` , `payment_instrument_id` , `receive_date` , `total_amount` , `fee_amount` , `net_amount` , `currency` , `contribution_status_id` , `tax_amount` ) VALUES ( 204 , 1234 , 4 , 20220208000000 , 50 , 0 , 50 , 'USD' , 1 , 0 ) [nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`dmastercivi_g5lis`.`civicrm_contribution`, CONSTRAINT `FK_civicrm_contribution_financial_type_id` FOREIGN KEY (`financial_type_id`) REFERENCES `civicrm_financial_type` (`id`))]",
"to_string": "[db_error: message=\"DB Error: constraint violation\" code=-3 mode=callback callback=CRM_Utils_REST::fatal prefix=\"\" info=\"INSERT INTO `civicrm_contribution` (`contact_id` , `financial_type_id` , `payment_instrument_id` , `receive_date` , `total_amount` , `fee_amount` , `net_amount` , `currency` , `contribution_status_id` , `tax_amount` ) VALUES ( 204 , 1234 , 4 , 20220208000000 , 50 , 0 , 50 , 'USD' , 1 , 0 ) [nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`dmastercivi_g5lis`.`civicrm_contribution`, CONSTRAINT `FK_civicrm_contribution_financial_type_id` FOREIGN KEY (`financial_type_id`) REFERENCES `civicrm_financial_type` (`id`))]\"]",
"is_error": 1
}
```
Using a text value produces a similar example query:
```php
$result = civicrm_api3('Contribution', 'create', [
'financial_type_id' => "Event Fee",
'receive_date' => "2022-02-08",
'total_amount' => 50,
'contact_id' => "user_contact_id",
]);
```
and the result is successful:
```json
{
"is_error": 0,
"version": 3,
"count": 1,
"id": 116,
"values": {
"116": {
"id": "116",
"contact_id": "204",
"financial_type_id": "4",
"contribution_page_id": "",
"payment_instrument_id": "4",
"receive_date": "20220208000000",
"non_deductible_amount": "",
"total_amount": "50",
"fee_amount": "0",
"net_amount": "50",
"trxn_id": "",
"invoice_id": "",
"invoice_number": "",
"currency": "USD",
"cancel_date": "",
"cancel_reason": "",
"receipt_date": "",
"thankyou_date": "",
"source": "",
"amount_level": "",
"contribution_recur_id": "",
"is_test": "",
"is_pay_later": "",
"contribution_status_id": "1",
"address_id": "",
"check_number": "",
"campaign_id": "",
"creditnote_id": "",
"tax_amount": "0",
"revenue_recognition_date": "",
"is_template": "",
"contribution_type_id": "4"
}
}
}
```
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.45.35.46.2https://lab.civicrm.org/dev/core/-/issues/3059Regression - fatal error when viewing custom fields with money > 10002022-02-09T22:34:18ZeileenRegression - fatal error when viewing custom fields with money > 1000AFFECTS 5.46
To replicate - create a custom field of type money - mine was against entity contribution.
Create a contribution (or whatever) with the field and give it a value greater than 1000.
Attempt to view - fatal error
![image](...AFFECTS 5.46
To replicate - create a custom field of type money - mine was against entity contribution.
Create a contribution (or whatever) with the field and give it a value greater than 1000.
Attempt to view - fatal error
![image](/uploads/2a5e654878a4cc8470890cad953e0299/image.png)5.46.1https://lab.civicrm.org/dev/core/-/issues/3056Search Builder crashes if you have admin access and CiviGrant is not enabled2022-02-28T17:00:43ZDaveDSearch Builder crashes if you have admin access and CiviGrant is not enabledThis is "search builder" as in the menu option Search -> Search Builder (civicrm/contact/search/builder)
CiviGrant was recently moved to an extension. If you don't have it enabled and have admin access search builder thinks you have acc...This is "search builder" as in the menu option Search -> Search Builder (civicrm/contact/search/builder)
CiviGrant was recently moved to an extension. If you don't have it enabled and have admin access search builder thinks you have access to civigrant and tries to add the component but can't find it:
`Error: Class 'CRM_Grant_BAO_Grant' not found in CRM_Core_BAO_Mapping::addComponentFields() (line 764 of ...\CRM\Core\BAO\Mapping.php).`
```php
if (CRM_Core_Permission::check('access CiviGrant')) {
$fields['Grant'] = CRM_Grant_BAO_Grant::exportableFields();
```5.47.0https://lab.civicrm.org/dev/core/-/issues/3055System.check permissions changed in Civi 5.462022-02-09T05:05:44ZJonGoldSystem.check permissions changed in Civi 5.46This is a regression, but most folks aren't going to see this.
[PR 22369](https://github.com/civicrm/civicrm-core/pull/22369) adds a new system check to ensure dedupe rules are present. However, it makes [an API4 call](https://github.c...This is a regression, but most folks aren't going to see this.
[PR 22369](https://github.com/civicrm/civicrm-core/pull/22369) adds a new system check to ensure dedupe rules are present. However, it makes [an API4 call](https://github.com/civicrm/civicrm-core/blob/bf2fc668d9e458df17248e35968fbb06b97411d6/CRM/Utils/Check/Component/DedupeRules.php#L25) without bypassing a permission check.
Most of the time you need "Administer CiviCRM" to run `System.check` so this is usually fine. However, I have an extension that creates a custom permission that can also be used. This allows me to monitor CiviCRM remotely without storing an API key for an admin account on my monitoring server. So on 5.46 that user gets "authorization failed" when I run `System.check`.
Given the non-sensitive nature of this data, and the fact that someone must have permission to run `System.check`, I think it makes sense for this API call to bypass the permission check.5.46.1JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3047Contribution receipt no longer sends groupName to alterMailParams hook2022-01-30T16:44:44ZDaveDContribution receipt no longer sends groupName to alterMailParams hookLooks like it's these changes: https://github.com/civicrm/civicrm-core/pull/22615/files#diff-9a5050a22004395ee29b440cd543c11c4283cdb72563f28eae30806e5eba8cd3L418
I know there is some ongoing work to deprecate groupName etc but I thought...Looks like it's these changes: https://github.com/civicrm/civicrm-core/pull/22615/files#diff-9a5050a22004395ee29b440cd543c11c4283cdb72563f28eae30806e5eba8cd3L418
I know there is some ongoing work to deprecate groupName etc but I thought current hooks would still work for now, unless I missed it somewhere in a dev-digest.
Putting regression (in master) for the moment.https://lab.civicrm.org/dev/core/-/issues/3046searchkit: Where clauses no longer working2022-01-31T05:23:32ZDaveDsearchkit: Where clauses no longer workingNot sure when this broke. Probably recent.
It returns no records.
![Untitled2](/uploads/705e0f68edf50b8c44c264d0c2f7fd34/Untitled2.png)Not sure when this broke. Probably recent.
It returns no records.
![Untitled2](/uploads/705e0f68edf50b8c44c264d0c2f7fd34/Untitled2.png)5.47.0https://lab.civicrm.org/dev/core/-/issues/3045Upgrade error - unknown column 'entity_modified_date' in 'civicrm_managed'2022-02-02T01:47:08ZwmortadaUpgrade error - unknown column 'entity_modified_date' in 'civicrm_managed'Overview
----------------------------------------
I've come across an issue when upgrading a site from CiviCRM 5.33.5 to CiviCRM 5.45.1.
Looking at the error log, I think the issue is that the upgrade process is trying to set the `enti...Overview
----------------------------------------
I've come across an issue when upgrading a site from CiviCRM 5.33.5 to CiviCRM 5.45.1.
Looking at the error log, I think the issue is that the upgrade process is trying to set the `entity_modified_date` in `civicrm_managed` before this field is created.
I think the error occurs when the upgrader is running the `upgrade_5_39_alpha1` in `/CRM/Upgrade/Incremental/php/FiveThirtyNine.php`. The post hook calls `/CRM/Core/BAO/Managed.php`(which was added in CiviCRM 5.45). Line 37 of which executes this SQL:
```sql
UPDATE civicrm_managed SET entity_modified_date = CURRENT_TIMESTAMP WHERE entity_type = 'SavedSearch' AND entity_id = 348;
```
This fails with an error, because `entity_modified_date` field isn't added until CiviCRM 5.45. It is added in `/CRM/Upgrade/Incremental/php/FiveFortyFive.php`.
Reproduction steps
----------------------------------------
Update from CiviCRM 5.33.5 to CiviCRM 5.45.1 using `cv upgrade:db`.
Presumably the site needs to have some saved searches that are modified in the 5.39 upgrade process.
Current behaviour
----------------------------------------
Upgrade fails with error:
```shell
Dropping SQL triggers...
Preparing upgrade...
Executing upgrade...
...................................................PHP Warning: A non-numeric value encountered in phar:///usr/local/bin/cv/vendor/symfony/console/Output/Output.php on line 145
Warning: A non-numeric value encountered in phar:///usr/local/bin/cv/vendor/symfony/console/Output/Output.php on line 145
PHP Warning: A non-numeric value encountered in phar:///usr/local/bin/cv/vendor/symfony/console/Output/Output.php on line 148
Warning: A non-numeric value encountered in phar:///usr/local/bin/cv/vendor/symfony/console/Output/Output.php on line 148
Error executing task: %s
[CiviCRM_API3_Exception]
DB Error: no such field
```
Expected behaviour
----------------------------------------
Upgrade completes successfully.
Environment information
----------------------------------------
* __Browser:__ N/A
* __CiviCRM:__ 5.33.5 to 5.45.1
* __PHP:__ 7.3
* __CMS:__ WordPress 5.4
* __Database:__ MySQL 5.7.27
* __Web Server:__ Nginx 1.15.0
Comments
----------------------------------------
Possibly related error reported here: https://civicrm.stackexchange.com/questions/41040/upgrade-fails-unknown-column-entity-modified-date
Workaround
----------------------------------------
A workaround is to upgrade to CiviCRM 5.44 first and then to CiviCRM 5.45. This fixed the problem for me with this particular site.https://lab.civicrm.org/dev/core/-/issues/3036Form Builder (afform-admin) requires search_kit in 5.45 causing crash if you ...2022-03-01T00:32:23ZDaveDForm Builder (afform-admin) requires search_kit in 5.45 causing crash if you have Form Builder installed but not search kit before upgradingOne option is force install search kit during upgrade if form builder is installed. Pros and cons to that.
Another option is form builder disable itself during upgrade if search kit is not installed. Also pros and cons.
Another is a pr...One option is force install search kit during upgrade if form builder is installed. Pros and cons to that.
Another option is form builder disable itself during upgrade if search kit is not installed. Also pros and cons.
Another is a pre-upgrade message warning of the issue and what they can do (install search kit or disable afform-admin).
Another is make form builder more tolerant of missing search kit, but it seems like the extension system itself is also looking at the dependency and expecting it to be there.
https://civicrm.stackexchange.com/questions/41044/error-class-crm-search-upgrader-not-found-since-upgrading-to-5-45-1-joomla
and
https://civicrm.stackexchange.com/questions/41068/error-class-crm-search-upgrader-not-found-since-upgrading-civicrm-to-5-45-1-on/41084#410845.45.2https://lab.civicrm.org/dev/core/-/issues/3028Fatal error when merging Housholds (getTemplateForGreeting)2022-02-04T14:41:41Zmagnolia61Fatal error when merging Housholds (getTemplateForGreeting)Overview
----------------------------------------
When I try to merge two households of which one has the "communication style" filled, the merge results in a fatal error
Reproduction steps
----------------------------------------
1. Cl...Overview
----------------------------------------
When I try to merge two households of which one has the "communication style" filled, the merge results in a fatal error
Reproduction steps
----------------------------------------
1. Click on merge housholds
2. Merge two households of which one has a "communication style" field
1. Try to merge: end up with fatal error.
Current behaviour
----------------------------------------
![afbeelding](/uploads/378cececbc7a52ab2f6f1074255e345f/afbeelding.png)
`TypeError: Return value of CRM_Contact_BAO_Contact::getTemplateForGreeting() must be of the type string, null returned in CRM_Contact_BAO_Contact::getTemplateForGreeting() (line 3509 of /var/www/vhosts/xyz/webroot/sites/all/modules/civicrm/CRM/Contact/BAO/Contact.php).`
`Notice: Undefined offset: 1 in CRM_Contact_BAO_Contact::getTemplateForGreeting() (line 3509 of /var/www/vhosts/xyz/webroot/sites/all/modules/civicrm/CRM/Contact/BAO/Contact.php).`
Expected behaviour
----------------------------------------
Successful merge of two households
Environment information
----------------------------------------
- CiviCRM: 5.45.0
- CMS: Drupal 7.84
- PHP: 7.4.27 (fpm-fcgi)
- Database: 10.6.5-MariaDB-1:10.6.5+maria~bullseye-log engine: InnoDB 10 row format: Dynamic
- Webserver: Apache
- OS: Linux
Comments
----------------------------------------
_Anything else you would like the reviewer to note._5.45.2