Development issueshttps://lab.civicrm.org/groups/dev/-/issues2020-02-18T19:54:56Zhttps://lab.civicrm.org/dev/core/-/issues/1597Variable type error during import process2020-02-18T19:54:56ZbenmoreassyntVariable type error during import processOverview
----------------------------------------
After upgrading to 5.22.0 importing data using dedupe rules is throwing a fatal PHP error and the import stops.
While this could be caused by a failure either in the data being imported...Overview
----------------------------------------
After upgrading to 5.22.0 importing data using dedupe rules is throwing a fatal PHP error and the import stops.
While this could be caused by a failure either in the data being imported or the specific (custom) dedupe rule being used, it seems like this is behaviour that either shouldn't happen at all, or that a more graceful error should be thrown informing the user of the cause of the problem.
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Import Contacts**.
2. Import CSV file with circa 1000 rows of contact data.
3. Select to update duplicate contacts.
4. Select custom dedupe rule which identifies dupes based on a numeric custom field, name and email address (fields should be allowed to be empty).
4. Click 'Continue' to reach confirmation screen.
6. Start import.
Current behaviour
----------------------------------------
Fatal error thrown within in 2 or 3 seconds. PHP error log shows following error:
```
[15-Feb-2020 11:47:14 America/Toronto] PHP Fatal error: Uncaught TypeError: Argument 1 passed to civicrm_api3() must be of the type string, null given, called in /home/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Dedupe/BAO/Rule.php on line 62 and defined in /home/wordpress/wp-content/plugins/civicrm/civicrm/api/api.php:84
Stack trace:
#0 /home/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Dedupe/BAO/Rule.php(62): civicrm_api3(NULL, 'getfields', Array)
#1 /home/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Dedupe/BAO/RuleGroup.php(172): CRM_Dedupe_BAO_Rule->sql()
#2 /home/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Dedupe/BAO/RuleGroup.php(190): CRM_Dedupe_BAO_RuleGroup->tableQuery()
#3 /home/wordpress/wp-content/plugins/civicrm/civicrm/CRM/Dedupe/Finder.php(127): CRM_Dedupe_BAO_RuleGroup->fillTable()
#4 /home/wordpress/wp-conten in /home/wordpress/wp-content/plugins/civicrm/civicrm/api/api.php on line 84
```
Expected behaviour
----------------------------------------
Contact data should import succesfully
Environment information
----------------------------------------
* __Browser:__ _Firefox 59.0.1/Chrome 78.0.3904/Safari 13_
* __CiviCRM:__ _5.22.0_
* __PHP:__ _7.3_
* __CMS:__ _WordPress 5.3.2_
* __Database:__ _MySQL 5.7.29_
* __Web Server:__ _Apache 2.4.18_
Comments
----------------------------------------
_ In order to complete the import I hacked civicrm/civicrm/CRM/Dedupe/BAO/Rule.php in the following way as a temporary workaround: _
```
At Line 61:
$entity = CRM_Core_DAO_AllCoreTables::getBriefName(CRM_Core_DAO_AllCoreTables::getClassForTable($this->rule_table));
// Start of hack:
if ($entity === NULL){
return;
}
//End of hack
$fields = civicrm_api3($entity, 'getfields', ['action' => 'create'])['values'];
```
This prevents api3 being called with a null value. However I doubt this is a good way to address the problem, and will obviously be overwritten by future updates.
5.22.1https://lab.civicrm.org/dev/core/-/issues/1596unreleased regression - Contribution summary report gives fatal error in mast...2020-02-25T20:25:25ZDaveDunreleased regression - Contribution summary report gives fatal error in master with just the defaultsI think it's from this line https://github.com/civicrm/civicrm-core/pull/16467/files#diff-c2f466cf0d5fef7048b1ec82ec5aaaceR615 which then adds a grouping parameter after WITH ROLLUP, which it doesn't like.I think it's from this line https://github.com/civicrm/civicrm-core/pull/16467/files#diff-c2f466cf0d5fef7048b1ec82ec5aaaceR615 which then adds a grouping parameter after WITH ROLLUP, which it doesn't like.5.24.0https://lab.civicrm.org/dev/core/-/issues/1594Extension unit tests broken in master2020-02-14T23:48:22ZseamusleeExtension unit tests broken in masterOverview
----------------------------------------
Currently unable to run any extension unit tests in master branch
Reproduction steps
----------------------------------------
1. Download Flexmailer extension.
1. try to run unit tests u...Overview
----------------------------------------
Currently unable to run any extension unit tests in master branch
Reproduction steps
----------------------------------------
1. Download Flexmailer extension.
1. try to run unit tests using phpunit6.
1. Tests don't run.
Current behaviour
----------------------------------------
A bunch of notices show up as well
```
PHP Warning: file_get_contents(./xml/version.xml): failed to open stream: No such file or directory in...civicrm/CRM/Core/CodeGen/Util/Xml.php on line 16
PHP Warning: DOMDocument::loadXML(): Empty string supplied as input in...civicrm/CRM/Core/CodeGen/Util/Xml.php on line 17
PHP Warning: simplexml_import_dom(): Invalid Nodetype to import in...civicrm/CRM/Core/CodeGen/Util/Xml.php on line 20
PHP Notice: Trying to get property 'version_no' of non-object in...civicrm/CRM/Core/CodeGen/Main.php on line 79
Parsing schema description ./xml/schema/Schema.xml
PHP Warning: file_get_contents(./xml/schema/Schema.xml): failed to open stream: No such file or directory in...civicrm/CRM/Core/CodeGen/Util/Xml.php on line 16
PHP Warning: DOMDocument::loadXML(): Empty string supplied as input in...civicrm/CRM/Core/CodeGen/Util/Xml.php on line 17
PHP Warning: simplexml_import_dom(): Invalid Nodetype to import in...civicrm/CRM/Core/CodeGen/Util/Xml.php on line 20
Extracting database information
PHP Notice: Trying to get property 'name' of non-object in...civicrm/CRM/Core/CodeGen/Specification.php on line 70
Extracting table information
PHP Notice: Trying to get property 'tables' of non-object in...civicrm/CRM/Core/CodeGen/Specification.php on line 96
PHP Warning: Invalid argument supplied for foreach() in...civicrm/CRM/Core/CodeGen/Specification.php on line 96
```
Expected behaviour
----------------------------------------
PHP Unit tests run
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:__ _Master_
* __PHP:__ _7.1_
* __CMS:__ _Drupal 7.69
Comments
----------------------------------------
ping @totten @eileen5.24.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/1593E_WARNING on New/Edit Tag screen2020-02-16T04:00:24ZDaveDE_WARNING on New/Edit Tag screen`Warning: count(): Parameter must be an array or an object that implements Countable in include() (line 71 of blah\...\templates_c\en_US\%%4D\4D9\4D941223%%Edit.tpl.php`
I think this is new in master or 5.23 and at first glance it's bec...`Warning: count(): Parameter must be an array or an object that implements Countable in include() (line 71 of blah\...\templates_c\en_US\%%4D\4D9\4D941223%%Edit.tpl.php`
I think this is new in master or 5.23 and at first glance it's because $parent_tags is null when the template tries to do `{if $parent_tags|@count > 0}`
(Linking to 5.22.0 since then the ref won't change but I'm not sure yet if this affects 5.22.)
https://github.com/civicrm/civicrm-core/blob/5.22.0/templates/CRM/Tag/Form/Edit.tpl#L60
I might first look into why this changed to see if it's something deeper but the obvious quick fix is to check the variable exists first before applying count. Also this is a good candidate for a test as described at https://lab.civicrm.org/dev/core/issues/1536.5.24.0https://lab.civicrm.org/dev/core/-/issues/1592Advanced Search: "active period" filter regression2020-02-15T21:47:10ZbgmAdvanced Search: "active period" filter regressionTo reproduce:
* Go to: https://dmaster.demo.civicrm.org/civicrm/contact/search/advanced?reset=1
* Under "Relationships", select "Relationship Status" = Active.
* Click search, notice you get 85 results.
Now under the relationships,
* ...To reproduce:
* Go to: https://dmaster.demo.civicrm.org/civicrm/contact/search/advanced?reset=1
* Under "Relationships", select "Relationship Status" = Active.
* Click search, notice you get 85 results.
Now under the relationships,
* Select "Relationship Status" = "All"
* then "Active Period" = "Today"
This should give the same number of results, but it returns zero results.
I traced it to a regression caused by 6245de60a716da2d16f124233789d57c48e49a45
https://github.com/civicrm/civicrm-core/pull/16287
I'm not sure how to fix this except from checking: `$fieldSpec['name'] == 'relation_active_period_date'` to reverse the date conditions.5.23.1https://lab.civicrm.org/dev/core/-/issues/1591Vendor pruning should support D8-style root-projects2023-02-12T05:03:26ZtottenVendor pruning should support D8-style root-projectsOverview
----------------------------------------
In `civicrm-core:composer.json`, there are a series of script declarations. One of the most common elements of these scripts is that the clean out example files.
Example use-case
------...Overview
----------------------------------------
In `civicrm-core:composer.json`, there are a series of script declarations. One of the most common elements of these scripts is that the clean out example files.
Example use-case
----------------------------------------
There are two basic scenarios for deploying `civicrm-core.git`:
* (A) CiviCRM as root-project/application
```bash
git clone https://github.com/civicrm/civicrm-core.git civircm
cd civicrm
composer install
```
* (B) CiviCRM as library/dependency in another root-project/application
```bash
composer create-project drupal/recommended-project my-site
cd my-site
composer require civicrm/civicrm-core
```
Current behavior
----------------------------------------
In scenario (A), various files (examples/docs/tests) under `vendor` are cleaned out.
In scenario (B), they are not.
For a list of specific items that are currently cleaned, see:
```
grep safe_delete tools/scripts/composer/*.sh
```
Proposed behavior
----------------------------------------
1. It should be possible to clean out these artifacts in both scenarios.
2. The cleaning mechanism and rules should be the same (shared) in both scenarios.
3. The cleaning should be optional - so that (a) it is possible to create a development-oriented build and (b) it is possible to choose some cleaner that is designated by the CMS community.
4. (Low priority) The cleaning should be enabled by default (i.e. opt-out).
5. When cleaning scenario (B), one should converge on identical code in each sub-case: (i) creating a project and adding CiviCRM to it anew; (ii) taking an existing `composer.json` (with CiviCRM and everything else), deleting the `vendor/` tree, and re-running `composer install`; (iii) performing updates on an existing project.
Many of th rules in `tools/scripts/composer/*.sh` could potentially be replaced by some kind of composer-based cleaning plugin.
Comments
----------------------------------------
The list of [composer plugins](https://github.com/jakoch/awesome-composer) includes a few focused on cleaning up `vendor`. I haven't fully assessed how these match up with the proposed behavior.
* https://github.com/barryvdh/composer-cleanup-plugin
* https://github.com/dg/composer-cleaner
* https://github.com/lichunqiang/composer-ignore-plugin
* https://github.com/liborm85/composer-vendor-cleaner
* https://github.com/drupal/core-vendor-hardening
If you were comparing (A) w/d7 against (B) w/D8, you might observe that cleaning artifacts is *less* important in the latter case because `vendor` is hidden. That means `*.php` files aren't web-accessible. Never-the-less, even in (B), there is a file-sync operation to publish assets, and this could publish example/test/doc files in JS/CSS/etc format. Vulnerabilities in that case are less likely and more constrained (e.g. it probably cannot execute arbitrary PHP code; but OTOH the browser trusts JS files based on their origin, and that might be exploitable in some poorly written JS demo file).https://lab.civicrm.org/dev/core/-/issues/1590Scheduled reminder: "Additional recipients" receive reminders under circumsta...2023-12-01T05:03:19ZJonGoldScheduled reminder: "Additional recipients" receive reminders under circumstances where they ought not toThis is a superset of event#28. The issue seems to be more generalized than I'd realized.
"Additional recipients" will receive reminders on events (and presumably other entities) that have been deleted. To test:
* Create a scheduled r...This is a superset of event#28. The issue seems to be more generalized than I'd realized.
"Additional recipients" will receive reminders on events (and presumably other entities) that have been deleted. To test:
* Create a scheduled reminder for an existing event.
* Under *Limit or Add Recipients*, select **Also Include** and add a group or contact(s).
* Delete the event.
* Run the scheduled reminders job.
**Expected result**
No scheduled reminder.
**Actual result**
Scheduled reminder to the "additional recipients".
### Why it happens
Scheduled reminder recipients are decided in two passes. First, whomever qualifies by the "normal" criteria (e.g. event participants) and a second pass for anyone in "Additional Participants".
The first pass is specific to the type of reminder (event, membership, contribution); the second is the same code regardless. This caused event#28; the "additional recipients" pass, by virtue of not being event/membership/etc-specific, wasn't aware that events have the special case of templates, which other entities don't. It also doesn't check for deleted entities.
The solution is to add a new method to the `Civi\ActionSchedule\MappingInterface` interface - a `sendToAdditional` method that returns a boolean. Then, each class that implements this interface can abort the "additional recipients" pass in an entity-specific way. Besides deleted entities and event templates, contributions have templates as well now, so we should check for that.https://lab.civicrm.org/dev/core/-/issues/1589"DB Error: unknown error" when merging if duplicate contact has null created_...2020-02-14T20:27:09ZIan Wilson"DB Error: unknown error" when merging if duplicate contact has null created_dateThis is partly a data quality issue on our end, but when merging two contacts a DB error is thrown if the one on the left has a null created date (the default value for the column) and the one on the right doesn't.
I am able to reproduc...This is partly a data quality issue on our end, but when merging two contacts a DB error is thrown if the one on the left has a null created date (the default value for the column) and the one on the right doesn't.
I am able to reproduce this with latest CiviCRM on https://dmaster.demo.civicrm.org
**Steps to reproduce on dmaster.demo.civicrm.org:**
start the merge:
* get a listing of contacts
* go to find contacts - https://dmaster.demo.civicrm.org/civicrm/contact/search?reset=1
* click search
* check box next to two individual contacts (not organizations)
* select "merge contacts" from actions menu
* get the contact id for the contact on the left (hover over the name and remember the value of cid in the url that pops up)
use the api to set created_date to null for the duplicate contact:
* open a new tab and go to - https://dmaster.demo.civicrm.org/civicrm/api3
* entity: contact
* action: create
* parameter: contact id = {{ duplicate contact id }}
* parameter: created date = "" (two double quotes)
* execute
perform the merge:
* go back to the tab with the merge page and refresh it - "created" should now be empty on the duplicate
* click merge
**Information from logs:**
```sql
UPDATE civicrm_contact SET created_date = '' WHERE id = 123 [nativecode=1292 ** Incorrect datetime value: '' for column `dev_civicrm`.`civicrm_contact`.`created_date` at row 1]
```5.24.0https://lab.civicrm.org/dev/core/-/issues/1588Positive integer expected for recurring interval even when user is not making...2020-02-16T20:02:17Zfreeform.stephPositive integer expected for recurring interval even when user is not making a recurring contributionOverview
----------------------------------------
If you enabled the recurring option "Support recurring intervals" on a contribution page you can no longer submit the contribution form unless you enter a value for the recurring interval...Overview
----------------------------------------
If you enabled the recurring option "Support recurring intervals" on a contribution page you can no longer submit the contribution form unless you enter a value for the recurring interval, even if you have not selected to make a recurring contribution.
Error: recurFrequencyInterval must be a positive integer
This appears to have been introduced with release 5.21.x. This is most likely a result of the work that was released in 5.21.0 with respect to the new class Civi\Payment\PropertyBag.
Reproduction steps (on demo)
----------------------------------------
1. duplicate the existing donation form
1. disable the pledge section
1. enable recurring contributions section, select "Support recurring intervals" + "Offer installments"
1. test the form, leaving the recurring options blank (ie attempt to make a single one-time donation)
Current behaviour
----------------------------------------
Returns:
```
Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred. recurFrequencyInterval must be a positive integer"
```
Expected behaviour
----------------------------------------
Should be able to submit a one-time donation without expectation of a recurring interval
Environment information
----------------------------------------
Running 5.21.1 on WordPress 5.3.2.
This is reproducible on https://dmaster.demo.civicrm.org/ (CiviCRM 5.23.alpha1) so is independent of CMS.
Comments
----------------------------------------
First reported on StackExchange: https://civicrm.stackexchange.com/questions/34436/positive-integer-expected-for-recurring-interval-even-when-user-is-not-making-a5.23.0https://lab.civicrm.org/dev/drupal/-/issues/106Latest master (5.23) code not working with roundearth/drupal 8 because resour...2020-04-02T19:36:52ZDaveDLatest master (5.23) code not working with roundearth/drupal 8 because resource urls are formed incorrectlyIt seems at least partly from the changes here https://github.com/civicrm/civicrm-core/pull/16407#pullrequestreview-350540291. When I remove that block the resources start loading again except for a few places, like the "include profiles...It seems at least partly from the changes here https://github.com/civicrm/civicrm-core/pull/16407#pullrequestreview-350540291. When I remove that block the resources start loading again except for a few places, like the "include profiles" tab when configuring a contribution page.
What's happening is the resource urls are all coming out like
```
<script src="http://example.org/full/filesystem/path/to/vendor/civicrm/civicrm-core/bower_components/jquery/dist/jquery.min.js">
```
I first tried updating my drupal 8 dev site, then I started fresh like below and had the same problem, so it wasn't specific to my earlier testing environment.
* Installed roundearth and got a working 5.22 install.
* Then updated it to master - using [this method](https://civicrm.stackexchange.com/a/34321/181).
* Briefly, hack roundearth Handler.php to understand that dev-master means the NIGHTLY tarball, then composer require civicrm/civicrm-core:dev-master.
* I had to adjust the require command slightly for civicrm-setup and zetamail (civicrm/civicrm-setup:^0.4.x-dev zetacomponents/mail:^1.9).
Does the latest master require a different resources install path or different settings from what roundearth uses for drupal 8? @totten?https://lab.civicrm.org/dev/financial/-/issues/117Payment edit link cannot be modified2020-02-11T20:07:09Zadrian@roomify.usPayment edit link cannot be modifiedOn the 'View Contribution' page, the payment details edit link is not currently modifiable via hook_civicrm_links. Related issue: https://issues.civicrm.org/jira/browse/CRM-13434
I'll be submitting a PR.On the 'View Contribution' page, the payment details edit link is not currently modifiable via hook_civicrm_links. Related issue: https://issues.civicrm.org/jira/browse/CRM-13434
I'll be submitting a PR.5.24.0https://lab.civicrm.org/dev/core/-/issues/1585Payment Notification sent wrongly2023-02-11T05:03:24ZpbatroffPayment Notification sent wronglyOverview
----------------------------------------
When the <s>system</s> recurring contribution is configured to *NOT* send Email notification, it is still triggered via PayPal hook, when a Expired notification is received.
Reproduction...Overview
----------------------------------------
When the <s>system</s> recurring contribution is configured to *NOT* send Email notification, it is still triggered via PayPal hook, when a Expired notification is received.
Reproduction steps
----------------------------------------
Hard to reproduce, since it takes the recurring amount time to reproduce the issue. But the general procedure would be:
1. Configure civicrm to not send emails on contributions start/end (civicrm_contribution_recur - is_email_receipt)
2. Create a recurring Paypal donation
3. Log the donation in the system
4. Cancel recurring donation
5. Paypal sends out a webhook event, the Contribution is expired, but an email is sent nevertheless.
Current behaviour
----------------------------------------
An Email is sent even though CiviCRM is configured to not send emails for contributions.
Expected behaviour
----------------------------------------
On a cancelled contribution, if no emailing for contributions is configured, no mail should be sent.
Environment information
----------------------------------------
- Happened in 5.19.4
- Code seems to be the same in current master.
- Relevant code pieces:
[CRM/Core/Payment/PayPalProIPN.php:150](https://lab.civicrm.org/dev/core/blob/master/CRM/Core/Payment/PayPalProIPN.php#L250) in case of a paypal notification `$sendNotification` is set to TRUE, not checking if emailing is configured or not.
Then in [CRM/Contribute/BAO/ContributionPage.php:L544](https://lab.civicrm.org/dev/core/blob/master/CRM/Contribute/BAO/ContributionPage.php#L544), if an id for the recurring BAO object is present, `$emailReceipe` is set to TRUE. ID is set in case of a webhook event.
Comments
----------------------------------------
The code comment says
> // This means we are coming from back-office - ie. no page ID, but recurring.
> // Ideally this information would be passed into the function clearly rather than guessing by convention.
But this will be accessed via paypal [webhook](https://lab.civicrm.org/dev/core/blob/master/CRM/Core/Payment/PayPalProIPN.php#L272). It should either be tested in PayPalProIPN.php, or the logic in ContributionPage needs to be adjusted. The check for the id seems flawed.
I'm having a hard time reproducing this, so I wanted to gather my findings and put them up for review! thanks for looking into this.https://lab.civicrm.org/dev/core/-/issues/1584Allow payment processors to indicate whether they require an email address2020-02-24T21:27:10Zaydunsaidan.saunders@squiffle.ukAllow payment processors to indicate whether they require an email addressOverview
----------------------------------------
Payment processors in webforms are assumed to require an email address, but that is not necessarily true, for example in the case of the Cash/Check payment processor. Currently there is ...Overview
----------------------------------------
Payment processors in webforms are assumed to require an email address, but that is not necessarily true, for example in the case of the Cash/Check payment processor. Currently there is no way for the payment processor to indicate that it does not require an address.
Proposed changes
----------------
~~Create CRM_Core_Payment::requiresEmailAddress() to return TRUE, but can be overridden by processors - https://github.com/civicrm/civicrm-core/pull/16503~~
~~Adjust wf_crm_webform_postprocess.inc to check requiresEmailAddress() (if method is defined) - https://github.com/colemanw/webform_civicrm/pull/292~~
~~Override requiresEmailAddress() in Cash processor - https://lab.civicrm.org/extensions/cashpp/blob/master/CRM/Core/Payment/Manual/Cash.php#L8-10~~
[Updated as per Eileen's comment]
Create CRM_Core_Payment::supportsNoEmailProvided() to return FALSE, but can be overridden by processors - https://github.com/civicrm/civicrm-core/pull/16503
Adjust wf_crm_webform_postprocess.inc to check $processor->supports('NoEmailProvided')- https://github.com/colemanw/webform_civicrm/pull/292
Override supportsNoEmailProvided() in Manual processor to return TRUE
5.24.0aydunsaidan.saunders@squiffle.ukaydunsaidan.saunders@squiffle.ukhttps://lab.civicrm.org/dev/core/-/issues/1583API v4 returning incorrect count of contributions under certain WHERE conditions2020-02-17T02:21:40ZjamieAPI v4 returning incorrect count of contributions under certain WHERE conditionsThe database has three contributions with the `contribution_recur_id` set to 19.
When I query for these via apiv4 using just the `contribution_recur_id`, I get three results from the database (and the `first()` function works properly)....The database has three contributions with the `contribution_recur_id` set to 19.
When I query for these via apiv4 using just the `contribution_recur_id`, I get three results from the database (and the `first()` function works properly).
When I query and limit to those with `is_template` set to 1 (there should be no matching results), I get a count of 1, but NULL when I call `first()`.
Here's the data:
```
MariaDB [ptp]> SELECT * FROM civicrm_contribution WHERE contribution_recur_id =19;
+------+------------+-------------------+----------------------+-----------------------+---------------------+-----------------------+--------------+------------+------------+-----------------------------+----------------------------------+----------+-------------+---------------+---------------------+---------------+---------------------------------------------------------------------------------+--------------+-----------------------+---------+--------------+------------------------+------------+--------------+-------------+------------+---------------+--------------------------+----------------+-------------+
| id | contact_id | financial_type_id | contribution_page_id | payment_instrument_id | receive_date | non_deductible_amount | total_amount | fee_amount | net_amount | trxn_id | invoice_id | currency | cancel_date | cancel_reason | receipt_date | thankyou_date | source | amount_level | contribution_recur_id | is_test | is_pay_later | contribution_status_id | address_id | check_number | campaign_id | tax_amount | creditnote_id | revenue_recognition_date | invoice_number | is_template |
+------+------------+-------------------+----------------------+-----------------------+---------------------+-----------------------+--------------+------------+------------+-----------------------------+----------------------------------+----------+-------------+---------------+---------------------+---------------+---------------------------------------------------------------------------------+--------------+-----------------------+---------+--------------+------------------------+------------+--------------+-------------+------------+---------------+--------------------------+----------------+-------------+
| 3928 | 10459 | 2 | 14 | 1 | 2019-12-02 13:07:59 | 0.00 | 296.00 | 8.88 | 287.12 | in_1FlKFWAwDzuDdbFCuWUlA4EZ | 0f3dd1eda0400becb9ecd33c58d28ae8 | USD | NULL | 0 | 2019-12-02 13:07:56 | NULL | Online Contribution: PowerBase Subscription Payment with Monthly Payment Option | NULL | 19 | 0 | 0 | 1 | 24745 | NULL | NULL | NULL | NULL | NULL | NULL | 0 |
| 3951 | 10459 | 2 | 14 | 1 | 2020-01-02 13:08:03 | 0.00 | 296.00 | 8.88 | 287.12 | in_1FwZ1bAwDzuDdbFCXoBfw8UM | NULL | USD | NULL | NULL | 2020-01-02 14:13:42 | NULL | Online Contribution: PowerBase Subscription Payment with Monthly Payment Option | NULL | 19 | 0 | 0 | 1 | NULL | NULL | NULL | NULL | NULL | NULL | NULL | 0 |
| 3999 | 10459 | 2 | 14 | 1 | 2020-02-02 13:08:03 | 0.00 | 296.00 | 8.88 | 287.12 | in_1G7nnbAwDzuDdbFCvncHVNPH | NULL | USD | NULL | NULL | 2020-02-07 15:03:30 | NULL | Online Contribution: PowerBase Subscription Payment with Monthly Payment Option | NULL | 19 | 0 | 0 | 1 | NULL | NULL | NULL | NULL | NULL | NULL | NULL | 0 |
+------+------------+-------------------+----------------------+-----------------------+---------------------+-----------------------+--------------+------------+------------+-----------------------------+----------------------------------+----------+-------------+---------------+---------------------+---------------+---------------------------------------------------------------------------------+--------------+-----------------------+---------+--------------+------------------------+------------+--------------+-------------+------------+---------------+--------------------------+----------------+-------------+
3 rows in set (0.001 sec)
MariaDB [ptp]>
```
Here is the test code:
```
<?php
$res = \Civi\Api4\Contribution::get()
->setCheckPermissions(FALSE)
->addWhere('contribution_recur_id', '=', 19)
->execute();
echo "=== NOTE Results are correct ===\n\n";
echo "count is: " . $res->count() . "\n";
echo "First...\n";
print_r($res->first());
foreach ($res as $r) {
print_r($r);
}
$contribution_recur_id = 19;
$res = \Civi\Api4\Contribution::get()
->setCheckPermissions(FALSE)
->addWhere('contribution_recur_id', '=', 19)
->addWhere('is_template', '=', 1)
->execute();
echo "\n\n";
echo "=== NOTE: count is one, but no results from first() === \n";
echo "count is: " . $res->count() . "\n";
echo "First...\n";
print_r($res->first());
foreach ($res as $r) {
// No output from this call.
print_r($r);
}
```
And here is the output when running that code via `cv`:
```
=== NOTE Results are correct ===
count is: 4
First...
Array
(
[id] => 3928
[contact_id] => 10459
[financial_type_id] => 2
[contribution_page_id] => 14
[payment_instrument_id] => 1
[receive_date] => 2019-12-02 13:07:59
[non_deductible_amount] => 0.00
[total_amount] => 296.00
[fee_amount] => 8.88
[net_amount] => 287.12
[trxn_id] => in_1FlKFWAwDzuDdbFCuWUlA4EZ
[invoice_id] => 0f3dd1eda0400becb9ecd33c58d28ae8
[invoice_number] =>
[currency] => USD
[cancel_date] =>
[cancel_reason] => 0
[receipt_date] => 2019-12-02 13:07:56
[thankyou_date] =>
[source] => Online Contribution: PowerBase Subscription Payment with Monthly Payment Option
[amount_level] =>
[contribution_recur_id] => 19
[is_test] => 0
[is_pay_later] => 0
[contribution_status_id] => 1
[address_id] => 24745
[check_number] =>
[campaign_id] =>
[creditnote_id] =>
[tax_amount] =>
[revenue_recognition_date] =>
[is_template] => 0
)
Array
(
[id] => 3928
[contact_id] => 10459
[financial_type_id] => 2
[contribution_page_id] => 14
[payment_instrument_id] => 1
[receive_date] => 2019-12-02 13:07:59
[non_deductible_amount] => 0.00
[total_amount] => 296.00
[fee_amount] => 8.88
[net_amount] => 287.12
[trxn_id] => in_1FlKFWAwDzuDdbFCuWUlA4EZ
[invoice_id] => 0f3dd1eda0400becb9ecd33c58d28ae8
[invoice_number] =>
[currency] => USD
[cancel_date] =>
[cancel_reason] => 0
[receipt_date] => 2019-12-02 13:07:56
[thankyou_date] =>
[source] => Online Contribution: PowerBase Subscription Payment with Monthly Payment Option
[amount_level] =>
[contribution_recur_id] => 19
[is_test] => 0
[is_pay_later] => 0
[contribution_status_id] => 1
[address_id] => 24745
[check_number] =>
[campaign_id] =>
[creditnote_id] =>
[tax_amount] =>
[revenue_recognition_date] =>
[is_template] => 0
)
Array
(
[id] => 3951
[contact_id] => 10459
[financial_type_id] => 2
[contribution_page_id] => 14
[payment_instrument_id] => 1
[receive_date] => 2020-01-02 13:08:03
[non_deductible_amount] => 0.00
[total_amount] => 296.00
[fee_amount] => 8.88
[net_amount] => 287.12
[trxn_id] => in_1FwZ1bAwDzuDdbFCXoBfw8UM
[invoice_id] =>
[invoice_number] =>
[currency] => USD
[cancel_date] =>
[cancel_reason] =>
[receipt_date] => 2020-01-02 14:13:42
[thankyou_date] =>
[source] => Online Contribution: PowerBase Subscription Payment with Monthly Payment Option
[amount_level] =>
[contribution_recur_id] => 19
[is_test] => 0
[is_pay_later] => 0
[contribution_status_id] => 1
[address_id] =>
[check_number] =>
[campaign_id] =>
[creditnote_id] =>
[tax_amount] =>
[revenue_recognition_date] =>
[is_template] => 0
)
Array
(
[id] => 3999
[contact_id] => 10459
[financial_type_id] => 2
[contribution_page_id] => 14
[payment_instrument_id] => 1
[receive_date] => 2020-02-02 13:08:03
[non_deductible_amount] => 0.00
[total_amount] => 296.00
[fee_amount] => 8.88
[net_amount] => 287.12
[trxn_id] => in_1G7nnbAwDzuDdbFCvncHVNPH
[invoice_id] =>
[invoice_number] =>
[currency] => USD
[cancel_date] =>
[cancel_reason] =>
[receipt_date] => 2020-02-07 15:03:30
[thankyou_date] =>
[source] => Online Contribution: PowerBase Subscription Payment with Monthly Payment Option
[amount_level] =>
[contribution_recur_id] => 19
[is_test] => 0
[is_pay_later] => 0
[contribution_status_id] => 1
[address_id] =>
[check_number] =>
[campaign_id] =>
[creditnote_id] =>
[tax_amount] =>
[revenue_recognition_date] =>
[is_template] => 0
)
=== NOTE: count is one, but no results from first() ===
count is: 1
First...
www-data@fecbf38eb0bb:~/powerbase$
```https://lab.civicrm.org/dev/core/-/issues/1582Display preferences settings "Do not notify assignees for" and "Include ICal ...2023-02-25T05:03:39ZDaveDDisplay preferences settings "Do not notify assignees for" and "Include ICal Invite to Activity Assignees" are only implemented in the form layerI'm unlikely to work on this but logging that these two display preferences are tied to the form layer and only referenced (either directly or indirectly) via CRM/Activity/Form/Activity.php, and so are ignored when using the api.
This i...I'm unlikely to work on this but logging that these two display preferences are tied to the form layer and only referenced (either directly or indirectly) via CRM/Activity/Form/Activity.php, and so are ignored when using the api.
This is not recent. I'm sure it has always been this way.https://lab.civicrm.org/dev/core/-/issues/1580Allow to search on contribution id2023-03-10T06:17:56ZyashodhaAllow to search on contribution idAllow to search on contribution idAllow to search on contribution id5.28.1yashodhayashodhahttps://lab.civicrm.org/dev/financial/-/issues/116Cancelling a payment thru the API2020-02-14T19:24:31ZalicefruminCancelling a payment thru the APIWhen a user updates a Contribution with the status "Completed" to have the status "Cancelled" thru the UI (or the API using Contribution.create and an id) a negative payment is created with a status of "Cancelled" like in the screen shot...When a user updates a Contribution with the status "Completed" to have the status "Cancelled" thru the UI (or the API using Contribution.create and an id) a negative payment is created with a status of "Cancelled" like in the screen shot below:
![cancelled](/uploads/04c0dcd8c7798a42184e2f0a902b1697/cancelled.png)
This works fine if you are cancelling a full contribution however there is now way in the UI or the API to cancel one of multiple payments.
For Example:
+ a user has a $10 contribution with two payments one for $2 and one for $8
+ The user wants to cancel the $2 contribution
If you cancel the contribution it will record a negative payment of $10.
IF you do `Payment.cancel` it will record a negative payment of $2 with a status "Refunded"
Using `FinancialTrxn.create` you can create a payment of -$2 with a status of "Cancelled" but it will not update the contribution status AND when you update the contribution status to "Cancelled" a new negative payment (of -$10) will be created with a status of cancelled.
PROPOSED SOLUTIONS:
+ Update the `Contribution.create` api so that there is a flag to not create new payments.
+ Allow 'status_id' to be passed to the Payment API and update the contribution and payment statuses based on the status_id if providedhttps://lab.civicrm.org/dev/core/-/issues/1579CRM_Core_Payment_PayPalProIPN should not call getPayPalPaymentProcessorID() i...2020-08-06T21:15:00ZAllenShawCRM_Core_Payment_PayPalProIPN should not call getPayPalPaymentProcessorID() if processor_id is clearly provided in URLWhen processing PayPal Pro IPN messages, `CRM_Core_Payment_PayPalProIPN::main()` attempts to determine the payment processor ID by calling `self::getPayPalPaymentProcessorID()` ([code reference](https://github.com/civicrm/civicrm-core/bl...When processing PayPal Pro IPN messages, `CRM_Core_Payment_PayPalProIPN::main()` attempts to determine the payment processor ID by calling `self::getPayPalPaymentProcessorID()` ([code reference](https://github.com/civicrm/civicrm-core/blob/990a93e05dceeba0f6e1872a2d8081e06825d3d9/CRM/Core/Payment/PayPalProIPN.php#L460)), despite having already determined the processor ID `xx` based on the url `civicrm/payment/ipn/xx ` earlier ([here](https://github.com/civicrm/civicrm-core/blob/990a93e05dceeba0f6e1872a2d8081e06825d3d9/CRM/Core/Payment/PayPalImpl.php#L711), then passed in [here](https://github.com/civicrm/civicrm-core/blob/990a93e05dceeba0f6e1872a2d8081e06825d3d9/CRM/Core/Payment/PayPalImpl.php#L726))
This method immediately logs a warning message, "Unreliable method used to get payment_processor_id for PayPal Pro IPN - this will cause problems if you have more than one instance", which seems needless if the processor_id is already provided in the url.
I propose skipping this call if processor_id is already known.https://lab.civicrm.org/dev/core/-/issues/1578API4: 500 error on chain with custom field2020-07-19T20:07:08ZJonGoldAPI4: 500 error on chain with custom fieldIn API Explorer, I created two API chained commands. When I chain using the contact ID, it works; with a contact reference custom field, it fails.
**Works**
```php
$contributions = \Civi\Api4\Contribution::get()
->addSelect('contact_...In API Explorer, I created two API chained commands. When I chain using the contact ID, it works; with a contact reference custom field, it fails.
**Works**
```php
$contributions = \Civi\Api4\Contribution::get()
->addSelect('contact_id')
->setChain([
'name_me_0' => ['Contact', 'get', ['where' => [['id', '=', '$contact_id']]], 0],
])
->execute();
foreach ($contributions as $contribution) {
// do something
}
```
**Fails**
```php
$contributions = \Civi\Api4\Contribution::get()
->setSelect([
'contact_id',
])
->addWhere('contact_id', '=', 127364)
->addWhere('contribution_status.value', '!=', 'Pending')
->addOrderBy('receive_date', 'ASC')
->setChain([
'name_me_1' => ['Contact', 'get', ['where' => [['id', '=', '$gift_details.Acknowledgee']]], 0],
])
->setCheckPermissions(FALSE)
->execute();
foreach ($contributions as $contribution) {
// do something
}
```
![Selection_803](/uploads/06edff3ad38a54a935f0d70cea93d5fe/Selection_803.png)https://lab.civicrm.org/dev/core/-/issues/1577Custom Group Types not filterable2020-02-10T04:27:09ZMonish DebCustom Group Types not filterableOn Manage groups, you can filter the group list by group type (e.g. Mailing List, Access Control). If you add an additional group type (add value to the respective option group). that works fine when managing groups (i.e. you can save th...On Manage groups, you can filter the group list by group type (e.g. Mailing List, Access Control). If you add an additional group type (add value to the respective option group). that works fine when managing groups (i.e. you can save the record with the custom group), but although the option is displayed in manage groups, the filter does not work. there must be some hardcoding for that filter field.
Issue:
![after](/uploads/09f8d3fbc1f672f23a297c1c9d5b999b/after.gif)
Custom group type filter doesn't work
Proposed fix:
Currently, the custom group type is available to choose as filter in 'Manage Group' but doesn't filter the list of groups. Fix the code to allow filtering of groups on basis of custom group type.5.24.0Monish DebMonish Deb