Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-08-10T18:27:55Zhttps://lab.civicrm.org/dev/core/-/issues/3795Custom Groups should not exclude activity types where filter > 0 if in manage...2022-08-10T18:27:55ZherbdoolCustom Groups should not exclude activity types where filter > 0 if in managed entitiesOverview
----------------------------------------
CRM_Core_BAO_CustomGroup::getSubTypes() excludes all subtypes where filter is not zero. This is a problem for managed entities where an activity type is defined with `filter = 1` for exa...Overview
----------------------------------------
CRM_Core_BAO_CustomGroup::getSubTypes() excludes all subtypes where filter is not zero. This is a problem for managed entities where an activity type is defined with `filter = 1` for example.
It uses this deprecated function $activityType = CRM_Core_PseudoConstant::activityType(FALSE, TRUE, FALSE, 'label', TRUE);
https://chat.civicrm.org/civicrm/pl/oy16q7rrgbrppqyi69dw6a5waa
Reproduction steps
----------------------------------------
1. Put an activity type into a managed entity; make sure 'filter' => 1.
2. Then create a custom group and have it extend that activity type.
3. Put that custom group in a managed entity.
4. Delete the manually made activity type and custom group so they'll properly be created with managed entity.
5. Now run flush and reconciling the managed entities fails: get error: "Supplied Sub type is not valid for the specified entitiy"
Current behaviour
----------------------------------------
Managed entity reconciliation fails with error: "Supplied Sub type is not valid for the specified entitiy"
Expected behaviour
----------------------------------------
Should run.
Environment information
----------------------------------------
* __CiviCRM:__ 5.52.x
* __PHP:__ 7.4
* __CMS:__ Drupal 9.4.xhttps://lab.civicrm.org/dev/core/-/issues/3792Search Kit: HTML markup is visible to the end user2022-08-18T16:28:34ZjhungerfordSearch Kit: HTML markup is visible to the end userOverview
----------------------------------------
Currently, if you create a Form from a SearchKit search, HTML markup stored in displayed fields will be shown to the user. For example, Activity Details generally contain markup, so the e...Overview
----------------------------------------
Currently, if you create a Form from a SearchKit search, HTML markup stored in displayed fields will be shown to the user. For example, Activity Details generally contain markup, so the end user will see something like "<p>Example details</p>".
Example use-case
----------------------------------------
1. Create a new SearchKit search
1. Search for: Activities
1. Where: Details contains <p>
1. Add Details column to the output table
1. Save
1. press Search
1. Observe that HTML markup is visible
2. click "Create form for search results table"
2. Assign a Title and Page route
2. Save
2. Click View Page
2. Observe that HTML markup is also visible in the Form
Current behaviour
----------------------------------------
HTML is shown to the end user.
Proposed behaviour
----------------------------------------
Ideally, the HTML would be rendered. Failing that, simply stripping out HTML tags would provide a better user experience.
Comments
----------------------------------------
There was a small amount of discussion about this in the chat, in which it was noted that it would be good if the schema knew which fields could contain HTML:
https://chat.civicrm.org/civicrm/pl/1f67mo4kkfgbbbuaksf9i1rceh
In a development environment, I tried replacing this line:
https://lab.civicrm.org/dev/core/-/blob/master/ext/search_kit/ang/crmSearchDisplay/traits/searchDisplayBaseTrait.service.js#L173
As a proof of concept, I added some code which strips out all HTML tags if the string begins with "<", but this is obviously improper. I didn't find a way to get it to render the HTML by intervening at that point. For reference, this is the code I inserted in place of line 173, but I'm not suggesting this as a solution:
```
let stringData = angular.isArray(colData.val) ? colData.val.join(', ') : colData.val;
if (typeof(stringData) == "string" && stringData.startsWith('<')) {
let cleanText = stringData.replace(/<\/?[^>]+(>|$)/g, "");
return cleanText;
}
else {
return stringData;
}
```
I tried a few variations on this suggestion for rendering HTML instead of displaying it verbatim, but in that context, my attempts just resulted in the addition of more HTML tags to the output:
https://stackoverflow.com/questions/50749487/rendering-data-with-html-tags-rendering-themhttps://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/3788Afform - Unable to add relationship afform filters2022-08-18T01:24:31ZfrancescbassasAfform - Unable to add relationship afform filtersI don't know if it's a non-featured or a regression, but the fact is I'd swear this worked at some point. Now I'm on version 5.2. I can't get relationship afform filters
![afform-filters](/uploads/2ed17464bcc463ec7573f268f9e86333/afform...I don't know if it's a non-featured or a regression, but the fact is I'd swear this worked at some point. Now I'm on version 5.2. I can't get relationship afform filters
![afform-filters](/uploads/2ed17464bcc463ec7573f268f9e86333/afform-filters.png)
from a relationship SearchKit like that
![searchkit-relationship](/uploads/556bf3741bcc7ee4043cfad698d8d2f1/searchkit-relationship.png)https://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/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/3783Make Recent Items available providers an option group so extensions can exten...2022-08-10T04:17:03ZherbdoolMake Recent Items available providers an option group so extensions can extend itOverview
----------------------------------------
I would like my custom entities to be available to the Recent Items block.
In `CRM_Utils_Recent::getProviders()` there's a comment to make the hard-coded list into an Open Group. I agree...Overview
----------------------------------------
I would like my custom entities to be available to the Recent Items block.
In `CRM_Utils_Recent::getProviders()` there's a comment to make the hard-coded list into an Open Group. I agree. Let's make it so.
Current behaviour
----------------------------------------
Hard-coded list of some core entities.
Proposed behaviour
----------------------------------------
Create an option group and call it from this method.5.53.0https://lab.civicrm.org/dev/core/-/issues/3782Don't prevent contact with Cancelled membership from signing up online2023-01-02T17:47:01Zmattwiremjw@mjwconsult.co.ukDon't prevent contact with Cancelled membership from signing up onlineContribution page prevents signing up for a membership if the matched contact has an existing cancelled membership of the same type.
I don't really understand why https://github.com/civicrm/civicrm-core/pull/3531 ever got merged given t...Contribution page prevents signing up for a membership if the matched contact has an existing cancelled membership of the same type.
I don't really understand why https://github.com/civicrm/civicrm-core/pull/3531 ever got merged given that it seems no-one was in favour of restricting memberships in this way: https://issues.civicrm.org/jira/browse/CRM-14645
A restriction such as this could easily be put in place via the `validateForm` hook for anyone who actually needs it and it seems a pretty obscure restriction to have hardcoded in core.5.56.0https://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/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.0https://lab.civicrm.org/dev/core/-/issues/3770Figure out how to offer preferredLanguage in api explorer with options2024-03-20T05:03:26ZeileenFigure out how to offer preferredLanguage in api explorer with optionsFrom discussion of adding preferredLanguage - options should be explorer-discoverable
https://github.com/civicrm/civicrm-core/pull/24116#pullrequestreview-1057986655From discussion of adding preferredLanguage - options should be explorer-discoverable
https://github.com/civicrm/civicrm-core/pull/24116#pullrequestreview-1057986655