CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-02-13T05:03:22Zhttps://lab.civicrm.org/dev/core/-/issues/1518Add additional columns to Pledged But not Paid Report report2023-02-13T05:03:22ZyashodhaAdd additional columns to Pledged But not Paid Report reportAdd additional columns to *Pledged But not Paid Report* report:
* Total Amount Paid
* Balance DueAdd additional columns to *Pledged But not Paid Report* report:
* Total Amount Paid
* Balance Dueyashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/1509Mirror the ISO 3166 country / province databases including IDs2023-01-25T05:03:28ZndavisMirror the ISO 3166 country / province databases including IDsThe country/province lists do not have the correct ISO 3166 numeric ids (ex 1228 for USA should be 240).
This is important because everyone else uses ISO ids and in order to map the right country IDs for CiviCRM, you need to create a ma...The country/province lists do not have the correct ISO 3166 numeric ids (ex 1228 for USA should be 240).
This is important because everyone else uses ISO ids and in order to map the right country IDs for CiviCRM, you need to create a mapping table.
As well not all of the country names match.
Why not just use the ISO data dumps to create these tables?
This becomes very important when you need to create forms with addresses in them. You have to use one ID for civi and the standard ID for everything else....https://lab.civicrm.org/dev/core/-/issues/1489Port "+options" for constant-parameters to APIv4-PHP2023-02-12T05:03:27ZtottenPort "+options" for constant-parameters to APIv4-PHPOverview
----------------------------------------
APIv4 made a step forward in more clearly distinguishing different parts of the input (where-criteria vs update-values vs options...). This also had the affect of making it more verbose....Overview
----------------------------------------
APIv4 made a step forward in more clearly distinguishing different parts of the input (where-criteria vs update-values vs options...). This also had the affect of making it more verbose. For CLI bindings in `cv api4`, improvising API calls was a struggle... until I started using a DSL with `+` options. This issue proposes to make the same mechanism available in PHP code.
Current behavior
----------------------------------------
In PHP, one may write:
```php
Civi\Api4\Foo::update()
->addWhere('field1', '=', 'value1')
->addWhere('field2', '>', 'value2')
->setValue('field3', 'value3')
->execute()
civicrm_api3('Foo', 'update', [
'where' => [
['field1', '=', 'value1'],
['field2', '>', 'value2'],
],
'values' => ['field3' => 'value3'],
]);
```
This is good in that it's very structured, but it's also very verbose.
In CLI usage, the verbosity of JSON killed the ability to improvise calls to the API. `cv api4` worked around this with a DSL -- the most common options support a "+" notation ("where" == "+w"; "select" == "+s"; "limit" == "+l"; etc). This allows one to express constant parameters much more concisely:
```
cv api4 Foo.update +w field1=value1 +w field2>value2 +v field3=value3
```
Proposed behavior
----------------------------------------
Migrate the [Api4ArgParser](https://github.com/civicrm/cv/blob/master/src/Util/Api4ArgParser.php) ([Test](https://github.com/civicrm/cv/blob/master/tests/Util/Api4ArgParserTest.php)) into core. Provide a high-level entry function which accepts constant parameters in "+" notation.
```php
api4('Activity.update +w field1=value1 +w field2>value2 +v field3=value3')->execute();
$count = api4('Activity.get +s row_count +w activity_type.name="Tell a friend"')->execute();
$events = api4('Event.get +s id,title +o start_date')->execute();
```
What if you want to include a mix of constant-parameters and variable-parameters? You wouldn't drop random variable expressions inside the string - because that leads to escaping issues. Instead, mix-in the normal APIv4 OOP notation:
```php
// Same as above, but the filter "value2" is a dynamic value coming from a variable
api4('Activity.update +w field1=value1 +w field2>value2')
->setValue('field3', $value3)
->execute();
```
Side benefit: having the parser in core would make it easier for drush/wp-cli bindings to use the same notation as cv.https://lab.civicrm.org/dev/core/-/issues/1479Relate memberships to (Drupal Organic) Groups and have separate access2020-01-02T15:58:50ZedvanleeuwenRelate memberships to (Drupal Organic) Groups and have separate accessOverview
----------------------------------------
I have a number of groups. Each (Drupal Organic Group originated) group has one or more memberships. With ACL I can discern between the access to the different groups and their contacts. ...Overview
----------------------------------------
I have a number of groups. Each (Drupal Organic Group originated) group has one or more memberships. With ACL I can discern between the access to the different groups and their contacts. However, when access is granted, the accessor can change all memberships, not only the ones which are related to the group.
Example use-case
----------------------------------------
1. Have a group A and B and have separate admins for them.
2. Add a contact and add them to groups A and B.
3. Add a membership.
It is now unclear where the membership belongs to and who is allowed to change it.
Current behaviour
----------------------------------------
Proposed behaviour
----------------------------------------
1. Click on memberships.
2. Add membership.
3. Be able to choose and relate the membership from a field populated with the group a contact already belongs to.
4. Apply ACL to have group admins see and change only their own memberships, depicted by the relationship between the membership and the group.
5. If no group is selected, fall back to the current behaviour, for compatibility with existing instances.
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/1461Donor can modify existing fields of honoree2023-01-19T05:03:38ZBobSDonor can modify existing fields of honoreeOverview
----------------------------------------
Values specified in the honoree fields of a contribution update existing values of the honoree contact record.
Reproduction steps
----------------------------------------
1. Ensure that...Overview
----------------------------------------
Values specified in the honoree fields of a contribution update existing values of the honoree contact record.
Reproduction steps
----------------------------------------
1. Ensure that the unsupervised dedupe rule requires first name and email to match.
1. Create an honoree contact: Joe Honoree, joe@honoree.com.
1. Create a contribution page with the Honoree section enabled. Use the default honoree profile consisting of first name, last name, email.
1. Make a contribution, specifying for the honoree joE WrongName, joe@honoree.com.
Current behaviour
----------------------------------------
The honoree contact has been changed to joE WrongName.
in addition to the last name in the honoree's contact record being changed completely, the capitalization of the first name has also been changed.
Expected behaviour
----------------------------------------
Existing fields in the honoree's contact record should not be changeable by a third party (donor). It would be best to create a new contact which can later be manually deduped, rather than to allow a third party to overwrite existing information.
Environment information
----------------------------------------
* __CiviCRM:__ _5.20.0_
* __PHP:__ _7.2.25_
* __CMS:__ _Drupal 7.30_
* __Database:__ _MariaDB 10.0_https://lab.civicrm.org/dev/core/-/issues/1460How best to handle Event Dispatchers during upgrade2023-03-08T05:03:30ZseamusleeHow best to handle Event Dispatchers during upgradeAs shown by #1449 and in PRs https://github.com/civicrm/civicrm-core/pull/13551 and https://github.com/civicrm/civicrm-core/pull/16034 there have been shown issues with dispatching most hooks when in upgrade mode, this ticket is to discu...As shown by #1449 and in PRs https://github.com/civicrm/civicrm-core/pull/13551 and https://github.com/civicrm/civicrm-core/pull/16034 there have been shown issues with dispatching most hooks when in upgrade mode, this ticket is to discuss the best ways forward and if we need to move the whitelisting or similar to the dispatcher or elsewhere ping @eileen @tottenhttps://lab.civicrm.org/dev/core/-/issues/1457Sort Custom Fields by Custom Field Group in Search Builder2023-01-18T05:03:44Zmagnolia61Sort Custom Fields by Custom Field Group in Search BuilderOverview
----------------------------------------
The list of custom fields is not sorted in the search builder when *not* selecting a contact subtype.
This makes creating a selection when you have quite a few custom fields very labor i...Overview
----------------------------------------
The list of custom fields is not sorted in the search builder when *not* selecting a contact subtype.
This makes creating a selection when you have quite a few custom fields very labor intensive and cumbersome.
Example use-case
----------------------------------------
See screenshots below.
Current behaviour
----------------------------------------
When choosing a contact type the list of Custom Fields is not sorted
![Screenshot_from_2019-12-07_20-27-47](/uploads/ea28ab71b8e23f8d96e97d893059b3f6/Screenshot_from_2019-12-07_20-27-47.png)
After seleting a contact subtype the list is alfabetically sorted by Custom Group / Custom Field
![Screenshot_from_2019-12-07_20-27-52](/uploads/cd2a434a4ff42ddaa2f8552b4ec569a1/Screenshot_from_2019-12-07_20-27-52.png)
Proposed behaviour
----------------------------------------
The list of custom fields is also sorted by Custom Group / Custom Field for when no contact subtype is selected.
Comments
----------------------------------------
Probably this is a very small change. Sorting an array or different query. I just don't know in which haystack to look for this needle :-)https://lab.civicrm.org/dev/core/-/issues/1456Major search limitations and inconsistency2020-01-15T11:43:46Zmagnolia61Major search limitations and inconsistencyOverview
----------------------------------------
I have been using CiviCRM for some 7 years nowm more as a implementer and casual small and simple pr creator.
Something we have run into since using CiviCRM is the inconsistency in using...Overview
----------------------------------------
I have been using CiviCRM for some 7 years nowm more as a implementer and casual small and simple pr creator.
Something we have run into since using CiviCRM is the inconsistency in using the search functions to create smart groups.
We have found workarounds but these are mostly resource expensive.
Example use-case
----------------------------------------
**Advanced Search (AS)**
+ intuitive interface
- Is not able to do advanced logic like '= NULL'
**Search Builder (SB)**
+ great overall flexibility
- Is not able to use relative date filters
Current behavior
----------------------------------------
For creating some of the smart groups we need, we now usually create 3 smartgroups.
1. smartgroup AS with participant info with relative date filter
2. smartgroup SB with some value = (NOT) NULL
3. An include/exclude search group to combine the two
This is very resource intensive but the only workaround we know of today
Proposed behavior
----------------------------------------
enable the following search logic Advanced Search:<br>- IS NULL / IS NOT NULL for select and date fields<br>
enable the following search logic for Search Builder:<br>- relative date filters for date fields
Comments
----------------------------------------
I will try to come up with some more comprehensive examples which I think will enhance both functionality and performance of CiviCRM.
Related issues, pr's and stackexchange topics:
----------------------------------------
Proposal to add is empty / is not empty to AS date field filters https://lab.civicrm.org/dev/core/issues/1211<br>
Api4 Search Builder Vision by Eileen: https://lab.civicrm.org/dev/core/issues/1106 https://lab.civicrm.org/dev/core/-/issues/1452Recurring contributions label on contribution pages is unstylable text, leadi...2021-05-03T11:44:27ZlarsssandergreenRecurring contributions label on contribution pages is unstylable text, leading to problems with themesOn a contribution page with recurring contributions enabled, the label for the recurring selection shows up as:
`<label for="is_recur">I want to contribute this amount</label>
every month
...On a contribution page with recurring contributions enabled, the label for the recurring selection shows up as:
`<label for="is_recur">I want to contribute this amount</label>
every month
`
(including some odd spacing around between the label and the word every). If you allow more than one option (e.g. weeks and months), only the word every is outside the label tags.
Because of this, any theme that changes the styling of the labels ends up looking very bad, as the words "every month" will be in a different font, size, etc. and there can also be some weird spacing. It seems like the fix would be to apply additional label tags around the words.
This is fixable on individual sites by applying styles to the divs that contain this label, but that's obviously not a great solution.
Confirmed on latest demo.5.38.0https://lab.civicrm.org/dev/core/-/issues/1446Find Activities search has no link to return to search results2023-01-16T05:03:34ZandyburnsFind Activities search has no link to return to search resultsIf you run Find Activities Search and click on the Name of the Contact, when you get to the Contact Summary Screen and do whatever it was you meant to do, there is no way to Return To the Search Results of the Find Activities Search, lik...If you run Find Activities Search and click on the Name of the Contact, when you get to the Contact Summary Screen and do whatever it was you meant to do, there is no way to Return To the Search Results of the Find Activities Search, like there is in Advanced Search. You have to rerun the Find Activities Search if you want to continue reviewing the selected records.
Find Activities Search:
![no_return_to_search_results](/uploads/7837e790055427f3db3b6b4a902697c0/no_return_to_search_results.PNG)
Advanced Search:
![search-results-link](/uploads/a6a308144f95216548f8e56e34d7b3d0/search-results-link.PNG)
There is also no `previous` or `next` paging when on the contact summary screen.https://lab.civicrm.org/dev/core/-/issues/1438when importing contributions, can't match contact on phone number2020-02-17T15:27:10Zjamiewhen importing contributions, can't match contact on phone numberOverview
----------------------------------------
When importing contributions, you can't match an existing contact using a phone number, even when the default unsupervised rule specified the phone field. It is because the dedupe rule ca...Overview
----------------------------------------
When importing contributions, you can't match an existing contact using a phone number, even when the default unsupervised rule specified the phone field. It is because the dedupe rule calls the phone field "phone_numeric" yet the contact list of importable fields lists the field as "phone" - so no match is every made.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Find and Merge Duplicate Contacts**.
1. Click **Add rule for Individuals**.
1. Rule Name: Phone, Used: Unsupervised, Select field Phone and enter weight: 1, Threshhold: 1 and **Save**
1. Click **Contributions -> Import Contributions**
1. Upload any CSV file, choose defaults
1. Click Next
1. See that Phone is not listed in fields to import
Current behaviour
----------------------------------------
When the field mapper screen appears and you have an supervised dedupe rule with a phone field, you get a missing index error, a phantom "match to contact" option in the field list, and the phone field is not listed.
![phone-import-error](/uploads/26b39da7bed124937c3666d4fb275a03/phone-import-error.png)
Expected behaviour
----------------------------------------
The phone field should be listed (with "match to contact").
Environment information
----------------------------------------5.24.0https://lab.civicrm.org/dev/core/-/issues/1433CRM_Case_XMLProcessor::allActivityTypes() doesn't do caching right2020-06-16T11:13:35ZDaveDCRM_Case_XMLProcessor::allActivityTypes() doesn't do caching rightThis isn't recent. The function looks like this:
```php
public static function &allActivityTypes($indexName = TRUE, $all = FALSE) {
if (self::$activityTypes === NULL) {
self::$activityTypes = CRM_Case_PseudoConstant::caseActiv...This isn't recent. The function looks like this:
```php
public static function &allActivityTypes($indexName = TRUE, $all = FALSE) {
if (self::$activityTypes === NULL) {
self::$activityTypes = CRM_Case_PseudoConstant::caseActivityType($indexName, $all);
}
return self::$activityTypes;
}
```
So it works fine the first time in any given page run, but then if you call it again with different parameters it just returns the thing it cached last time regardless of the parameters. It isn't used very often and so I guess it doesn't come up in a typical page run, but it was driving me a bit nuts while trying to write a unit test and not getting what I was expecting.
PR coming, just debating whether it's worth trying to eliminate completely since it isn't used in that many places, i.e. deprecate it and replace everywhere it's used in core with CRM_Case_PseudoConstant::caseActivityType which does its own caching anyway.5.28.0https://lab.civicrm.org/dev/core/-/issues/1431Feature: Ability to filter relationship tab by relationship type in a very si...2023-01-12T05:03:21ZlolcodeFeature: Ability to filter relationship tab by relationship type in a very similar way to the activity tabOverview
----------------------------------------
It would be great to have the ability to filter relationship tab by relationship tab in a very similar way to the activity tab.
Example use-case
----------------------------------------
...Overview
----------------------------------------
It would be great to have the ability to filter relationship tab by relationship tab in a very similar way to the activity tab.
Example use-case
----------------------------------------
1. View a contact with hundreds or thousands of relationships
2. Some staff are only concerned with one or two relationship types that have low quantities.
Current behaviour
----------------------------------------
The staff have to page through all relationships or sort by relationship type and then guess a page number if the type sorts into the middle.
Proposed behaviour
----------------------------------------
A filter with relationship types, start_date and end_date is available in a similar way as it is for the activity tab. The `CRM_Contact_BAO_Relationship::getContactRelationshipSelector` function would ideally have a relationshipTypeIds filter or something similar.https://lab.civicrm.org/dev/core/-/issues/1424Export doesn't work in Excel with diacritic chars2020-07-12T03:19:04ZeileenExport doesn't work in Excel with diacritic charsPROPOSAL - prepend the BOM for UTF8 "\xEF\xBB\xBF" so csv's exported from excel
Discussion (note this is the same writeup on the PR - creating a gitlab too as I suspect there might be discussion).
There is a long-standing issue ...PROPOSAL - prepend the BOM for UTF8 "\xEF\xBB\xBF" so csv's exported from excel
Discussion (note this is the same writeup on the PR - creating a gitlab too as I suspect there might be discussion).
There is a long-standing issue whereby files exported from CiviCRM with diacritic characters - eg.
ę are mangled when opened in MS Excel.
The underlying issue is that the characters are UTF-8 encoded & MS Excel by default does not assume UTF8.
In order to do so it needs a BOM - Byte Order Marker - which is a few hex characters at the start of
the csv.
The BOM indicator is 'not recommended' .... unless you want your csv to work with
MS Excel. Since MS Excel is a major use case for csvs I think it's pretty clear that all
things being equal we want to support it... I note that there are extensions to export to excel
natively but I don't think that replaces this. The number one reason to want to export
a csv is to work with it in a spreadsheeting programme & unless we can't safely make it
work in core we shouldn't require an extension for that.
There are various recommendations over time but it seems things have improved in the MS
Excel world and what works on Windows now appears to work on Mac too - at least on a recent version.
This link https://donatstudios.com/CSV-An-Encoding-Nightmare is a pretty good discussion.
While the above link and others say that you need a different BOM for MAC than Windows my
testing shows that the one recommended for Windows works fine on Mac Excel (while you would need
to convert to UTF 16 to follow the Mac recommendation. (https://csv.thephpleague.com/9.0/interoperability/encoding/)
Other links
https://stackoverflow.com/questions/35294443/does-excel-for-mac-2016-properly-import-unicode-in-csv-files
https://stackoverflow.com/questions/2223882/whats-the-difference-between-utf-8-and-utf-8-without-bom/2223926#2223926
Notably this summary :
" When should you encode with a BOM?
If you're unable to record the metadata in any other way (through a charset tag or file system meta), and the programs being used like BOMs, you should encode with a BOM. This is especially true on Windows where anything without a BOM is generally assumed to be using a legacy code page. The BOM tells programs like Office that, yes, the text in this file is Unicode; here's the encoding used.
When it comes down to it, the only files I ever really have problems with are CSV. Depending on the program, it either must, or must not have a BOM. For example, if you're using Excel 2007+ on Windows, it must be encoded with a BOM if you want to open it smoothly and not have to resort to importing the data."
So the argument for a BOM is - if you want it to be compatible with MS Excel use a BOM. This seems to apply.
The risk is that perhaps there is some variant of csv viewing programme that can't cope - the risk of this is rather mitigited by
1) the fact that MS Excel adds the BOM to the start of any files it saves as UTF-8 encoded csv so any programme that expects to open MS Excel generated
csvs would need to be able to cope with it. In addition it is a standard, if not required, file indicator so it feels like the programmes
that were legacy in 2016 writeups might be of no concern now.
2) There really is no programatic way to export these csvs so the risk that this is being parsed by code is close to zero
There are 2 other things we could do to mitigate
1) test on more platforms - I've tested with MS Excel for Mac (Office 365 v 16.31) and Libre Office and MS Numbers
& MS word, cot editor & notes
2) We could add a setting. I'm generally a bit loath on settings as they are a bit of a maintenance nightmare.
However, perhaps it would be a setting like 'export csvs in legacy format & there could be a link
to the gitlab to explain your use-case if you feel the need to set it. If no-one does then we could later remove.
Final note - csv tables are created with the CRM_Core_Report_Excel (spot the irony) from 3 places
- the main export, the export for custom fields & a third place which I believe to be unreachable. This is one path
only but I can look at centralising for the custom fields export path.5.22.0https://lab.civicrm.org/dev/core/-/issues/1417Default view on Constituent details wastes space with unneeded headers2023-01-11T05:03:27ZCoreyBurgerDefault view on Constituent details wastes space with unneeded headersThe default Constituent Detail report wastes huge amounts of space on pages, while the Constitient Summary report, which is nicely organized, lacks key details like membership.
My use case is as follows: I want to print off the high lev...The default Constituent Detail report wastes huge amounts of space on pages, while the Constitient Summary report, which is nicely organized, lacks key details like membership.
My use case is as follows: I want to print off the high level details for a committee meeting. My contacts are organized into a group. What I want to be able to view for that meeting is the following: Name, Email, Address and Membership Status.
There are three reports I could use for this:
1. Constituent Summary - no membership
2. Constituent Details - wasted space
3. Membership Summary - misses all non-members
The simplest solution to this problem is to edit the Constituient Details template to remove unneeded headers. I'm happy to help make this change, but I honestly have no idea where in the code I would find the needed templates to edithttps://lab.civicrm.org/dev/core/-/issues/1415No easy way to see campaign activities2023-01-10T05:03:25ZCoreyBurgerNo easy way to see campaign activitiesOn the campaign dashboard, there is no way to see data related to that campaign. Ideally, there should be a View Activities link that is a search that lists all activities associated with that campaign.
As a secondary goal, this should...On the campaign dashboard, there is no way to see data related to that campaign. Ideally, there should be a View Activities link that is a search that lists all activities associated with that campaign.
As a secondary goal, this should be expanded to be a "dashboard" showing goals: revenue, membership, etc. along with a list of latest activities below that.https://lab.civicrm.org/dev/core/-/issues/1404Test assertions should include message describing the assertion2020-09-17T22:58:00ZFrancis (Agileware)Test assertions should include message describing the assertionWhile checking test failures for a PR, received the test error:
> Failed asserting that true is false.
On quick review of the refs in the phpunit tests directory, I found that almost none of the assertFalse calls in the test suite use ...While checking test failures for a PR, received the test error:
> Failed asserting that true is false.
On quick review of the refs in the phpunit tests directory, I found that almost none of the assertFalse calls in the test suite use the second argument to provide a descriptive message about the assertion. The assumption is then that the other assertion types are in the same situation.
The provides a less than stellar testing environment, as you have to check a source code reference to understand your test failure.
We should improve the tests so that they explain (summarise) the assertion that failed.https://lab.civicrm.org/dev/core/-/issues/1398Option to open navigation item in new window (if present)2019-11-26T20:25:31ZMonish DebOption to open navigation item in new window (if present)Currently, the ```target``` attribute of submenus are ignored whereas the menu item adds this property in the anchor links [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/Navigation.php#L443)Currently, the ```target``` attribute of submenus are ignored whereas the menu item adds this property in the anchor links [here](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/Navigation.php#L443)5.21.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/1388civicrm_group is missing important indexes on cache fields2023-01-10T05:03:25Zeileencivicrm_group is missing important indexes on cache fieldsWe had a recent server degradation where queries ran a lot slower and I spotted a non-indexed query that the small table size would normally cause to fly under the radar - basically we need to add these indexes:
```
$tables = ['civicr...We had a recent server degradation where queries ran a lot slower and I spotted a non-indexed query that the small table size would normally cause to fly under the radar - basically we need to add these indexes:
```
$tables = ['civicrm_group' => ['cache_date', 'refresh_date']];
CRM_Core_BAO_SchemaHandler::createIndexes($tables);
```
Note I'm just logging, rather than doing a PR, at this stage as I'm pretty snowed under.
@seamuslee @mattwire FYI - you might get benefit from indexing thishttps://lab.civicrm.org/dev/core/-/issues/1387"config_backend" should be thoroughly removed2023-02-05T05:03:36Ztotten"config_backend" should be thoroughly removedOverview
----------------------------------------
In CiviCRM 4.7.0, the column `civicrm_domain.config_backend` was migrated to the `civicrm_setting` table. However, the migration was incomplete.
Reproduction steps
----------------------...Overview
----------------------------------------
In CiviCRM 4.7.0, the column `civicrm_domain.config_backend` was migrated to the `civicrm_setting` table. However, the migration was incomplete.
Reproduction steps
----------------------------------------
1. Create a new site (e.g. `civibuild create dmaster`)
2. Run `DESC civicrm_domain`
3. Observe that column `config_backend` exists
Current behaviour
----------------------------------------
* If a site upgrades from `$ver <= 4.6`, then the column `civicrm_domain.config_backend` does NOT exist.
* If a new site is created in `4.7 <= $ver <= 5.21`, then the column `civicrm_domain.config_backend` DOES exist.
Expected behaviour
----------------------------------------
The column should not exist in v5.21 (or whatever gets the fix). It should not matter if the site originated on v4.5, v4.7, or v5.20.
Comments
----------------------------------------
Historically, this field is related to `CRM_Core_BAO_ConfigSetting`. One should grep on both `config_backend` and `ConfigSetting` to track down code-paths that may be referencing it.
It is still desirable to retain upgrade/transitional logic (eg `CRM_Upgrade_Incremental_php_FourSeven`, `Civi\Core\SettingsBag`); but otherwise these should be removed, and any dependent code-paths should be re-tested.