Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-03-04T05:03:17Zhttps://lab.civicrm.org/dev/core/-/issues/1699Membership status changed automatically despite status override2023-03-04T05:03:17ZalainbMembership status changed automatically despite status overrideOverview
----------------------------------------
When you change the status of a contribution from Pending to Completed, it changes the status of a linked membership. This is OK for "normal memberships", but when the status override is ...Overview
----------------------------------------
When you change the status of a contribution from Pending to Completed, it changes the status of a linked membership. This is OK for "normal memberships", but when the status override is set to "override permanently", I don't expect CiviCRM to change the status.
As the online help describes: If you select "Override Permanently", the status you assign will remain in force.
Reproduction steps
----------------------------------------
1. go to the civi demo environment
1. select Russell Samson
1. delete his contribution
1. edit his membership:
1. set "status override" to "override permanently"
1. set "Membership status" to "current"
1. check "Record Membership Payment"
1. set "Payment Status" to "Pending"
1. click "save"
1. edit the contribution
1. change the "Contribution Status" from "Pending" to "Completed"
1. check the membership status: it was changed to "New". The override setting was not respected.
Expected behaviour
----------------------------------------
When "Status override" is set to "Override permanently", the status should not be changed by CiviCRM.
When it is set to "Override until Selected Date", the status should not be changed automatically if that date is in the future.seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/1698Upgrade script for 5.23 can fail if config_backend exists and logging is enabled2023-03-05T05:03:26ZDaveDUpgrade script for 5.23 can fail if config_backend exists and logging is enabledhttps://civicrm.stackexchange.com/questions/35302/stuck-upgrading-to-5-24-1-on-joomla
The upgrade script for https://github.com/civicrm/civicrm-core/pull/15842/files#diff-2cbb1d9cc3ea352d50c109fc5ec3efb1R87 uses the dropColumn utility f...https://civicrm.stackexchange.com/questions/35302/stuck-upgrading-to-5-24-1-on-joomla
The upgrade script for https://github.com/civicrm/civicrm-core/pull/15842/files#diff-2cbb1d9cc3ea352d50c109fc5ec3efb1R87 uses the dropColumn utility function https://github.com/civicrm/civicrm-core/blob/5.24.1/CRM/Upgrade/Incremental/Base.php#L236 but that function doesn't take log tables into account, so you can still have the column referenced in the trigger at the point where it then goes to update the version in civicrm_domain, which happens **before** the final Logging fixSchemaDifferences where it rebuilds. Note this is only a problem because config_backend is in the same civicrm_domain table. Otherwise the rebuild at the end handles it.https://lab.civicrm.org/dev/core/-/issues/1697set is_deceased to not null in schema and upgrade script2020-04-09T23:07:11ZMichael McAndrewset is_deceased to not null in schema and upgrade scriptOver the past few years, compelling evidence has has emerged to suggest that Zombies do exist in CiviCRM databases. Here are a couple of the most high profile cases:
- https://civicrm.org/extensions/zombie-check
- https://civicrm.org/bl...Over the past few years, compelling evidence has has emerged to suggest that Zombies do exist in CiviCRM databases. Here are a couple of the most high profile cases:
- https://civicrm.org/extensions/zombie-check
- https://civicrm.org/blog/simonparkervitiligosocietyorguk/solution-all-recipients-not-showing-up-for-sending-mass-email
Whilst various attempts have been made to eliminate the scourge of zombies once and for ever, the most notable of which being https://lab.civicrm.org/dev/core/-/blob/master/CRM/Upgrade/Incremental/sql/4.7.beta2.mysql.tpl#L15-17 ...
```sql
-- CRM-17147 People with empty deceased-flag ('is null') get removed from recipient list of a mailing
UPDATE civicrm_contact SET is_deceased = 0 WHERE is_deceased IS NULL;
ALTER TABLE civicrm_contact ALTER COLUMN is_deceased SET DEFAULT 0;
```
... it has come to light that Zombies persist across CiviCRM instances.
Although the upgrade script defaults all existing fields to 0, and new sites have a default of 0, this does not prevent the columns from being asssigned a null value.
:coffin: :cross:
PR here that alters the definition for new tables and adds another upgrade step: https://github.com/civicrm/civicrm-core/pull/170255.26.0https://lab.civicrm.org/dev/core/-/issues/1696Update attachment message on mailing form.2020-04-10T03:15:49ZjitendraUpdate attachment message on mailing form.The Attachment tab on the Mailing page displays a message on the screen to add new files. But there is no indication of the size of the file which could be attached here. Larger file attachments lead to failure in the mailing process and...The Attachment tab on the Mailing page displays a message on the screen to add new files. But there is no indication of the size of the file which could be attached here. Larger file attachments lead to failure in the mailing process and eventually results in not sending mails to the recipients.
![image](/uploads/ab7354a0ecb366409ce0994ee58b6471/image.png)
The above message should be displayed something like -
>Alternatively, you may add new files using drag/drop. Each file must be less than <max_size>M in size. For larger files, please upload it somewhere else and paste a link in the body of this mailing.
Normal email form do have this specified -
![image](/uploads/6534588f143cb4241497d62d7795fef1/image.png)5.26.0https://lab.civicrm.org/dev/translation/-/issues/43Ticket to collect steps needed when adding a new language2020-10-22T14:36:09ZDaveDTicket to collect steps needed when adding a new languageSorry if this is already documented somewhere. I found [this page](https://lab.civicrm.org/dev/translation/-/wikis/New-official-language) but it's about policies not procedures.
As I learned recently, when a new language is added to civ...Sorry if this is already documented somewhere. I found [this page](https://lab.civicrm.org/dev/translation/-/wikis/New-official-language) but it's about policies not procedures.
As I learned recently, when a new language is added to civicrm-core:master, future PR's against the RC or current release will fail test runs in a confusingly unrelated way. So at least at the moment one of the non-obvious steps is that the language needs to be backported. (UPDATE: not strictly needed now as of 2020-04-08.)
So while it's fresh in my head trying to gather the steps.
ref: https://lab.civicrm.org/dev/translation/-/issues/4
* Create the new translation of CiviCRM in transifex.
* If a language variant, sync it from another variant (jenkins script).
* Update [conf/distributed_languages.txt](https://lab.civicrm.org/dev/translation/-/blob/master/conf/distributed_languages.txt).
* Wait until the language appears in the daily l10n tarball.
* Update [xml/templates/languages.tpl](https://github.com/civicrm/civicrm-core/blob/master/xml/templates/languages.tpl), and then run bin/regen.sh which will update
* install/langs.php
* sql/civicrm_generated.mysql
* Make a core PR against master including those three files, and an upgrade script to add the option value.
* ~~Backport the PR to the RC and current (maybe - pending https://github.com/civicrm/civicrm-core/pull/17021).~~ 17021 was merged so it's not strictly necessary - lang will show as the code, e.g `(nl_BE)`, and is technically usable, until master becomes current.https://lab.civicrm.org/dev/core/-/issues/1695Upgrading to 5.24.1 custom field not saved for Case when submitted from webform2020-08-07T03:09:34ZPradeep Nayakpradpnayak@gmail.comUpgrading to 5.24.1 custom field not saved for Case when submitted from webformTo Replicate:
Create a webform and enable civicase with custom field. After submitting the webform a new case is created but the custom fields are blank.
This was working until 5.22.x and than update to DB/ packages in 5.23 broke this f...To Replicate:
Create a webform and enable civicase with custom field. After submitting the webform a new case is created but the custom fields are blank.
This was working until 5.22.x and than update to DB/ packages in 5.23 broke this functionality. This cannot be replicated when case is created from UI but can be replicated by writing code eg
```
$result = civicrm_api3('Case', 'create', [
'contact_id' => 202,
'case_type_id' => "housing_support",
'subject' => "test",
])['id'];
$cust = array(
'19' => array(
'-1' => array(
'id' => '',
'value' => '344',
'type' => 'Money',
'custom_field_id' => '19',
'custom_group_id' => '13',
'table_name' => 'civicrm_value_reportable_co_13',
'column_name' => 'reportable_cost_19',
'file_id' => '',
'is_multiple' => '0',
)
)
);
CRM_Core_BAO_CustomValueTable::store($cust, 'civicrm_case', $result);
```
Digging into the code found that the entry civicrm_value_reportable_co_13 table does get created but isn't shown. I guess this is because the transaction is started but not committed. Below patch fixes my problem (which removes Transaction code) but I guess its not ideal solution.
```
diff --git a/Civi/CCase/Events.php b/Civi/CCase/Events.php
index 114875f17e..f76c92c267 100644
--- a/Civi/CCase/Events.php
+++ b/Civi/CCase/Events.php
@@ -78,12 +78,10 @@ class Events {
public static function fireCaseChangeForRealz($caseIds) {
foreach ((array) $caseIds as $caseId) {
if (!isset(self::$isActive[$caseId])) {
- $tx = new \CRM_Core_Transaction();
self::$isActive[$caseId] = 1;
$analyzer = new \Civi\CCase\Analyzer($caseId);
\CRM_Utils_Hook::caseChange($analyzer);
unset(self::$isActive[$caseId]);
- unset($tx);
}
}
}
```5.24.2https://lab.civicrm.org/dev/core/-/issues/1694Sending Emails Using The Email Activity Form Does Not Replace Case Tokens2020-04-07T14:37:06Ztunbola@compucorp.co.ukSending Emails Using The Email Activity Form Does Not Replace Case TokensOverview
----------------------------------------
The Activity Email Form at `civicrm/activity/email/add` accepts the caseid parameter which allows the case tokens to be available for the Email form. However these case tokens does not ge...Overview
----------------------------------------
The Activity Email Form at `civicrm/activity/email/add` accepts the caseid parameter which allows the case tokens to be available for the Email form. However these case tokens does not get replaced with the actual case values for these tokens and the sent email contain these tokens in the raw form without being replaced.
Reproduction steps
----------------------------------------
- Add a new Email activity for a case using the URL: `civicrm/activity/email/add?action=add&caseid=18&atype=3&reset=1&cid=2` For valid contact Id and case Id.
- Add the email subject and body and use case tokens in the subject and body of the email.
- Send the email
![adminexample.com_Civi_Awards_-_Email__CiviAwards_2020-04-07_13-44-30](/uploads/d52ca4f7326746c3fc91f32859f151d5/adminexample.com_Civi_Awards_-_Email__CiviAwards_2020-04-07_13-44-30.png)
Current behaviour
----------------------------------------
The Email gets sent but the case tokens does not get replaced
![Mailtrap_-_Safe_Email_Testing_2020-04-07_13-52-52](/uploads/7db3d048ab037c1f756ffdc6037a55e9/Mailtrap_-_Safe_Email_Testing_2020-04-07_13-52-52.png)
Expected behaviour
----------------------------------------
When adding an email activity for a case and the email gets sent, the case tokens added in the email should be replaced with the correct case values for the given Case ID.https://lab.civicrm.org/dev/core/-/issues/1693allow inline help text title to be overriden2020-04-14T15:08:10Zlcdweballow inline help text title to be overridenExtend the intent of this PR -- to support overriding the inline help text title too.
https://github.com/civicrm/civicrm-core/pull/13488/filesExtend the intent of this PR -- to support overriding the inline help text title too.
https://github.com/civicrm/civicrm-core/pull/13488/fileslcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/1692Case Details field is empty2020-04-07T00:22:14Zivan_compucorpCase Details field is emptyOverview
----------------------------------------
When user creates new case using core form (non webform) the details field value is not saved (respective field of civicrm_case table is empty).
Reproduction steps
----------------------...Overview
----------------------------------------
When user creates new case using core form (non webform) the details field value is not saved (respective field of civicrm_case table is empty).
Reproduction steps
----------------------------------------
1. Go to **Cases -> New Case**.
1. Fill in all the fields, including **Details** and click **Save**.
1. Case entity is created, but **Details** are emtpy.
Current behaviour
----------------------------------------
![case-details](/uploads/70934a3fc5c5460f2898b78056bb615e/case-details.gif)
Expected behaviour
----------------------------------------
The **Details** field of case entity should have a value.
Environment information
----------------------------------------
* __CiviCRM:__ 5.19.4
* __PHP:__ 7.3
* __CMS:__ Drupal 7.69
* __Database:__ MySQL 5.7.295.26.0https://lab.civicrm.org/dev/core/-/issues/1691Activity.get with custom field in return parameter returns unrelated custom f...2023-03-02T05:03:20ZPatrick Figelpfigel@greenpeace.orgActivity.get with custom field in return parameter returns unrelated custom fields in APIv3This is a rather obscure bug we hit recently, and while I don't think it's worth fixing at this point in the APIv3 lifecycle, I'm documenting it here in case anyone else runs into it.
In APIv3, when a custom field is requested via the `...This is a rather obscure bug we hit recently, and while I don't think it's worth fixing at this point in the APIv3 lifecycle, I'm documenting it here in case anyone else runs into it.
In APIv3, when a custom field is requested via the `return` parameter, Civi will also return other custom fields if they have a default value set. This includes cases where the custom field is not enabled for the relevant activity type and where the relevant activity doesn't actually have a record in the corresponding custom field table.
We have code that roughly looks like this:
```php
civicrm_api3('Activity', 'get', [
'return' => ['id', 'custom_39'],
'id' => 631,
]);
```
On the same installation, there's another custom field group that is not enabled for the associated activity type. This field group has a custom field - `custom_40` - with a default value set. The following API result is produced:
```json
{
"is_error": 0,
"version": 3,
"count": 1,
"id": 631,
"values": [
{
"id": "631",
"custom_39": "bar",
"source_contact_id": "203",
"source_contact_name": "demo@example.com",
"source_contact_sort_name": "demo@example.com",
"custom_40": "2",
"custom_40_-1": "2"
}
]
}
```
(In our case, the results were modified and later passed back into an `Activity.create` API call. This has the side-effect of actually creating a database row for an activity-type-limited custom field group, which is arguably kind of a bug as well.)
None of this behaviour applies to APIv4, so I'm happy to leave this as-is.https://lab.civicrm.org/dev/core/-/issues/1690Multiple scheduled reminders per contact when scheduled job fails2023-03-11T05:03:20ZMartinMultiple scheduled reminders per contact when scheduled job failsOverview
----------------------------------------
We're seeing scheduled reminders occurring more than once. In our case we have reminders set up before expiry of memberships (e.g. 7 days before). In some cases when we look at the activi...Overview
----------------------------------------
We're seeing scheduled reminders occurring more than once. In our case we have reminders set up before expiry of memberships (e.g. 7 days before). In some cases when we look at the activities for a contact, there are multiple entries for a reminder (all with status "completed"). For a given contact these show up once per cron run, for multiple subsequent cron intervals (i.e. 1 activity each hour for multiple hours in a row).
These occurrences coincide with failures of the send_reminder scheduled job. Looking at the job log shows this result:
```
Entity: Job Action: send_reminder
Summary
Finished execution of Scheduled reminders sender with result: Failure, Error message: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
Details
Parameters parsed (and passed to API method):
a:1:{s:7:"version";i:3;}
Full message:
Finished execution of Scheduled reminders sender with result: Failure, Error message: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
```
It appears when this failure happens for the scheduled job, the contact still get an activity for their scheduled reminder, and they continue to do so each cron run (in our case this scheduled job is set to be hourly), until the job shows a success (at this point is the last activity they get).
Looking at the code in CRM_Core_BAO_ActionSchedule it appears that the email is sent (sendReminderEmail) before the activity is created (createMailingActivity), so I expect the contact has in fact received multiple emails, NOT that multiple activities were created without emails being sent.
Without digging further, I'm guessing maybe civi considers ALL reminders have failed in the batch if the scheduled job fails, even if some were sent out and the job failed partway through.
Reproduction steps
----------------------------------------
In our case the "MySQL server has gone away" db error appears to be causing this, which of course is a problem unto itself, but would be preferable if Civi could handle this situation better.
Current behavior
----------------------------------------
Contact receives multiple emails and activity entries when only 1 should occur. They are getting n+1 of these, where n is the number of times the scheduled job fails.
Expected behavior
----------------------------------------
It would be preferable for only 1 email to be sent to each contact, and that if the job fails, only the unsent emails are then sent later.
Contacts should only get 1 email reminder, and 1 "completed" activity. Maybe they should also get other activities for the failed cron runs with another status such as "failed" or "cancelled", but that probably doesn't matter much either way.
Environment information
----------------------------------------
* __CiviCRM:__ 5.23.0
* __PHP:__ 7.2.29
* __CMS:__ Drupal 7.69
* __Database:__ MySQL 5.7.29https://lab.civicrm.org/dev/joomla/-/issues/27CiviCRM menus disappear in Joomla after 5.24.x upgrade2020-04-13T10:35:47ZspalmstromCiviCRM menus disappear in Joomla after 5.24.x upgradeUnder Joomla, the CiviCRM menus disappear after upgrading to 5.24.x.Under Joomla, the CiviCRM menus disappear after upgrading to 5.24.x.https://lab.civicrm.org/dev/core/-/issues/1689Database upgrade for 5.24.0 hangs2020-04-07T00:22:30ZphilmckDatabase upgrade for 5.24.0 hangsTwo of the four sites I tried to upgrade to CiviCRM 5.24.0 last night (from 5.23.3) failed and had to be rolled back. All four sites run on WordPress 5.4, PHP 7.3, Ubuntu 18.04 so I'm not sure why some succeeded and others failed. There'...Two of the four sites I tried to upgrade to CiviCRM 5.24.0 last night (from 5.23.3) failed and had to be rolled back. All four sites run on WordPress 5.4, PHP 7.3, Ubuntu 18.04 so I'm not sure why some succeeded and others failed. There's some difference in extensions but there are many permutations there and I haven't had time to go through them.
In each of the failure cases I deleted the /wp-content/plugins/civicrm folder and replaced it with the Civi 5.24.0 files and the I10n files. Then I deleted /wp-content/uploads/civicrm/templates_c, went to Administer > Administration Console > System Status and saw the expected red warning that a database update was needed. Clicked on that and saw the usual progress bar which got about half-way across and then stopped progressing. I came back about half an hour later and it was still hung, tried to refresh the page without success, went back to the status page and it said a database update was incomplete and to restore from a backup and try again. I did that, but the results were the same.5.24.1https://lab.civicrm.org/dev/drupal/-/issues/116D8 and localization files2020-04-03T16:31:28ZRob_SD8 and localization filesHi. Can someone advise me please how to install the localization files on a D8 Civi install that was set up using the Roundearth method?Hi. Can someone advise me please how to install the localization files on a D8 Civi install that was set up using the Roundearth method?https://lab.civicrm.org/dev/core/-/issues/1688[regression] CiviCRM reports smart groups won't work due to deleted custom fi...2020-04-07T00:23:20ZJonGold[regression] CiviCRM reports smart groups won't work due to deleted custom fields that aren't deletedAny smart group based on at least one custom field that allows multiple selections (checkboxes, multi-select, etc.) will incorrectly show as having a deleted custom field in the `CRM_Utils_Check_Component_Schema::checkSmartGroupCustomFie...Any smart group based on at least one custom field that allows multiple selections (checkboxes, multi-select, etc.) will incorrectly show as having a deleted custom field in the `CRM_Utils_Check_Component_Schema::checkSmartGroupCustomFieldCriteria()` check.
To replicate on the demo site:
* Create a new custom field with Input Field Type of checkbox (see screenshot). Make the field searchable.
* Populate this value for at least one contact (you can't create a search group if no contacts are found).
* Using Advanced Search, search for the custom value you just created.
* Create a Smart Group.
* Run the API `System.check` (or visit the System Status page).
### Expected Result
The newly created smart group should not report a deleted custom field.
### Actual result
¯\\_(ツ)_/¯
I'm not sure how best to handle this without regex...so I'll submit a patch with regex and let smarter heads decide if that's acceptable.
![Selection_866](/uploads/dd70ae5400aba1c6c9bdd29885f44abe/Selection_866.png)5.24.1JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1687Default from email address on multisite not restricted to its domain2023-03-03T05:03:27ZandyburnsDefault from email address on multisite not restricted to its domain## Overview
After upgrading to 5.23.4 on multisite the from email address does not respect the domain ID. However we used to see this occur and I think it was resolved prior by saving the default from email address on the right domain a...## Overview
After upgrading to 5.23.4 on multisite the from email address does not respect the domain ID. However we used to see this occur and I think it was resolved prior by saving the default from email address on the right domain although I cannot be sure. After clearing cache with cv flush whichever domain ID I go to first shows 'correctly' but then that would be the default from email address shown on any other domain I'd go to subsequently. So it looks like a caching issue. Very similar to https://lab.civicrm.org/dev/core/-/issues/1677.
## Reproduction steps
1. Run cv flush
1. Go to a contact with an email
1. Click actions > send email
1. You'll see the correct from email address for the domain you first test on.
1. Go to another domain and run steps 2-3 and it will be the same default from email address in step 4. Repeats on all other domains.
## Current behaviour
Default from email address is not respected.
## Expected behaviour
You should only see from email address of the organization domain when sending an email.https://lab.civicrm.org/dev/translation/-/issues/42Document guidelines for situations where trivial technical changes do more ha...2020-04-02T13:28:24ZDaveDDocument guidelines for situations where trivial technical changes do more harm than goodMoved to gitlab from https://github.com/civicrm/civicrm-dev-docs/pull/754
The [end-to-end process](https://lab.civicrm.org/dev/translation/-/wikis/Pushing-new-strings-to-transifex) from the time you make a change in the code to when the...Moved to gitlab from https://github.com/civicrm/civicrm-dev-docs/pull/754
The [end-to-end process](https://lab.civicrm.org/dev/translation/-/wikis/Pushing-new-strings-to-transifex) from the time you make a change in the code to when the translation of it ends up in the tarball of a release is lengthy, depends on human translators' time, and currently includes a [manual tedious step](https://lab.civicrm.org/infra/ops/-/issues/931) for administrators (which means it doesn't even get to transifex to be made available to translators for a few months). In the meantime the string you just changed has now potentially become untranslated immediately in all languages in both master and likely still untranslated when it becomes a release candidate. And possibly for several releases/months after.
So if the wording is not preventing users from completing tasks and the technical functionality is working, then is having it be EXACTLY right worth invalidating an existing translation and generating another end-to-end cycle of the translation process *if that is the only change being made*. It seems like it is possible to write out some guidelines and examples.
The PR proposed these as a starting point:
#### Don't change
```smarty
{ts 1="https://www.example.org"}This is a block of text where the wording is fine and the link works but the <a href="%1" target="_blank">link attributes</a> should be a parameter to the ts. But it's not preventing anyone completing their work tasks and isn't confusing to users.{/ts}
```
#### Do change
* If it would normally break translation but the new string is already used somewhere else, and so it's already translated.
* Spelling mistakes. While not preventing a user from completing a task, the positives outweigh the negatives, and this is visible to the user, as compared to the above "don't change" example where the user doesn't see a problem.https://lab.civicrm.org/dev/user-interface/-/issues/16"Default Language for contacts" has no influence on the "Preferred Language" ...2020-04-06T04:58:28ZBenedikt"Default Language for contacts" has no influence on the "Preferred Language" option when creating a new contactWhen creating a new contact the "Preferred Language" option is always set to the default language, even if "Default Language for contacts" is set to "Leave undefined". One has to explicitly remove the default language for it to be undefi...When creating a new contact the "Preferred Language" option is always set to the default language, even if "Default Language for contacts" is set to "Leave undefined". One has to explicitly remove the default language for it to be undefined after creation.
Steps to reproduce:
* Under *civicrm/admin/setting/localization* set "Default Language for contacts" to "Leave undefined".
* Create a new contact.
* Under "Communication Preferences" the option "Preferred Language" is set to the default language.
Expected behaviour:
* The "Preferred Language" option is empty (undefined) when "Default Language for contacts" is "Leave undefined".
CiviCRM versions (at least):
* 5.19.4
* masterhttps://lab.civicrm.org/dev/core/-/issues/1686Export via membership dashboard exports all contacts in db, not the selection2020-04-04T21:59:08ZwannesderoyExport via membership dashboard exports all contacts in db, not the selectionOverview
----------------------------------------
If we go to CiviMember dashboard on /civicrm/member and click on one of the numbers in the last column of the table of memberships. We get a list of all the contacts with that active memb...Overview
----------------------------------------
If we go to CiviMember dashboard on /civicrm/member and click on one of the numbers in the last column of the table of memberships. We get a list of all the contacts with that active membership. But if we want to export this list by selecting the "all xxxx contacts" radio button and running the export action in the dropdown we eventually get a csv export of all our contacts in civicrm. Not just the selection we just made.
I also noticed that on the result list in the search criteria fieldset there is nothing prefilled. Maybe this is why our selection does not appear to work.
Reproduction steps
----------------------------------------
1. go to CiviMember dashboard on /civicrm/member
2. click on one of the numbers in the last column of the table of memberships
3. select the "all xxxx contacts" radio button
4. run the export action in the dropdown.
5. select the primary fields option (but the same happens if you select some fields)
6. run export
Current behaviour
----------------------------------------
This results in a csv of all the contacts in CiviCRM.
Expected behaviour
----------------------------------------
We should get a csv of the selection we just made.
Environment information
----------------------------------------
* __Browser:__ _Chrome 80.0.3987.149_
* __CiviCRM:__ _tested on 5.21.2 and 5.23.4_
* __PHP:__ _7.2.26__
* __CMS:__ _Drupal 8.8.1_
* __Database:__ _MySQL 5.7.23_
* __Web Server:__ _nginx/1.16.1_5.24.0https://lab.civicrm.org/dev/core/-/issues/1685Search builder returns DB error on Group => Empty condition2023-03-02T05:03:19ZjitendraSearch builder returns DB error on Group => Empty conditionTo replicate -
- Navigate to Search builder https://dmaster.demo.civicrm.org/civicrm/contact/search/builder?reset=1
- Select Contacts => Groups => Is Empty/Not Empty and submit the form
![image](/uploads/fce63047e006afea0cf8073b5411d18...To replicate -
- Navigate to Search builder https://dmaster.demo.civicrm.org/civicrm/contact/search/builder?reset=1
- Select Contacts => Groups => Is Empty/Not Empty and submit the form
![image](/uploads/fce63047e006afea0cf8073b5411d183/image.png)
returns -
![image](/uploads/65560a6e4fb16a62f9f9a452f4f5aa32/image.png)