Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-05-25T15:54:17Zhttps://lab.civicrm.org/dev/core/-/issues/4274SearchKit: Entities that are no longer results of the search remain selected2023-05-25T15:54:17ZlarsssandergreenSearchKit: Entities that are no longer results of the search remain selectedIf you search for Contacts in SearchKit, select all or some of the Contacts, then edit your search to make it more specific and click search again, the previously selected Contacts, who may not be within the results of the current search...If you search for Contacts in SearchKit, select all or some of the Contacts, then edit your search to make it more specific and click search again, the previously selected Contacts, who may not be within the results of the current search, remain selected. This not only gives nonsensical totals (`100 selected of 10 results`), it can result in unintended changes, for instance if you were to add or remove the Contacts from a group, expecting to be adding or removing the results of your current search, not the results of your previous search (not a theoretical concern, this actually happened to me).
I think the solution is pretty simple, just clear the selection of entities whenever we search again. I can't see why we would want the selected entities to remain selected when we are doing a new search.https://lab.civicrm.org/dev/core/-/issues/4283Search Kit did not install automatically (Civi 5.61.1 FR and Drupal 7.97.FR2023-05-25T13:23:57ZWebmasterBouclierSearch Kit did not install automatically (Civi 5.61.1 FR and Drupal 7.97.FROverview
----------------------------------------
Funny issue while doing a fresh installation of CiviCRM 5.61.1 FR on a Drupal 7.97 FR (not an upgrade). Search Kit is available in the extensions and indicatated as "Obligatoire" (mandato...Overview
----------------------------------------
Funny issue while doing a fresh installation of CiviCRM 5.61.1 FR on a Drupal 7.97 FR (not an upgrade). Search Kit is available in the extensions and indicatated as "Obligatoire" (mandatory). But it is not outlined in green as the other extensions allready installed. And there is no button to install it.
While trying to install Mosaico, system tell me that Search Kit needs to be installed before.
The Search Kit were not created in the Civi database.
More details and screenshots on chat.civicrm.org : [https://chat.civicrm.org/civicrm/pl/ea5osnwhrj855regwhjkbpse9y](https://chat.civicrm.org/civicrm/pl/ea5osnwhrj855regwhjkbpse9y)
Is this a bug in the installation process of SearchKit?
I solved the issue by using API3 install process, and that solved my problem.
But I understand that Search Kit should have installed itself automatically.
PHP 7.3
MySQL 5.7
Hosting OVH (France)https://lab.civicrm.org/dev/core/-/issues/2156Constant DRUPAL_ROOT already defined2023-05-25T05:06:51ZedvanleeuwenConstant DRUPAL_ROOT already definedOverview
----------------------------------------
Notice: Constant DRUPAL_ROOT already defined in CRM_Utils_System_Drupal->loadBootStrap()
Reproduction steps
----------------------------------------
Unknown.
Current behaviour
---------...Overview
----------------------------------------
Notice: Constant DRUPAL_ROOT already defined in CRM_Utils_System_Drupal->loadBootStrap()
Reproduction steps
----------------------------------------
Unknown.
Current behaviour
----------------------------------------
In the log:
Notice: Constant DRUPAL_ROOT already defined in CRM_Utils_System_Drupal->loadBootStrap() (regel 481 van /home/xxx/domains/xxx/public_html/sites/all/modules/civicrm/CRM/Utils/System/Drupal.php).
The log shows this during cron execution.
Expected behaviour
----------------------------------------
_What should happen._
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. -->
* __Browser:__ _Edge_
* __CiviCRM:__ _5.30.0_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.4/...__
* __CMS:__ _Drupal 7.73_
* __Database:__ _MariaDB 10.4_
* __Web Server:__ _Apache 2.4_
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/4307SearchKit "If/Else" field transformation does not behave as described2023-05-25T02:13:22ZnoahSearchKit "If/Else" field transformation does not behave as describedFirst of all, [the description for the "If/Else" field transformation](https://github.com/civicrm/civicrm-core/blob/9e9feedffa6146ffb211f5a47de305b9bf591d22/Civi/Api4/Query/SqlFunctionIF.php#L54) is backwards. It says:
"If the field is ...First of all, [the description for the "If/Else" field transformation](https://github.com/civicrm/civicrm-core/blob/9e9feedffa6146ffb211f5a47de305b9bf591d22/Civi/Api4/Query/SqlFunctionIF.php#L54) is backwards. It says:
"If the field is empty, the first value, otherwise the second."
The order of "first" and "second" in that sentence are reversed. And, since we're just talking about the MySQL IF construct here, a closer description would be (according to the [MYSQL docs regarding the if/else construct](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#function_if)):
"If the field is nonzero and non-NULL, the first value, otherwise the second."
But even that isn't totally accurate. It leaves out the fact that the field (the comparison value) will be cast to an integer for comparison. In MySQL, strings starting with any character except 1-9 will be cast to 0 (false).
````
+---------------------------+
| IF(true, 'true', 'false') |
+---------------------------+
| true |
+---------------------------+
+----------------------------+
| IF(false, 'true', 'false') |
+----------------------------+
| false |
+----------------------------+
+------------------------+
| IF(1, 'true', 'false') |
+------------------------+
| true |
+------------------------+
+------------------------+
| IF(0, 'true', 'false') |
+------------------------+
| false |
+------------------------+
+---------------------------+
| IF(null, 'true', 'false') |
+---------------------------+
| false |
+---------------------------+
+---------------------------------------+
| IF("5_golden_rings", 'true', 'false') |
+---------------------------------------+
| true |
+---------------------------------------+
+--------------------------------------+
| IF("my_1_and_only", 'true', 'false') |
+--------------------------------------+
| false |
+--------------------------------------+
````
So an accurate description of this field transformation is:
"If the field is boolean TRUE, any number except 0, or a string not starting with the digits 1-9, the first value, otherwise the second."https://lab.civicrm.org/dev/core/-/issues/3986FormBuilder: defaults for bulk create2023-05-24T14:05:46Zaydunsaidan.saunders@squiffle.ukFormBuilder: defaults for bulk createOverview
----------------------------------------
Provide a 'defaults' entity for bulk entry
Example use-case
----------------------------------------
1. Create a submission form for Activities
2. On the main Activity1 fieldset, mark it...Overview
----------------------------------------
Provide a 'defaults' entity for bulk entry
Example use-case
----------------------------------------
1. Create a submission form for Activities
2. On the main Activity1 fieldset, mark it as 'Repeat'
3. You can now create a set of activities
4. But ...
Current behaviour
----------------------------------------
All relevant fields need to be completed even if they are repetitive
Proposed behaviour
----------------------------------------
Provide a 'defaults' version of the fieldset where repeated values can be entered.
The normal entries are then combined with the default values before creating the entities.
Note this is different to the 'Values' feature: those are specified by the form designer (eg specifying an activity type)
The defaults are provided by the user filling in the form such as specifying a 'key contact' that is used when creating all the other entities, unless that value is specified.
```
Default entry: Field 1: Field 2: abc
Entry 1: Field 1: Hi 1 Field 2:
Entry 2: Field 1: Hi 2 Field 2:
Entry 3: Field 1: Hi 3 Field 2: def
Entry 4: Field 1: Hi 4 Field 2:
Entry 5: Field 1: Hi 5 Field 2: ghi
```
should create:
```
Entry 1: Field 1: Hi 1 Field 2: abc
Entry 2: Field 1: Hi 2 Field 2: abc
Entry 3: Field 1: Hi 3 Field 2: def
Entry 4: Field 1: Hi 4 Field 2: abc
Entry 5: Field 1: Hi 5 Field 2: ghi
```
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/4305Implementing hook_civicrm_alterAngular breaks href attributes that include so...2023-05-24T10:43:11ZDaveDImplementing hook_civicrm_alterAngular breaks href attributes that include some angular expressionsSee also https://chat.civicrm.org/civicrm/pl/xqbryepb4fra5f6smn8uazbeoc
searchkit has a line like this in the code: `<a href="#/create/{{:: row.data.api_entity + '?params=' + $ctrl.encode(row.data.api_params) }}">`
If you implement alt...See also https://chat.civicrm.org/civicrm/pl/xqbryepb4fra5f6smn8uazbeoc
searchkit has a line like this in the code: `<a href="#/create/{{:: row.data.api_entity + '?params=' + $ctrl.encode(row.data.api_params) }}">`
If you implement alterAngular, even if you don't change anything, it breaks that code because the `+`'s become spaces. e.g.
```php
function myextension_civicrm_alterAngular(\Civi\Angular\Manager $angular) {
$changeSet = \Civi\Angular\ChangeSet::create('dosomething')
->alterHtml('~/crmSearchAdmin/searchListing/buttons.html',
function (phpQueryObject $doc) {
// it breaks even if you don't do anything here
});
$angular->add($changeSet);
```
The problem seems to be in DOMDocument itself (or maybe libxml). It treats href specially, but is picky about which characters it encodes. It will encode `{`, `[`, `&`, `$`, etc but not `+`, `.`, `=`, etc, and amazingly not even `%`. So then when you urldecode it turns the `+` into a space, and if you had something like `%12` in your original string, it would end up decoding that into a single char. It serves you right a bit for using those chars in a filename/url, but it's legal.
This seems inconsistent/error-prone.
And note it only does this for href attributes, e.g.
```php
<?php
$d = new DOMDocument();
$d->loadHTML('<a href="abc/!@#$%12*-.+(){}[]=" data-foo="abc/!@#$%12*-.+(){}[]=">');
echo $d->saveHTML();
```
gives
```
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html><body><a href="abc/!@#%24%12*-.+()%7B%7D%5B%5D=" data-foo="abc/!@#$%12*-.+(){}[]="></a></body></html>
```
So while Civi\Angular\Coder could maybe be updated somehow, there isn't really a way for it to know if you meant something like `%2C` to be a literal percent followed by 2C, or if you meant `,`, and ditto for all the other characters it skips. So using ng-href instead seems like a good way of avoiding the problem, just as noted in the chat it's hard to enforce this. But core could do it at least.5.63.0https://lab.civicrm.org/dev/core/-/issues/4310Membership HTML output on contribution pages causing layout errors due to unc...2023-05-24T07:36:13ZFrancis (Agileware)Membership HTML output on contribution pages causing layout errors due to unclosed div - 5.61 regressionOverview
----------------------------------------
[commit:dfc5fb9](https://github.com/civicrm/civicrm-core/commit/dfc5fb948b0cb11947b3b75131b54b1c365f08b1) caused a regression in the display of the Membership block, where the logic wrapp...Overview
----------------------------------------
[commit:dfc5fb9](https://github.com/civicrm/civicrm-core/commit/dfc5fb948b0cb11947b3b75131b54b1c365f08b1) caused a regression in the display of the Membership block, where the logic wrapping the "makeContribution" context skips both the closing div and the javascript portion that replaces the auto renew checkbox with a note in force autorenewal mode.
Reproduction steps
----------------------------------------
1. Create a membership contribution page.
2. Attempt to use the contribution page.
Current behaviour
----------------------------------------
The membership block escapes its containment matrix, causing an unclosed div error on the form. This manifests in the browser as a layout nesting issue.
The [W3 validator](https://validator.w3.org/nu/) explains the problem as:
```
Error: End tag form seen, but there were open elements.
From line 1779, column 3; to line 1779, column 9
>↩ ↩ ↩ </form>↩
Error: Unclosed element div.
From line 692, column 3; to line 692, column 128
↩ ↩ <div class="crm-contribution-page-id-7 crm-block crm-contribution-main-form-block" data-page-id="7" data-page-template="main">↩↩
Fatal Error: Cannot recover after last error. Any further errors will be ignored.
From line 1779, column 3; to line 1779, column 9
>↩ ↩ ↩ </form>↩
```
In addition to this, if the membership type should force autorenewal, it may not due to a missing javascript section.
Expected behaviour
----------------------------------------
There should be no layout nesting issue, and all divs should be closed appropriately.
The script to advise the end use on autorenewal should function.
Environment information
----------------------------------------
* __CiviCRM:__ _Master, 5.61.x_
* __PHP:__ 8.0
* __CMS:__ WordPress 6.2.25.61.4https://lab.civicrm.org/dev/core/-/issues/4295SearchKit - non-core legacy search tasks don't work with contributions2023-05-24T07:05:24ZufundoSearchKit - non-core legacy search tasks don't work with contributionsReproduction steps
----------------------------------------
1. Create a SearchKit with contribution entities
1. Enable an extension with a legacy search task (e.g. https://lab.civicrm.org/ufundo/ukgiftaid/-/tree/searchkit-actions )
1. Ta...Reproduction steps
----------------------------------------
1. Create a SearchKit with contribution entities
1. Enable an extension with a legacy search task (e.g. https://lab.civicrm.org/ufundo/ukgiftaid/-/tree/searchkit-actions )
1. Task appears in the ACTIONS menu for the contributions
2. But the popup when you click the action fails ( "Unable to reach the server. Please refresh this page in your browser and try again.")
Current behaviour
----------------------------------------
![image](/uploads/f8f841892e5741e9544b5797aa07fbfd/image.png)
```
We can't load the requested web page. This page requires cookies to be enabled in your browser settings. Please check this setting and enable cookies (if they are not enabled). Then try again. If this error persists, contact the site administrator for assistance.<br /><br />Site Administrators: This error may indicate that users are accessing this page using a domain or URL other than the configured Base URL. EXAMPLE: Base URL is http://example.org, but some users are accessing the page via http://www.example.org or a domain alias like http://myotherexample.org.<br /><br />Error type: Could not find a valid session key.
```
Expected behaviour
----------------------------------------
Action form should appear in the pop up.
Comments
----------------------------------------
`SearchDisplay::getSearchTasks` currently generates qfKey for legacy search task forms based on hard-coded class `CRM_Contribute_Controller_Task` in this line https://github.com/civicrm/civicrm-core/blob/a599e40ad27ebcd9d4b8e80bf0a5904983d5ee82/ext/search_kit/Civi/Api4/Action/SearchDisplay/GetSearchTasks.php#LL196C1-L196C77
This causes tasks using any other class controller fail due to the mismatch.
Couple of potential fixes incoming...ufundoufundohttps://lab.civicrm.org/dev/core/-/issues/2151Permissioned contact needs Edit All Contact to disable a relationship.2023-05-24T05:03:17ZspalmstromPermissioned contact needs Edit All Contact to disable a relationship.Overview
----------------------------------------
Reproduction steps
----------------------------------------
1. Set up a contact to have permissions to edit a relationship with an organisation, say, but do not grant *Edit all contacts*...Overview
----------------------------------------
Reproduction steps
----------------------------------------
1. Set up a contact to have permissions to edit a relationship with an organisation, say, but do not grant *Edit all contacts*.
1. Log in as that contact and display the organisation and click on the Relationship tab.
![image](/uploads/97a43012ece6555f384a4c73bd3586a3/image.png)
1. Select a contact in the list and click on more > Disable
1. Click Yes to disable the record.
1. You get this error:
![image](/uploads/58fb1815ac858cd5edcee8e426515916/image.png)
Current behaviour
----------------------------------------
_What happens currently. Please provide error messages, screenshots or gifs ([LICEcap](http://www.cockos.com/licecap/), [SilentCast](https://github.com/colinkeenan/silentcast)) where appropriate._
![image](/uploads/ace441f3a68f8c70019ec06bc1e8a770/image.png)
Expected behaviour
----------------------------------------
_What should happen._
The relationship in question gets disabled.
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 necessary. -->
* __Browser:__ _Edge/Chrome_ but probably irrelevant
* __CiviCRM:__ _5.32.alpha1/5.29.1_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.4.11/7.3.23/__ but probably irrelevant
* __CMS:__ _Joomla 3.9.6_ - this may be relevant as it demands a CiviCRM permission in Joomla.
* __Database:__ _5.7.31-log/5.6.40-84.0-log_ but probably irrelevant
* __Web Server:__ _IIS/Apache_ but probably irrelevant.
Comments
----------------------------------------
_Anything else you would like the reviewer to note._
Letting the user edit all contacts via CiviCRM ACL rather than Joomla did not help.
It is not a high priority issue, but someone may have a quick fix for it.https://lab.civicrm.org/dev/core/-/issues/2043[cq] Do not pass by reference where avoidable2023-05-24T05:03:17Zeileen[cq] Do not pass by reference where avoidableOne of our nastier code legacies is the prevalence of pass-by-reference - many places in code look something like this
```
function doIt(&$params) {
// don't alter $params
}
doIt($params);
```
In order to understand what is happenin...One of our nastier code legacies is the prevalence of pass-by-reference - many places in code look something like this
```
function doIt(&$params) {
// don't alter $params
}
doIt($params);
```
In order to understand what is happening wit $params it is necessary to dig into the function to see if $params is altered in the process.
On an ongoing basis we need to identify places where a variable is passed-by-reference unnecessarily and remove the &
Note that these were added originally for 2 reasons
1) retrofitting php4 compatibility
2) the incorrect belief it was more efficient on memoryhttps://lab.civicrm.org/dev/core/-/issues/4303Custom field post help results in "Unable to load help file."2023-05-23T22:58:09Zwil_SRQCustom field post help results in "Unable to load help file."Overview
----------------------------------------
See https://civicrm.stackexchange.com/questions/44976/custom-field-post-help-results-in-unable-to-load-help-file/44978#44978
Clicking the blue help bubble for a custom field yields the e...Overview
----------------------------------------
See https://civicrm.stackexchange.com/questions/44976/custom-field-post-help-results-in-unable-to-load-help-file/44978#44978
Clicking the blue help bubble for a custom field yields the error message "Unable to load help file." The log records an exception, [attached.](/uploads/8a35ccf2e69e50a8104f8ae8e755f715/log1.txt) Non-custom fields are working normally.
Reproduction steps
----------------------------------------
1. Locate or create a custom field with field post help text
1. Go to a Create or Edit page that allows filling the custom field
1. Click the blue help bubble
Current behaviour
----------------------------------------
Described in the overview.
Expected behaviour
----------------------------------------
The field post help text displays in a pop-up at the top right of the page.
Environment information
----------------------------------------
* __CiviCRM:__ _5.61.1_
* __PHP:__ _7.4.33_
* __CMS:__ _Drupal 7.97_
* __Database:__ _MySQL 5.7.42_
*
Comments
----------------------------------------
This error is new (regression), but I don't know when it emerged. [Lars](https://civicrm.stackexchange.com/users/3533/lars-sg) confirmed correct operation on 5.58.1 and the problem on dmaster.5.61.3https://lab.civicrm.org/dev/core/-/issues/4302Fatal errors in code that calls methods in `CRM_Dedupe_BAO_RuleGroup` in 5.62+2023-05-23T07:39:02ZhaystackFatal errors in code that calls methods in `CRM_Dedupe_BAO_RuleGroup` in 5.62+Overview
----------------------------------------
There are a number of plugins out in the wild that call `CRM_Dedupe_BAO_RuleGroup::getByType()` to retrieve a keyed array of Dedupe Rules. These include, but may not be limited to:
* [Ca...Overview
----------------------------------------
There are a number of plugins out in the wild that call `CRM_Dedupe_BAO_RuleGroup::getByType()` to retrieve a keyed array of Dedupe Rules. These include, but may not be limited to:
* [Caldera Forms CiviCRM](https://wordpress.org/plugins/cf-civicrm/) (or whichever adapted version people are still using)
* [CiviCRM Profile Sync](https://wordpress.org/plugins/civicrm-wp-profile-sync/)
* [CiviCRM Admin Utilities](https://wordpress.org/plugins/civicrm-admin-utilities/) (thankfully not used internally)
* [Integrate CiviCRM with WooCommerce](https://github.com/WPCV/wpcv-woo-civi-integration)
* [CiviCRM Event Organiser](https://github.com/christianwach/civicrm-event-organiser)
I have updated each of these to use API4 instead - but I don't know how many other plugins, modules and extensions there are out there that use similar code for similar purposes. Moreover, if people update to CiviCRM 5.62.x without updating their plugins first, their sites will throw a fatal error and (in some cases) become non-functional - though the severity of this depends on when the code is called.
Reproduction steps
----------------------------------------
1. Install CiviCRM 5.62.x
1. Install one of the unpatched plugins listed above.
1. Go to a screen that renders a list of Dedupe Rules (with CiviCRM Profile Sync using ACF Extended forms, any screen will do)
1. **PHP Fatal error: Uncaught Error: Class "CRM_Dedupe_BAO_RuleGroup" not found**".
Current behaviour
----------------------------------------
Calling `CRM_Dedupe_BAO_RuleGroup::getByType()` throws a fatal error.
Expected behaviour
----------------------------------------
I don't object to [files being removed from CiviCRM](https://github.com/civicrm/civicrm-core/pull/26025) as such, however there should be mitigations in place to warn developers that this is likely to happen in a future version of CiviCRM.
When aliasing classes, it would be really helpful if methods are overloaded and implemented something like [`_deprecated_function`](https://developer.wordpress.org/reference/functions/_deprecated_function/) to write _something_ to the logs so that developers are aware of the impending removal of classes and methods, e.g.:
```php
/**
* @inheritDoc
*/
public static function getByType($contactType = NULL) {
civicrm_deprecated_function( __METHOD__, '5.39', 'CRM_Dedupe_BAO_DedupeRuleGroup::getByType()' );
return parent::getByType($contactType);
}
```
I'd have acted sooner if I'd seen something like the following in my logs:
```
Function CRM_Dedupe_BAO_RuleGroup::getByType() is deprecated since CiviCRM version 5.39. Use CRM_Dedupe_BAO_DedupeRuleGroup::getByType() or civicrm_api4() instead.
```
As it stands, people have 2 weeks or so to update their plugins/modules/etc before updating CiviCRM to 5.62 causes issues.https://lab.civicrm.org/dev/core/-/issues/2051jQuery validation not working2023-05-23T05:03:28ZAndie HuntjQuery validation not workingjQuery validation is currently not functioning in CiviCRM. The `validate`, `cancel`, and `required` classes on form elements are not triggering jQuery validation. The form still validates accurately, but this is server-side using Quick...jQuery validation is currently not functioning in CiviCRM. The `validate`, `cancel`, and `required` classes on form elements are not triggering jQuery validation. The form still validates accurately, but this is server-side using Quickform.
I first noticed this in [PR 17675](https://github.com/civicrm/civicrm-core/pull/17675), and I attempted to make a change there. However, that PR was delayed for unrelated reasons and there has been a lot of activity involving jQuery validate in the past few months.
- [PR 16488](https://github.com/civicrm/civicrm-core/pull/16488) attempted to apply the `required` attribute to required form elements.
- [PR 17929](https://github.com/civicrm/civicrm-core/pull/17929) rolled that back because it was invalid syntax.
- [PR 17937](https://github.com/civicrm/civicrm-core/pull/17937) adds the `required` attribute to individual radio options
- [PR 18080](https://github.com/civicrm/civicrm-core/pull/18080) dev/core#1928 switches the `required` on each radio option to a class name rather than an attribute
@colemanw @mattwire @seamuslee @DaveD I'm opening a PR that's mostly that one commit detached from [PR 17675](https://github.com/civicrm/civicrm-core/pull/17675).
There are two problems that remain even with the PR:
1. A required element inside a collapsed accordion won't be easily noticed. Server-side validation forces the accordion open, but the jQuery validation does not. However, I see no console errors from the result.
2. The behavior seems to vary from form to form. The New Contribution form is quite different from New Activity. The latter seems to never use jQuery Validator. Even besides looking for POST activity, you can see the different ways the validation appears:
With jQuery validator:
![image](/uploads/baac45affed515d1e7d2bcf67985da3a/image.png)
Server-side validation:
![image](/uploads/22e682d1fe77bf9344bae34a42841321/image.png)https://lab.civicrm.org/dev/core/-/issues/2088Maximum Participant Count for Event not enforced in some situation (Wordpress...2023-05-23T05:03:28ZclementMaximum Participant Count for Event not enforced in some situation (Wordpress 5.0.8, CIVICRM 5.12.0, also observed on WP 5.4.2/CIVICRM 5.21.2))We saw recently that 2 event registration that were set to have a maximum number of participants. Event A has set to a maximum number of 29 but allowed 30, and Event B has set to a maximum number of 17 but allowed 19. Until these 2 event...We saw recently that 2 event registration that were set to have a maximum number of participants. Event A has set to a maximum number of 29 but allowed 30, and Event B has set to a maximum number of 17 but allowed 19. Until these 2 events, the maximum number has been enforced well on the events.
When I looked at the last few registrations (all frontend) for these 2 events, for Event A, the last registration registered 1min after the prior 2 registrations which registered at the same time to the minute. For Event B, the last 3 registrations where all registered at the same time to the minute. I tried to register for these events and the Event is full message is correctly shown.
Would this anomaly be due to how the registrations take place particularly when they are in close succession? Any advice and what can be done ? I researched on the net and it seems there was a issue about max participant enforcement (CRM5039), but that was more than ten years ago, that woulnd't be the issue by know i suppose. Any advise? Thanks.
After some fiddling around, I managed to get 2 participants into a event with a 1 participant limit using the following method:
- Participant A typing in his details to register for event
- Participant B registered later but completed his registration and pressed "Continue"
- Participant A pressed "Continue"
- Both participants pressed "Continue" together at the "Confirm Your Registration Information" page
This looks like a bug to me, any views ? Thanks.https://lab.civicrm.org/dev/core/-/issues/4306New SMS screen crashes due to extra space in {htxt id ="id-sms_..."} in Group...2023-05-23T00:11:48ZjhungerfordNew SMS screen crashes due to extra space in {htxt id ="id-sms_..."} in Group.hlpOverview
----------------------------------------
After updating from Civi 5.57.x to 5.61.2, pressing "New SMS" or navigating to /civicrm/sms/send?reset=1 results in this error message:
```
Sorry, due to an error, we are unable to fulfi...Overview
----------------------------------------
After updating from Civi 5.57.x to 5.61.2, pressing "New SMS" or navigating to /civicrm/sms/send?reset=1 results in this error message:
```
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.
Invalid {htxt} tag. Wrapped 10 opening-tags and 12 closing-tags.
```
Reproduction steps
----------------------------------------
1. Navigate to /civicrm/sms/send?reset=1
Current behaviour
----------------------------------------
Some of the page content is present, but most of it is replaced with the error message mentioned above.
Expected behaviour
----------------------------------------
It should have a form for selecting the SMS provider, as well as "Next" and "Cancel" buttons.
Environment information
----------------------------------------
* __CiviCRM:__ 5.61.2
Comments
----------------------------------------
The bug is caused by the extra spaces in the last two {htxt} tags in this file:
https://lab.civicrm.org/dev/core/-/blob/master/templates/CRM/SMS/Form/Group.hlp#L50-53
This regex doesn't match the extra space, so it throws an exception when the count of `{htxt}`s doesn't match the count of `{/htxt}`s:
https://lab.civicrm.org/dev/core/-/blob/master/CRM/Core/Smarty/plugins/prefilter.htxtFilter.php#L21
Removing the extra spaces fixes the page:
`{htxt id="id-sms_provider-title"}`
and
`{htxt id="id-sms_provider"}`https://lab.civicrm.org/dev/core/-/issues/2101Add relationship start date logic to the existing Civi scheduled job for rela...2023-05-22T05:03:24ZshitijgAdd relationship start date logic to the existing Civi scheduled job for relationshipsOverview
----------------------------------------
If a user creates a relationships with a future start date:
- The relationship shows in the ‘active’ relationships section
- is_active field of the relationship is set as 1
As CiviCRM t...Overview
----------------------------------------
If a user creates a relationships with a future start date:
- The relationship shows in the ‘active’ relationships section
- is_active field of the relationship is set as 1
As CiviCRM treats this as an ‘active relationship’, so does webform_civicrm, which means users can select a contact with this relationship (through setting the existing contact field show contacts with this relationship) even if the start date is in the future
Example use-case
----------------------------------------
1. Go to a contact
2. Add a relationship with start date in future ie start date > today (and no end date)
3. Save relationship
4. is_active field for the relationship (check civicrm_relationship table) is set to 1
Current behaviour
----------------------------------------
On creation / updating of a relationship with a future start date (start date>today), CiviCRM sets the is_active field = 1
Proposed behaviour
----------------------------------------
On creation / updating of a relationship with a future start date (start date>today):
- SET is_active =0
Add to the logic of the existing relationship expiry scheduled job (Disable expired relationships) which sets the is_active field to 0 for relationships where end date is in the past:
- Update 'Title' to: Enable and Disable relationships
- Help text:
Enables relationships where start date < = today (ie those relationships whose start date is today / in the past)
Disables relationships that have expired (ie. those relationships whose end date is in the past).
- Logic: Along with the existing logic (for disabling expired relationships), we are adding the following logic to the same scheduled job:
Sets the relationship is_active field = 1 for relationships where start date < = today AND end date >today (ie those relationships whose start date is today / in the past)https://lab.civicrm.org/dev/core/-/issues/1343Document REST API using OpenAPI specification2023-05-22T05:03:23ZbrylieDocument REST API using OpenAPI specificationSplit from #1310
It would be helpful if the CiviCRM REST API were to be documented using the [OpenAPI Specification](https://www.openapis.org/). This would have at least a couple of benefits:
* the docs could be rendered in any of sev...Split from #1310
It would be helpful if the CiviCRM REST API were to be documented using the [OpenAPI Specification](https://www.openapis.org/). This would have at least a couple of benefits:
* the docs could be rendered in any of several developer-friendly interfaces
* integration code could be auto-generated from the specificationhomotechsualhomotechsualhttps://lab.civicrm.org/dev/core/-/issues/2134Order of custom groups not correct2023-05-21T05:03:17ZxavierOrder of custom groups not correctOverview
----------------------------------------
When editing a case, the order of custom groups isn't correct (doesn't respect weight)
Reproduction steps
----------------------------------------
1. Create a new custom group for a cas...Overview
----------------------------------------
When editing a case, the order of custom groups isn't correct (doesn't respect weight)
Reproduction steps
----------------------------------------
1. Create a new custom group for a case "second"
2. Create a new custom group for a case "first"
3. change the order (weight) so "first" is before "second"
4. create a new case
Current behaviour
----------------------------------------
the custom groups are sorted by id, not by weight
Expected behaviour
----------------------------------------
The custom groups are sorted by weight
Environment information
----------------------------------------
Out of the box normal civi. Do you want me to create a test case on demo?
Comments
----------------------------------------
I spent a few hours drilling through the code, getTree (CRM/Core/BAO/CustomGroup.php) returns the groups properly sorted
but groupTree in templates/CRM/Custom/Form/CustomData.tpl isn't ;(
in CRM/Core/BAO/CustomGroup.php::buildQuickForm
$groupTree is correct (with the correct order)
but $form->assign_by_ref("{$prefix}groupTree", $groupTree);
ends up with the groupTree being re-ordered in smarty?
I'm a bit confused as when the order of the custom block is defined, but I'm pretty keen on having it respecting the weight/sort order ;)https://lab.civicrm.org/dev/core/-/issues/2124Add skip triggers to cv / drush / wp mysql dump to ensure we skip the definer...2023-05-21T05:03:16ZseamusleeAdd skip triggers to cv / drush / wp mysql dump to ensure we skip the definers to assist in server / mysql moves@eileen @kcristiano @eileen @justinfreeman@eileen @kcristiano @eileen @justinfreemanseamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/161Adding preSave_table_name hook2023-05-20T05:03:22Zomar_compucorpAdding preSave_table_name hookCurrently there is only **postSave_table_name** hook that run after a write operation on a core table that has an associated DAO. But in some cases it is useful to have a hook that run before the write operation.
An example whwre such ...Currently there is only **postSave_table_name** hook that run after a write operation on a core table that has an associated DAO. But in some cases it is useful to have a hook that run before the write operation.
An example whwre such hook is useful is when you cancel a membership contribution then the membership status will also change to **Cancelled**, but the cancellation of the membership does not trigger **hook_civicrm_pre** nor **hook_civicrm_post** hooks because this is how civicrm change the membership status when you cancel the membership :
https://github.com/civicrm/civicrm-core/blob/cbaa9a31f02afda8d2e19610da823fd0c4d28a16/CRM/Contribute/BAO/Contribution.php#L1049-L1052
hence that **hook_civicrm_pre** and **hook_civicrm_post** are invoked in the BAO class create method so doing anything using DAO directly as in the example above won't invoke any of these hooks and if you are planning to do any operation before editing the membership table in the case above then you are out of luck.
A new hook similar to **postSave_table_name** hook with the name **preSave_table_name** should be added to solve the issue mentioned issue.