Development issueshttps://lab.civicrm.org/groups/dev/-/issues2021-05-03T14:54:29Zhttps://lab.civicrm.org/dev/drupal/-/issues/160No dashboard displaying after installing and configuring CiviCRM with Backdrop2021-05-03T14:54:29ZcedeweyNo dashboard displaying after installing and configuring CiviCRM with BackdropI just installed CiviCRM on my Backdrop CMS site and walked through the configuration checklist.
When I click on the CiviCRM admin menu link I am taken to an essentially blank page. It seems like I must be missing a configuration or per...I just installed CiviCRM on my Backdrop CMS site and walked through the configuration checklist.
When I click on the CiviCRM admin menu link I am taken to an essentially blank page. It seems like I must be missing a configuration or permission setting, but I can't find what that might be. I am logged in as user 1 (administrator).
Also, when I hover over the CiviCRM menu item, no subpages appear in a dropdown as I have seen on other CiviCRM sites.
![civicrm-no-dashboard-no-menu](/uploads/ee163fe2b83d699e94b2185e85da0e5c/civicrm-no-dashboard-no-menu.png)https://lab.civicrm.org/dev/core/-/issues/1380No easy way to import signatures to petition2022-11-30T19:32:57ZCoreyBurgerNo easy way to import signatures to petitionSo there is no easy way to mass import signatures to a petition.
When looking at Petitions on Campaign > Dashboard > Petitions on the right side under the more option, there should be an option to "import signatures", which should be a...So there is no easy way to mass import signatures to a petition.
When looking at Petitions on Campaign > Dashboard > Petitions on the right side under the more option, there should be an option to "import signatures", which should be a custom version of the Import Activities.
As a workaround, I had to manually lookup how to import it, include the required numeric fields for source_record_id and activity_id.
CiviCRM 5.15 on Wordpresshttps://lab.civicrm.org/dev/core/-/issues/3909No installation of extensions dependencies on upgrade might lead to errors2022-10-21T07:25:55Zsluc23No installation of extensions dependencies on upgrade might lead to errorsOverview
----------------------------------------
Current CiviCRM behavior installs dependencies on extension installation, but it does not on extension upgrade.
Having an installed extension and when in a new release this extension ad...Overview
----------------------------------------
Current CiviCRM behavior installs dependencies on extension installation, but it does not on extension upgrade.
Having an installed extension and when in a new release this extension adds dependencies in `info.xml`, there's might be a problem on the upgrade process (depending on the case)
A clear example is `mosaico` upgrade from 2.8 to 2.9.
Until version 2.8 `mosaico` has no dependencies apart from `flexmailer`, but in 2.9 it added `org.civicrm.search_kit` and `org.civicrm.afform`
Reproduction steps
----------------------------------------
1. Have a CiviCRM installation with `mosaico` 2.8 but not installed `org.civicrm.search_kit` and `org.civicrm.afform`
2. Upgrade `mosaico` codebase to 2.9.
3. CiviCRM will crash on bootstrap because of unmet dependencies
Current behaviour
----------------------------------------
If you don't install the dependencies before upgrading the codebase of the extension, you might have unexpected results (depending where the dependent classes are called, in case of mosaico at bootstrap)
Expected behaviour
----------------------------------------
Not sure what's the best solution.. @totten suggested on a automatic process to check for unmet dependencies and disable this problematic extensions to avoid further errors
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.51_
* __PHP__:__7.4/8.0__https://lab.civicrm.org/dev/translation/-/issues/83No translation for "sections" in "New <contact>"2023-08-30T12:57:17Zthoni56No translation for "sections" in "New <contact>"When creating a new person/household/organisation there are foldable sections for details, address, communication preferences etc.
When the site has a non-English localization (at least a Swedish one) they are not translated.
![Skärmav...When creating a new person/household/organisation there are foldable sections for details, address, communication preferences etc.
When the site has a non-English localization (at least a Swedish one) they are not translated.
![Skärmavbild_2023-08-11_kl._13.38.33](/uploads/effa60ca9aa352a2d735ddfe89bb8d79/Skärmavbild_2023-08-11_kl._13.38.33.png)
I'm contributing to the Swedish translation so I know that the strings are translated in Transifex ;-). I have `uplang` installed and it seems to update other translations (although I would love a way to explicitly trigger the download, see https://lab.civicrm.org/extensions/uplang/-/issues/2).https://lab.civicrm.org/dev/financial/-/issues/49No way to customize contribution receipt based on individual entering data wh...2021-11-23T17:28:26ZJonGoldNo way to customize contribution receipt based on individual entering data when giving "On behalf of" an organizationWhen giving on behalf of an organization, we don't store the contact ID of the person who actually entered the contribution, nor do we pass it to the receipt in `$tplParams`. My PR will resolve the latter issue, since it's a safe fix th...When giving on behalf of an organization, we don't store the contact ID of the person who actually entered the contribution, nor do we pass it to the receipt in `$tplParams`. My PR will resolve the latter issue, since it's a safe fix that doesn't affect folks who don't choose to use its functionality.JonGoldJonGoldhttps://lab.civicrm.org/dev/user-interface/-/issues/28Norway has changed the names of its counties2020-10-14T00:40:05ZsudomanNorway has changed the names of its countiesNorway recently updated the names of its counties, which Civi refers to as "states". Could you please update this list of counties? Thanks! : )
Norwegian government (Norwegian)
https://www.regjeringen.no/no/tema/kommuner-og-regioner/reg...Norway recently updated the names of its counties, which Civi refers to as "states". Could you please update this list of counties? Thanks! : )
Norwegian government (Norwegian)
https://www.regjeringen.no/no/tema/kommuner-og-regioner/regionreform/regionreform/nye-fylker/id2548426/
Wikipedia (English)
https://en.wikipedia.org/wiki/Counties_of_Norwayhttps://lab.civicrm.org/dev/core/-/issues/3969Notice: Undefined offset: 1 in /var/www/html/civicirm/wp-content/plugins/civi...2023-01-17T02:01:54ZyodatakNotice: Undefined offset: 1 in /var/www/html/civicirm/wp-content/plugins/civicrm/civicrm/CRM/Utils/Date.php on line 908Overview
----------------------------------------
I got this error showing in civicrm on PHP7.4 and civicrm 5.55.0, Wordpres 6.1 , Nginx
Reproduction steps
----------------------------------------
Go to a report and on top this show
N...Overview
----------------------------------------
I got this error showing in civicrm on PHP7.4 and civicrm 5.55.0, Wordpres 6.1 , Nginx
Reproduction steps
----------------------------------------
Go to a report and on top this show
Notice: Undefined offset: 1 in /var/www/html/civicrm/wp-content/plugins/civicrm/civicrm/CRM/Utils/Date.php on line 908https://lab.civicrm.org/dev/core/-/issues/4848Nuance logging on API Authorization fails2023-12-07T00:07:32ZeileenNuance logging on API Authorization failsWhen an api request fails authorization one of 2 things happens
1) too much information is logged to our logs
2) too little information is logged.
In the former case some things like SearchKit rely on authorization failing appropriatel...When an api request fails authorization one of 2 things happens
1) too much information is logged to our logs
2) too little information is logged.
In the former case some things like SearchKit rely on authorization failing appropriately and logging can cause people to spend time debugging & trying to fix issues that are normal operation - ultimately both https://github.com/civicrm/civicrm-core/pull/28259 and https://github.com/civicrm/civicrm-core/pull/28260 fall in this category & nearly wound up opening up security to fix log noise
In the latter case an api call is failing authorization but it is hard to tell where. We recently hit this where the logged output was unhelpful because the backtrace being logged only got as far as the api call - we were not getting the trace from the exception itself (and the fail was happening on something the api called, not the main api). Hence we wound up altering the code to
```
\CRM_Core_Error::backtrace('API Request Authorization failed' . $apiRequest['action'] . " " . $apiRequest['entity'], TRUE);
\CRM_Core_Error::debug_var('backtrace', $e->getTraceAsString());
```
I think that it makes sense to be able to specify at the api call level when you don't care about logging exceptions (ie searchkit) but also to get some more info when you dohttps://lab.civicrm.org/dev/core/-/issues/5002Number field input validation does not respect decimal separator (member cust...2024-03-07T12:13:16ZCésarNumber field input validation does not respect decimal separator (member custom field)## Overview
Hello I think its related to: https://lab.civicrm.org/dev/core/-/issues/4941 and https://lab.civicrm.org/dev/core/-/issues/4154
## Reproduction steps
1. Under Administer > Localization > Languages, Currency, Locations, set...## Overview
Hello I think its related to: https://lab.civicrm.org/dev/core/-/issues/4941 and https://lab.civicrm.org/dev/core/-/issues/4154
## Reproduction steps
1. Under Administer > Localization > Languages, Currency, Locations, set "Thousands Separator" to "." (dot) and "Decimal Delimiter" to "," (comma).
2. Create a custom field extending Memberships. Data type: Number. (money works)
3. Edit an existing member (or: add a new member). In the number field, enter a number that includes a comma, such as "1,5".
## Current behaviour
Validation fails with the error message "**Error One of parameters (value: 1,5) is not of the type Float**"
## Environment information
Tested on https://dmaster.demo.civicrm.org/ 5.72.alpha1https://lab.civicrm.org/dev/core/-/issues/3948Oauth authentication against MS Exchange IMAP fails since basic authenticatio...2023-03-11T13:16:37ZspalmstromOauth authentication against MS Exchange IMAP fails since basic authentication blockedOverview
----------------------------------------
----------------------------------------
Bounce processing using Oauth to authenticate against MS Exchange fails since Microsoft blocked basic authentication against IMAP.
Reproduction ...Overview
----------------------------------------
----------------------------------------
Bounce processing using Oauth to authenticate against MS Exchange fails since Microsoft blocked basic authentication against IMAP.
Reproduction steps
----------------------------------------
1. Set up an Azure AD application to allow CiviCRM to check bounce processing against MS Exchange
1. Configure Oauth to use it.
1. Create a Mail account for bounce processing.
1. Save and Test fails.
Current behaviour
----------------------------------------
```
An error occured while sending or receiving mail. The IMAP server did not accept the username and/or password: A0001 NO LOGIN failed.. (See log for more details.)
```
Expected behaviour
----------------------------------------
Success.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ _MS Edge_ but probably irrelevant.
* __CiviCRM:__ _5.54.0_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.4__ but probably irrelevant.
* __CMS:__ _Drupal 9.4.8_ but probably not relevant
* __Database:__ _MySQL 8.31_ but probably not relevant
* __Web Server:__ _IIS 10_ but probably not relevant.
Comments
----------------------------------------
Oauth scopes:
```
https://outlook.office.com/IMAP.AccessAsUser.All
https://outlook.office.com/POP.AccessAsUser.All
https://outlook.office.com/SMTP.Send
https://outlook.office.com/User.Read
```
Azure AD App permissions:
```
Microsoft Graph (12)
email Delegated
IMAP.AccessAsUser.All Delegated
Mail.Read Application
Mail.ReadBasi Application
Mail.ReadBasic.All Application
Mail.ReadWrite Application
Mail.Send Application
offline_access Delegated
openid Delegated
POP.AccessAsUser.All Delegated
SMTP.Send Delegated
User.Read Delegated
```
My suspicion is that the extension _never_ worked properly but instead the mail account was using basic authentication so it wasn't an issue. So, when basic authentication was disabled, the application stopped working. Has anyone else seen this issue?https://lab.civicrm.org/dev/core/-/issues/4064Off-line Contribution receipts are sent to on hold emails2023-04-22T16:38:36ZlarsssandergreenOff-line Contribution receipts are sent to on hold emailsIf you record an off-line contribution for a contact with an email on hold, the option to send them a receipt at their on-hold email address is shown (with no indication that the email is on hold).
I would think the expected behaviour w...If you record an off-line contribution for a contact with an email on hold, the option to send them a receipt at their on-hold email address is shown (with no indication that the email is on hold).
I would think the expected behaviour would be to not show the receipt option if the contributor's email is on hold.https://lab.civicrm.org/dev/financial/-/issues/122Offer api support for failed payments2022-10-16T08:10:45ZeileenOffer api support for failed paymentsCurrently the support we have for failed payments is on the BaseIPN class - it should be moved to the BAO / api layer. In general BaseIPN should just call apis ....
I'm thinking about what the api call should look like
I *think* what w...Currently the support we have for failed payments is on the BaseIPN class - it should be moved to the BAO / api layer. In general BaseIPN should just call apis ....
I'm thinking about what the api call should look like
I *think* what we we want is to support the following in Payment.create api/BAO
- status_id = 'Failed'
- 'is_update_contribution_status' = TRUE/ FALSE
This would add a Failed payment to the contribution and optionally (default yes I think) do all the flow on things that currently happen. If the default for is_update_contribution_status then it is closer to the current expectations.
I realise that not everyone thinks we should fail those things in all scenarios - but they feel kinda baked in & like a bigger change to address.
I also thought about using 'is_fail_contribution' - but then if we have status_id = 'Cancelled' we don't want 'is_cancel_contribution' & is a cancel the same as a fail?
As a follow on thought - we should possibly have a message template that could be sent out when a fail occurs.
@JoeMurray @mattwire @monish.debhttps://lab.civicrm.org/dev/user-interface/-/issues/13Offline receipt sending fields inconsistently handled2023-11-23T07:19:06ZAndie HuntOffline receipt sending fields inconsistently handledThe backend contribution, event registration, and membership forms each offer the ability to email a receipt to the contact. However, this parallel behavior is handled independently for each form and is done inconsistently. This has ca...The backend contribution, event registration, and membership forms each offer the ability to email a receipt to the contact. However, this parallel behavior is handled independently for each form and is done inconsistently. This has caused a handful of issues:
1. The admin can specify receipt text for memberships and event registrations but not for contributions. @alicefrumin wrote a fix for this in [PR 15605](https://github.com/civicrm/civicrm-core/pull/15605), but @bgm thought it required a Gitlab issue to discuss and @eileen was uncomfortable with any improvements to receipts until some code is cleaned up.
2. There is a regression in 5.21 where the backend new contribution form in "standalone" context (coming in cold, rather than from a contact) never allows you to send a receipt from the form. This appears to have been introduced by [PR 15757](https://github.com/civicrm/civicrm-core/pull/15757) which, ironically enough, was an attempt to make the new contribution form work consistently with member, participant, and grant forms.
I think it will be challenging to resolve all of the ways the forms are similar but inconsistent, but the receipts are a clear problem and perhaps somewhere to start.https://lab.civicrm.org/dev/drupal/-/issues/109OG_Sync gives fatal error if User is Anonymous2020-03-16T07:37:34ZTony Maynard-SmithOG_Sync gives fatal error if User is AnonymousWhen creating or updating an Organic Group page, if the Author is set to Anonymous or left blank, the OG_Sync module throws a Fatal Error. This can be seen as line 224 of the civicrm_og_sync.module file in the attached backtrace.
Anonym...When creating or updating an Organic Group page, if the Author is set to Anonymous or left blank, the OG_Sync module throws a Fatal Error. This can be seen as line 224 of the civicrm_og_sync.module file in the attached backtrace.
Anonymous is a valid entry for Author on the Drupal form, and should not throw this error. We have a number of occurrences of this where the Group Page has been converted from a previous normal page not using OG, and the original Author had been deleted or otherwise set to Anonymous.
![OG_Sync_error](/uploads/d1c254caa0e18bb4370186657cf1c556/OG_Sync_error.png)https://lab.civicrm.org/dev/core/-/issues/4544Older sites missing index for `is_deceased` on `civicrm_contact`2023-09-06T13:56:12ZwmortadaOlder sites missing index for `is_deceased` on `civicrm_contact`This is a follow up from Eileen's comment about a missing index in https://lab.civicrm.org/dev/core/-/issues/4539#note_150479.
The index for `is_deceased` was added in CiviCRM 4.7 and is defined in [xml/schema/Contact/Contact.xml](https...This is a follow up from Eileen's comment about a missing index in https://lab.civicrm.org/dev/core/-/issues/4539#note_150479.
The index for `is_deceased` was added in CiviCRM 4.7 and is defined in [xml/schema/Contact/Contact.xml](https://github.com/civicrm/civicrm-core/blob/f068222ac25a5a393e9238b617ae91a4d9d29797/xml/schema/Contact/Contact.xml#L722-L726). However, there doesn't appear to be an upgrade task to add this index to existing sites. As a result any site installed before CiviCRM 4.7 is likely to be missing this index. Checking our client sites, I can see a mix of sites that do and don't have it.
The MR where this index was added is: https://github.com/civicrm/civicrm-core/pull/10489
There was a question from Tim about whether there should be an upgrader. There was a later comment from Eileen about whether this index should be removed.
So I guess the question is whether we want this index or not:
- if we **do** want this index we should add an upgrade task so that older sites have this index
- if we **don't** want this index we should add an upgrade task to remove it from sites that have ithttps://lab.civicrm.org/dev/core/-/issues/1807on hold is not respected when two contacts have duplicate email2022-10-10T09:16:44ZIan Kellingon hold is not respected when two contacts have duplicate emailOverview
----------------------------------------
If you have group with two contacts that have the same email, a mailing
will only send to one of them. Then, if that email bounces with the
right classification, one of contacts will hav...Overview
----------------------------------------
If you have group with two contacts that have the same email, a mailing
will only send to one of them. Then, if that email bounces with the
right classification, one of contacts will have their email put on
hold. The next mailing will then ignore that status and send an email to
the other contact which has the same email address.
Reproduction steps
----------------------------------------
Create two contacts that both have a email that doesn't exist and will
produce a bounce that civi understands. Create a group with those two
contacts. Send one or more mailings, processing the bounce until the
contact goes on hold. Then send another mailing.
Current behavior
----------------------------------------
The mailing goes out to the email address that is on hold.
Expected behavior
----------------------------------------
The mailing does not go to the on hold email address.
Environment information
----------------------------------------
* __CiviCRM:__ 5.24.3 with patches that don't affect this issue,
available at https://agpl.fsf.org/crm.fsf.org/CURRENT/
Comments
----------------------------------------
We have many duplicate contacts our database, often 10+ duplicates, thus
making bounce processing require 10+ times more bounces, making bounce
processing very broken. Civi allows users to create contacts with
duplicate emails with the right profile settings, etc, so it should be
able to handle the result without breaking bounce processing.
We are using a rule in our email system to detect these emails
and avoid sending them, it checks if this count is greater than 0:
```
select count(*) FROM civicrm_email where email = REPLACEME and on_hold = 1;
```https://lab.civicrm.org/dev/core/-/issues/4561On new mailing screen the widget for include/exclude double-escapes characters2023-09-13T12:22:17ZDaveDOn new mailing screen the widget for include/exclude double-escapes characters1. Create a group like "2023 Donated >$100". You don't have to actually create a search, just manually create a group with that title.
2. On the new mailing screen, try filtering by typing ">$100". It won't find it because the title disp...1. Create a group like "2023 Donated >$100". You don't have to actually create a search, just manually create a group with that title.
2. On the new mailing screen, try filtering by typing ">$100". It won't find it because the title displays as `>$100`. Searching for `gt;` will find it but that's silly.https://lab.civicrm.org/dev/financial/-/issues/106on Order API test, pass parameters required to create line items, not line items2020-05-28T06:51:36ZJoeMurrayon Order API test, pass parameters required to create line items, not line itemsThe idea of the order api is to provide a wrapper around creating a contribution and all of the line item objects, eg the membership created when buying a membership, or the event registration when buying a ticket.
In the specification ...The idea of the order api is to provide a wrapper around creating a contribution and all of the line item objects, eg the membership created when buying a membership, or the event registration when buying a ticket.
In the specification (https://wiki.civicrm.org/confluence/display/CRM/Order+API), the idea was that there would be array of of the parameters required to create line items. Note that although the entity_table is specified, the entity_id is set to null. Moreover, there is no contribution_id value. Calling the Order API is NOT supposed to require prior calls to create other objects.https://lab.civicrm.org/dev/financial/-/issues/75on order.get, line item has obsoleted contribution_type_id2019-10-19T22:49:23ZJoeMurrayon order.get, line item has obsoleted contribution_type_idThe line item table does not have a contribution_type_id. But when the results of a contribution.get are displayed, the line item fields includes both financial_type_id and contribution_type_id. This seems like an historical artifact tha...The line item table does not have a contribution_type_id. But when the results of a contribution.get are displayed, the line item fields includes both financial_type_id and contribution_type_id. This seems like an historical artifact that should be removed.https://lab.civicrm.org/dev/core/-/issues/4500Ongoing duplicate contact creation if mismatch in civicrm_uf_match2024-01-24T21:04:46ZAllenShawOngoing duplicate contact creation if mismatch in civicrm_uf_match(I've only seen this on WordPress, but the relevant file is in core, so I'm filing under dev/core).
**Summary:**
Under certain circumstances involving "crossed wires" in the `civicrm_uf_match` table, a logged-in user's mere activity in...(I've only seen this on WordPress, but the relevant file is in core, so I'm filing under dev/core).
**Summary:**
Under certain circumstances involving "crossed wires" in the `civicrm_uf_match` table, a logged-in user's mere activity in CiviCRM will create a new contact (containing only the user's email address) for each CiviCRM page load (or ajax call, etc.). Left un-checked, this can lead to thousands of duplicate contacts containing only an identical email address.
**Scope of impact:**
I've seen this on a handful of WordPress sites over the past 5-7 years. I've not heard others in the community mention it, nor seen an existing issue on l.c.o.
**Example steps to reproduce:**
This is only one example; there are surely other steps that will get us there. See "Requisite data conditions" below.
These steps are for repro under WordPress. I haven't tried this under other CMSs.
1. Create WP user _a_ with email address _a@example.com_. Observe this creates a corresponding civicrm contact; we'll call this contact C1. Observe that the entry in `civicrm_uf_match` is correct (i.e. Summary tab for contact C1 shows the user ID of user _a_).
2. Change the email address for user _a_ to _a2@example.com_. Observe that the `civicrm_uf_match` link is preserved (but also that the email address in `civicrm_uf_match.uf_name` is unchanged).
3. Delete contact C1 (permanently or to trash). Observe entry in `civicrm_uf_match` is deleted, and user _a_ still exists.
4. Create a new contact (which we'll call C2) with another email address, e.g. _aFoo@example.com_.
5. Use CiviCRM's "Create User Record" feature to create a new WP user for contact C2; specify any username you like, but we'll assume username _a2_. Observe that the entry in `civicrm_uf_match` is correct (i.e. Summary tab for contact C2 shows the user ID of user _a2_), and that user _a2_ has email address _aFoo@example.com_.
6. Change contact C2's email address to _a2@example.com_. Observe that the email address in `civicrm_uf_match.uf_name` is updated, and the emmail address for WP user _a2_ is unchanged.
At this point, you'll have this state of data:
| wp_users.ID* | wp_users.user_login | civicrm_uf_match.id* | civicrm_uf_match.contact_id* | civicrm contact primary email | civicrm_uf_match.uf_name | wp_users.user_email |
|-------------|---------------------|---------------------|-----------------------------|-------------------------------|--------------------------|---------------------|
| 64 | a | NULL | NULL | NULL | NULL | a2@example.com |
| 65 | a2 | 162 | 75512 | a2@example.com | a2@example.com | aFoo@example.com |
_\* IDs in this table are from my real data; yours will differ of course._
7. As for permissions, I granted user _a_ the WP Administrator role, which has _Administer CiviCRM_; you could probably repro with narrower permissions.
8. Log in as user _a_. Perform a CiviCRM search for contacts having email address _a2@example.com_. Observe the result count N.
9. **Bad Behavior:** Do just about anything in CiviCRM. For example, refresh the search just performed. Observe the result count is >N.
10. Repeat step 9 and observe the increasing number of contacts with email address _a2@example.com_.
**Requisite data conditions**:
As mentioned above, there are probably many possible repro recipes, but the key is to arrive at this requisite state of data:
Given a specific WP user e.g. username _a_, email address _a2@example.com_, new contacts are created containing only this email address, each time this logged-in user takes any action (or presumably almost any action) in CiviCRM, as long as:
1. The WP user ID is not represented in `civicrm_uf_match.uf_id`; and
2. The WP user email (_a2@example.com_) is associated with one or more CiviCRM contacts; in a list of these contacts, sorted by `is_primary DESC, contact_id`, the first contact in that list is represented in `civicrm_uf_match.contact_id`; and
3. The WP user email (_a2@example.com_) is represented in `civicrm_uf_match.uf_name`.
**Relevant code:**
This all seems to be primarily handled by `CRM_Core_DAO_UFMatch::synchronizeUFMatch()`. The above "requisite data conditions" are a summary of the logical path in that method that leads to the stated problem.
Interestingly, the code seems to be aware of this problem, as in [line 284](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/UFMatch.php#L284) it defines a variable `$msg` which would read along the lines of (using values from my data-state above) "Contact ID 162 is a match for WordPress user 64 but has already been matched to 65" -- but that message is never used or logged anywhere.
**Workarounds:**
My simplest fix has been simply to update civicrm_uf_match via SQL to link the right user with the right contact, like so (again using values from my real data above): `update civicrm_uf_match set uf_id = 64 where contact_id = 75512;`. And then of course to remove all of the duplicate contacts.
I thought _Synchronize Users to Contacts_ might do the trick, but it has no affect on the relevant data, and the bad behavior persists.
(Joinery reference: F#1180, F#1339)