Development issueshttps://lab.civicrm.org/groups/dev/-/issues2020-08-23T21:47:08Zhttps://lab.civicrm.org/dev/core/-/issues/1950Profile settings - Add new contacts to a Group? is misleading2020-08-23T21:47:08ZlarsssandergreenProfile settings - Add new contacts to a Group? is misleadingIn settings for profiles, there is an option to "Add new contacts to a Group?" with a help text "Select a group if you are using this profile for adding new contacts, AND you want the new contacts to be automatically assigned to a group....In settings for profiles, there is an option to "Add new contacts to a Group?" with a help text "Select a group if you are using this profile for adding new contacts, AND you want the new contacts to be automatically assigned to a group."
However, on profile submission, any contact is added to the group, not just new contacts. I think that this is the desired behaviour, but the text is misleading.
I would suggest "Add contacts to a group?" and "Select a group if you want contacts to be automatically added to that group when the profile is submitted." or something along those lines.5.30.0https://lab.civicrm.org/dev/drupal/-/issues/133Breadcrumb error on CiviCRM admin pages (Drupal 8)2023-12-13T17:46:26ZW01FBreadcrumb error on CiviCRM admin pages (Drupal 8)Getting the following error on several CiviCRM admin pages, including /civicrm/admin
```
Warning: Invalid argument supplied for foreach() in CRM_Utils_System_Drupal8->appendBreadCrumb() (line 190 of /home/customer/www/youpickfarms.org/v...Getting the following error on several CiviCRM admin pages, including /civicrm/admin
```
Warning: Invalid argument supplied for foreach() in CRM_Utils_System_Drupal8->appendBreadCrumb() (line 190 of /home/customer/www/youpickfarms.org/vendor/civicrm/civicrm-core/CRM/Utils/System/Drupal8.php).
CRM_Utils_System_Drupal8->appendBreadCrumb('Administer CiviCRM', '/civicrm/admin?reset=1') (Line: 60)
CRM_Utils_System::__callStatic('appendBreadCrumb', Array) (Line: 76)
CRM_Contact_Form_Domain->preProcess() (Line: 599)
CRM_Core_Form->buildForm() (Line: 120)
CRM_Core_StateMachine->perform(Object, 'next', 'Next') (Line: 45)
CRM_Core_QuickForm_Action_Next->perform(Object, 'next') (Line: 203)
HTML_QuickForm_Controller->handle(Object, 'next') (Line: 103)
HTML_QuickForm_Page->handle('next') (Line: 347)
CRM_Core_Controller->run() (Line: 98)
CRM_Utils_Wrapper->run('CRM_Contact_Form_Domain', 'Organization Address and Contact Info', Array) (Line: 285)
CRM_Core_Invoke::runItem(Array) (Line: 68)
CRM_Core_Invoke::_invoke(Array) (Line: 36)
CRM_Core_Invoke::invoke(Array) (Line: 88)
Drupal\civicrm\Civicrm->invoke(Array) (Line: 80)
Drupal\civicrm\Controller\CivicrmController->main(Array, '')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
```5.70.0https://lab.civicrm.org/dev/core/-/issues/1949Payment method should reflect the last transaction on the contribution2020-09-09T05:18:38ZyashodhaPayment method should reflect the last transaction on the contributionPayment method should reflect the last transaction on the contribution.
When the payment method is updated on the contribution, the system creates a new payment record with the new payment method attached to the contribution.
When the ...Payment method should reflect the last transaction on the contribution.
When the payment method is updated on the contribution, the system creates a new payment record with the new payment method attached to the contribution.
When the contribution is saved, we must update the payment method field on the contribution with the payment method on the most recent payment record attached to that contribution.
I know we are planning on dropping the payment method on contribution and just have it for individual transaction but till the time it does exist it should have the correct value.
Create a contribution which is pay later by check
![pay_later](/uploads/73fda0162672541c39db8f212f945f59/pay_later.png)
Record payment complete with method Cash
![new_payment](/uploads/5c721d3cf7f0d40daf02373a7ce28916/new_payment.png)
It doesn't reflect
![payment_view](/uploads/72697eeae2a99dee75dcc519ece65b97/payment_view.png)5.31.0https://lab.civicrm.org/dev/core/-/issues/1947create config setting to control if roles are disabled when a case is closed2021-08-18T20:34:38Zlcdwebcreate config setting to control if roles are disabled when a case is closedCurrently, when a case is closed each of the relationships (roles) attached to the case are updated with an end date, thus disabling them. This results in the Case Roles listing being empty when you view/manage the case. I understand the...Currently, when a case is closed each of the relationships (roles) attached to the case are updated with an end date, thus disabling them. This results in the Case Roles listing being empty when you view/manage the case. I understand the thought process behind this, but believe it assumes too much. I've had multiple clients be confused when they were not able to view a closed case and see who had been assigned various roles.
I propose we add a config setting to the CiviCase component to condition this behavior. We can default it to the current behavior to avoid any disruption with existing users.
Looking for concept approval and then I'll file a PR.5.40.0lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/1946Batch Update via Profile does not supply data for editing when custom fields ...2023-04-19T05:03:26ZmarshBatch Update via Profile does not supply data for editing when custom fields created after participant added to eventOverview
----------------------------------------
When trying to "update via Profile" on event participants, some of the custom fields for specific roles do not pull through to the form for editing.
Reproduction steps
------------------...Overview
----------------------------------------
When trying to "update via Profile" on event participants, some of the custom fields for specific roles do not pull through to the form for editing.
Reproduction steps
----------------------------------------
2. add a participant to an event
1. create custom fields for participants
- [add fields page](https://dmaster.demo.civicrm.org/civicrm/admin/custom/group?reset=1)
- name: test participant
- used for: Participants (Event Name) > Select three (not sure if 'All' will reproduce)
- Add field
- simple radio field will do
2. Administer profiles > reserved profile > "Participant Status" profile > fields
- add fields
- add the 'test participant' radio button fields created above
1. do participant search for participant created at step 1.
1. select the created participant
1. actions > update via profile
1. select profile Participant Status
Current behaviour
----------------------------------------
notice the radio field created column is there, but does not contain any data or data structure for the participant
Expected behaviour
----------------------------------------
All participants have the custom fields pull through
Environment information
----------------------------------------
* CiviCRM 5.24.4
* __PHP:__ 7.3
* __CMS: Drupal-7.72
* __Database:__ _MySQL 5.7.7
* __Web Server: Nginxhttps://lab.civicrm.org/dev/core/-/issues/1945[Regression] Users without permission can edit recurring contributions2020-08-20T10:27:28Zjensschuppe[Regression] Users without permission can edit recurring contributionsOverview
----------------------------------------
Users _without_ the permission "edit contributions" can edit _recurring_ contributions of any contact (might be mitigated by specific scenarios, see below).
Reproduction steps
----------...Overview
----------------------------------------
Users _without_ the permission "edit contributions" can edit _recurring_ contributions of any contact (might be mitigated by specific scenarios, see below).
Reproduction steps
----------------------------------------
1. Create a user with a role that has only the following permissions:
* CiviCRM: access CiviCRM backend and API
* CiviContribute (Contributions): access CiviContribute
but explicitly _not_ the "CiviContribute (Contributions): Edit Contributions" permission
2. _Configure an ACL for them to view contacts in a specific group and their contributions._ - not sure this is necessary
3. With that user logged in, go to any visible contact's Contributions tab and the Recurring Contributions sub tab
Current behaviour
----------------------------------------
The user is presented links to edit recurring contributions and clicking it also shows the form. Saving the form is also allowed.
Expected behaviour
----------------------------------------
Editing should not be allowed, i.e. there should be no _Edit_ link at all and opening the forms should result in a 404.
Environment information
----------------------------------------
* __CiviCRM:__ 5.24.5
* __CMS:__ Drupal 7.30
Comments
----------------------------------------
This seems to have been introduced as a regression with https://github.com/civicrm/civicrm-core/pull/13237 which originated in #571.
The compared contact ID is retrieved using `$this->getContactID()` which calls `CRM_Core_Form::setContactID()` which states the following in its docblock:
```php
/**
* Get contact if for a form object. Prioritise
* - cid in URL if 0 (on behalf on someoneelse)
* (@todo consider setting a variable if onbehalf for clarity of downstream 'if's
* - logged in user id if it matches the one in the cid in the URL
* - contact id validated from a checksum from a checksum
* - cid from the url if the caller has ACL permission to view
* - fallback is logged in user (or ? NULL if no logged in user) (@todo wouldn't 0 be more intuitive?)
*
* @return NULL|int
*/
```
The relevant part seems to be: __`cid from the url if the caller has ACL permission to view`__, but I couldn't verify yet, since it's a production system this is appearing on.
Background: The scenario is a _regional department_ user (being restricted to viewing contacts of a specific regional group only - which is done using ACLs), who should be allowed to view contributions, but not edit them at all.
Since the aforementioned issue tried to bypass access checks for editing one's own recurring contributions, I'm not sure this is a correct assumption at all. There should be a separate permission for controlling whether editing own recurring contributions is allowed.5.28.1https://lab.civicrm.org/dev/core/-/issues/1944Add new columns to mailing summary report2020-08-12T18:22:51ZyashodhaAdd new columns to mailing summary reportAdd new columns to mailing summary report
- Sender name
- Sender emailAdd new columns to mailing summary report
- Sender name
- Sender email5.30.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/1943Fix : Enable Drupal Watchdog Logging for Drupal 82020-08-10T21:07:07ZsunilFix : Enable Drupal Watchdog Logging for Drupal 8Overview
----------------------------------------
Currently We have Setting to log CiviCRM Error Log to Drupal Access Log, but functionality in code is not present.
Current behaviour
----------------------------------------
Code not pre...Overview
----------------------------------------
Currently We have Setting to log CiviCRM Error Log to Drupal Access Log, but functionality in code is not present.
Current behaviour
----------------------------------------
Code not present of Functionality present at /civicrm/admin/setting/debug?reset=1, `Enable Drupal Watchdog Logging`
Proposed behaviour
----------------------------------------
After changes, it will start logging into Drupal log if `Enable Drupal Watchdog Logging` is enabled.
https://github.com/civicrm/civicrm-core/pull/181155.30.0https://lab.civicrm.org/dev/core/-/issues/1942Multiple Memberships Status Not updated when payment status changed from pend...2020-10-09T21:08:23ZsunilMultiple Memberships Status Not updated when payment status changed from pending to CompletedOverview
----------------------------------------
Pending Membership (multiple) created through Webform not updated in CiviCRM when Payment Status changed from Pending (paylater) to Completed.
Reproduction steps
------------------------...Overview
----------------------------------------
Pending Membership (multiple) created through Webform not updated in CiviCRM when Payment Status changed from Pending (paylater) to Completed.
Reproduction steps
----------------------------------------
1. Create Webform in Drupal 7/8, Enable multiple contacts for Membership Signup/renew.
2. Each contact can choose different/same membership type (-- User Select -- option for Membership Type)
3. When form is submitted. Contribution Record created and Multiple membership created and these memberships linked to same contribution record in **civicrm_membership_payment** table
4. In this scenario, All contact have chosen Same Membership Types
Current behaviour
----------------------------------------
at backend, when Contribution/payment record status changed from Pending (Pay_later) to Completed, only last membership record from `civicrm_membership_payment` against contribution record get updated to New/Current, other membership status remain Pending.
Note : This is no Inherited Membership, Each contact get Direct Membership for Same Contribution Record.
e.g. IF 3 person signup for General Membership. then in `civicrm_membership_payment` table we have 3 entries of membership record with common contribution id.
Expected behaviour
----------------------------------------
All Pending Membership Status should change to New/Current.
https://github.com/civicrm/civicrm-core/pull/181135.31.1https://lab.civicrm.org/dev/core/-/issues/1941Required Fields in Onbehalf of an Organization look not Required after donor ...2023-04-16T05:03:21ZKarinGRequired Fields in Onbehalf of an Organization look not Required after donor uses the Go Back button on Confirm page [Regression]When reviewing/testing https://github.com/civicrm/civicrm-core/pull/18102 - I noticed a small ad-hoc regression. Seamus asked me to log a new lab ticket.
-> none of the I'm contributing on behalf of an organization look required if a d...When reviewing/testing https://github.com/civicrm/civicrm-core/pull/18102 - I noticed a small ad-hoc regression. Seamus asked me to log a new lab ticket.
-> none of the I'm contributing on behalf of an organization look required if a donor changes their mind and hits the go back button on the confirm page. This was definitively not the case before the jquery PRs on Contribution pages:
**Reproducing this on dmaster:**
https://dmaster.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=4
![image](https://user-images.githubusercontent.com/5340555/89713968-9ba73f00-d958-11ea-9d8f-f1e6017da783.png)
Hitting Review Contribution -> CiviCRM does remember that these were required after all - except for State/Province ?!
![image](https://user-images.githubusercontent.com/5340555/89714007-d01afb00-d958-11ea-8af2-cd36658e4723.png)https://lab.civicrm.org/dev/core/-/issues/1940Remove language column from civicrm_ufmatch table2023-04-13T05:03:16Zmattwiremjw@mjwconsult.co.ukRemove language column from civicrm_ufmatch tableFollow up to #1891 we should actually remove the column after a few versions (change was merged in 5.29 so 5.32?).Follow up to #1891 we should actually remove the column after a few versions (change was merged in 5.29 so 5.32?).https://lab.civicrm.org/dev/financial/-/issues/140Order API - Participant Status2020-12-09T15:25:34Zmattwiremjw@mjwconsult.co.ukOrder API - Participant StatusCurrently Order API does not allow setting participant or membership status. It is hardcoded to `Pending from incomplete transaction` for participant and `Pending` for Membership.
This is a problem for event cart which will use Order A...Currently Order API does not allow setting participant or membership status. It is hardcoded to `Pending from incomplete transaction` for participant and `Pending` for Membership.
This is a problem for event cart which will use Order API per https://github.com/civicrm/civicrm-core/pull/17886 and needs to set `Pending from cart` as status.
All other parameters for participant/membership can be passed through and will be set to whatever you set them to (or defaults if not set).
My view is that we don't need to put any restrictions in place on what the status can be set to.
We are not talking about contribution status here - the two are independent. Any flow that "completes" a contribution will also complete any linked participants/memberships if they are not already "completed" but we hope to separate this logic more in the future as it doesn't work for everyone.
Over the last couple of years we've been progressively removing more and more restrictions within core about what can/can't be done (with memberships mostly) but also participants because any restriction in core restricts what can be done via extension/third-party integrations.
My proposal here is to remove the restriction on participant status when created/updated using Order API per: https://github.com/civicrm/civicrm-core/pull/18096 Note that you *can* pass a participant/membership ID in here but it will still get overwritten with the hardcoded status (so eg. a "completed" membership would get set to Pending and a "On waitlist" participant would get set to "pending from incomplete transaction").
I don't think we are going to run into the same issues that we do with contributions when changing statuses because the participant/membership entities don't have a whole set of financial accounting behind them.
Thoughts please @eileen @artfulrobot @KarinG (webform_civicrm will need converting to Order API at some point) @wmortada @bgm
Also note that, according to the docs here https://docs.civicrm.org/dev/en/latest/financial/orderAPI/#sample-ordercreate-for-single-event-registration until 5.20 the Order API created participants as `Registered` by default.5.34.0https://lab.civicrm.org/dev/core/-/issues/1939$crazy_null assignment in DB_DataObject has a typo that makes it crazier2020-08-10T13:39:22ZDaveD$crazy_null assignment in DB_DataObject has a typo that makes it crazierhttps://github.com/civicrm/civicrm-packages/blob/02e7eaa0a2aa072a032afff8179f6c26c1ad87b3/DB/DataObject.php#L4936
`strtolower($options['disable_null_strings'] === 'full')`
It should be
`strtolower($options['disable_null_strings']) ===...https://github.com/civicrm/civicrm-packages/blob/02e7eaa0a2aa072a032afff8179f6c26c1ad87b3/DB/DataObject.php#L4936
`strtolower($options['disable_null_strings'] === 'full')`
It should be
`strtolower($options['disable_null_strings']) === 'full'`
Is DB_DataObject still being updated upstream? I can't find a recent repo. Although I don't think this bug ever comes up in practice how it's used in civi.https://lab.civicrm.org/dev/core/-/issues/1938Something in here is locking composer.lock to use phpseclib 1.0 which is inco...2021-01-03T21:14:07ZHeneryHSomething in here is locking composer.lock to use phpseclib 1.0 which is incompatable with OpenSocialwhich is locked at phpseclib
"phpseclib/phpseclib": "~0.3.10||~2.0"which is locked at phpseclib
"phpseclib/phpseclib": "~0.3.10||~2.0"5.33.0https://lab.civicrm.org/dev/drupal/-/issues/132Drupal 8 Profile menu items2020-10-04T04:46:49ZAlanDixonDrupal 8 Profile menu itemsWhen using the CiviCRM profiles for "View/Edit Drupal User Account", the tab generated on the user page doesn't use the 'public title'.
Fix on line 40 of
src/Plugin/Derivative/LocalTasks.php
change uf_group['title'] to uf_group['fronten...When using the CiviCRM profiles for "View/Edit Drupal User Account", the tab generated on the user page doesn't use the 'public title'.
Fix on line 40 of
src/Plugin/Derivative/LocalTasks.php
change uf_group['title'] to uf_group['frontend_title']5.31.0https://lab.civicrm.org/dev/core/-/issues/1937Upgrading a site that still has "mysql" in the dsn string breaks in latest ma...2020-08-28T01:22:17ZDaveDUpgrading a site that still has "mysql" in the dsn string breaks in latest masterI think it's partly because of https://github.com/civicrm/civicrm-packages/pull/302 but more because I remember once seeing something somewhere that civi silently converted mysql to mysqli for you, and maybe that has also been removed so...I think it's partly because of https://github.com/civicrm/civicrm-packages/pull/302 but more because I remember once seeing something somewhere that civi silently converted mysql to mysqli for you, and maybe that has also been removed somewhere. While reviewing it maybe I missed it.
The fix is easy, just update your DSN in civicrm.settings.php to explicitly say "mysqli".
The technical issue is that without that silent conversion, it ends up trying to load php-mysql. It's just confusing at first because the error is `extension not found`, which makes you think "Civi Extension", but it means php extension.
Going to label it regression, but it's not the usual type of regression and it just started yesterday.5.30.0https://lab.civicrm.org/dev/core/-/issues/3385Event cart hidden/enabled in buildkit 5.29 RC2022-04-22T16:22:30ZAndie HuntEvent cart hidden/enabled in buildkit 5.29 RCWhen viewing an event info page, there's a "Add to Cart" button. It looks like the eventcart extension is enabled (looking via the API) but it is not visible through the UI.
I don't know if this is for buildkit only or something that w...When viewing an event info page, there's a "Add to Cart" button. It looks like the eventcart extension is enabled (looking via the API) but it is not visible through the UI.
I don't know if this is for buildkit only or something that will take effect for everyone when they download the tarball, but it shouldn't be the default for buildkit to enable the event cart.5.29.0https://lab.civicrm.org/dev/core/-/issues/1936When Contribution Page has no labels (just amounts) -> the Review and Thank y...2020-08-20T00:52:10ZKarinGWhen Contribution Page has no labels (just amounts) -> the Review and Thank you and Receipt all show string - null in ESR 5.27.4 AND dmaster [Regression]
Upgrading from 5.21.3 (previous ESR) to 5.27.4 (current ESR)
**To reproduce:**
Create a Contribution page -> Amounts section: fill in Amounts without Labels -> that produces:
![image](/uploads/e50c31e6542fe83feb249a8b321f4081/image.png...
Upgrading from 5.21.3 (previous ESR) to 5.27.4 (current ESR)
**To reproduce:**
Create a Contribution page -> Amounts section: fill in Amounts without Labels -> that produces:
![image](/uploads/e50c31e6542fe83feb249a8b321f4081/image.png)
Hit Review your Contribution button
**Before (5.21.3) -> all good**
![image](/uploads/45ca387ee6c46c0c14d2fea712ee657b/image.png)
**After (5.27.4) -> **
![image](/uploads/3300ecc0248bc39aff646a3d2916afb2/image.png)
the `null` is visible on Review, Thank you and Receipt.
**Quick solution:** hide label with CSS5.27.5https://lab.civicrm.org/dev/core/-/issues/1935Contribution Pages with On Behalf of Organization profile enabled stop workin...2020-08-08T16:09:03ZKarinGContribution Pages with On Behalf of Organization profile enabled stop working in ESR 5.27.4 [Regression]Upgrading from 5.21.3 (previous ESR) to 5.27.4 (current ESR).
**To reproduce:**
Enable the checkbox "Allow individuals to contribute and / or signup for membership on behalf of an organization" in the Contribution Page settings:
![image...Upgrading from 5.21.3 (previous ESR) to 5.27.4 (current ESR).
**To reproduce:**
Enable the checkbox "Allow individuals to contribute and / or signup for membership on behalf of an organization" in the Contribution Page settings:
![image](/uploads/6583b87856bc1ea6f1d22446686b7fb6/image.png)
**Problem:**
Visit Contribution Page + do NOT select to make an On Behalf of Contribution - pick your amounts, fill in card details and then click Review Contribution button at the bottom of the form:
Nothing happens; no error message. Just a non-responsive button.
**Digging in:** opening up the On Behalf of Contribution (after clicking Review Contribution button and nothng happening):
![image](/uploads/56551687401cae077e82ec64fdf837d6/image.png)
**Conclusion** -> Province/State is required even if this On Behalf of section is hidden.
**Quick Workaround:** in Localization -> set a default Province.
Solution @seamuslee -> see https://chat.civicrm.org/civicrm/pl/ehfq919d4jb6mk4yfmmy13mtgr
This fix was not backported to 5.27.x yethttps://lab.civicrm.org/dev/core/-/issues/1934Merging Contacts causes DB Error: Already Exists - conflict on setting table2020-09-03T20:15:33ZsadashivMerging Contacts causes DB Error: Already Exists - conflict on setting tableOverview
----------------------------------------
After upgrading my civicrm from 4.7.31 to 5.27.0 I found that merging contacts breaks. It no longer merges the contacts but shows DB Error: Already Exist as shown in the snapshot.
Repro...Overview
----------------------------------------
After upgrading my civicrm from 4.7.31 to 5.27.0 I found that merging contacts breaks. It no longer merges the contacts but shows DB Error: Already Exist as shown in the snapshot.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> New Individual**.
2. Entered **First Name** and **Last Name** and clicked **Save**.
3. Follow same steps and create one more contact which is a duplicate.
4. Check if both contacts have a navigation entry in the civicrm_setting table
5. Click on **Search -> Find Contacts**.
6. Search by the name and locate the duplicates
7. Click on merge contact
8. Click merge
9. Got an error "**DB error**".
Current behaviour
----------------------------------------
![Screen_Shot_2020-08-04_at_2.57.24_PM](/uploads/0939bd069e2b722d1f0f5275692a4a9c/Screen_Shot_2020-08-04_at_2.57.24_PM.png)
Backtrace from ConfigLogs
```
Aug 06 04:12:23 [error] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
) [code] => -5
[message] => DB Error: already exists
[mode] => 16
[debug_info] => UPDATE civicrm_setting SET contact_id = 244336 WHERE contact_id = 243714 [nativecode=1062 ** Duplicate entry '1-244336-navigation' for key 'index_domain_contact_name']
[type] => DB_Error
[user_info] => UPDATE civicrm_setting SET contact_id = 244336 WHERE contact_id = 243714 [nativecode=1062 ** Duplicate entry '1-244336-navigation' for key 'index_domain_contact_name']
[to_string] => [db_error: message="DB Error: already exists" code=-5 mode=callback callback=CRM_Core_Error::handle prefix="" info="UPDATE civicrm_setting SET contact_id = 244336 WHERE contact_id = 243714 [nativecode=1062 ** Duplicate entry '1-244336-navigation' for key 'index_domain_contact_name']"]
)
Aug 06 04:12:23 [debug] $backTrace = #0 /var/www/html/sites/all/modules/civicrm/CRM/Core/Error.php(205): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /var/www/html/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(922): CRM_Core_Error::handle(Object(DB_Error))
#2 /var/www/html/sites/all/modules/civicrm/packages/DB.php(998): PEAR_Error->__construct("DB Error: already exists", -5, 16, (Array:2), "UPDATE civicrm_setting SET contact_id = 244336 WHERE contact_id = 243714 [nat...")
#3 /var/www/html/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(575): DB_Error->__construct(-5, 16, (Array:2), "UPDATE civicrm_setting SET contact_id = 244336 WHERE contact_id = 243714 [nat...")
#4 /var/www/html/sites/all/modules/civicrm/vendor/pear/pear-core-minimal/src/PEAR.php(223): PEAR->_raiseError(Object(DB_mysqli), NULL, -5, 16, (Array:2), "UPDATE civicrm_setting SET contact_id = 244336 WHERE contact_id = 243714 [nat...", "DB_Error", TRUE)
#5 /var/www/html/sites/all/modules/civicrm/packages/DB/common.php(1925): PEAR->__call("raiseError", (Array:7))
#6 /var/www/html/sites/all/modules/civicrm/packages/DB/mysqli.php(935): DB_common->raiseError(-5, NULL, NULL, "UPDATE civicrm_setting SET contact_id = 244336 WHERE contact_id = 243714 [nat...", "1062 ** Duplicate entry '1-244336-navigation' for key 'index_domain_contact_n...")
#7 /var/www/html/sites/all/modules/civicrm/packages/DB/mysqli.php(405): DB_mysqli->mysqliRaiseError()
#8 /var/www/html/sites/all/modules/civicrm/packages/DB/common.php(1231): DB_mysqli->simpleQuery("UPDATE civicrm_setting SET contact_id = 244336 WHERE contact_id = 243714")
#9 /var/www/html/sites/all/modules/civicrm/packages/DB/DataObject.php(2696): DB_common->query("UPDATE civicrm_setting SET contact_id = 244336 WHERE contact_id = 243714")
#10 /var/www/html/sites/all/modules/civicrm/packages/DB/DataObject.php(1829): DB_DataObject->_query("UPDATE civicrm_setting SET contact_id = 244336 WHERE contact_id = 243714")
#11 /var/www/html/sites/all/modules/civicrm/CRM/Core/DAO.php(421): DB_DataObject->query("UPDATE civicrm_setting SET contact_id = 244336 WHERE contact_id = 243714")
#12 /var/www/html/sites/all/modules/civicrm/CRM/Core/DAO.php(1473): CRM_Core_DAO->query("UPDATE civicrm_setting SET contact_id = 244336 WHERE contact_id = 243714", TRUE)
#13 /var/www/html/sites/all/modules/civicrm/CRM/Dedupe/Merger.php(563): CRM_Core_DAO::executeQuery("UPDATE civicrm_setting SET contact_id = 244336 WHERE contact_id = 243714", (Array:0), TRUE, NULL, TRUE)
#14 /var/www/html/sites/all/modules/civicrm/CRM/Dedupe/Merger.php(1316): CRM_Dedupe_Merger::moveContactBelongings(Object(CRM_Dedupe_MergeHandler), (Array:12), (Array:0))
#15 /var/www/html/sites/all/modules/civicrm/CRM/Contact/Form/Merge.php(308): CRM_Dedupe_Merger::moveAllBelongings(244336, 243714, (Array:74))
#16 /var/www/html/sites/all/modules/civicrm/CRM/Core/Form.php(484): CRM_Contact_Form_Merge->postProcess()
#17 /var/www/html/sites/all/modules/civicrm/CRM/Core/StateMachine.php(144): CRM_Core_Form->mainProcess()
#18 /var/www/html/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Next.php(45): CRM_Core_StateMachine->perform(Object(CRM_Contact_Form_Merge), "next", "Next")
#19 /var/www/html/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Next->perform(Object(CRM_Contact_Form_Merge), "next")
#20 /var/www/html/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contact_Form_Merge), "next")
#21 /var/www/html/sites/all/modules/civicrm/CRM/Core/Controller.php(335): HTML_QuickForm_Page->handle("next")
#22 /var/www/html/sites/all/modules/civicrm/CRM/Utils/Wrapper.php(98): CRM_Core_Controller->run()
#23 /var/www/html/sites/all/modules/civicrm/CRM/Core/Invoke.php(285): CRM_Utils_Wrapper->run("CRM_Contact_Form_Merge", "Merge Contact", (Array:0))
#24 /var/www/html/sites/all/modules/civicrm/CRM/Core/Invoke.php(68): CRM_Core_Invoke::runItem((Array:13))
#25 /var/www/html/sites/all/modules/civicrm/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:3))
#26 /var/www/html/sites/all/modules/civicrm/drupal/civicrm.module(454): CRM_Core_Invoke::invoke((Array:3))
#27 /var/www/html/includes/menu.inc(527): civicrm_invoke("contact", "merge")
#28 /var/www/html/index.php(21): menu_execute_active_handler()
#29 {main}
```
Expected behaviour
----------------------------------------
Contact should be merged
Environment information
----------------------------------------
* __Browser:__ Tried on Firefox and chrome both
* __CiviCRM:__ Tried with 5.27.0
* __PHP:__ Tested with 7.2
* __CMS:__ Drupal 7.32
* __Database:__ MySQL 5.7.7
* __Web Server:__ Apache 2.4
Comments
----------------------------------------
Issue seems to be related to https://github.com/civicrm/civicrm-core/commit/bbc11d1920687d2e88c0fd24697032fd9a1b673f as reverting this change fixes this issue.5.28.1