CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-10-31T17:07:22Zhttps://lab.civicrm.org/dev/core/-/issues/3940Method and Tracking not set from API4 for Subscription History when creating ...2022-10-31T17:07:22ZlarsssandergreenMethod and Tracking not set from API4 for Subscription History when creating or updating GroupContactMethod and Tracking can be specified when creating or updating a GroupContact in API4 (with a default Method of API). However, these are always set as null for the Subscription History that is created.
I've been doing some debugging to ...Method and Tracking can be specified when creating or updating a GroupContact in API4 (with a default Method of API). However, these are always set as null for the Subscription History that is created.
I've been doing some debugging to follow these variables through the process and can see where this is going wrong, but am not clear on how this should actually work. The Subscription History is created by a [hook_post](https://github.com/civicrm/civicrm-core/blob/902fc38d0d6cd9d09ee02f30cc6621747151a06a/CRM/Contact/BAO/GroupContact.php#L39). The hook isn't even trying to set the Method and Tracking, nor does it have access to these variables (they are there when the GroupContact is created, but they aren't used for that).
I'm not clear on how these variables are supposed to get from the API call to the hook here. Happy to implement a fix, but not sure I understand how this is supposed to work or if we need to use an entirely different approach. I will also do the same with the delete action, which [I'm adding Subscription History to](https://github.com/civicrm/civicrm-core/pull/24804), so I'm looking for an approach which will also work for delete.https://lab.civicrm.org/dev/core/-/issues/3896api.Contact.create happy to create invalid employer relationship2022-10-20T07:25:22Zkonadaveapi.Contact.create happy to create invalid employer relationshipOverview
----------------------------------------
api.Contact.create does not check that the relationship between `employer_id` and the contact is valid.
Reproduction steps
----------------------------------------
Reproduced on dmaster....Overview
----------------------------------------
api.Contact.create does not check that the relationship between `employer_id` and the contact is valid.
Reproduction steps
----------------------------------------
Reproduced on dmaster.demo using combo of UI and API 3 Explorer. Showing as command line here to better illustrate.
```bash
$ cv api Contact.create first_name="Mickey" last_name="Mouse" email="mickey.mouse@example.com" contact_type="Individual"
{
"is_error": 0,
"version": 3,
"count": 1,
"id": 9,
"values": {...}
}
$ cv api Contact.create first_name="Minnie" last_name="Mouse" email="minnie.mouse@example.com" contact_type="Individual"
{
"is_error": 0,
"version": 3,
"count": 1,
"id": 10,
"values": {...}
}
$ cv api RelationshipType.getsingle name_b_a="Employer of" return="id,contact_type_b"
{
"id": "5",
"contact_type_b": "Organization"
}
$ cv api Relationship.create contact_id_a="9" contact_id_b="10" relationship_type_id="5"
{
"tip": "add debug=1 to your API call to have more info about the error",
"is_error": 1,
"error_message": "Invalid Relationship"
}
$ cv api Contact.create id="9" employer_id="10"
{
"is_error": 0,
"version": 3,
"count": 1,
"id": 9,
"values": {...}
}
$ cv api Relationship.get contact_id_a="9"
{
"is_error": 0,
"version": 3,
"count": 1,
"id": 5,
"values": {
"5": {
"id": "5",
"contact_id_a": "9",
"contact_id_b": "10",
"relationship_type_id": "5",
"is_active": "1",
"is_permission_a_b": "0",
"is_permission_b_a": "0",
"created_date": "2022-10-05 19:48:23",
"modified_date": "2022-10-05 19:48:23"
}
}
}
```
Current behaviour
----------------------------------------
An invalid relationship is created. On the contact summary screen, an employer may or may not be listed, but it's unlikely to be the invalid contact (i.e. it lists a unrelated org instead).
Expected behaviour
----------------------------------------
The API call should fail for the same reason as api.Relationship.create.
Environment information
----------------------------------------
Confirmed on dmaster.demo, and a local vanilla install of D9/Civi 5.48.2.https://lab.civicrm.org/dev/core/-/issues/3889API4 dates entered without time can give unexpected results2022-10-25T11:50:59ZlarsssandergreenAPI4 dates entered without time can give unexpected resultsFor a datetime field, any date in an API call is converted to a datetime (midnight on the date in question). This can give unexpected results for gets, especially using Search Kit or Form Builder, where users probably aren't thinking abo...For a datetime field, any date in an API call is converted to a datetime (midnight on the date in question). This can give unexpected results for gets, especially using Search Kit or Form Builder, where users probably aren't thinking about dates versus datetimes. These results also aren't consistent with what you get from Advanced Search or other searches.
For example, searching for a contribution with receive_date = 2022-01-01 does not return all contributions received on that date. It only returns contributions received at exactly midnight, i.e. with receive_date = 20220101000000.
Similar issues exist for other operators, like !=, > (will include the date), <= (won't include the date), BETWEEN and NOT BETWEEN (will include the from date, but not the to date), and IN and NOT IN.
The simplest solution would be to put a SQL DATEFORMAT() around the database date field when the date does not include a time and use a Ymd format. This wouldn't work for BETWEEN or IN when one date includes a time and the other doesn't though.
Or if we don't want to change the query, another approach would be to check absolute dates entered into the API to see if they include a time component or not.
- If they include a time, proceed as usual.
- If they don't include times, for all operators except = and !=/<>, set the time component or components depending on the operator (e.g. for BETWEEN set 000000 for the from date, 235959 for the to date).
- For = or !=, switch the operator to BETWEEN or NOT BETWEEN, set the from date to 000000 and the to date to 235959.
- For IN and NOT IN, I'm not sure there's an easy solution in this case. We'd have to convert that to a series of BETWEENs and that's going to be difficult. Is there a good way to warn users that this won't work?
- Not sure what the other operators are supposed to do with dates.
But maybe there's a more elegant solution to this problem. Hoping to get some expert feedback before starting any work on this, since date stuff can be such a quagmire.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/2869Api4 explorer - Clicking the Debug checkbox on or off doesn't change the samp...2023-09-30T05:15:09ZDaveDApi4 explorer - Clicking the Debug checkbox on or off doesn't change the sample codeI think it should add setDebug()?
Issue needs debugging. I tried clicking the debug checkbox to ... oh, right.
FYI @colemanwI think it should add setDebug()?
Issue needs debugging. I tried clicking the debug checkbox to ... oh, right.
FYI @colemanwhttps://lab.civicrm.org/dev/core/-/issues/2788Add tokenlist api2023-09-24T22:53:09ZeileenAdd tokenlist apiWe need an api to call via ajax to determine the available tokens for a given entity. An example is the Scheduled reminders UI which currently presents the tokens for all entities (available or not) but would ideally look up the tokens v...We need an api to call via ajax to determine the available tokens for a given entity. An example is the Scheduled reminders UI which currently presents the tokens for all entities (available or not) but would ideally look up the tokens via ajax once the entity is selected.
I think the hardest part of doing this is agreeing how it should look - eg. entity, action, parameters - eg
```
Civi\Api4\Tokens::list()
->setSchema(['contributionId', 'contactId')
->setWhere('contact_type', '=', 'Organization')
->execute();
```
Possible entity names
- Token
- Tokens
- TokenProcessor
- EntityTokens
Possible actions
-list
- getTokens
- listTokens
Schema - maybe this one is clear cut
And - how do we pass relatively free form tokens such as activity_type_id, contact_type or (possibly in the future) saved_search_id where search kit plays a rolehttps://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/2484Create apiv4 payment api2023-07-13T08:07:37ZeileenCreate apiv4 payment apiIn order to be able to search for payments we need to be able to search for payment rows (rows with is_payment = TRUE) in the financial_trxn table and for the entity bridge to be able to find it's way from there to the contribution table...In order to be able to search for payments we need to be able to search for payment rows (rows with is_payment = TRUE) in the financial_trxn table and for the entity bridge to be able to find it's way from there to the contribution table.
This gives us the ability to say find all contributions with a payment with a payment instrument of 'Check' or find the contribution where the payment's trxn value is y
The scope I would be looking for is
1) can use any of the fields in financial_trxn as a filter
2) can logically link to the contribution (probably through bridge entities)
3) forces 'is_payment' as a filter (only gets payments)
4) the create action calls Payment.create
5) the update & delete actions are blocked
This effectively gives us parity with the v3 api albeit with more options provided through the apiv4 layer itself.
Note that I think this is likely blocked on other feature requests which @mattwire will add notes onhttps://lab.civicrm.org/dev/core/-/issues/1321group.get API (v3- but lets fix for v4) fails to find groups of one group_typ...2023-08-04T20:49:54ZRichgroup.get API (v3- but lets fix for v4) fails to find groups of one group_type if group has multiple typesWe used (5.15) to be able to filter for mailing groups with the API and now we can't. I'm not sure when this came in.
e.g. on a buildkit at 58e7f004e2
```
cv api Group.get return='id,title,group_type'
```
Returns
```
{
"is_error":...We used (5.15) to be able to filter for mailing groups with the API and now we can't. I'm not sure when this came in.
e.g. on a buildkit at 58e7f004e2
```
cv api Group.get return='id,title,group_type'
```
Returns
```
{
"is_error": 0,
"version": 3,
"count": 4,
"values": {
"1": {
"id": "1",
"title": "Administrators",
"group_type": [
"1"
]
},
"2": {
"id": "2",
"title": "Newsletter Subscribers",
"group_type": [
"1",
"2"
]
},
"3": {
"id": "3",
"title": "Summer Program Volunteers",
"group_type": [
"1",
"2"
]
},
"4": {
"id": "4",
"title": "Advisory Board",
"group_type": [
"1",
"2"
]
}
}
}
```
But
```
cv api Group.get return='id,title,group_type' group_type='Mailing List'
cv api Group.get return='id,title,group_type' group_type=2
```
returns none.
<del>On 5.15 Mailing groups are returned properly.</del>