Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-08-11T01:07:11Zhttps://lab.civicrm.org/dev/core/-/issues/3794civicrm_admin_ui: Changes custom field groups to extend Contacts2022-08-11T01:07:11ZJonGoldcivicrm_admin_ui: Changes custom field groups to extend ContactsOverview
----------------------------------------
I have incomplete information, but it seems serious enough to report anyway.
Current behaviour
----------------------------------------
My client informed me that custom field groups ha...Overview
----------------------------------------
I have incomplete information, but it seems serious enough to report anyway.
Current behaviour
----------------------------------------
My client informed me that custom field groups had all changed to extend Contacts. I confirmed this. I then compared the advanced log tables to Apache logs.
There are a large number of calls to `POST /wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fajax%2Fapi4`. Based on the advanced logs, I'm reasonably sure this was my client adjusting the weight of various fields. The first "real" GET request preceding this was `GET /wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fcustom%2Fgroup%2Fedit&action=update&reset=1&id=3&snippet=json`.
I'll also note that my client deleted some custom field groups just prior to this.
I'm uncertain of the version, since we had to switch to a beta to fix a different urgent issue, but it should be close to stock 5.51.colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3793Path for imports through the UI causes permission issues2022-08-10T04:15:54ZbriennePath for imports through the UI causes permission issuesImports through the UI (such as Import Contributions from the Contributions menu) use the same path for the import summary page as the Import Contacts summary page in the UI (civicrm/import/contacts/summary). This causes the import to fa...Imports through the UI (such as Import Contributions from the Contributions menu) use the same path for the import summary page as the Import Contacts summary page in the UI (civicrm/import/contacts/summary). This causes the import to fail if the user does not have the "Import Contacts" permission, even if they do have the proper permissions for other imports.
I am currently working on a fix for this and should have a PR in the next few hours for the release candidate 5.53.
**Steps to Replicate:**
1. Login as a user who does not have the Import Contacts permission
2. Go to **Contributions > Import Contributions**
3. Go through the process of importing a csv file with a test contribution
4. After clicking **import now**, a queue runner will briefly pop up, and then the page will show an error message: "you are not authorized to access this page."
5. Note that the url is civicrm/import/contacts/summary
**Why:**
PR #23669 seems to have introduced this bug (in version 5.51), specifically in the [Import.xml file, lines 20-27](https://github.com/civicrm/civicrm-core/blob/d7a8ffbdd8ee5cf98f712358f261f023f7ebf015/CRM/Core/xml/Menu/Import.xml#L21)5.53.0https://lab.civicrm.org/dev/core/-/issues/3791Wizard: Navigation buttons have weird activation2024-03-27T05:03:23ZtottenWizard: Navigation buttons have weird activationOverview
----------------------------------------
A wizard, such as "New A/B Test", allows you proceed through multiple steps sequentially. Every step in a wizard should be completed in order, although it is also valid to return to a pr...Overview
----------------------------------------
A wizard, such as "New A/B Test", allows you proceed through multiple steps sequentially. Every step in a wizard should be completed in order, although it is also valid to return to a prior step and revise it.
The current behavior of the navigation-bar does not correctly implement this.
Reproduction steps
----------------------------------------
* Click on "**Mailings -> New A/B Test**."
* Within "__1. Setup__"
1. Fill in a **Name**
1. Observe: In the navbar, you are now allowed to jump from step 1 to step 2 or 3 or 4. (*Proceeding to the next step is fine, but you should not be allowed to go step 3 or 4 -- that is premature.*)
![Screenshot_from_2022-08-08_22-26-01](/uploads/eb0c0043394dcd12da65947a1dbd0571/Screenshot_from_2022-08-08_22-26-01.png)
1. Click **Next** (or click the `2. Target` link)
* Within "__2. Target__"
1. Observe: In the navbar, you cannot jump to *any* other step. (*Proceeding to step 3 would be premature, but you should be allowed to go back to step 1.*)
![Screenshot_from_2022-08-08_22-27-06](/uploads/2e70548c9d47577ae369e3e506b7bb02/Screenshot_from_2022-08-08_22-27-06.png)
1. Fill in **Recipients**
1. Observe: In the navbar, you are now allowed to jump to any other step. (*Proceeding to step 3 is OK, but you should not be allowed to jump to step 4.*)
Current behaviour
----------------------------------------
You may jump to any step *if the current step is complete*.
Expected behaviour
----------------------------------------
You may jump to any step *if its predecessors have valid complete/data* (ie *if the prerequisites for the selected step are met*).
Comments
----------------------------------------
The behavior of the "Previous" and "Next" buttons is OK. It's just the top navbar that has the quirk.
This gets to the basic difference between a "wizard" and "tab set". A "tab set" is free-form, so you may navigate to any tab at any time. A "wizard" is sequential, and the steps build upon each other. (In fact, steps may be added or removed as you go through.)
This appears to have regressed in 4.7.28 via https://github.com/civicrm/civicrm-core/commit/5919adff1dc7a531d426c211baf65d8c9b538eeb. I suspect that dev+review focused on "New Mailing", which is deceptively simple use-case (*static 2-step wizard*). The "New A/B Test" is a representative use-case (*dynamic, 4/5-step wizard*).https://lab.civicrm.org/dev/core/-/issues/3790Pledge status is missing on View Pledge page2022-09-09T23:27:08ZyashodhaPledge status is missing on View Pledge pageWhen clicking on View Pledge, pledge status is blank.
![pledge_Status_missing](/uploads/7a9246fce9427cdc7a23c2b6fe11ddfd/pledge_Status_missing.png)
Fix this bug to display the pledge status.When clicking on View Pledge, pledge status is blank.
![pledge_Status_missing](/uploads/7a9246fce9427cdc7a23c2b6fe11ddfd/pledge_Status_missing.png)
Fix this bug to display the pledge status.5.54.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3787Issue with SQL import with > and < in the SQL query2024-03-23T05:03:32ZseamusleeIssue with SQL import with > and < in the SQL queryOverview
----------------------------------------
When using the SQL import datasource there is an issue in recent versions of CiviCRM due to the user job entity.
Reproduction steps
----------------------------------------
1. Create tab...Overview
----------------------------------------
When using the SQL import datasource there is an issue in recent versions of CiviCRM due to the user job entity.
Reproduction steps
----------------------------------------
1. Create table in database that contains at least a field called id and insert some rows, less than 15 would be enough
1. Ensure that your role has permission to use the SQL datasource
1. Click on **Contacts -> Import Contacts**.
1. Select SQL mode and enter an SQL like `SELECT * FROM <table name> WHERE id > 5 AND id <= 12`.
1. Got an error "**Fatal error: DB syntax error**".
Expected behaviour
----------------------------------------
Should be able to move onto the Field mapping stepps
Environment information
----------------------------------------
* __CiviCRM:__ _5.49.5_
Comments
----------------------------------------
It seems to be because we are getting the sqlQuery from the userJob entity as per https://github.com/civicrm/civicrm-core/blob/master/CRM/Import/DataSource/SQL.php#L85 and https://github.com/civicrm/civicrm-core/blob/master/CRM/Import/DataSource.php#L225 and that seems to have an html encoded value for < and > so the query includes > etc rather than > in it
ping @eileenhttps://lab.civicrm.org/dev/core/-/issues/3786CiviCRM 5.51, Import Participants when matching by External / Contact ID alwa...2022-08-09T04:21:33Zjustinfreeman (Agileware)CiviCRM 5.51, Import Participants when matching by External / Contact ID always matches to Contacts with ID < 10Import Participants when matching by External / Contact ID always matches to Contacts with ID < 10
This is due do an incorrectly replaced Error generation function in core commit [972906b](https://github.com/civicrm/civicrm-core/commit/...Import Participants when matching by External / Contact ID always matches to Contacts with ID < 10
This is due do an incorrectly replaced Error generation function in core commit [972906b](https://github.com/civicrm/civicrm-core/commit/972906b33960dd2126bcb5629faec188f6d1a8f9) (Merged for 5.51.0)
**Steps to reproduce**
1. Create a CSV with a Contact External ID or Contact ID, Event Title, Registration Status
2. Set up the import to match on Contact External ID or Contact ID
3. Map the other fields
4. Execute import
**Error**: Import will execute and create Participant records associated all with Contact ID: 1 or Contact ID: 2 (or another ID < ID:10). Not matching against the correct Contact ID.
Agileware Ref: CIVICRM-20255.52.2https://lab.civicrm.org/dev/core/-/issues/3785participant field group sort order does not reflect configured order2024-03-23T05:03:29Zmagnolia61participant field group sort order does not reflect configured orderOverview
----------------------------------------
We have several custom field groups for participants.
Some for a specific event type, some others for specific participant roles
Current behaviour
---------------------------------------...Overview
----------------------------------------
We have several custom field groups for participants.
Some for a specific event type, some others for specific participant roles
Current behaviour
----------------------------------------
Currently the order in which the custom field groups are displayed while editing of viewing does not reflect the sort order that we selected in the custom field group settings. There is even a difference between viewing and editing a participant the one is ascending, the other descending.
Proposed behaviour
----------------------------------------
The sort order of the custom field groups for participants follows the selected order of the custom field groups. They are not groupes by selector (event type, role, etc), but follow the order that is configured.
Comments
----------------------------------------
I have no clue where to find this, and I'm not really a coder. Probably this is a very small change if you know where to look for.https://lab.civicrm.org/dev/core/-/issues/37845.51 regression - Contribution import - external id/contact id matches to wro...2022-08-09T04:22:24Znoah5.51 regression - Contribution import - external id/contact id matches to wrong recordsOverview
----------------------------------------
5.51 introduced a bug whereby contributions were assigned to the wrong contacts if external id or contact id was used as a matching field.
Reproduction steps
----------------------------...Overview
----------------------------------------
5.51 introduced a bug whereby contributions were assigned to the wrong contacts if external id or contact id was used as a matching field.
Reproduction steps
----------------------------------------
1. Make sure you have a contact whose id is 1.
2. Create another contact whose id *starts with* 1. E.g. 11, 1002...
3. Give the second contact an external identifier.
4. Create a CSV for contribution import; include an external id column; create a valid row that uses the external id from the last step.
5. Run the contribution import, using external identifier as a match-to-contact field.
Current behaviour
----------------------------------------
The imported contribution is attached to contact id 1.
Expected behaviour
----------------------------------------
The imported contribution should be attached to the contact with the specified external id.
Comments
----------------------------------------
PR forthcoming5.52.2https://lab.civicrm.org/dev/core/-/issues/3781Fatal Error on upgrade to 5.52.02022-08-18T23:26:03ZkcristianoFatal Error on upgrade to 5.52.0After upgrade from 5.51.3 to 5.52.0 the browser returns a 500 error.
php log shows:
```
[05-Aug-2022 11:41:51 UTC] PHP Fatal error: Declaration of Symfony\Component\DependencyInjection\ServiceLocator::has(string $id) must be compatible...After upgrade from 5.51.3 to 5.52.0 the browser returns a 500 error.
php log shows:
```
[05-Aug-2022 11:41:51 UTC] PHP Fatal error: Declaration of Symfony\Component\DependencyInjection\ServiceLocator::has(string $id) must be compatible with Psr\Container\ContainerInterface::has($id) in /home/wpcv/public_html/wp-content/plugins/civicrm/civicrm/vendor/symfony/dependency-injection/ServiceLocator.php on line 46
```
There is no corresponding entry in ConfigAndLog nor the apache error log
I thought it might be extended reports due to https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/issues/516 But doing a git checkout of master first had no effect.
This had not come up in the testing I had done on generic sites, but this did occur on the first production site I upgraded. I'll look further as it may be something site-specific. Logging an issue in case any others have the same problem.
Env:
Apache 2.4
php 7.4
mariadb 10.3
WP 5.9.3
CiviCRM 5.52.0 (upgrade from 5.51.3)https://lab.civicrm.org/dev/core/-/issues/3780Add an ability to set a field as hidden in formbuilder2023-12-21T07:20:06ZKurund JalmiAdd an ability to set a field as hidden in formbuilderKurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3779Add display only field support for formbuilder2024-02-02T01:19:18ZKurund JalmiAdd display only field support for formbuildercolemanwcolemanwhttps://lab.civicrm.org/dev/drupal/-/issues/181Error: Trying to access array offset on value of type null in Drupal\civicrm\...2022-08-05T00:42:28ZherbdoolError: Trying to access array offset on value of type null in Drupal\civicrm\Plugin\Block\CivicrmBlock->build### Error:
> Notice: Trying to access array offset on value of type null in Drupal\civicrm\Plugin\Block\CivicrmBlock->build() (line 57 of modules/contrib/civicrm/src/Plugin/Block/CivicrmBlock.php).
### How to recreate
1. Add the block...### Error:
> Notice: Trying to access array offset on value of type null in Drupal\civicrm\Plugin\Block\CivicrmBlock->build() (line 57 of modules/contrib/civicrm/src/Plugin/Block/CivicrmBlock.php).
### How to recreate
1. Add the block Recent Items to a blocks layout. I don't think it matters if it's the front or admin side. And this may be an issue with other blocks too.
2. Log in as a user *without* the `access CiviCRM` permission and visit a page where that block is supposed to appear.
### Background
`CivicrmBlock::build()` has this line `$content = \CRM_Core_Block::getContent($block_id)['content'];`. But `getContent()` can return `NULL` (despite it claiming it only returns arrays). It'll return NULL if various access checks fail.
### What should happen
`CivicrmBlock::build()` should first check the result is an array before trying to access an offset.
```
/**
* {@inheritdoc}
*/
public function build() {
$block_id = $this->getDerivativeId();
$content = \CRM_Core_Block::getContent($block_id);
// Bypass Drupal SafeString escaping by setting output as already escaped.
if (!empty($content['content']) {
return [
'#markup' => Markup::create($content['content']),
'#cache' => ['max-age' => 0],
];
}
return [];
}
```5.53.0https://lab.civicrm.org/dev/core/-/issues/3778Event participant registered by contact ID2023-09-04T08:05:09Zmattwiremjw@mjwconsult.co.ukEvent participant registered by contact IDSee discussion at https://github.com/civicrm/civicrm-core/pull/23936
The existing field "registered_by_id" has a number of problems:
It does not get set if you add a registration via the backend forms.
It always gets set to the primary...See discussion at https://github.com/civicrm/civicrm-core/pull/23936
The existing field "registered_by_id" has a number of problems:
It does not get set if you add a registration via the backend forms.
It always gets set to the primary participant even when the user selects "Not X, or want to register a different person" (ie. URL has the parameter cid=0).
The "registered_by_id" field requires a participant ID and not a contact ID. This means that you cannot record that you registered one or more participants unless you are also a participant of that event.
Why not change registered_by_id to a contact ID? That's likely to have all sorts of unexpected impacts as the existing field is used in various wonderful ways (eg. registration emails behave a bit differently if there is a registered_by_id).
Does this fix everything?
No, not yet. That will require more work on the UI / mailing side of things to use the new field. But it's accessible as part of the Participant entity which means it can be used via the API and with searchkit.
This PR includes a little bit of UI work on the backend event participant form to allow you to set the new "registered by contact" field and this form will prefer that field.
What about setting the primary participant ID when they weren't the one registering?
Yes, this PR fixes that. It checks if the contact ID on the form is the same as the primary participant contact ID. If it's not it won't set the registered_by_id field.
Core patches:
- ~~https://github.com/civicrm/civicrm-core/pull/24167 - Add created_id field to civicrm_participant~~ merged
- ~~https://github.com/civicrm/civicrm-core/pull/24304 - Add code hook to set civicrm_participant.created_id~~ merged
- https://github.com/civicrm/civicrm-core/pull/24749 - Add 'Registered by Contact ID' to civireport
- _Need to extract patches from https://github.com/civicrm/civicrm-core/pull/23936 for Quickform UI etc._
- https://github.com/civicrm/civicrm-core/pull/24750 - Work in progress for participant forms.https://lab.civicrm.org/dev/core/-/issues/3777Afform: Radios should show default value when form is loaded/reset2023-09-02T05:11:54Zmattwiremjw@mjwconsult.co.ukAfform: Radios should show default value when form is loaded/resetSee #3449, #3450, https://github.com/civicrm/civicrm-core/pull/23413 (testing comments from @artfulrobot )
If you select a default value the filter is applied but it is not shown as "selected" when the form is loaded/reset.See #3449, #3450, https://github.com/civicrm/civicrm-core/pull/23413 (testing comments from @artfulrobot )
If you select a default value the filter is applied but it is not shown as "selected" when the form is loaded/reset.Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3776CiviCRM - next version? Getting fit for future...2022-08-24T03:00:46ZTobias KrauseCiviCRM - next version? Getting fit for future...Sorry if this ticket is too general but I don't know where to go with my concerns.
We just updated our servers to PHP 8.0 (which was released im November 2020) and then I found some warnings in the logs about deprecated code. To find th...Sorry if this ticket is too general but I don't know where to go with my concerns.
We just updated our servers to PHP 8.0 (which was released im November 2020) and then I found some warnings in the logs about deprecated code. To find the reasons for these I diged into the code basis of CiviCRM and I found out that CiviCRM relys on very old frameworks (e.g. Smarty version 2.6 from the year 2016) or on frameworks not really actively maintained (zetacomponents/mail from the year 2020). Just two examples but I feel if I would check the other dependencies there might be some more old frameworks.
The tip for now from the Civi-community: stay on PHP 7.4 - which will reach end of life by November this year. Even PHP 8.0 will just receive security updates until November this year so that from November on PHP 8.1 would be the correct version - on which CiviCRM is absolutely not working as I already tested.
Now I got very concerned about the next years. We heavily use CiviCRM in our daily work for the administration of thousands of donators and newsletter subscribers and for the newsletter sending so that CiviCRM is the main tool of our daily work. And now CiviCRM already feels a little bit like a dinosaur to me - especially compared with Drupal 9 I am working with in general. I fear that CiviCRM cannot keep up with the ongoing developments of PHP (and JavaScript).
My question: are there any plans for updating the dependencies? Maybe even a plan to change to more modern frameworks like Twig? I found a roadmap where Form Builder, CiviCRM Standalone and UI Improvements are listed but this feels just like some new features based on the current code basis.https://lab.civicrm.org/dev/core/-/issues/3775Disable Deadlock retries for Mailing Jobs2024-03-24T05:03:28ZseamusleeDisable Deadlock retries for Mailing JobsSo CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful becaus...So CiviCRM added a feature which re-tries the same query x number of times by default that is 3 when either a deadlock or a lock wait timeout is hit which is useful, but in the concept of mailing job processing it is not so useful because it means it can get tied up on get_lock queries re-trying them a silly number of times when it should be moving onto the next thingseamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/3774Can't submit backend credit card contribution unless you have at least one pa...2022-08-04T21:07:47ZJonGoldCan't submit backend credit card contribution unless you have at least one payment processor that supports a future start dateIf you don't have a payment processor that supports a future start date, you can't submit a credit card contribution.
### Steps to replicate
* On a buildkit site, add a PayPal Pro payment processor. The creds don't have to be valid.
* S...If you don't have a payment processor that supports a future start date, you can't submit a credit card contribution.
### Steps to replicate
* On a buildkit site, add a PayPal Pro payment processor. The creds don't have to be valid.
* Submit a backend credit card contribution with PayPal Pro. Should go through (or tell you invalid credentials).
* Delete the default processor of type "Dummy Payment Processor".
* Submit another backend credit card contribution with PayPal Pro.
### Expected Result
Absence of a dummy test processor shouldn't affect the ability to submit a credit card processor.
### Actual result
```
Please correct the following errors in the form fields below:
Date Received is a required field.
```
### Why
In `CRM_Contribution_Form_AbstractEditPayment::assignProcessors()` is this line:
```
$this->assign('processorSupportsFutureStartDate', CRM_Financial_BAO_PaymentProcessor::hasPaymentProcessorSupporting(['FutureRecurStartDate']));
```
This will return `TRUE` if *any* payment processor supports a future start date. Which in turn causes the `receive_date` to appear on `templates/CRM/Contribute/Form/Contribution.tpl`.
Without the `receive_date` on the form, even hidden, you can't submit the form.
The workaround is to create a dummy processor on your site. I have to run, but tomorrow I'll try to put together a PR that fixes this at the template level.
Is this a regression? I mean, technically yes, but it's two years old. And tricky to catch because the test suite creates the dummy processor in `setUp()`. To catch this we might have to move that out of `setUp()` and into its own helper function.5.52.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3773Deprecated function: Required parameter $sortCriteria follows optional parame...2024-03-20T05:03:26ZTobias KrauseDeprecated function: Required parameter $sortCriteria follows optional parameter $countEverytime cron runs I see this message in logs:
`Deprecated function: Required parameter $sortCriteria follows optional parameter $count in include() (line571 in /var/www/civi_live/vendor/composer/ClassLoader.php)`
After searching a li...Everytime cron runs I see this message in logs:
`Deprecated function: Required parameter $sortCriteria follows optional parameter $count in include() (line571 in /var/www/civi_live/vendor/composer/ClassLoader.php)`
After searching a little bit the only place which makes sense for this message is ezcMailImapTransport->sortFromOffset() in vendor/zetacomponents/mail/src/transports/imap/imap_transport.php
My setup:
- drupal 9.3.19
- CiviCRM 5.51.1
- PHP 8.0
I don't knowwhere this dependency comes from but this library needs an update for PHP 8.0 - or it should be considered to use another dependency. For IMAP handling I have good experiences with https://github.com/ddeboer/imaphttps://lab.civicrm.org/dev/core/-/issues/3772Notice: Undefined offset: 18 in CRM_Member_Form_Task_Batch->buildQuickForm()2022-08-03T21:11:30ZRobert J. LangNotice: Undefined offset: 18 in CRM_Member_Form_Task_Batch->buildQuickForm()Getting lots of log reports of the form
Notice: Undefined offset: 18 in `CRM_Member_Form_Task_Batch->buildQuickForm()` (line 144 of /.../civicrm/CRM/Member/Form/Task/Batch.php).
This is because the offending line is
```
CR...Getting lots of log reports of the form
Notice: Undefined offset: 18 in `CRM_Member_Form_Task_Batch->buildQuickForm()` (line 144 of /.../civicrm/CRM/Member/Form/Task/Batch.php).
This is because the offending line is
```
CRM_Utils_System::isNull($entityColumnValue[$typeId])
```
and it should be
```
CRM_Utils_System::isNull($entityColumnValue[$typeId] ?? NULL)
```5.53.0https://lab.civicrm.org/dev/core/-/issues/3771Undefined array key "rows" in Search.tpl.php when entering "Manage Groups"2022-08-19T13:10:03ZTobias KrauseUndefined array key "rows" in Search.tpl.php when entering "Manage Groups"Whenever a user comes to "Manage groups" (/civicrm/group) the PHP warning appears:
`Warning: Undefined array key "rows" in include() (line 6 of sites/default/files/civicrm/templates_c/en_US/%%7A/7A2/7A24E297%%Search.tpl.php).`
It comes...Whenever a user comes to "Manage groups" (/civicrm/group) the PHP warning appears:
`Warning: Undefined array key "rows" in include() (line 6 of sites/default/files/civicrm/templates_c/en_US/%%7A/7A2/7A24E297%%Search.tpl.php).`
It comes from CRM/Group/Form/Search.tpl:
`<div class="crm-accordion-wrapper crm-search_builder-accordion {if $rows and empty($showSearchForm)}collapsed{/if}">`
Seems that this code is not correct anymore as stated by Demerit's answer?! https://civicrm.stackexchange.com/questions/42384/undefined-array-key-rows-in-search-tpl-php-when-entering-manage-groups5.54.0