Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-06-08T18:04:44Zhttps://lab.civicrm.org/dev/core/-/issues/4240Cannot set Entityref fields via APIv4 Explorer - on multi-value data2023-06-08T18:04:44ZAndrew WestCannot set Entityref fields via APIv4 Explorer - on multi-value dataOverview
----------------------------------------
Adding EntityRef data in APIv4 explorer fails on multi-value data, because validation in CRM_Utils_Type doesn't support EntityRef.
Reproduction steps
-----------------------------------...Overview
----------------------------------------
Adding EntityRef data in APIv4 explorer fails on multi-value data, because validation in CRM_Utils_Type doesn't support EntityRef.
Reproduction steps
----------------------------------------
1. Create a multi-value data set for all Individuals
2. Add an EntityRef field linked to Activities
3. Try to set it via the APIv4 Explorer
As of this second this is failing on the WP Demo site:
https://wpmaster.demo.civicrm.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fapi4#/explorer/Custom_Test_Multi/create?values=%5B%5B%22entity_id%22,%2256%22%5D,%5B%22Test_EntityRef_on_Multi%22,%22459%22%5D%5D
![image](/uploads/ae4edfeeabbdbf601725271349774929/image.png)
Current behaviour
----------------------------------------
There's one error in CRM_Utils_Type::escape() and two in CRM_Utils_Type::validate()
**CRM_Utils_Type::escape**
Just needs EntityReference added to the switch statement (I think)
**CRM_Utils_Type::validate**
Needs EntityReference added to $possibleTypes (I think)
Needs a case added for EntityReference. This works as a temporary workaround:
```
case 'EntityReference':
// null is valid
if (strlen(trim($data)) == 0) {
return trim($data);
}
return (int) $data;
```
But presumably it needs some kind of validation like happens in ContactReference:
```
case 'ContactReference':
// null is valid
if (strlen(trim($data)) == 0) {
return trim($data);
}
if (CRM_Utils_Rule::validContact($data)) {
return (int) $data;
}
break;
```
Environment information
----------------------------------------
Replicated on 5.60 and 5.62alpha15.61.0https://lab.civicrm.org/dev/core/-/issues/4090Managed Entity reconciliation fails if entity exists without Managed entity2023-06-08T16:37:28Zaydunsaidan.saunders@squiffle.ukManaged Entity reconciliation fails if entity exists without Managed entityOverview
----------------------------------------
Follow along now: "Managed Entities" involve both a `Managed` entity and the entity being managed. If the managed entity exists but the corresponding `Managed` entity does not, errors a...Overview
----------------------------------------
Follow along now: "Managed Entities" involve both a `Managed` entity and the entity being managed. If the managed entity exists but the corresponding `Managed` entity does not, errors are thrown.
For example, if an extension provides a `.mgd.php` file specifying a `PaymentProcessorType` entity, the reconciliation process will create the `PaymentProcessorType` entity and a `Managed` entity and then manage updates or deletion when the extension is updated or uninstalled.
In some (unknown) circumstances, the `Managed` entity does not exist but the managed (eg `PaymentProcessorType`) entity does exist. `CRM_Core_ManagedEntities::reconcile()` does not check for the existence of the `PaymentProcessorType` entity and so attempts to create a duplicate which fails. This happens any time a cache clear occurs.
Reproduction steps
----------------------------------------
I don't know how this has occurred on live systems, but to simulate:
1. Install Stripe (or other extension with `.mgd.php`)
2. Delete the `Managed` entity for Stripe: `cv api4 Managed.delete +w 'name = "Stripe"'`
3. `cv flush`
Current behaviour
----------------------------------------
```
$ cv flush
Flushing system caches
Error: API Call Failed: Array
(
[entity] => System
[action] => flush
[params] => Array
(
[debug] => 1
[version] => 3
)
[result] => Array
(
[trace] => #0 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(192): CRM_Core_ManagedEntities->onApiError()
#1 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(152): CRM_Core_ManagedEntities->insertNewEntity()
#2 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(113): CRM_Core_ManagedEntities->reconcileEntities()
#3 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php(417): CRM_Core_ManagedEntities->reconcile()
#4 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/api/v3/System.php(33): CRM_Core_Invoke::rebuildMenuAndCaches()
#5 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_system_flush()
#6 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(158): Civi\API\Provider\MagicFunctionProvider->invoke()
#7 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest()
#8 /opt/buildkit/build/dmaster/web/sites/all/modules/civicrm/api/api.php(22): Civi\API\Kernel->runSafe()
#9 phar:///opt/buildkit/bin/cv/src/Command/BaseCommand.php(63): civicrm_api()
#10 phar:///opt/buildkit/bin/cv/src/Command/FlushCommand.php(37): Civi\Cv\Command\BaseCommand->callApiSuccess()
#11 phar:///opt/buildkit/bin/cv/vendor/symfony/console/Command/Command.php(255): Civi\Cv\Command\FlushCommand->execute()
#12 phar:///opt/buildkit/bin/cv/vendor/symfony/console/Application.php(1009): Symfony\Component\Console\Command\Command->run()
#13 phar:///opt/buildkit/bin/cv/vendor/symfony/console/Application.php(273): Symfony\Component\Console\Application->doRunCommand()
#14 phar:///opt/buildkit/bin/cv/src/Application.php(82): Symfony\Component\Console\Application->doRun()
#15 phar:///opt/buildkit/bin/cv/vendor/symfony/console/Application.php(149): Civi\Cv\Application->doRun()
#16 phar:///opt/buildkit/bin/cv/src/Application.php(49): Symfony\Component\Console\Application->run()
#17 phar:///opt/buildkit/bin/cv/bin/cv(27): Civi\Cv\Application::main()
#18 /opt/buildkit/bin/cv(14): require('phar:///opt/bui...')
#19 {main}
[is_error] => 1
[error_message] => API error: DB Error: already exists on PaymentProcessorType.create( entity name Stripe)
)
)
```
Expected behaviour
----------------------------------------
No error - or at least a helpful error message.
I think `reconcile()` could just create the missing `Managed` entity but there may be other ramifications of doing that.
Environment information
----------------------------------------
* __CiviCRM:__ _Master_
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/2274Feature request: Include a "Aggregate Amount Filter" for "Top donor" report2023-06-08T05:03:23ZtapashFeature request: Include a "Aggregate Amount Filter" for "Top donor" reportI think the report does what it should but I was think would be a great addition to include a "Aggregate Amount Filter" for "Top donor" report.I think the report does what it should but I was think would be a great addition to include a "Aggregate Amount Filter" for "Top donor" report.https://lab.civicrm.org/dev/core/-/issues/4345SearchKit: Escaped text appearing in dropdown2023-06-08T03:10:06ZcstoneSearchKit: Escaped text appearing in dropdownOverview
----------------------------------------
Not sure if this is a bug or a feature, but the top two fields show up as escaped, the ones under them all look fine.
![friendlyescaping](/uploads/87f99e4f8f53f8fa2f6f573c92679303/friend...Overview
----------------------------------------
Not sure if this is a bug or a feature, but the top two fields show up as escaped, the ones under them all look fine.
![friendlyescaping](/uploads/87f99e4f8f53f8fa2f6f573c92679303/friendlyescaping.png)
{ts escape="sql"}Recurring Frequency Units{/ts}
The full HTML is:
`<div class="select2-result-label" id="select2-result-label-1943" role="option" title="{ts escape="sql"}Recurring Frequency Units{/ts}">{ts escape="sql"}Recurring Frequency Units{/ts}<div class="crm-select2-row-description"><p>{ts escape="sql"}Recurring Frequency Units{/ts}</p></div></div>`
Reproduction steps
----------------------------------------
1. I chose the searches in the screenshot above.
Current behaviour
----------------------------------------
It is displaying the first two options escaped.
Expected behaviour
----------------------------------------
The <ts> doesn't show up on the drop down.
Environment information
----------------------------------------
* __CiviCRM:__ 5.61.beta1https://lab.civicrm.org/dev/core/-/issues/4343SearchKit: Directive Filters can fail with non-privileged user2023-06-07T09:56:20ZJonGoldSearchKit: Directive Filters can fail with non-privileged userIt's possible to get a "Authorization Failed" error as a non-privileged user, even when ACL bypass is enabled. It requires you filter on an entity that has a `labelField` defined in the XML schema.
Steps to replicate:
Import the SK/Aff...It's possible to get a "Authorization Failed" error as a non-privileged user, even when ACL bypass is enabled. It requires you filter on an entity that has a `labelField` defined in the XML schema.
Steps to replicate:
Import the SK/Afform below. Or manually:
* Create a SK query of an entity that contains a labelField. "Countries" works well. No added WHERE, columns, etc. are necessary.
* Create a table display of this SK query. Enable ACL bypass.
* Create an Afform of the table display. Give it a path, make accessible on the front end, use a permission available to anonymous users (e.g. "make online contributions").
* On the second tab of the Afform, add a filter on the id, getting it from the URL.
---
* Once you have the afform in place, visit it as both an admin and anonymous user, both with and without filters.
Admin users get all results without a filter, and a single result with a filter.
Anonymous users can (correctly) get all results without a filter, but adding a filter results in an "Authorization failed" error on the API call.
This happens because there's an API call made where `checkPermissions` is set to whether the SK query should check permissions, but doesn't consider whether an ACL bypass is in place.
```json
[
[
"SavedSearch",
"save",
{
"records": [
{
"name": "d2_test",
"label": "d2 test",
"form_values": null,
"mapping_id": null,
"search_custom_id": null,
"api_entity": "Country",
"api_params": {
"version": 4,
"select": [
"id",
"name"
],
"orderBy": [],
"where": [],
"groupBy": [],
"join": [],
"having": []
},
"expires_date": null,
"description": null
}
],
"match": [
"name"
]
}
],
[
"SearchDisplay",
"save",
{
"records": [
{
"name": "d2_test_Table_1",
"label": "d2 test Table 1",
"saved_search_id.name": "d2_test",
"type": "table",
"settings": {
"description": null,
"sort": [],
"limit": 50,
"pager": [],
"placeholder": 5,
"columns": [
{
"type": "field",
"key": "id",
"dataType": "Integer",
"label": "Country ID",
"sortable": true
},
{
"type": "field",
"key": "name",
"dataType": "String",
"label": "Country",
"sortable": true
}
],
"actions": true,
"classes": [
"table",
"table-striped"
]
},
"acl_bypass": true
}
],
"match": [
"name",
"saved_search_id"
]
}
],
[
"Afform",
"save",
{
"records": [
{
"name": "afsearchD2TestAfform",
"requires": [],
"title": "d2 test afform",
"description": "",
"is_dashlet": false,
"is_public": true,
"is_token": false,
"permission": "make online contributions",
"type": "search",
"icon": "fa-list-alt",
"server_route": "civicrm/d2",
"entity_type": null,
"join_entity": null,
"contact_summary": null,
"summary_contact_type": null,
"redirect": null,
"create_submission": null,
"navigation": null,
"layout": "<div af-fieldset=\"\">\n <crm-search-display-table search-name=\"d2_test\" display-name=\"d2_test_Table_1\" filters=\"{id: routeParams.id}\"></crm-search-display-table>\n</div>\n"
}
]
}
]
]
```JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2253Proposal: API4 should add `IS NULL` to `!=` queries2023-06-07T05:03:24ZJonGoldProposal: API4 should add `IS NULL` to `!=` queriesAndrew Hunt named this problem [in a blog post](https://civicrm.org/extensions/zombie-check) a while back - the database schema often allows `NULL` where a reasonable person would assume that is identical to `FALSE`. Most notably with `...Andrew Hunt named this problem [in a blog post](https://civicrm.org/extensions/zombie-check) a while back - the database schema often allows `NULL` where a reasonable person would assume that is identical to `FALSE`. Most notably with `is_deceased`, but there are lots of other places in the schema.
As we move Search Kit into mainstream use, we're going to run into problems where common sense and SQL disagree.
Consider the search kit results for "Prefix is Mr." and "Prefix is not Mr.". An end user would expect the sum of both of those to be everyone in the database. However, anyone without a prefix is excluded.
At first I thought the answer was an overhaul of the schema - but there's simply too many instances where `0` and `NULL` mean two different things.
I propose that when the "not equals" operator is used, we should add `OR <field> IS NULL`. I'm not sure whether an `OR` here breaks indexing but this seems like it's going to become a much more frequent complaint soon.https://lab.civicrm.org/dev/core/-/issues/4330API4 error "Column in order clause is ambiguous"2023-06-07T00:21:50ZsamuelsovAPI4 error "Column in order clause is ambiguous"I have a specific query that used to work but seems to be broken since around CiviCRM 5.60.
I was able to reproduced in master.
This is the api4 call:
```php
$addresses = \Civi\Api4\Address::get()
->addJoin('Contact AS contact', 'LEF...I have a specific query that used to work but seems to be broken since around CiviCRM 5.60.
I was able to reproduced in master.
This is the api4 call:
```php
$addresses = \Civi\Api4\Address::get()
->addJoin('Contact AS contact', 'LEFT', ['master_id.contact_id', '=', 'contact.id'])
->addOrderBy('location_type_id:label', 'ASC')
->setLimit(25)
->execute();
```
`location_type_id` is in Address and as it it doing a join for another address to get the master_id address, it is ambiguous.
Looking at the generated query, we can see that the table prefix is not added in the order by :
```sql
SELECT `a`.`id` AS `id`, `contact`.`display_name` AS `contact.display_name`
FROM civicrm_address a
LEFT JOIN `civicrm_address` `master_id_1` ON `a`.`master_id` = `master_id_1`.`id`
LEFT JOIN `civicrm_contact` `contact` ON `master_id_1`.`contact_id` = `contact`.`id`
ORDER BY FIELD(`location_type_id`,'16','14','1','19','3','15','4','12','2','17','18','20','21','5','11') ASC;
```
Giving the error :
```
ERROR 1052 (23000): Column 'location_type_id' in order clause is ambiguous
```https://lab.civicrm.org/dev/core/-/issues/2260Can't set more than one bulk email even when the setting to allow more than o...2023-06-06T05:03:19ZDaveDCan't set more than one bulk email even when the setting to allow more than one is turned onI don't have a stake in this it just came up while reviewing a PR. It might be a good one for a newcomer to look at.
1. Administer - CiviMail - CiviMail Component Settings.
1. Turn on "Enable multiple bulk email address for a contact".
...I don't have a stake in this it just came up while reviewing a PR. It might be a good one for a newcomer to look at.
1. Administer - CiviMail - CiviMail Component Settings.
1. Turn on "Enable multiple bulk email address for a contact".
1. Edit a contact with 2 email addresses. Don't use inline editing use the full edit form. It works ok with the inline editing.
1. Try to set both emails to be bulk email (using the UI).
Since it works with inline, my guess is there's different javascript being loaded for the two forms, so maybe it's as simple as having the right javascript load. I haven't looked.https://lab.civicrm.org/dev/core/-/issues/1214Suggest to add a system status check that checks if trigger/view definer is t...2023-06-06T05:03:18ZDaveDSuggest to add a system status check that checks if trigger/view definer is the same db user as in civicrm_settings.phpIt comes up semi-regularly for people who are moving sites around or setting up staging/live where the trigger/view definer is the db user on the other site, and so errors happen. A system status check could point this out and point you ...It comes up semi-regularly for people who are moving sites around or setting up staging/live where the trigger/view definer is the db user on the other site, and so errors happen. A system status check could point this out and point you to the link to rebuild triggers. I don't think it should do it automatically because there might be a legit reason you purposely made them different, although that does seem unlikely for a civi site.
I can add this to my rainy-day todo list. It's just not going to be at the top.https://lab.civicrm.org/dev/core/-/issues/4337Dedupe using length doesn't appear to be working2023-06-05T21:12:43ZStoobDedupe using length doesn't appear to be workingTo reproduce on dmaster
1. create a rule that checks email, postal code, or street address on first X characters
2. run dedupe rule and see random (or perhaps name dedupe) certainly not by email
This is [how 'length' feature in dedupe i...To reproduce on dmaster
1. create a rule that checks email, postal code, or street address on first X characters
2. run dedupe rule and see random (or perhaps name dedupe) certainly not by email
This is [how 'length' feature in dedupe is documented](https://docs.civicrm.org/user/en/latest/common-workflows/deduping-and-merging/#configuring-rules) pretty clear it is intended to work this way, and IIRC worked as recently as two years ago @eileen please tag as regression if appropriate
![rule](/uploads/cdbcfacd21f3bc646ccabb9a073c4125/rule.png)
![f](/uploads/f221b72a0c1d1a8f816bf1bba330f1fa/f.png)
![result](/uploads/8ac18e3fcd72de10404db512356b0357/result.png)https://lab.civicrm.org/dev/core/-/issues/4329description is wrong for permission to view notes that are marked for author ...2023-06-05T05:06:28Ztpokorradescription is wrong for permission to view notes that are marked for author onlyOverview
----------------------------------------
I am wondering if the label in https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Permission.php#LL785C46-L785C46 is correct.
It is about the permission for viewing all notes. I...Overview
----------------------------------------
I am wondering if the label in https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Permission.php#LL785C46-L785C46 is correct.
It is about the permission for viewing all notes. It says: "even if they're marked admin only", but I would expect: "even if they're marked author only".
according to https://github.com/civicrm/civicrm-core/blob/master/sql/civicrm_data/civicrm_option_group/note_privacy.sqldata.php#L17
see https://chat.civicrm.org/civicrm/pl/ye4bu5w87b81mennu3at5ifcrr
Reproduction steps
----------------------------------------
1. Go to User Permissions in Drupal (/admin/people/permissions)
1. See the permission "CiviCRM: view all notes"
Current behaviour
----------------------------------------
The description says: View notes (for visible contacts) even if they're marked admin only
Expected behaviour
----------------------------------------
The description should say: View notes (for visible contacts) even if they're marked author only
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __CiviCRM:__ _5.60.0_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _8.1__
* __CMS:__ Drupal 9.8.5_
Comments
----------------------------------------
see the labels for the options for the notes: None or Author only.
https://github.com/civicrm/civicrm-core/blob/master/sql/civicrm_data/civicrm_option_group/note_privacy.sqldata.php#L17
There is nothing about "admin only"5.63.0https://lab.civicrm.org/dev/core/-/issues/2176JQuery not launching on Tag/Categories page, making it not usable2023-06-05T05:03:23ZSemperFiJQuery not launching on Tag/Categories page, making it not usableOverview
----------------------------------------
Hello - I'd like to report an issue on the tag/categories configuration page.
The list is not well displayed due to JQuery not be loaded. See attached normal view vs. my view
Developer c...Overview
----------------------------------------
Hello - I'd like to report an issue on the tag/categories configuration page.
The list is not well displayed due to JQuery not be loaded. See attached normal view vs. my view
Developer console reports "jquery-ui.min.js:9 Uncaught Invalid date" (see details attached)
In current situation I cannot either edit nor add tags/categories
This is not an urgent case, but anyhelp will be appreciated.
Thanks
Reproduction steps
----------------------------------------
1. Click on **Administer -> Customize data and screens -> Tags/categories**.
Current behaviour
----------------------------------------
Please see attached ![error_categorie_tag](/uploads/da1fb9ab9864a3519e65a315189c6885/error_categorie_tag.PNG)
Expected behaviour
----------------------------------------
Please see attached ![expected_view_categorie_tag](/uploads/0810a2c1ea720484fea7f42e7c6f99a4/expected_view_categorie_tag.PNG)
Environment information
----------------------------------------
* Browser: Chrome Version 86.0.4240.111
* CiviCRM: 5.31
* PHP: PHP 7.2.34-8+
* CMS: WordPress 5.5.3
* Database: 10.3.25-MariaDB
* Web Server: Apache/2.4.46 (Ubuntu)https://lab.civicrm.org/dev/core/-/issues/2223API v4 / search kit Or-by-union2023-06-05T05:03:22ZeileenAPI v4 / search kit Or-by-unionWe have a need to search for
Contribution has total amount = x OR soft credit has total amount = x
there are some more criteria but that is the gist of it.
Currently there is no good way to do this via search kit. Technically it's po...We have a need to search for
Contribution has total amount = x OR soft credit has total amount = x
there are some more criteria but that is the gist of it.
Currently there is no good way to do this via search kit. Technically it's possible but it uses an un-indexed query.
Ways to do this query
**Least performant.....**
- OR clause
```SELECT * FROM civicrm_contribution LEFT JOIN civicrm_contribution_soft...
WHERE civicrm_contribution.total_amount = x
OR civicrm_contribution_soft.amount = x
```
This use of OR on 2 fields on different tables is a known performance problem & the reason why we don't do this in advances search where we do
**A bit more performant**
Temp tables with all contributions & all soft credits combined into one temptable and then used as a join
Performs OK-ish on mid-sized (e.g 300k contacts) sites but building a table with x million rows in it to query doesn't scale
**More performant**
Build a filtered temp table. We do this in some places in civi report - so instead of creating a temp table of all contributions where amount = x or the credit amount = x
Performs better, we do this in a several places in civireport & extended reports - but it's hard to code and very hard to do generically. Also it's still pretty awful if you are using 'limit' and you just want the first 10 out of a large number
**Most performant - at least with limit**
Use Union. This is how we got quicksearch to actually be quick and we get pretty good group searching mileage in advanced search from this too.
This would look like
```
SELECT DISTINCT * FROM (
SELECT * FROM civicrm_contribution LEFT JOIN civicrm_contribution_soft...
WHERE civicrm_contribution.total_amount = x
LIMIT 10
UNION
SELECT * FROM civicrm_contribution LEFT JOIN civicrm_contribution_soft...
WHERE civicrm_contribution_soft.amount = x
LIMIT 10
) as allofem
LIMIT 10
```
The challenge is how to expose a query like that.....https://lab.civicrm.org/dev/core/-/issues/4333Attachment uploader information is missing in case attachments2023-06-04T15:14:55Zahed_compucorpAttachment uploader information is missing in case attachmentsOverview
----------------------------------------
The Case attachments don't have the uploader information. The `created_id` is not supposed to be empty regardless of how you uploaded the attachments i.e. when creating new cases or creat...Overview
----------------------------------------
The Case attachments don't have the uploader information. The `created_id` is not supposed to be empty regardless of how you uploaded the attachments i.e. when creating new cases or creating/editing the related activities.
For the records, the `created_id` field was added in the [#11739](https://github.com/civicrm/civicrm-core/pull/11739) PR / [#CRM-19948](https://issues.civicrm.org/jira/browse/CRM-19948) issue, but they didn't consider the case attachments scenario.
Reproduction steps
----------------------------------------
![attachment-uploader-issuee](/uploads/4e0b28319155ed0b34e477a1a7e793ac/uploader-issue.mp4)
1. Click on **Cases -> New Case**.
2. Under Attachments, upload a file and click **Save**.
3. In the case details page, click on any activity.
4. Under Attachments, upload a file and click **Save**.
Current behaviour
----------------------------------------
Files uploaded in steps two and four, don't have the uploader information i.e. the created_id value is empty.
Expected behaviour
----------------------------------------
Files uploaded in steps two and four should have the uploader information.
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.61.0/.../5.3.0 (since adding the [created_id field/feature](https://github.com/civicrm/civicrm-core/pull/11739/commits/ae2c7e000bf9548adbf8afd355d2127b0030e670))_
Proposed Solution
----------------------------------------
In the old [#11739](https://github.com/civicrm/civicrm-core/pull/11739) PR, it uses the current logged-in `$contact_id` for the created_id field when calling the method [create](https://github.com/civicrm/civicrm-core/blob/5.61.0/CRM/Core/BAO/File.php#L50):
```php
/**
* BAO object for crm_log table
*/
class CRM_Core_BAO_File extends CRM_Core_DAO_File {
...
public static function create($params) {
$fileDAO = new CRM_Core_DAO_File();
...
if (empty($params['id']) && empty($params['created_id'])) {
$fileDAO->created_id = CRM_Core_Session::getLoggedInContactID();
}
```
For case attachments, another method is called to create the File which is [filePostProcess](https://github.com/civicrm/civicrm-core/blob/5.61.0/CRM/Core/BAO/File.php#L100) :
```php
public static function filePostProcess(...) {
...
$fileDAO = new CRM_Core_DAO_File();
$op = 'create';
if (isset($dao->cfID) && $dao->cfID) {
$op = 'edit';
$fileDAO->id = $dao->cfID;
unlink($directoryName . DIRECTORY_SEPARATOR . $dao->uri);
}
if (!empty($fileParams)) {
$fileDAO->copyValues($fileParams);
}
```
The proposed solution is to set the `$created_id` inside the [filePostProcess](https://github.com/civicrm/civicrm-core/blob/5.61.0/CRM/Core/BAO/File.php#L100) method :
```diff
$fileDAO = new CRM_Core_DAO_File();
$op = 'create';
if (isset($dao->cfID) && $dao->cfID) {
$op = 'edit';
$fileDAO->id = $dao->cfID;
unlink($directoryName . DIRECTORY_SEPARATOR . $dao->uri);
}
+ else if (empty($fileParams['created_id'])) {
+ $fileDAO->created_id = CRM_Core_Session::getLoggedInContactID();
+ }
```
I've created the PR https://github.com/civicrm/civicrm-core/pull/26409 to check the proposed solution.5.63.0https://lab.civicrm.org/dev/core/-/issues/3591Public view link for draft mailing is visible to public before mailing is sen...2023-06-04T14:17:12ZlolcodePublic view link for draft mailing is visible to public before mailing is sent and even before it is completeIt doesn't seem quite right that the mailing is public even when it is in draft state.
Of course a bot or interested party would need to be cycling through mailing ids to access it.
It also shows even if the mailing is clearly not compl...It doesn't seem quite right that the mailing is public even when it is in draft state.
Of course a bot or interested party would need to be cycling through mailing ids to access it.
It also shows even if the mailing is clearly not complete. For example if the user doesn't select a mailing header before saving the draft then viewing the public page can also result in errors such as `Error: Call to a member function headers() on null in civicrm_api3_mailing_preview() (line 597 of /sites/all/modules/civicrm/api/v3/Mailing.php).`https://lab.civicrm.org/dev/core/-/issues/2229Contribution page start/end dates don't affect widget's total contributions sum2023-06-04T05:03:24ZedgimarContribution page start/end dates don't affect widget's total contributions sumWhen using a contribution widget associated with a particular contribution-page, it would be nice to be able to modify the start/end dates of the contribution page, and have them affect which contributions are included when computing the...When using a contribution widget associated with a particular contribution-page, it would be nice to be able to modify the start/end dates of the contribution page, and have them affect which contributions are included when computing the sum that is displayed by the widget. Currently this date-range has no effect on the computed widget sum.
The use-case is this: a contribution page is set up, and the user wants to continue to be able to use the same contribution page and widget, but to adjust the date-range (e.g. to match a new year or matching-grant period) on occasion.
On a tangentially related topic, it would probably be better to still allow people to access a contribution page even if the current date is outside the start/end date range. Otherwise potential donors are greeted with an "invalid page" message instead of a form by which they can donate.https://lab.civicrm.org/dev/core/-/issues/1561"Primary" email option in Search Builder behaves as "Any"2023-06-04T05:03:24ZBobS"Primary" email option in Search Builder behaves as "Any"Overview
----------------------------------------
If Primary is selected as the email location in Search Builder, then contacts with a matching email address which is not primary are returned in the search results.
Reproduction steps
--...Overview
----------------------------------------
If Primary is selected as the email location in Search Builder, then contacts with a matching email address which is not primary are returned in the search results.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Search Builder**.
1. Create a search term **Contact | Email | Primary | = | <email_address>**.
1. Click **Search**.
Current behaviour
----------------------------------------
Contacts having <email_address> as a non-primary email are returned. Primary seems to function like "Any". Same problem with other operators, e.g. Like, RegEx.
Expected behaviour
----------------------------------------
Only contacts having a matching email address which is primary should be returned.
Environment information
----------------------------------------
* __CiviCRM:__ _5.21.0_
* __PHP:__ _7.2_
* __CMS:__ _Drupal 7.69_
* __Database:__ _MariaDB 10.0_
* __Web Server:__ _Apache 2.4.41_
Comments
----------------------------------------
The current behavior is useful, but should be called "Any" rather than "Primary", and a working "Primary" option should by provided as well.
Confirmed on [demo site](https://demo.circle-interactive.co.uk/civicrm)https://lab.civicrm.org/dev/core/-/issues/2202Confusing note regarding ACLs for events2023-06-03T05:03:28ZfkohrtConfusing note regarding ACLs for eventsOverview
----------------------------------------
When managing ACLs for Events, users are presented with the following [note](https://lab.civicrm.org/dev/core/-/blob/34d6cec4/templates/CRM/ACL/Form/ACL.tpl#L90-94):
> NOTE: For Event A...Overview
----------------------------------------
When managing ACLs for Events, users are presented with the following [note](https://lab.civicrm.org/dev/core/-/blob/34d6cec4/templates/CRM/ACL/Form/ACL.tpl#L90-94):
> NOTE: For Event ACLs, the 'View' operation allows access to the event information screen. "Edit" allows users to register for the event if online registration is enabled.
Please remember that Drupal's "register for events" permission overrides CiviCRM's control over event information access.
I find this wording highly confusing for several reasons.
Current behaviour
----------------------------------------
1. Reading `event information screen` I thought only page visits of `/civicrm/event/info` are affected, when in fact, this also concerns the events I see in the backend's event dashboard at `/civicrm/event`. I think I would have correctly guessed what the _View_ permission does without this note.
2. Reading `"Edit" allows users to register for the event if online registration is enabled.`...
1. I thought this has nothing to do with configuring events in the backend, when in fact, this is just exactly that. Again, I find this note more confusing than helpful.
2. I am additionally confused as a user of the [Webform CiviCRM Integration](https://www.drupal.org/project/webform_civicrm) because my participants never use CiviCRM's online registration feature. So I am asking myself “Does this cover my use case as well?” and “Who actually needs the permission to edit in my case?”
3. If I allow anonymous users to access all events on Drupal's permission page and also grant _Edit_ permissions via CiviCRM's ACLs, then those users granted edit rights __do not__ have the right to _View_ other events anymore. The UI does not inform me about this behaviour.
4. Reading `View` and `Edit` I wonder whether the latter includes the former. Would make sense, but I don't know from the UI.
Proposed behaviour
----------------------------------------
1. Maybe this should read `[...] allows access to the event's information.`
2. (see the suggestions below)
1. Maybe add a clause that the _Edit_ permission also allows configuring the event in the backend. But isn't this even more confusing then, because the _Edit_ permission allows event configuration __and__ event registration (two rights that most would think are different)?
2. Maybe add an explanation for those who register their participants through Drupal's Webform module.
3. Maybe add a clause that explains that once any of the _View_ or _Edit_ permissions is given through the ACLs, Drupal's CiviEvent permissions _view event info_ is overriden, even granted for anonymous users (at least that's how I understand it).
4. Maybe add a clause that _Edit_ includes the right to _View_ (if this is the case),
Comments
----------------------------------------
I am using CiviCRM 5.31 on Drupal 8https://lab.civicrm.org/dev/core/-/issues/465Multiselect for Event Type in Advanced Search2023-06-03T05:03:27ZfrancescbassasMultiselect for Event Type in Advanced SearchOriginal issue: https://issues.civicrm.org/jira/browse/CRM-20183
Affected versions: at least from 4.7.16
[Richard](https://issues.civicrm.org/jira/secure/ViewProfile.jspa?name=magnolia61) reports:
> Hello there, for creating a specifi...Original issue: https://issues.civicrm.org/jira/browse/CRM-20183
Affected versions: at least from 4.7.16
[Richard](https://issues.civicrm.org/jira/secure/ViewProfile.jspa?name=magnolia61) reports:
> Hello there, for creating a specific smartgroup I want to be able to select multiple event types from the advanced search page.
>
> The event type is currently a one value field. I would love to make it behave like the participant status or role so more than one can be selected.
>
> Who can point me in the right direction. When I know which files are involved and see some examples I think I can create the PR myself.
>
> This would definitely make our life easier, since the difference search options (the builder, participant search and advanced search are so different in behavior
![Screenshot_from_2017-02-26_17-02-54](/uploads/83d2cb5614dade321364c4fab597dc79/Screenshot_from_2017-02-26_17-02-54.png)https://lab.civicrm.org/dev/core/-/issues/2209Activities can't be moved to a Case re-opened by the API2023-06-02T05:03:18ZjhungerfordActivities can't be moved to a Case re-opened by the APIOverview
----------------------------------------
When the API sets a Case to an Open status, it does not clear the end date. When moving an Activity to a Case, the filter for the list of available cases requires the end date to be null....Overview
----------------------------------------
When the API sets a Case to an Open status, it does not clear the end date. When moving an Activity to a Case, the filter for the list of available cases requires the end date to be null. If a case has been closed and then reopened by the API (e.g. by filling out a webform which sets the case status), it will still have an end date, so it will not be available in this list.
The end date is not visible to the user, so there's no visual indication of why Cases reopened in this manner behave differently.
Reproduction steps (using the demo database)
----------------------------------------
1. Choose or create a Contact with at least one Activity
2. Create a Case for this Contact
3. Set the Case status to Resolved using the UI or API
4. Use the API explorer to set the status of that Case to Ongoing
5. Go to the Contact's summary screen and click on Activities
6. Choose any suitable Activity, click "File on Case"
7. Search for the newly reopened Case and note that it does not appear in the list
Current behaviour
----------------------------------------
A Case can have an Open status and an end_date, meaning it is not possible to move Activities to that Case, and the reason isn't visible to the user.
* The API and webform-civicrm do not clear the end date when setting a case to an Opened status class
* The code which filters the list of available Cases when moving an Activity (example [here](https://lab.civicrm.org/dev/core/-/blob/5.32/CRM/Case/Form/ActivityToCase.php#L96-107)) finds Open cases according to these criteria:
```
'case_id.is_deleted' => 0,
'case_id.status_id' => ['!=' => "Closed"],
'case_id.end_date' => ['IS NULL' => 1],
```
There are at least two other places which implement this logic (one in the same file, another [here](https://lab.civicrm.org/dev/core/-/blob/5.32/CRM/Case/BAO/Case.php#L2383-2388)).
Expected behaviour
----------------------------------------
If a Case has an Open status, it should be possible to move Activities to that Case.
There are several places where this could be addressed, but I think the filter shown above should check the status class, and probably should not check the end_date at all.
If it does check the end_date:
* Either the API or webform-civicrm should clear the end date (if it's in the past) when setting a Case to an Opened status
* If this is done by webform-civicrm, should it also create the Changed Status activities which would have been created if the Case were re-opened through the normal UI?
* Should the filter include Cases with future end dates as well as null end dates?
Environment information
----------------------------------------
* __CiviCRM:__ Discovered on 5.27.5, tested on 5.33.alpha1
* __CMS:__ Drupal 7.74
* __webform-civicrm:__ tested on 7.x-5.1 and 7.x-5.3
Comments
----------------------------------------
I can see reasons why the API might not want to clear the end date for a reopened Case, and how webform-civicrm is simply passing the submitted values along to the API. It's not clear which part of the system should be responsible, and I'm guessing most sites don't encounter this issue.
We considered using a CiviRule to do some extra processing when the Case status changes, but when attempting to configure this it fails with "Entity Case does not implement status condition". We can probably solve this by writing a custom CiviRule trigger (or maybe upgrading CiviRules), but it also seems like the core logic could be improved.
I've tested a patch locally which doesn't look at the end date when filtering the list of Cases in this context, and which looks for the Opened status classes by first fetching them like so:
```
$openStatuses = array_keys(CRM_Case_PseudoConstant::caseStatus('value', TRUE, "AND grouping = 'Opened'"));
```
Looking at the current code, I'm wondering whether this is checking the status class without needing to fetch the list first:
```
'case_id.status_id' => ['!=' => "Closed"],
```