CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-12-20T05:03:24Zhttps://lab.civicrm.org/dev/core/-/issues/1274Improve interaction between payment processor & cancelling2022-12-20T05:03:24ZeileenImprove interaction between payment processor & cancellingI've just taken a look at why some contributions don't show the full cancel screen but only the disable screen for cancelling recurring ie
![Screen_Shot_2019-09-23_at_7.01.15_PM](/uploads/152d70982f50131b4b02670311f5c19a/Screen_Shot_201...I've just taken a look at why some contributions don't show the full cancel screen but only the disable screen for cancelling recurring ie
![Screen_Shot_2019-09-23_at_7.01.15_PM](/uploads/152d70982f50131b4b02670311f5c19a/Screen_Shot_2019-09-23_at_7.01.15_PM.png)
vs
![Screen_Shot_2019-09-23_at_7.01.39_PM](/uploads/a7b3d23e855585fda481b758fa1dee15/Screen_Shot_2019-09-23_at_7.01.39_PM.png)
And what I see is the former shows if the payment processor supports CancelRecurring - this is set to TRUE - which is the case if the function cancelSubscription exists
However, it's only relevant if 'send_cancel_request' is checked.
```
if (CRM_Utils_Array::value('send_cancel_request', $params) == 1) {
$cancelParams = ['subscriptionId' => $this->_subscriptionDetails->subscription_id];
$cancelSubscription = $this->_paymentProcessorObj->cancelSubscription($message, $cancelParams);
}
```
So we have 2 decision points
1) do we show the cancel form or the disable form
2) do we show the notify payment processor checkbox / call cancelSubscription
**PROPOSAL**
I feel like a better mix would be.
1) always show the cancel screen rather than the if supportsCancelRecurring is TRUE. (I'm about 70% of the way to just saying 'always' - I don't see the advantage of the disable screen)
2) add an additional parameter supportsCancelNotifyProcessor that determines whether the check box shows up - we would need to default to TRUE for grandfathering (probably at the form level) unless supportsCancelRecurring is FALSE
3) always call the cancelRecurring button on submit IF the function cancelRecurring exists. (new preferred behaviour to grandfather in)
4) if cancelRecurring does not exist fall back to cancelSubscription IF exists AND 'send_cancel_request' is true (current behaviour)
5
Changes to documentation would be
1) if your processor allows recurring contributions to be cancelled then implement supportsCancelRecurring and return a boolean (relying on the parent is deprecated)
2) implement supportsCancelNotifyProcessor to determine whether the 'Send cancellation request to xx' radio button will show (default = yes )
3) add the current disabled text in if not showing the 'send to processor' box but use $processor->getText() so it can be overridden & set to null
4) implement cancelRecurring function if your processor needs to take an action on cancelling (it will need to parse the 'send_cancel_request' param in that function as it will be called either way.
5) cancelSubscription is deprectated
Secondary thoughts
1) I'm not a fan of it defaulting to notify the person but OK
2) I'm really not a fan of the backstop implementation of supportsCancelRecurring
```
protected function supportsCancelRecurring() {
return method_exists(CRM_Utils_System::getClassName($this), 'cancelSubscription');
}
```
I'd rather see us expect the payment processor to return TRUE or FALSE
@mattwire @adixon @KarinG @aghhttps://lab.civicrm.org/dev/core/-/issues/1225Event Info/Contribution Page Smarty templates are inconsistent and ugly2022-12-16T05:03:23ZJonGoldEvent Info/Contribution Page Smarty templates are inconsistent and uglyThat title encompasses quite a lot - but I'm just tackling one little corner. I'm introducing some classes and some consistency between identical elements of event and contribution pages.That title encompasses quite a lot - but I'm just tackling one little corner. I'm introducing some classes and some consistency between identical elements of event and contribution pages.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3934Settings - Deprecate "serialize" flag2022-12-16T01:05:12ZtottenSettings - Deprecate "serialize" flag# Background: Basic settings
Settings are "key-value" pairs. The "value" part allows type `mixed` (*ie `string` or `int` or `float` or `array` or whatever*).
Support for `mixed` is consistent between `Civi::settings()` and `$civicrm_se...# Background: Basic settings
Settings are "key-value" pairs. The "value" part allows type `mixed` (*ie `string` or `int` or `float` or `array` or whatever*).
Support for `mixed` is consistent between `Civi::settings()` and `$civicrm_setting`.
```php
// Consistent access to a scalar
Civi::setting()->set('my_string', 'abc');
$civicrm_setting['domain']['my_string'] = 'abc';
assert Civi::setting()->get('my_string') === 'abc';
```
```php
// Consistent access to an array
Civi::setting()->set('my_array', [1,2,3]);
$civicrm_setting['domain']['my_array'] = [1,2,3];
assert Civi::setting()->get('my_string') === [1,2,3];
```
Under the hood, values are stored in MySQL using `serialize()`. You can see this in both recent and ancient code:
* 5.54's `setDb()`: https://github.com/civicrm/civicrm-core/blob/5.54/Civi/Core/SettingsBag.php#L413
* 5.54's `loadValues()`: https://github.com/civicrm/civicrm-core/blob/5.54/Civi/Core/SettingsBag.php#L137
* 4.3's `setItem()`: https://github.com/civicrm/civicrm-core/blob/4.3/CRM/Core/BAO/Setting.php#L325
* 4.3's `getItems()`: https://github.com/civicrm/civicrm-core/blob/4.3/CRM/Core/BAO/Setting.php#L216
# Background: `serialize` metadata
There is an additional option in `*.setting.php` metadata called `serialize`. Superficially, this resembles `serialize` metadata for DAO fields.
This option is defined for 8 settings: `contact_view_options`, `contact_edit_options`, `advanced_search_options`, `user_dashboard_options`, `address_options`, `contact_autocomplete_options`, `contact_reference_options`, and `quicksearch_options`.
In all cases, the setting has a serialization format of `SERIALIZE_SEPARATOR_BOOKEND`.
APIv4's `Setting` is a wrapper for `Civi::settings()`. Notably, it interprets the `serialize` metadata and applies an (additional/secondary) serialization.
# What's good about this?
It makes it easier for REST/AJAX agents to read and write those 8 historical settings (*the pre-existing settings with the annoying BOOKEND format*).
At the time of introduction, it probably had no effects on compatibility and required no upgrade steps.
# What's bad about this?
It encourages people to add unnecessary serialization layers. If you are writing a _new_ setting with structured data, then you'll see the `serialize` metadata and think: "I should add that!" Here are some docs that suggest `JSON` for a setting:
https://docs.civicrm.org/dev/en/latest/framework/setting/#settings-definition
But you shouldn't do that on a new setting! Here's why:
* __It adds complexity -- double-encoding.__ Every read and write of the data goes through both `serialize()` and some additional serialization method.
* __It adds complexity -- conflicted APIs.__ The setting can be viewed through various programmatic interfaces (e.g. local PHP array `$civicrm_setting`; local PHP method `Civi::setting()->get()`; e.g. remote REST method `Setting.get`). Some APIs present an `array` -- but others present an encoded string (like `^1^2^3^`). There is no decent reason why `$civicrm_setting`, `Civi::setting()`, and `Setting.get` should present it differently.
* __It distracts from the real data-modeling problem of serialized fields.__ We generally do simple settings (strings/ints) because they're easier. Complex settings (like `mailing_backend`) are possible, but we don't do them as much - because the tooling/validation/etc is not as good. Intuitively, complex settings could work better if we added more metadata. _But this is the wrong metadata._ Switching `mailing_backend` between `serialize`/JSON/CSV/YAML/etc doesn't make this any better. What you need is a sharper description of the data inside of that serialized blob.
* __It becomes overall harder to change.__ Perhaps settings should be stored with `json_encode()` instead of `serialize()`? `serialize()` has additional kinds of vulnerabilities. JSON has better support in MySQL. Plot out the path for how to migrate the entirety of `civicrm_setting.value` -- and compare that to switching serialization on a setting-by-setting basis. It's easier to change if individual settings are _not_ committed to specific serializers.
# What to do
Simplest thing:
* Keep the mechanism
* Present it as deprecatedhttps://lab.civicrm.org/dev/core/-/issues/430Child groups of ACL groups cause ACL to fail2022-12-12T05:03:30ZRichChild groups of ACL groups cause ACL to fail## Problem
If you have group A which is used to identify contacts that an ACL grants permissions to, and you add group B as a child group of A, the ACLs fail to allow you to see the contacts in group A.
Seems that [this line](https://l...## Problem
If you have group A which is used to identify contacts that an ACL grants permissions to, and you add group B as a child group of A, the ACLs fail to allow you to see the contacts in group A.
Seems that [this line](https://lab.civicrm.org/dev/core/blob/master/CRM/ACL/BAO/ACL.php#L785) (and again in line 804) is assuming a table alias stored in a PHP serialized field to look like `civicrm_group_contact-N` where `N` is Group A's ID, but actually the alias will be `civicrm_group_contact-N,M` where M is the group B's ID.
Presumably the aliases get less predictable if a group has multiple children/grandchildren.
As far as I have understood, the code is trying to standardise the groups into two buckets: one for smart groups and one for normal groups.
I think the logic should be that groups both A and B should be included in the collected group IDs, since if you're in the child group, you're considered to be in the parent group - I *think*. Although this does mean that if someone has status "Removed" in the parent group (the one that defines which contacts the ACL grants access to), but "Added" in the child group, then the Added will win; access will be granted. So it could get more complicated.
Or the desired behaviour could simply be "no, you have to be actually added to group A since that is the only group explicitly mentioned in the ACL, and that status of group B should not have any bearing on the situation".
## Workaround
To fix this for my client I had to:
1. Edit group B: Remove group A as the parent for group B.
2. Edit group A and just hit Save. This step is necessary to ensure the whereTables and selectTables are updated.
3. Instruct them not to add child groups of ACL groups.
## Discuss
What's the desired behaviour? Is looping through the generated table aliases the most reliable way to implement it?https://lab.civicrm.org/dev/core/-/issues/1167Add new hook for summary overlay profile2022-12-09T05:03:28ZyashodhaAdd new hook for summary overlay profileCurrently, there is just one profile set for summary overlay.
This causes organisations/households to show demographics fields as well which is not relevant.
![summary_overlay](/uploads/5b621f22ad44e0dbd9adc6a2a5f3ca05/summary_overlay.pn...Currently, there is just one profile set for summary overlay.
This causes organisations/households to show demographics fields as well which is not relevant.
![summary_overlay](/uploads/5b621f22ad44e0dbd9adc6a2a5f3ca05/summary_overlay.png)
Add a new hook to change profile id used in summary overlay on search forms so that the extension can later decide which profile should be rendered for which contact type.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3645Eventually google will require OAUTH for bounce processing and may require it...2022-12-08T20:55:07ZDaveDEventually google will require OAUTH for bounce processing and may require it for outbound SMTP through gmail serversAs noted on [stackexchange](https://civicrm.stackexchange.com/questions/34142/sending-mail-via-gmail-google-announce-username-password-authentication-will-b), Google sent out an email outlining plans to require OAUTH and discontinue supp...As noted on [stackexchange](https://civicrm.stackexchange.com/questions/34142/sending-mail-via-gmail-google-announce-username-password-authentication-will-b), Google sent out an email outlining plans to require OAUTH and discontinue support for just username/password.
The way I read it, this is mostly applying to POP/IMAP clients for reading mail, and they are *hinting* that someday they might require it for outbound SMTP, i.e. at Administer - System Settings - Outbound Mail you choose SMTP and have it set to use gmail servers. The relevant quote is
> No change is required for scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails. If you replace your device, look for one that sends email using OAuth.
(LSA means less secure apps, which is google-speak for username/password)
They are targeting June 2020 - Feb 2021 for IMAP etc, but as noted above they have not specifically set a date for changes regarding sending outbound emails.
It occurs to me though that bounce processing and the email processor use POP/IMAP. For the email processor you can work around it by just forwarding it to a non-gmail address and polling that, but bounce processing might be harder depending on setup.https://lab.civicrm.org/dev/core/-/issues/1177Add system check for deprecated ARCHIVE log tables2022-12-06T05:03:34ZPatrick Figelpfigel@greenpeace.orgAdd system check for deprecated ARCHIVE log tablesIn #663, we changed the default engine for log tables from `ARCHIVE` to `InnoDB` and shipped this with 5.16. While new installations (and tables first created on 5.16+) will use the `InnoDB` engine by default, existing log tables are not...In #663, we changed the default engine for log tables from `ARCHIVE` to `InnoDB` and shipped this with 5.16. While new installations (and tables first created on 5.16+) will use the `InnoDB` engine by default, existing log tables are not migrated automatically. This needs to be done using the `System.updatelogtables` API with `forceEngineMigration` set to "1".
Once the change has seen some production usage (i.e. a couple of releases from now), we should add a system check to warn admins if any of their log tables use the `ARCHIVE` engine and prompt them to migrate affected tables using the API.https://lab.civicrm.org/dev/core/-/issues/4007Proposal: SearchKit Templates2022-12-05T23:15:19ZcolemanwProposal: SearchKit TemplatesBackground
-------------
Olly is working on a new Extension called [SearchKit Reports](https://lab.civicrm.org/extensions/search_kit_reports) which is a collection of SavedSearches. The idea is to reproduce most of CiviReport using Searc...Background
-------------
Olly is working on a new Extension called [SearchKit Reports](https://lab.civicrm.org/extensions/search_kit_reports) which is a collection of SavedSearches. The idea is to reproduce most of CiviReport using SearchKit, and people can then use those packaged searches to get a jump-start on building their own searches.
Since these searches are intended to be used as templates, why not actually make them templates.
Rationale
-------------
I think this would benefit the SK UI because because so far, the "Packaged Searches" tab contains stuff the average user shouldn't mess with unless they know what they're doing; searches like "Administer Custom Fields" provide critical functionality to various CiviCRM screens that could potentially be broken if messed with.
Now the [SearchKit Reports](https://lab.civicrm.org/extensions/search_kit_reports) extension is introducing a bunch of packaged searches with the opposite intention. They provide *no* functionality out of the box and we *want* the user to mess with them & experiment as much as they want. We also want to encourage a workflow where they don't directly edit the packaged version but save a copy.
Design
-----------
I'm thinking that SavedSearchTemplates would:
1. Appear on their own tab in SearchKit
2. Not be runnable outside the SearchKit Admin UI - clicking on one would pull up a new pre-configured search (the same as clicking the "Clone" button on a SavedSearch)
3. Stored in their own table `civicrm_saved_search_template`
4. Can be created, updated & packaged like regular saved searches
To point 3, I thought about adding an `is_template` column like we do in the `civicrm_event` table, and then thought about what a PITA that column is, and is it really so hard to create a new table? No, not hard at all.https://lab.civicrm.org/dev/core/-/issues/1168"Full" domain of the site is stored in the database in serialised fashion for...2022-12-05T05:03:26ZJamie Novick - Compuco"Full" domain of the site is stored in the database in serialised fashion for each CiviReport instance making sites less transportable to new domainsI'm not sure if this is a known issue or not as I think it relates to making the site more "transportable" but at the moment it appears that the site base path is stored in a serialised fashion for each report instance.
How it works cur...I'm not sure if this is a known issue or not as I think it relates to making the site more "transportable" but at the moment it appears that the site base path is stored in a serialised fashion for each report instance.
How it works currently:
If you create a new report instance the system will automatically store the report instance configuration as a serialised blob field. This however includes the full report URL in a form:
"http://[yoursitehere]/civicrm/report/instance/3?reset=1&output=criteria"
How it should/could work:
Whilst I'm not sure technically how to achieve this (and I wonder what the impact on multisites would be) it would be preferable if the report instance could not include the base path of the site:
"/civicrm/report/instance/3?reset=1&output=criteria"
As such this would make sites transportable to new URL's.
Thoughts?https://lab.civicrm.org/dev/core/-/issues/1634Evaluate if any indexed fields are unused2022-12-04T23:07:09ZeileenEvaluate if any indexed fields are unused
**Proposal** (note this is being updated based on discussion & comments may refer to an earlier version)
1. Remove the following columns from the xml from civicrm_activity
* phone_id
* phone_number
* relationship_id
1. Remove th...
**Proposal** (note this is being updated based on discussion & comments may refer to an earlier version)
1. Remove the following columns from the xml from civicrm_activity
* phone_id
* phone_number
* relationship_id
1. Remove the index from the xml on
* medium_id
* is_deleted
1. During upgrade we drop the above columns, if empty.
**Follow ups to consider**
2. There are other columns in the civicrm_activity table that are case specific - we might consider indexing is_current_revision & original_id only when CiviCase is enabled
3. I've been doing some tests on searches and found that searching is faster if I DROP the contribution_status_id index - it might be interesting to test the activity_type_id index although I suspect it has a much greater cardinality & is more useful
**Impact of the above**
1. Data would not be lost but api fields would no longer access those fields
2. Developers who might be using them outside of core could be impacted - we can mitigate by communicating on the dev list & perhaps putting checks & deprecation notices onto sites with data in the fields for a few months before making any changes.
3. DB size would be reduced. Note that empty fields contribute notably to table size IF they are indexed
4. Dev confusion & efficiency is improved by not having unused stuff in core.
**Background**
Obviously that's not something we should rush into so I'll have to ping the dev list etc
Looking at our civicrm_activity table it appears that each index has a base size - of around a half a gig. From there, the index size increases based on how much data is in the table. So an index on an empty field is around 57% of the size of our largest index.
There are 5 fields that are indexed + empty in our database for the civicrm_activity table (
```
Original id used for CiviCase
Medium id
Phone id
relationship_id
is_deleted
```
Plus - is_current_revision is effectively null
So my first question is are these all used in other databases - e.g when civicase is in use.
I couldn't spot references to phone_id and it feels 'wrong' to me anyway as I think you would want to either link to the contact or have a hard reference. I wonder if some of these fields are quietly obsolete?
It's very unsafe to drop core fields. However, I'm pondering dropping the indexes on these fields
@DaveD I'd appreciate your thoughts....https://lab.civicrm.org/dev/core/-/issues/1161relationship custom data creates duplicate relationship records2022-12-03T05:03:23Zlcdwebrelationship custom data creates duplicate relationship recordsSeveral years back, a commit was implemented that checked relationship custom data when determining if two contacts had an existing relationship. If the custom data did not match, a new relationship between the two contacts was created. ...Several years back, a commit was implemented that checked relationship custom data when determining if two contacts had an existing relationship. If the custom data did not match, a new relationship between the two contacts was created. The commit is here: https://github.com/civicrm/civicrm-core/commit/6b28495231b5c42f42ef4c837b88042c17faba3e
I understand and appreciate the intent of the behavior, and agree that it may be legitimate to want multiple relationships of the same type between the same two contacts when custom data should represent distinct historical information. However, the behavior has some negative consequences.
In particular -- it effectively ensures duplicate relationships will be created if at any time you expose the current employer field to a frontend facing form. In that context, there is no way to know or set the relationship custom data. If the employee/employer already have a relationship with any custom data set, submitting the form will create a duplicate relationship (and it will be set as the current employer). If the existing relationship had permissioning set, or the custom data had importance in other areas of the system, this can have a very negative impact.
All that said, I'm not sure of the best solution. One option is to create a global setting where you can choose to check relationship custom fields or not check them. Another option is to ignore the check if the new relationship has no custom fields set. Actually -- from the comments in the existing code it looks like that was the intent, but it may not be working (see https://github.com/civicrm/civicrm-core/commit/e312bf627757145dfca7ee9fa60c7dda30d5aaf2).
Anyway, I wanted to get some input on what may be viewed as a preferred solution.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/654Contribution Field Map not saving Soft Credit Type2022-11-30T19:39:36ZphilmorbruContribution Field Map not saving Soft Credit TypeWhen importing Contributions with Soft Credits and saving a field mapping, the Soft Credit fields do not save the type of soft credit in the mapping. When reusing the saved mapping, the user must change the "Matching CiviCRM Field" to a ...When importing Contributions with Soft Credits and saving a field mapping, the Soft Credit fields do not save the type of soft credit in the mapping. When reusing the saved mapping, the user must change the "Matching CiviCRM Field" to a field other than Soft Credit, and then change it back to Soft Credit to select the proper choice. Compare attached files of incorrect and expected/correct behavior.
![wrong](/uploads/ef41cb0ec6cf2b02a40a0a3cbbdfa6ed/wrong.jpeg)
![right](/uploads/185289c1c32fde58999381d14aefee65/right.jpeg)
Replicated on clean install of 5.7.0 on Joomla 3.9.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/4009Proposal: SearchKit show Calculated Field entity refs as joins2022-11-30T08:39:36Zaydunsaidan.saunders@squiffle.ukProposal: SearchKit show Calculated Field entity refs as joinsOverview
----------------------------------------
If you join an entity using 'With' then it appears in the 'Add' dropdown as an expandable entity: - see 'Contact Contributions' in this image:
![image](/uploads/78451866fa4f155fb32594879e...Overview
----------------------------------------
If you join an entity using 'With' then it appears in the 'Add' dropdown as an expandable entity: - see 'Contact Contributions' in this image:
![image](/uploads/78451866fa4f155fb32594879efb754d/image.png)
However entities that are joined via Calculated Fields show differently so we get fields like 'Address (billing) Country' rather than a dropdown for Address providing access to all the address fields.
With the recently merged https://github.com/civicrm/civicrm-core/pull/25056, the `master_id` field appears in the list but none of its fields.
So can we make those entities show in the same way as those joined via 'With' ? (APIv4 Explorer does this).https://lab.civicrm.org/dev/core/-/issues/4010Proposal: SearchKit add optional labels to joins2022-11-30T08:39:20Zaydunsaidan.saunders@squiffle.ukProposal: SearchKit add optional labels to joinsOverview
----------------------------------------
Proposal: Add an optional label after a 'With' and use that in the Add dropdown. For Calculated Fields, this might another element in `FieldSpec`
Rationale
----------
1. If you add the...Overview
----------------------------------------
Proposal: Add an optional label after a 'With' and use that in the Add dropdown. For Calculated Fields, this might another element in `FieldSpec`
Rationale
----------
1. If you add the same entity multiple times you get eg:
![image](/uploads/c4a12ab363c6fae415a8028ad2575797/image.png)
with an Add dropdown of:
![image](/uploads/c09359051f68512ebf1f992c1f42fb60/image.png)
'Contact Contributions' and 'Contact Contributions 2' would be easier to use if you could add an optional label 'Completed contributions', 'Cancelled contributions', and then have those appear in the dropdown instead.
2. If you have several layers of joins, the titles get unwieldy. Those can be replaced by shorter, more meaningful labels.https://lab.civicrm.org/dev/core/-/issues/1172Mapping field schema inadequate2022-11-30T08:21:42ZeileenMapping field schema inadequateI've been digging into the import code in the hope of applying a similar combination of Iterate by Month & Leap by Extension as we have recently done for export.
In the course of the export UI work we established that if we separated th...I've been digging into the import code in the hope of applying a similar combination of Iterate by Month & Leap by Extension as we have recently done for export.
In the course of the export UI work we established that if we separated the building of the mapping out from the rest of the code then the form & the work engine only had to agree on that format to be upgraded separately. For export the format was pretty straight forward -ie. use the schema / api for MappingField & Mapping.
For import I've discovered a few issues with how the Mapping Fields currently store the import mappings
1) Labels - unlike the export fields, which sensibly store field names, the Import schema stores the field label into the 'name' field (obviously any renaming breaks it)
2) Soft credits = arg. The field mappings store this in the sort of way Cinderella's sisters got that slipper on... In the 'name' / label field the word 'Soft Credit' is stored. In the 'contact_type' field the identifier is stored (ie. contact_id, external_identifier, email). The 'soft credit type' can be configured via the UI but per https://lab.civicrm.org/dev/core/issues/654 is never saved...
I think it would be good to agree if mapping_field is the right place to store mappings - I'm inclined to think it is - but if so we probably want to extend the schema to support soft credits - probably in a slightly more generic way than just adding 'soft_credit_identifier' & 'soft_credit_type_id'...
It's worth also noting some of the things the current import DOES do for a user since the temptation to just replace it wholesale (which I don't think removes the 'how do we map' question) needs to be balanced against what it needs to do
- allows a range of date formats in import csv
- allows importing to a range of related contacts fields
- allows importing soft credits with a range of match criteria
- supports varied match criteria - eg. external_identifier, email, contact_id & for contribution trxn_id, invoice_reference
- provides a range of dedupe options & rule
- provides a range of matching - e.g matches to labels, values, state abbreviations
Does not
- allow you to choose whether 'empty' overwrites or is ignored
- allow you to specify a column value (ie. for everything in this import I want the source to be 'my import 2019' - potentially only if blank or for all fields). This can be done in the csv but ... users.https://lab.civicrm.org/dev/core/-/issues/300Proposal - Attach cross-cms "page identifier" class to <body>2022-11-30T05:03:31ZAkA84Proposal - Attach cross-cms "page identifier" class to <body>## Problem
Currently there is no consistent way in Civi to tell which page you are on by querying the DOM. Usually this is done by having a class attached to the `<body>` tag that identifies the current page. Unfortunately each CMS use d...## Problem
Currently there is no consistent way in Civi to tell which page you are on by querying the DOM. Usually this is done by having a class attached to the `<body>` tag that identifies the current page. Unfortunately each CMS use different naming conventions, or attaches no class at all.
For example: this is the Contact Summary page's `<body>` tag on each CMS
```html
<!-- Drupal: .page-civicrm-contact-view -->
<body class="html not-front ... page-civicrm page-civicrm-contact page-civicrm-contact-view">
<!-- Joomla: .task-civicrmcontactview -->
<body class="admin com_civicrm ... task-civicrmcontactview">
<!-- Wordpress: none :( -->
<body class="wp-admin wp-core-ui ... customize-support svg”>
```
## Proposed solution
Civi should attach "proprietary" classes to `<body>`, independent from the underlying cms, so we would have something like
```html
<!-- Drupal -->
<body class="html not-front ... page-civicrm page-civicrm-contact page-civicrm-contact-view civi-page-contact-view">
<!-- Joomla -->
<body class="admin com_civicrm ... task-civicrmcontactview civi-page-contact-view">
<!-- Wordpress -->
<body class="wp-admin wp-core-ui ... customize-support svg civi-page-contact-view”>
```
## Why
It would open new cross-cms customization avenues for devs: styles applied only a specific page, JS plugins that use the body class to bootstrap itself or perform an action only on certain pages, etc.
Of course currently one can already inject a css/js file on specific pages by using `hook_civicrm_pageRun()`, but this approach lacks the flexibility that the proposed solution would instead provide.
## Technical challenges
I figured that there would be at least two:
1. Find a way in all 3 cms to alter the list of classes attached to `<body>` that _doesn't_ involve using a theme hook, given that this solution should be both cms and theme agnostic (you don't want those classes to disappear the moment an admin decides to change the administration theme)
2. Figure out how to programmatically generate the class name for each individual civi page
---
Before opening the issue I asked in the dev channel if there was already a way to identify a page that I wasn't aware of (https://chat.civicrm.org/civicrm/pl/of6xsr17sidujmm1tuasr8bupy), but apparently there isn't, at least not the in the way I'm proposing herehttps://lab.civicrm.org/dev/core/-/issues/1141Remove deprecated SQL_CALC_FOUND_ROWS2022-11-30T05:03:30ZJoeMurrayRemove deprecated SQL_CALC_FOUND_ROWSMySQL has deprecated SQL_CALC_FOUND_ROWS https://dev.mysql.com/doc/refman/8.0/en/information-functions.html:
> The SQL_CALC_FOUND_ROWS query modifier and accompanying FOUND_ROWS() function are deprecated as of MySQL 8.0.17 and will be r...MySQL has deprecated SQL_CALC_FOUND_ROWS https://dev.mysql.com/doc/refman/8.0/en/information-functions.html:
> The SQL_CALC_FOUND_ROWS query modifier and accompanying FOUND_ROWS() function are deprecated as of MySQL 8.0.17 and will be removed in a future MySQL version. As a replacement, considering executing your query with LIMIT, and then a second query with COUNT(*) and without LIMIT to determine whether there are additional rows.
We should refactor to remove it from core in the following places:
>>>
$ grep -R SQL_CALC_FOUND_ROWS ./*
```php
./CRM/Core/BAO/CustomValueTable.php: $query = "SELECT SQL_CALC_FOUND_ROWS id, " . implode(', ', $clauses) . " FROM $tableName WHERE entity_id = $entityID {$orderBy} {$limit}";
./CRM/Core/BAO/PrevNextCache.php:SELECT SQL_CALC_FOUND_ROWS {$selectString}
./CRM/Contribute/BAO/ContributionSoft.php: SELECT SQL_CALC_FOUND_ROWS ccs.id, ccs.amount as amount,
./CRM/Case/BAO/Case.php: SELECT SQL_CALC_FOUND_ROWS COUNT(ca.id) AS ismultiple,
./CRM/Report/Form/Contribute/Sybunt.php: $getContacts = "SELECT SQL_CALC_FOUND_ROWS {$this->_aliases['civicrm_contact']}.id as cid {$this->_from} {$this->_where} GROUP BY {$this->_aliases['civicrm_contact']}.id {$this->_limit}";
./CRM/Report/Form/Contribute/Lybunt.php: SELECT SQL_CALC_FOUND_ROWS {$this->_aliases['civicrm_contact']}.id as cid {$this->_from}
./CRM/Report/Form/Contribute/Lybunt.php: $sql = str_replace('SQL_CALC_FOUND_ROWS', '', $sql);
./CRM/Report/Form/Contribute/Lybunt.php: $sql = "SELECT SQL_CALC_FOUND_ROWS * FROM ( $sql ) as inner_query {$this->_orderBy} $this->_limit";
./CRM/Report/Form/Contribute/History.php: $getContacts = "SELECT SQL_CALC_FOUND_ROWS {$this->_aliases['civicrm_contact']}.id as cid, SUM({$this->_aliases['civicrm_contribution']}.total_amount) as civicrm_contribution_total_amount_sum {$this->_from} {$this->_where} {$addWhere} GROUP BY {$this->_aliases['civicrm_contact']}.id {$this->_having} {$this->_limit}";
./CRM/Report/Form/Contribute/Detail.php: return "SELECT SQL_CALC_FOUND_ROWS * FROM {$this->temporaryTables['civireport_contribution_detail_temp3']['name']} $this->_orderBy $this->_limit";
./CRM/Report/Form/Contribute/Detail.php: $select = str_ireplace('SELECT SQL_CALC_FOUND_ROWS ', 'SELECT ', $this->_select);
./CRM/Report/Form/Contribute/TopDonor.php: $this->_select = preg_replace('/SELECT/', 'SELECT SQL_CALC_FOUND_ROWS ', $this->_select, 1);
./CRM/Report/Form.php: if (stristr($this->_select, 'SQL_CALC_FOUND_ROWS')) {
./CRM/Report/Form.php: $select = str_ireplace('SELECT SQL_CALC_FOUND_ROWS ', 'SELECT ', $this->_select);
./CRM/Report/Form.php: $this->_select = preg_replace('/SELECT(\s+SQL_CALC_FOUND_ROWS)?\s+/i', 'SELECT SQL_CALC_FOUND_ROWS ', $this->_select);
./CRM/Report/Form.php: $select = preg_replace('/SELECT(\s+SQL_CALC_FOUND_ROWS)?\s+/i', $select, $this->_select);
./tests/phpunit/api/v3/ReportTemplateTest.php: SELECT SQL_CALC_FOUND_ROWS contact_civireport.id as cid FROM civicrm_contact contact_civireport INNER JOIN civicrm_contribution contribution_civireport USE index (received_date) ON contribution_civireport.contact_id = contact_civireport.id
```
>>>Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/1156Do not delete associated contributions when membership is deleted2022-11-29T05:03:30ZStoobDo not delete associated contributions when membership is deletedBack in 2011 https://issues.civicrm.org/jira/browse/CRM-7188 it appears it was the intent to change the behavior of membership deletion to NOT delete associated contributions. This warning message was instituted as a work around but the...Back in 2011 https://issues.civicrm.org/jira/browse/CRM-7188 it appears it was the intent to change the behavior of membership deletion to NOT delete associated contributions. This warning message was instituted as a work around but the behavior change was apparently never implemented. I'd like to get some discussion and/or traction on finally implementing this change. Having discussed with @eileen @andrewhunt @JoeMurray @KarinG and BoT, I haven't found yet an opinion or a use case where the current behavior is desirable, but I don't want to assume that the community is unanimous in this reagard.
Input from others is welcome, I'm asking @colemanw @cividesk and any others who have run into this behavior for their thoughts and/or historical memory.
![delete-member](/uploads/2528146de59e3210bf7015eb726d036e/delete-member.jpg)https://lab.civicrm.org/dev/core/-/issues/451False duplicate relationship2022-11-26T20:59:12ZsamuelsovFalse duplicate relationshipIn our case, we use the description to define the job title so we want to have the history of the different job title over time. I see no reason why we couldn't have multiple inactive employer relationship with the same organisation and ...In our case, we use the description to define the job title so we want to have the history of the different job title over time. I see no reason why we couldn't have multiple inactive employer relationship with the same organisation and only one active at a time.
It's not possible to create 2 relationship of the same type with the same contacts even if the other one is disabled.
Message when creating a new SymbioTIC employer relationship on the contact (with an inactive relationship) :
![Screenshot_2018-10-17_-_duplicate](/uploads/9452f48ac111d4a31b479d6a6f8510b9/Screenshot_2018-10-17_-_duplicate.png)
On the other hand, if we have a start and/or end date on the relationship, the checkDuplicateRelationship doesn't consider it to be a duplicate.
Same as above but with a start date on the inactive relationship.
![Screenshot_2018-10-17_-_no_duplicate](/uploads/f74903c333c70638cf6ca5797b3e9cc5/Screenshot_2018-10-17_-_no_duplicate.png)
If we remove the start date from the inactive relationship, there is no warning so after all it's possible to do what we want but with some unnecessary steps.