Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-02-09T05:05:44Zhttps://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/joomla/-/issues/38HTML Class generation assumes "class safe" names2022-02-11T20:21:03ZphilmorbruHTML Class generation assumes "class safe" namesBringing this issue over from the [iATS extension page](https://github.com/iATSPayments/com.iatspayments.civicrm/issues/367) where there are images and more documentation. Indications are that this also affects WordPress sites.
In short...Bringing this issue over from the [iATS extension page](https://github.com/iATSPayments/com.iatspayments.civicrm/issues/367) where there are images and more documentation. Indications are that this also affects WordPress sites.
In short, html classes that are generated for the iATS extension and possibly other contexts assume the machine name is class safe. If the name has spaces ("iATS Payments Credit Card" rather than "iATS_Payments_Credit_Card"), it results in multiple classes (.iATS .Payments .credit .card) rather than the single class (.iATS_Payments_Credit_Card).
A primary problem with this is that if the standard .card class is used on a site (very common with bootstrap), it leads to formatting problems for elements with Civi-generated classes. Otherwise this issue might fly under the radar on most sites.
Joomla! 3.9.24, Civi 5.39.0, iATS extension 1.7.45.48.0https://lab.civicrm.org/dev/core/-/issues/3052Homepage field does not accept non-ascii2022-09-29T14:42:48Zthoni56Homepage field does not accept non-asciiOverview
----------------------------------------
The Contact field "Homepage" does not accept anything other than ASCII.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> New Individual**.
1. Entered...Overview
----------------------------------------
The Contact field "Homepage" does not accept anything other than ASCII.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> New Individual**.
1. Entered the following URL in Homepage field: "https://www.linkedin.com/in/marcus-junström-8ba54626/".
Current behaviour
----------------------------------------
Got an error "Enter a valid web address beginning with 'http://' or 'https://'.", which is wrong, but also prevents using modern URLs which allows UTF8 or other encoding, such as LinkedIN pages.
Expected behaviour
----------------------------------------
It should be possible to enter modern, encoded, URL:s.
Environment information
----------------------------------------
* __Browser:__ _Safari 15.3_
* __CiviCRM:__ _5.45.1_
* __CMS:__ _Joomla 3.10_5.51.0https://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/3038Import contribution fails to update payment instrument in update mode2022-05-31T13:09:04ZKurund JalmiImport contribution fails to update payment instrument in update modeSteps to replicate:
* Add a contribution record with payment method `Cheque`
* Import contribution in update mode.
Here is the sample CSV
| Total Amount | Financial Type | Payment Method | Contribution ID |
|--------------|----------...Steps to replicate:
* Add a contribution record with payment method `Cheque`
* Import contribution in update mode.
Here is the sample CSV
| Total Amount | Financial Type | Payment Method | Contribution ID |
|--------------|----------------|-----------------|-----------------|
| 100 | Donation | Cash | 10 |
Current behavior: Payment method is still `Cheque`
Expected behavior: Payment method should be `Cash`5.50.0https://lab.civicrm.org/dev/core/-/issues/3037Proposal: update 2-digit year import to be configurable/rolling2022-01-28T14:54:48ZnoahProposal: update 2-digit year import to be configurable/rollingOverview
----------------------------------------
The handling of 2-digit years during import uses a heuristic that no longer makes sense. For example, "1/1/22" is imported as January 1, **19**22 (not 2022). We should implement somethin...Overview
----------------------------------------
The handling of 2-digit years during import uses a heuristic that no longer makes sense. For example, "1/1/22" is imported as January 1, **19**22 (not 2022). We should implement something that makes more sense.
Current behaviour
----------------------------------------
Currently the following is hard-coded into CRM/Utils/Date.php within `convertToDefaultDate()`.
```php
// simple heuristic to determine what century to use
// 00 - 20 is always 2000 - 2020
// 21 - 99 is always 1921 - 1999
if ($year < 21) {
$year = (strlen($year) == 1) ? $cen . '0' . $year : $cen . $year;
}
elseif ($year < 100) {
$year = $prevCen . $year;
}
```
This affects the import of Activity dates and presumably other places where a two-digit year input is selected.
Proposed behaviour
----------------------------------------
- Civi should translate 2-digit years into 4-digit years based on a rolling cutoff. For example, if the cutoff is the current date plus ten years, any two-digit input that would result in a date more than ten years in the future will be placed in the prior century instead.
- The cutoff could be configurable: X years in the future.
Comments
----------------------------------------
I guess configuration would go under civicrm/admin/setting/preferences/date (`CRM_Core_BAO_PreferencesDate`).
Optionally, the setting could be overridable within the import wizard itself.5.47.0https://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/3034Filename in content-disposition should have extension2022-04-04T14:27:07ZmasettoFilename in content-disposition should have extensionOverview
----------------------------------------
When I download the pdf of a mail merge contact activity, the filename in `content-disposition` is without extension.
Reproduction steps
----------------------------------------
1. Edit...Overview
----------------------------------------
When I download the pdf of a mail merge contact activity, the filename in `content-disposition` is without extension.
Reproduction steps
----------------------------------------
1. Edit a contact and go to activities
1. Click 'edit' on a Mail merge activity
1. Click preview or download.
Current behaviour
----------------------------------------
This is the header of response:
```
content-type: application/pdf
content-disposition: attachment; filename="filename_without_extension"
```
Expected behaviour
----------------------------------------
```
content-type: application/pdf
content-disposition: attachment; filename="filename_without_extension.pdf"
```
Environment information
----------------------------------------
* __CiviCRM:__ 5.45.1
* __PHP:__ 7.4
* __CMS:__ Wordpress 5.8.3
* __Database:__ MySQL 8
Comments
----------------------------------------
I think that at row 266 of `CRM/Contact/Form/Task/PDFTrait.php` we have to add extension to filename:
```
if ($type === 'pdf') {
CRM_Utils_PDF_Utils::html2pdf($html, $fileName . '.pdf', FALSE, $formValues);
}
```
current:
```
if ($type === 'pdf') {
CRM_Utils_PDF_Utils::html2pdf($html, $fileName, FALSE, $formValues);
}
```5.49.0https://lab.civicrm.org/dev/core/-/issues/3029TypeError when trying to replace tokens for custom fields that don't exist2022-01-27T01:14:13ZjensschuppeTypeError when trying to replace tokens for custom fields that don't existOverview
----------------------------------------
A `TypeError: Return value of CRM_Core_EntityTokens::getCustomFieldName() must be of the type string, none returned` is being thrown when trying to replace `custom_123` tokens for custom ...Overview
----------------------------------------
A `TypeError: Return value of CRM_Core_EntityTokens::getCustomFieldName() must be of the type string, none returned` is being thrown when trying to replace `custom_123` tokens for custom fields that don't exist.
Reproduction steps
----------------------------------------
1. For a contact, choose the action *Print/Merge Document*
1. In the message body field, enter a token for a custom field, that does not exist, e.g. `{contact.custom_99999}`
1. Hit *Preview* or *Download Document*
This is just an example, the error occurs everywhere a non-existent custom field token is being fed into the token system.
Current behaviour
----------------------------------------
PHP fatals with a 500 with an error message `TypeError: Return value of CRM_Core_EntityTokens::getCustomFieldName() must be of the type string, none returned in CRM_Core_EntityTokens->getCustomFieldName() (Line 511 of /path/to/civicrm/core/CRM/Core/EntityTokens.php).`
Expected behaviour
----------------------------------------
Invalid tokens should just be ignored or replaced with an empty string (not sure what the previous behavior was).
Comments
----------------------------------------
`\CRM_Core_EntityTokens::getCustomFieldName()` should not be type hinted to `string` for its return value when it can't keep that promise.
If the token systems really requires validating token names before calling this code path, this should be clearly documented and done within Core.5.46.0https://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.2https://lab.civicrm.org/dev/core/-/issues/3026Drupal Full-Text Search block session time out error2022-01-12T14:24:48ZlcdwebDrupal Full-Text Search block session time out errorA recent upgrade migrated all custom searches to an extension framework. In so doing, it looks like it broke the Drupal full-text search block. Enabling that block and running a search consistently triggers a session timeout error.A recent upgrade migrated all custom searches to an extension framework. In so doing, it looks like it broke the Drupal full-text search block. Enabling that block and running a search consistently triggers a session timeout error.5.46.0https://lab.civicrm.org/dev/drupal/-/issues/174Change message so it doesn't say Drupal8 on Drupal9 site2022-09-20T22:27:16ZJoeMurrayChange message so it doesn't say Drupal8 on Drupal9 siteThere was a message today on page for Synchronize Users to Contacts (/civicrm/admin/synchuser:
Synchronize Drupal8 Users
This was on a Drupal9 site, and the client got concerned about what they were running.
Please adjust the message s...There was a message today on page for Synchronize Users to Contacts (/civicrm/admin/synchuser:
Synchronize Drupal8 Users
This was on a Drupal9 site, and the client got concerned about what they were running.
Please adjust the message so that it either refers to just Drupal or ideally emits the correct major version of Drupal, eg Drupal9, Drupal10, etc.5.55.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3025Can't create a relationship with CiviMember disabled2022-01-11T20:38:01ZJonGoldCan't create a relationship with CiviMember disabledWhen creating a relationship via the "Add Relationship" UI, Civi crashes if CiviMember is disabled.
### Steps to Replicate
* Disable CiviMember.
* Add a relationship by pressing the **Add Relationship** button on the *Relationships* tab...When creating a relationship via the "Add Relationship" UI, Civi crashes if CiviMember is disabled.
### Steps to Replicate
* Disable CiviMember.
* Add a relationship by pressing the **Add Relationship** button on the *Relationships* tab.
### Expected Result
Relationship added, no error.
### Actual Result
Relationship is added, but with error `Key id not found in api results` (in Civi 5.45) or `MembershipType API is not available because CiviMember component is disabled` (Civi 5.47).
This is a regression introduced in 5.43 by [PR 21803](https://github.com/civicrm/civicrm-core/pull/21803). Post-save, Civi tries to calculate the membership/contribution counts to display on the contact tab. `CRM_Contact_BAO_Contact::getCountComponent()` attempts to look up the count using API4, but without regard for whether that entity is present.5.45.1JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3022Custom contribution field of type money crashes if it has a blank value when ...2022-01-10T00:08:07ZDaveDCustom contribution field of type money crashes if it has a blank value when viewing contribution1. Create a custom field for contributions of type money and single-line input (text).
2. View any existing contribution where you haven't updated it yet.
3. Crash.
This is basically the same as https://github.com/civicrm/civicrm-core/p...1. Create a custom field for contributions of type money and single-line input (text).
2. View any existing contribution where you haven't updated it yet.
3. Crash.
This is basically the same as https://github.com/civicrm/civicrm-core/pull/22427, but I'll note that CRM_Core_BAO_CustomField::displayValue() also ends up with a similar error with such a field defined but by directly calling money formatting from php not via smarty, just I don't have a way at the moment to reproduce on master, possibly because of the recent token changes, but is still a theoretical issue.
```
Brick\Math\Exception\NumberFormatException: "The given value "" does not represent a valid number."
0 .../civicrm/vendor/brick/math/src/BigNumber.php(119): Brick\Math\BigNumber::Brick\Math\{closure}()
1 .../civicrm/vendor/brick/money/src/Money.php(196): Brick\Math\BigNumber::of("")
2 .../civicrm/Civi/Core/Format.php(43): Brick\Money\Money::of("", Object(Brick\Money\Currency), Object(Brick\Money\Context\DefaultContext), 5)
3 .../civicrm/CRM/Core/Smarty/plugins/modifier.crmMoney.php(32): Civi\Core\Format->money("", "USD")
4 .../templates_c/en_US/%%FD/FD4/FD481315%%CustomDataView.tpl.php(79): smarty_modifier_crmMoney("")
5 .../civicrm/packages/Smarty/Smarty.class.php(1914): include("/home/jenkins/bknix-dfl/build/core-22401-55dqr/web/sites/default/files/civicr...")
6 .../templates_c/en_US/%%82/82F/82F38BFE%%ContributionView.tpl.php(375): Smarty->_smarty_include((Array:2))
7 .../civicrm/packages/Smarty/Smarty.class.php(1914): include("/home/jenkins/bknix-dfl/build/core-22401-55dqr/web/sites/default/files/civicr...")
8 .../templates_c/en_US/%%5E/5EA/5EA30681%%Tab.tpl.php(12): Smarty->_smarty_include((Array:2))
9 .../civicrm/packages/Smarty/Smarty.class.php(1914): include("/home/jenkins/bknix-dfl/build/core-22401-55dqr/web/sites/default/files/civicr...")
10 .../templates_c/en_US/%%0C/0CB/0CBEC124%%default.tpl.php(19): Smarty->_smarty_include((Array:2))
11 .../civicrm/packages/Smarty/Smarty.class.php(1914): include("/home/jenkins/bknix-dfl/build/core-22401-55dqr/web/sites/default/files/civicr...")
12 .../templates_c/en_US/%%F7/F77/F77C7890%%CMSPrint.tpl.php(51): Smarty->_smarty_include((Array:2))
13 .../civicrm/packages/Smarty/Smarty.class.php(1914): include("/home/jenkins/bknix-dfl/build/core-22401-55dqr/web/sites/default/files/civicr...")
14 .../templates_c/en_US/%%06/069/0693F89E%%drupal.tpl.php(6): Smarty->_smarty_include((Array:2))
15 .../civicrm/packages/Smarty/Smarty.class.php(1273): include("/home/jenkins/bknix-dfl/build/core-22401-55dqr/web/sites/default/files/civicr...")
16 .../civicrm/CRM/Core/Smarty.php(194): Smarty->fetch("CRM/common/drupal.tpl", NULL, NULL, FALSE)
17 .../civicrm/CRM/Core/Page.php(244): CRM_Core_Smarty->fetch("CRM/common/drupal.tpl")
18 .../civicrm/CRM/Contribute/Page/Tab.php(463): CRM_Core_Page->run()
19 .../civicrm/CRM/Core/Invoke.php(319): CRM_Contribute_Page_Tab->run((Array:4), NULL)
20 .../civicrm/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem((Array:13))
21 .../civicrm/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:4))
22 .../civicrm/drupal/civicrm.module(471): CRM_Core_Invoke::invoke((Array:4))
23 .../web/includes/menu.inc(527): civicrm_invoke("contact", "view", "contribution")
24 .../web/index.php(21): menu_execute_active_handler()
25 {main}
```5.46.0https://lab.civicrm.org/dev/core/-/issues/3018Cannot configure repeat events in CiviCRM2022-01-06T00:13:17ZChabadrichmondCannot configure repeat events in CiviCRMWhen trying to create an event and add repeating it shows a critical wordpress error page.
If I go into an existing event and try to go the repeat tab it gives me the network error.
This seems somewhat recent (maybe since V 5.3x... but I...When trying to create an event and add repeating it shows a critical wordpress error page.
If I go into an existing event and try to go the repeat tab it gives me the network error.
This seems somewhat recent (maybe since V 5.3x... but I had the issue on 5.42 and 5.44)
I could not replicate on CiviCRM demo site but was able to replicate on both demos which show on the CiviCRM website [here](https://civicrm.org/demo?field_language_value=All&field_cms_demo_value=wordpress)
Attaching a VIDEO to show what's happening.
![Screen_Recording_2022-01-04_at_10.20.36_PM](/uploads/745accbe5266fd731c9799234585e6b6/Screen_Recording_2022-01-04_at_10.20.36_PM.mov)5.45.0https://lab.civicrm.org/dev/wordpress/-/issues/117Cannot configure repeat events in CiviCRM2022-01-05T23:33:29ZChabadrichmondCannot configure repeat events in CiviCRMWhen trying to create an event and add repeating it shows a critical wordpress error page.
If I go into an existing event and try to go the repeat tab it gives me the network error.
This seems somewhat recent (maybe since V 5.3x... but I...When trying to create an event and add repeating it shows a critical wordpress error page.
If I go into an existing event and try to go the repeat tab it gives me the network error.
This seems somewhat recent (maybe since V 5.3x... but I had the issue on 5.42 and 5.44)
I could not replicate on CiviCRM demo site but was able to replicate on both demos which show on the CiviCRM website [here](https://civicrm.org/demo?field_language_value=All&field_cms_demo_value=wordpress)
Attaching a VIDEO to show what's happening.
![Screen_Recording_2022-01-04_at_10.20.36_PM](/uploads/926a4eda5e1bfa42feee46791256d2e2/Screen_Recording_2022-01-04_at_10.20.36_PM.mov)5.45.0https://lab.civicrm.org/dev/core/-/issues/3003Preserve previous tab when navigating to and from contact page2022-05-05T14:57:50ZBradley TaylorPreserve previous tab when navigating to and from contact pageThe contact page is structured around a series of tabs: Summary, Contributions, Membership etc. There are often times when you click through from a contact to a related entity (say a related contact from the relationships tab). It would ...The contact page is structured around a series of tabs: Summary, Contributions, Membership etc. There are often times when you click through from a contact to a related entity (say a related contact from the relationships tab). It would be nice if using the browser's back button returned you to the tab you were previously looking at rather than returning to the summary tab each time.
This is a bigger issue for users with the "Enable Popup Forms" option unticked, but all users are affected by this.
This shouldn't be a massive technical change, but I do think this is one of those little annoyances, where fixing should improve the overall usability of the CRM for those who need to use it on a daily basis.
**Implementation details**
It is already possible to link to a specific tab with the `selectedChild` query parameter. I propose that whenever the active tab is changed, the [replaceState](https://developer.mozilla.org/en-US/docs/Web/API/History/replaceState) API is used to amend the `selectedChild` parameter in the URL.5.49.0https://lab.civicrm.org/dev/core/-/issues/3002Add activity created date in Form Builder2022-01-07T12:09:27ZkristinecAdd activity created date in Form BuilderWhen adding a Search Form in Form Builder, the available Activity Fields has "Activity Date" which is separate from the created date. It would be great to include "Activity Created Date" (or "Created Date"). SearchKit already has this fi...When adding a Search Form in Form Builder, the available Activity Fields has "Activity Date" which is separate from the created date. It would be great to include "Activity Created Date" (or "Created Date"). SearchKit already has this field available in its search.
To reproduce:
1. Create an activity with the activity date in the past (activity date occurred on 12/15/2021). CiviCRM records the activity created date as today (12/24/2021).
2. Create a "New Search" in Search Kit, showing "Cases" with "Case Activities". Search Kit has the options for two types of activity dates here.
- `Case_CaseActivity_Activity_01.activity_date_time`: The date when the activity occurred.
- `Case_CaseActivity_Activity_01.created_date`: The date when the activity was created.
3. In Afform, only "Activity Date" shows up which references `activity_date_time`, but there's no option to add `created_date` (see image below). Therefore, afform only can filter by activity date and not the created activity date.
![SharedScreenshot](/uploads/28832f8d7f626b2c43f7c102cb954dbc/SharedScreenshot.jpg).5.47.0https://lab.civicrm.org/dev/drupal/-/issues/172Deprecated function drupal_get_installed_schema_version() in 9.3, but with a ...2022-01-02T15:47:07ZDaveDDeprecated function drupal_get_installed_schema_version() in 9.3, but with a twistdrupal_get_installed_schema_version() is deprecated in drupal:9.3.0 and is removed from drupal:10.0.0. Use \Drupal\Core\Update\UpdateHookRegistry::getInstalledVersion() or \Drupal\Core\Update\UpdateHookRegistry::getAllInstalledVersions()...drupal_get_installed_schema_version() is deprecated in drupal:9.3.0 and is removed from drupal:10.0.0. Use \Drupal\Core\Update\UpdateHookRegistry::getInstalledVersion() or \Drupal\Core\Update\UpdateHookRegistry::getAllInstalledVersions() instead. See https://www.drupal.org/node/2444417
This is in vendor\civicrm\civicrm-core\CRM/Utils/System/Drupal8.php:
```
public function getModules() {
$modules = [];
$module_data = \Drupal::service('extension.list.module')->reset()->getList();
foreach ($module_data as $module_name => $extension) {
if (!isset($extension->info['hidden']) && $extension->origin != 'core') {
$extension->schema_version = drupal_get_installed_schema_version($module_name);
$modules[] = new CRM_Core_Module('drupal.' . $module_name, ($extension->status == 1));
}
}
return $modules;
}
```
The reason I haven't just put up a simple replacement PR is because if you look at the above function you'll notice schema_version is never used. If you look at the docblock in Base.php it says "List modules installed in the CMS, _including enabled and disabled ones_." Looking at the drupal 7 version (in DrupalBase.php), it does this:
`'SELECT name, status FROM {system} WHERE type = \'module\' AND schema_version <> -1'`
which means only the modules that are installed (but possibly disabled - that's what status is). Now in drupal 8 there is no concept of disabled, it's either installed or uninstalled, but the drupal 8 code is including all of them. In drupal 8 $extension->status means installed or uninstalled.
So two options are:
1. Try to match the drupal 7 implementation/docblock, which means excluding it if $extension->status is 0, and always passing 1 as the second parameter to CRM_Core_Module(), because disabled doesn't mean anything in drupal 8.
2. Leave it the way it is and just remove the unused line about schema_version.
Trying to track down where this gets used, it seems it's mostly in ManagedEntities, which I usually stay away from, and I'm not even sure why ManagedEntities would be dealing with drupal modules other than civicrm itself.
So I'm tempted to stop thinking about it and do item 2.5.46.0https://lab.civicrm.org/dev/core/-/issues/3000Can't save a shared address twice when you have custom address fields2021-12-25T19:34:53ZJonGoldCan't save a shared address twice when you have custom address fieldsThis is a regression from https://github.com/civicrm/civicrm-core/pull/21313, which is in Civi 5.42+.
### Steps to replicate
* Create an address custom field (it may have to be a certain type; it happens with alphanumeric select-autocom...This is a regression from https://github.com/civicrm/civicrm-core/pull/21313, which is in Civi 5.42+.
### Steps to replicate
* Create an address custom field (it may have to be a certain type; it happens with alphanumeric select-autocomplete for sure).
* Create or re-save an address on a contact (to create its custom field record).
* On a second contact, share the address from the first contact and save.
* Edit the address on the second contact and save.
### Expected result
Saves successfully.
### Actual result
`"DB Error: already exists"`
### Comments
The `entity_id` on a custom value field must be unique, but the PR mentioned above forces an `INSERT` when copying the custom fields of the original address.5.45.0