Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-20T13:55:38Zhttps://lab.civicrm.org/dev/core/-/issues/5102Allow access to API params from Api4Query2024-03-20T13:55:38ZMichael McAndrewAllow access to API params from Api4QueryContext:
* I am adding an 'extra' calculated field to a spec provider for a custom entity.
* The value of this extra calculated field depends on a parameter passed to the get action.
* I have access to the query in the setSqlRenderer me...Context:
* I am adding an 'extra' calculated field to a spec provider for a custom entity.
* The value of this extra calculated field depends on a parameter passed to the get action.
* I have access to the query in the setSqlRenderer method (which contains a _protected_ API object) but there doesn't appear to be a way to access the API parameters.
Adding the following method to Api4Query allows read only access to API params and seems inline with other methods like `getSelect()`, but feel free to let me know if I am doing it wrong and there is a better approach.
```php
/**
* @return mixed
*/
public function getParam(string $param) {
return call_user_func([$this->api, 'get'.ucfirst($param)]);
}
```
PR coming up...https://lab.civicrm.org/dev/core/-/issues/3738Feature request - APIv4 Get action, provide ability to define aliases for the...2024-03-15T14:56:37Zjustinfreeman (Agileware)Feature request - APIv4 Get action, provide ability to define aliases for the select fields so that external integrations with CiviCRM do not break when the field name changes OR a different field is selectedThis is a Feature request. It would be great if you could define an **alias** for each _select_ **field** when using a **APIv4 Get action**. This alias should then be used as the output in the results for the Get action.
This would enab...This is a Feature request. It would be great if you could define an **alias** for each _select_ **field** when using a **APIv4 Get action**. This alias should then be used as the output in the results for the Get action.
This would enable external CiviCRM integrations to be more robust, by allowing the fields selected in the Get action to be **changed** and but continue to use the **same alias**, thus not changing the structure of the results, the external integration would continue to work.
The other benefit would be that very long CiviCRM field names could be reduced to something shorter or more logical. eg. Instead of "email.email" the alias could just be set to "email". Or instead of "email_greeting_id:label" the alias could just be "email_greeting".
![image](/uploads/2ccae5082e4f50f5fc924d8e6998ffaa/image.png)https://lab.civicrm.org/dev/core/-/issues/5062APIv4: Cannot set multi-select ContactRef field that is part of a multi-recor...2024-03-07T15:44:13ZmmyriamAPIv4: Cannot set multi-select ContactRef field that is part of a multi-record custom fieldsetOverview
----------------------------------------
Adding multiple Contact References in a field that is part of a multi-record field set fails with APIv4.
Reproduction steps
----------------------------------------
1. Create a custom f...Overview
----------------------------------------
Adding multiple Contact References in a field that is part of a multi-record field set fails with APIv4.
Reproduction steps
----------------------------------------
1. Create a custom field set for all Individuals and check "Does this Custom Field Set allow multiple records?"
2. Add a ContactRef field and check "Multi-Select"
3. Try to set it via the APIv4 Explorer
![image](/uploads/44ecbf788a66150425e55a9de8a6212f/image.png)
Current behaviour
----------------------------------------
Failing with error:
```
{
"error_code": 0,
"error_message": "value: \u00013\u000193\u0001 is not of the right field data type: ContactReference",
"status": 500
}
```
Environment information
----------------------------------------
https://dmaster.demo.civicrm.org running 5.72.alpha1
Comments
---
Not an issue if the multi-select ContactRef field is not part of a multi-record custom fieldset.https://lab.civicrm.org/dev/core/-/issues/3704APIv4 'Invalid field' but really permission problem2024-03-07T05:03:20Zaydunsaidan.saunders@squiffle.ukAPIv4 'Invalid field' but really permission problemI used APIv4 Explorer to create this:
```
$results = \Civi\Api4\Email::update()
->addValue('on_hold', 0)
->addWhere('email', '=', 'test@example.org')
->addWhere('contact_id.is_deleted', '=', FALSE)
->addWhere('on_hold', '=', 1)
...I used APIv4 Explorer to create this:
```
$results = \Civi\Api4\Email::update()
->addValue('on_hold', 0)
->addWhere('email', '=', 'test@example.org')
->addWhere('contact_id.is_deleted', '=', FALSE)
->addWhere('on_hold', '=', 1)
->execute();
```
I copied it into a script, ran it and got the message:
```
Invalid field 'contact_id.is_deleted'
```
That caused a bit of head-scratching and double-checking I hadn't got weird characters in there until trying `update(FALSE)` - it worked.
An error message about lack of permission would be much more helpful than the current 'Invalid field'.
CiviCRM: 5.50.3https://lab.civicrm.org/dev/core/-/issues/4140API4: Contact.Get does not work for contact subtype2024-03-01T12:53:51Zmattwiremjw@mjwconsult.co.ukAPI4: Contact.Get does not work for contact subtypecontact_sub_type is stored as a "pseudo" array in the database and no results are returned if you search on Contact.Get with subtype =,IN,! etc. API3 has some code to work around this in `CRM/Contact/BAO/Query::includeContactSubTypes()` ...contact_sub_type is stored as a "pseudo" array in the database and no results are returned if you search on Contact.Get with subtype =,IN,! etc. API3 has some code to work around this in `CRM/Contact/BAO/Query::includeContactSubTypes()` which rewrites =,IN,! to LIKE and NOT and then rewrites the query parameter to contain wildcard chars `%` so API3 "works".
I hacked together a version of this that works for API4 with the `=` operator: https://github.com/civicrm/civicrm-core/compare/master...mattwire:civicrm-core:api4contactgethttps://lab.civicrm.org/dev/core/-/issues/3429API4: Make CaseType a managed entity2024-01-24T14:08:18ZherbdoolAPI4: Make CaseType a managed entityOverview
----------------------------------------
Allow CaseType to be a managed entity so it can be exported via api4.
Example use-case
----------------------------------------
1. Go to `/civicrm/api4`
1. Select CaseType and Export
C...Overview
----------------------------------------
Allow CaseType to be a managed entity so it can be exported via api4.
Example use-case
----------------------------------------
1. Go to `/civicrm/api4`
1. Select CaseType and Export
Current behaviour
----------------------------------------
Cannot export and use as a managed entity.https://lab.civicrm.org/dev/core/-/issues/3183Event template scheduled reminders lost when creating a new event using API42024-01-18T05:18:05ZufundoEvent template scheduled reminders lost when creating a new event using API4Overview
----------------------------------------
Scheduled reminders from an event template are lost when creating a new event using API4 with the `template id` parameter.
The scheduled reminders are copied, but don't get properly atta...Overview
----------------------------------------
Scheduled reminders from an event template are lost when creating a new event using API4 with the `template id` parameter.
The scheduled reminders are copied, but don't get properly attached to the event.
It seems to work fine if creating an event from template using the admin screens.
Reproduction steps
----------------------------------------
1. Create an event template with one or more scheduled reminders configured on it
1. Check the id for your new template
1. Use API4 to create a new event from the template, using the `template_id` parameter ![image](/uploads/d173de6a8c9cb611fcd4280e99a31727/image.png)
1. Check your new event - it won't have any scheduled reminders
Current behaviour
----------------------------------------
The reminders for the new event are half-created — they show in Administer >> Communications >> Schedule Reminders but but they aren't attached to anything. The issue seems to be they get copied as Event Template reminders and don't get updated to be Event reminders.
![image](/uploads/8d578ef97d71c8be6a6f76cd7d5ef09e/image.png)
(Top row is the original reminder on the template. Second is the 'orphaned' reminder. Third is the successfully copied reminder on event created from template through the web UI)
Expected behaviour
----------------------------------------
The reminders should be attached to the new event.
Environment information
----------------------------------------
* __CiviCRM:__ _dmaster on buildkit 5.50.alpha1_ (and previous versions since a while)
* __PHP:__ _7.4_
* __CMS:__ _Drupal_
Comments
----------------------------------------
I have a patch that seems to resolve though feels a bit hacky. The event schedule reminder code is a bit sticky...https://lab.civicrm.org/dev/core/-/issues/4202EntityRef custom fields don't work with API4 or SearchKit2024-01-12T15:49:42ZJonGoldEntityRef custom fields don't work with API4 or SearchKitOverview
----------------------------------------
EntityRef custom fields don't return values when selected in API4. Even after I fixed that, they're not part of the `CRM.crmSearchAdmin.joins` so they're not selectable in SearchKit.
Re...Overview
----------------------------------------
EntityRef custom fields don't return values when selected in API4. Even after I fixed that, they're not part of the `CRM.crmSearchAdmin.joins` so they're not selectable in SearchKit.
Reproduction steps
----------------------------------------
API4 issue:
* Create an EntityRef custom field.
* Go to API4 Explorer.
* Try to use them comparably to how one might use a core EntityRef field (e.g. Contact `employer_id`).
Selecting the field directly returns `NULL`. You can't join on EntityRef.
I have a PR that fixes the above, but after that, the joins still don't appear in SK. I've tracked the issue down to `\Civi\Search\Admin::getJoins()` but this exceeds my API4 knowledge limit.
Technically I'd consider this part of #3721 but since that's closed we'll track this separately.
@herbdool Once this is done, #3949 could be solved by using an EntityRef custom field instead of ContactRef.https://lab.civicrm.org/dev/core/-/issues/4848Nuance logging on API Authorization fails2023-12-07T00:07:32ZeileenNuance logging on API Authorization failsWhen an api request fails authorization one of 2 things happens
1) too much information is logged to our logs
2) too little information is logged.
In the former case some things like SearchKit rely on authorization failing appropriatel...When an api request fails authorization one of 2 things happens
1) too much information is logged to our logs
2) too little information is logged.
In the former case some things like SearchKit rely on authorization failing appropriately and logging can cause people to spend time debugging & trying to fix issues that are normal operation - ultimately both https://github.com/civicrm/civicrm-core/pull/28259 and https://github.com/civicrm/civicrm-core/pull/28260 fall in this category & nearly wound up opening up security to fix log noise
In the latter case an api call is failing authorization but it is hard to tell where. We recently hit this where the logged output was unhelpful because the backtrace being logged only got as far as the api call - we were not getting the trace from the exception itself (and the fail was happening on something the api called, not the main api). Hence we wound up altering the code to
```
\CRM_Core_Error::backtrace('API Request Authorization failed' . $apiRequest['action'] . " " . $apiRequest['entity'], TRUE);
\CRM_Core_Error::debug_var('backtrace', $e->getTraceAsString());
```
I think that it makes sense to be able to specify at the api call level when you don't care about logging exceptions (ie searchkit) but also to get some more info when you dohttps://lab.civicrm.org/dev/wordpress/-/issues/42404 Error when I use the Api v4 with Wordpress Multisite -> because no "do no...2023-12-06T17:14:08ZTomAnderson404 Error when I use the Api v4 with Wordpress Multisite -> because no "do not delete" post was generated for the subsiteI am encountering a 404 Error when I use the Api v4 with Wordpress Multisite.
My sites have urls like: `mainsite.com` and `subsite.com`.
I only get the 404 error on the subsite, not the main site. The data is retrieved, but there is a 4...I am encountering a 404 Error when I use the Api v4 with Wordpress Multisite.
My sites have urls like: `mainsite.com` and `subsite.com`.
I only get the 404 error on the subsite, not the main site. The data is retrieved, but there is a 404 error at the same time. This breaks the promises and makes it super awkward to use the API.
```
var this_works_v3 = await CRM.api3('Event', 'get');
var this_gets_a_404_result_but_the_promise_holds_the_data = await CRM.api4('Event', 'get');
var this_works_v4 = await CRM.api4('Event', 'get', {where: [["title", "LIKE", "%"]]});
```
I tracked it through the code and the problem occurs in the jQuery file.
``` jquery.js?r=lemn4 10252:10255
// Do send the request
// This may raise an exception which is actually
// handled in jQuery.ajax (so no try/catch here)
xhr.send( ( options.hasContent && options.data ) || null );
```
The options.data is empty in the 404 result version because there are no parameters in the API call.
I was stumped as to what else I could do to understand this problem. Until I checked the PHP-FPM log. It turned out, there was an error being thrown in wp-content\plugins\civicrm\civicrm\CRM\Utils\System\WordPress.php:224 because $post did not have ID ($post was undefined on the subsite).
```
/**
* @inheritDoc
*/
197 public function url(
```
Line 222 should be loading the post that indicates the url
```
222 global $post;
223 if (get_option('permalink_structure') != '') {
$script = get_permalink($post->ID);
}
if ($config->wpBasePage == $post->post_name) {
$basepage = TRUE;
}
```
I put the check for $post and found that on the subsite, it was not being populated. But in the main site, it was a post with the post content: 'post_content' => 'Do not delete this page. Page content is generated by CiviCRM.',
Well that's weird, the subsite doesn't have that post, but the main site says it should not be deleted. I copied the post to the subsite database table `wp_3_posts` changing the ID and the guid to match the subsite. And it works!
In summary, there is a flaw in the CiviCRM setup for multisite Wordpress, because the file Wordpress.php expects there to be a post in the database so it can grab its data. The workaround was to duplicate the autogenerated "Do not delete this post" post in the subsite. No more 404 error!haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/3062APIv4: Case activities ignores the time value passed via start_date using cre...2023-11-23T05:03:24ZKurund JalmiAPIv4: Case activities ignores the time value passed via start_date using create apiCase create API.
```php
$results = \Civi\Api4\CiviCase::create()
->addValue('case_type_id', 4)
->addValue('status_id', 9)
->addValue('contact_id', [
'user_contact_id',
])
->addValue('start_date', '2022-02-08 18:51:00')
-...Case create API.
```php
$results = \Civi\Api4\CiviCase::create()
->addValue('case_type_id', 4)
->addValue('status_id', 9)
->addValue('contact_id', [
'user_contact_id',
])
->addValue('start_date', '2022-02-08 18:51:00')
->execute();
```
```php
(1) [
{
"id": 578,
"case_type_id": 4,
"start_date": "2022-02-08",
"status_id": 9,
"is_deleted": false,
"created_date": "2022-02-08 18:51:00",
"modified_date": "2022-02-08 18:51:00"
}
]
```
Case is created correctly. However, associated activities ignores the time. My assumption was `start_date` value is used for creating activities. This happens when a case is created via UI.
```php
(1) [
{
"id": 120,
"source_record_id": null,
"activity_type_id": 13,
"subject": "test",
"activity_date_time": "2022-02-08 00:00:00",
"duration": null,
"location": null,
"phone_id": null,
"phone_number": null,
"details": null,
"status_id": 2,
"priority_id": 2,
"parent_id": null,
"is_test": false,
"medium_id": 7,
"is_auto": false,
"relationship_id": null,
"is_current_revision": true,
"original_id": null,
"result": null,
"is_deleted": false,
"campaign_id": null,
"engagement_level": null,
"weight": null,
"is_star": false,
"created_date": "2022-02-08 18:51:00",
"modified_date": "2022-02-08 18:51:00"
}
]
```https://lab.civicrm.org/dev/core/-/issues/2077Expose a REST end-point through standard routing2023-11-18T05:03:29ZtottenExpose a REST end-point through standard routingOverview
----------------------------------------
Provide a binding for CRM_Utils_REST in the conventional routing system.
Example use-case
----------------------------------------
1. Create a D8 site
1. Create user/contact and set the...Overview
----------------------------------------
Provide a binding for CRM_Utils_REST in the conventional routing system.
Example use-case
----------------------------------------
1. Create a D8 site
1. Create user/contact and set their API key
1. Access the `rest` end-point with their API key
Current behavior
----------------------------------------
* There is a binding through the `extern/rest.php`.
* There are tests for the REST contract in `E2E_Extern_RestTest`
* The end-point is difficult to use/deploy in environments like D8.
Proposed behavior
----------------------------------------
* There is another binding `civicrm/api/rest` which speaks the same protocol.
* The RestTest hits both end-points (depending on what's valid/available for the given build).
* References to the REST endpoint (eg RestTest and API Explorer) are constructed via `CRM_Utils_System::externUrl('extern/rest')`
Comments
----------------------------------------
* This is an offshoot of https://lab.civicrm.org/dev/drupal/-/issues/7 and https://lab.civicrm.org/dev/cloud-native/-/issues/16
* This sounds easier than it is.
* There's a draft/WIP: https://github.com/civicrm/civicrm-core/pull/17952
* The protocol's authentication-handler is tied into `CRM_Utils_System::loadBootstrap()`. This needs refactoring/reworking to apply to be valid in a standard route.https://lab.civicrm.org/dev/core/-/issues/2752Financial entity permissions2023-11-08T05:03:19ZeileenFinancial entity permissionsI hit an issue where a contact without 'Administer CiviCRM' but WITH 'view all contributions' cannot access a payment search display - [as described](https://civicrm.org/blog/eileen/searching-payments-civi)
I think the VIEW permissions ...I hit an issue where a contact without 'Administer CiviCRM' but WITH 'view all contributions' cannot access a payment search display - [as described](https://civicrm.org/blog/eileen/searching-payments-civi)
I think the VIEW permissions on all financial entities should be 'view all contributions' because otherwise we will keep hitting issues where part but not all of a contribution can be retrieved
@JoeMurray @monish.deb @seamusleehttps://lab.civicrm.org/dev/core/-/issues/4733Where art thou APIv4: MailingEventSubscribe Create? Missing parity with civic...2023-11-02T15:16:06Zjustinfreeman (Agileware)Where art thou APIv4: MailingEventSubscribe Create? Missing parity with civicrm_api3('MailingEventSubscribe', 'Create')Where art thou APIv4: MailingEventSubscribe Create? Missing parity with civicrm_api3('MailingEventSubscribe', 'Create')
Agileware Ref: CVAP-50Where art thou APIv4: MailingEventSubscribe Create? Missing parity with civicrm_api3('MailingEventSubscribe', 'Create')
Agileware Ref: CVAP-50https://lab.civicrm.org/dev/core/-/issues/2507API4: "Invalid field 'contact.is_deleted'"2023-10-26T05:03:28ZedvanleeuwenAPI4: "Invalid field 'contact.is_deleted'"I am getting several errors on Api4 and the field is_deleted on a contact. The field is available in the database. At the moment, I do not know how to reproduce this, so I will investigate further. Furthermore, I cannot see any problems....I am getting several errors on Api4 and the field is_deleted on a contact. The field is available in the database. At the moment, I do not know how to reproduce this, so I will investigate further. Furthermore, I cannot see any problems.
```
[error]
$Fatal Error Details = array:3 [
"message" => "Invalid field 'contact.is_deleted'"
"code" => null
"exception" => API_Exception {#2233
-extraParams: array:1 [
"error_code" => 0
]
#message: "Invalid field 'contact.is_deleted'"
#code: 0
#file: "/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php"
#line: 518
trace: {
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:518 {
› if ($strict && !$field) {
› throw new \API_Exception("Invalid field '$fieldName'");
› }
}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:371 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:349 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:245 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:114 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/Civi/Api4/Query/Api4SelectQuery.php:129 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/Civi/Api4/Generic/DAOGetAction.php:110 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/Civi/Api4/Generic/DAOGetAction.php:98 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/Civi/Api4/Provider/ActionObjectProvider.php:68 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/Civi/API/Kernel.php:149 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/Civi/Api4/Generic/AbstractAction.php:238 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/CRM/Profile/Page/Dynamic.php:449 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/CRM/Profile/Page/Dynamic.php:332 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/CRM/Profile/Page/View.php:91 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/CRM/Profile/Page/View.php:159 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php:312 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php:68 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php:36 { …}
/home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/drupal/civicrm.module:458 { …}
/home/covsp/domains/covs.nl/public_html/includes/menu.inc:527 { …}
/home/covsp/domains/covs.nl/public_html/index.php:21 { …}
}
}
]
apr 03 11:22:01 [debug] $backTrace = #0 /home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/CRM/Core/Error.php(433): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/CRM/Core/Invoke.php(39): CRM_Core_Error::handleUnhandledException(Object(API_Exception))
#2 /home/covsp/domains/covs.nl/public_html/sites/all/modules/civicrm/drupal/civicrm.module(458): CRM_Core_Invoke::invoke((Array:3))
#3 /home/covsp/domains/covs.nl/public_html/includes/menu.inc(527): civicrm_invoke("profile", "view")
#4 /home/covsp/domains/covs.nl/public_html/index.php(21): menu_execute_active_handler()
#5 {main}
```https://lab.civicrm.org/dev/core/-/issues/2965APIv4 Explorer, displays the Field Name as the selectable option. However, th...2023-10-23T05:03:22Zjustinfreeman (Agileware)APIv4 Explorer, displays the Field Name as the selectable option. However, the Field Label only is visible in the Custom Fields UI and may be different to the Field NameAPIv4 Explorer, displays the Field Name as the selectable option. However, the Field Label only is visible in the Custom Fields UI and may be different to the Field Name.
SearchKit on the other hand does use the Field Label to list the ...APIv4 Explorer, displays the Field Name as the selectable option. However, the Field Label only is visible in the Custom Fields UI and may be different to the Field Name.
SearchKit on the other hand does use the Field Label to list the available fields.
This can make it very difficult to use the APIv4 Explorer to select the correct fields if:
1. There are a large number of fields, and
2. The Field Name differs from the Field Label
This is a very common occurrence on older CiviCRM sites which tend to have fields that have been renamed over time and have a lot of old fields still active on the site.
My preference would be to always list the Field Label when displaying fields in the APIv4 Explorer.
![Screenshot_20211123_084139](/uploads/b71225e09f100a8e78d2c321a05704d1/Screenshot_20211123_084139.png)
Agileware Ref: CIVICRM-1890https://lab.civicrm.org/dev/core/-/issues/3965Adding mailing events (unsub, open, clicks, etc) to API42023-10-16T00:28:23ZlarsssandergreenAdding mailing events (unsub, open, clicks, etc) to API4I'd like to add mailing events to API4 so we can use them in SearchKit, to improve the A/B Mailing report page, and so on.
This would be all the [Mailing Events here.](https://github.com/civicrm/civicrm-core/tree/master/CRM/Mailing/Even...I'd like to add mailing events to API4 so we can use them in SearchKit, to improve the A/B Mailing report page, and so on.
This would be all the [Mailing Events here.](https://github.com/civicrm/civicrm-core/tree/master/CRM/Mailing/Event/DAO) Not sure they are all essential, but might as well do them all at once, as they will all be very similar.
Having poked around at this, I see a few issues that I think I need some help with before starting on this.
We have, for example, TrackableURLOpen, which links to a TrackableURL and also to the Queue entity, which links to the Job entity, which links to the Mailing entity. I don't think we want to have users building queries with joins on all of these entities in SearchKit in order to get useful information back. Ideally, we'd have an entity that has a get action that would return:
- id from TrackableURLOpen
- timestamp from TrackableURLOpen
- URL from TrackableURL
- contact id from Queue
- mailing id from Job
Can we do this by adding all these entities to the API, adding entity bridges to connect them all and then adding an abstract entity that wraps everything up together, with a get function that gets all the fields above from the API (and a getfields function as well). Or is there a less manual way to do this?
Also, I see that the Queue entity already exists in API4, but it isn't the Mailing_Event_Queue entity. Is there a way to specify the full class for an entity so that we don't get a collision? It looks like it just expects the last word from the classname as the API class and that won't work in this case. This might be helpful in general here, because adding an entity called just Opened is going to be confusing (versus naming it something like MailingEventOpened).https://lab.civicrm.org/dev/core/-/issues/2921APIv4 does not respect hook permissions via searchkit2023-10-14T05:03:22ZeileenAPIv4 does not respect hook permissions via searchkit**To Replicate**
git clone https://github.com/eileenmcnaughton/paymentsearch.git
- enable payment search extension
- go to Contributions->find payments, note that check numbers are populated
- create a user with permissions to all contac...**To Replicate**
git clone https://github.com/eileenmcnaughton/paymentsearch.git
- enable payment search extension
- go to Contributions->find payments, note that check numbers are populated
- create a user with permissions to all contacts & civiContribute but not 'adminster CiviCRM'
- note that use cannot see check numebrs at Contributions->find payments
**Details**
There is an issue for 'users who can see contributions should be able to see payments' (#2752) - this is not that issue. This issue is 'an extension should be able to alter the permissions when core is too restrictive. Note I think this is a regression from a few months back
When APIv4 checks if it can load data from a related entity it calls `getActions`
```
if ($actionName != 'permissions' && $actionName != 'getInfo' && $actionName[0] != '_') {
$this->loadAction($actionName, $method);
}
```
Which determines the top-level permission to check via
![image](/uploads/8ad71dfcc5471248f7caf4dceb8c0634/image.png)
Which calls
![image](/uploads/3f6ff7aa65d8b9bc5cb858ea99257e6c/image.png)
Unlike apiv3 this list of permissions is not filtered through the `apiAlterPermissions` hook = the problem
@colemanw I see that the docs confirm this https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_alterAPIPermissions/ - but I don't understand how extensions are supposed to fix up permissions with apiv4https://lab.civicrm.org/dev/core/-/issues/2486Apiv4 entity parity2023-10-13T21:11:08ZeileenApiv4 entity parity## Here are the entities in APIv3 & not v4
_In some cases by design - others we should maybe add..._
# Prioritised
- [ ] Attachment.php - `get` [has been added to support viewing attachments in SearchKit](https://github.com/civicrm/civ...## Here are the entities in APIv3 & not v4
_In some cases by design - others we should maybe add..._
# Prioritised
- [ ] Attachment.php - `get` [has been added to support viewing attachments in SearchKit](https://github.com/civicrm/civicrm-core/pull/27379) but `create` is still missing
- [ ] Extension.php - various install, uninstall etc functions (support for some actions already implemented)
# Partially done - lets resolve
- [ ] MembershipLog.php https://github.com/civicrm/civicrm-core/pull/21106
# Standard crud - note that doing these involves checking all pseudoconstants are correctly defined
- [ ] SmsProvider.php
- [ ] Premium.php
- [ ] RecurringEntity.php
# Mailing related - in scope
- [ ] MailingAB.php
- [ ] MailingComponent.php
- [ ] MailingContact.php
- [ ] MailingEventResubscribe.php
- [ ] MailingRecipients.php
# From here on down we are out of scope for 'entity parity'
## Order related - needed when we get to afform payment forms - out of scope for entity parity
- [ ] Order.php
- [ ] Payment.php
## Varied utils - out of scope for 'entity parity' - ad hoc
- [ ] SystemLog.php
- [ ] User.php
- [ ] Logging.php
## Migration doubtful - to be done ad hoc if we decide to
- [ ] ReportTemplate.php
- [ ] ParticipantPayment.php - likely should not be brought over
- [ ] CxnApp.php
- [ ] Cxn.php
- [ ] Profile.php
## Do not migrate
- ~~ActivityType.php (by design)~~
- ~~CustomSearch.php (by design)~~
- ~~Constant.php (by design)~~
- ~~SurveyRespondant.php(by design)~~
- ~~MembershipPayment.php (by design - use Line Item)~~
## Done
- [x] ~~AclRole.php~~ ACLEntityRole https://github.com/civicrm/civicrm-core/pull/20474
- [x] Batch.php https://github.com/civicrm/civicrm-core/pull/19931
- [x] CaseContact.php https://github.com/civicrm/civicrm-core/pull/19907
- [x] Case.php https://github.com/civicrm/civicrm-core/pull/19907
- [x] CaseType.php
- [x] ContributionProduct.php https://lab.civicrm.org/dev/core/-/issues/2683
- [x] Dedupe.php
- [x] EntityBatch.php https://lab.civicrm.org/dev/core/-/issues/2682
- [x] EntityFinancialAccount.php - https://github.com/civicrm/civicrm-core/pull/19927
- [x] EntityFinancialTrxn.php - https://github.com/civicrm/civicrm-core/pull/19932
- [x] ~~Exception.php~~ DedupeException.php https://github.com/civicrm/civicrm-core/pull/20466
- [x] File.php (part of attachment) https://github.com/civicrm/civicrm-core/pull/21158
- [x] FinancialItem.php - https://github.com/civicrm/civicrm-core/pull/20433
- [x] Job.php (crud portion)
- [x] Job.php
- [x] JobLog.php
- [x] Mailing.php - there are a bunch of related entities - see further down)
- [x] MailingEventConfirm.php
- [x] MailingEventQueue.php
- [x] MailingEventSubscribe.php
- [x] MailingEventUnsubscribe.php
- [x] MailingGroup.php
- [x] MailingJob.php
- [x] Membership.php - see https://lab.civicrm.org/dev/core/-/issues/2634 https://github.com/civicrm/civicrm-core/pull/21106
- [x] MembershipBlock.php https://github.com/civicrm/civicrm-core/pull/21106
- [x] MembershipStatus.php https://github.com/civicrm/civicrm-core/pull/21106
- [x] ParticipantStatusType.php
- [x] PaymentToken.php
- [x] Pcp.php
- [x] PrintLabel.php https://github.com/civicrm/civicrm-core/pull/21500
- [x] Product.php - since 5.41
- [x] ReportInstance.php
- [x] ~~Rule.php~~ DedupeRule.php https://github.com/civicrm/civicrm-core/pull/20466
- [x] ~~RuleGroup.php~~ DedupeRuleGroup.php https://github.com/civicrm/civicrm-core/pull/20466
- [x] Survey.php https://github.com/civicrm/civicrm-core/pull/21355
- [x] WordReplacement.php https://github.com/civicrm/civicrm-core/pull/20559https://lab.civicrm.org/dev/core/-/issues/2889Invalid field 'tx.language'2023-10-04T05:03:20ZeileenInvalid field 'tx.language'I'm hitting an api error on production and staging sites but oddly not the 'same' local dev site when I try to access the message template admin page.
Note that the api call fails in api explorer an in message admin extension.
I haven'...I'm hitting an api error on production and staging sites but oddly not the 'same' local dev site when I try to access the message template admin page.
Note that the api call fails in api explorer an in message admin extension.
I haven't re-written this for readability but the abbreviation `tx` means 'translation'.
Note the cache has had several days to age out & has been cleared using System.flush & the UI method
```
CRM.api4('MessageTemplate', 'get', {
select: ["id", "msg_title", "is_default", "is_active", "tx.language:label", "tx.language"],
join: [["Translation AS tx", "INNER", ["tx.entity_table", "=", "'civicrm_msg_template'"], ["tx.id", "=", "id"]]],
groupBy: ["tx.language"],
where: [["workflow_name", "IS NOT EMPTY"]],
limit: 25
}).then(function(messageTemplates) {
// do something with messageTemplates array
}, function(failure) {
// handle failure
});
```
backtrace
```
/civicrm/Civi/Api4/Query/Api4SelectQuery.php(655): CRM_Core_Error::backtrace("backTrace", TRUE)
#1
//civicrm/Civi/Api4/Query/Api4SelectQuery.php(600): Civi\Api4\Query\Api4SelectQuery->getField("tx.language", TRUE)
#2 //civicrm/Civi/Api4/Query/Api4SelectQuery.php(378): Civi\Api4\Query\Api4SelectQuery->getExpression("tx.language")
#3 /civicrm/Civi/Api4/Query/Api4SelectQuery.php(152): Civi\Api4\Query\Api4SelectQuery->buildGroupBy()
#4 //civicrm/Civi/Api4/Query/Api4SelectQuery.php(164): Civi\Api4\Query\Api4SelectQuery->getSql()
#5 //civicrm/Civi/Api4/Generic/DAOGetAction.php(111): Civi\Api4\Query\Api4SelectQuery->run()
```