Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-08-24T16:19:13Zhttps://lab.civicrm.org/dev/core/-/issues/4493Support for Note entity available in FormBuilder2023-08-24T16:19:13ZbrienneSupport for Note entity available in FormBuilderOverview
----------------------------------------
In continuing to expand FormBuilder's use cases, it would be great to support the Note entity on afforms, so that users can have a place to enter text without having to create a custom fi...Overview
----------------------------------------
In continuing to expand FormBuilder's use cases, it would be great to support the Note entity on afforms, so that users can have a place to enter text without having to create a custom field on the entity to which they want to stick a note.
Example use-case
----------------------------------------
1. A form for users to create a new contact and add a note about them, which may not fit into a specific (or reusable) custom field
Current behaviour
----------------------------------------
The Note entity is not currently available to add to an afform.
Proposed behaviour
----------------------------------------
A Note entity could be added in FormBuilder and configured so that the back end user can select the `entity_table` that the Note is associated with.https://lab.civicrm.org/dev/translation/-/issues/83No translation for "sections" in "New <contact>"2023-08-30T12:57:17Zthoni56No translation for "sections" in "New <contact>"When creating a new person/household/organisation there are foldable sections for details, address, communication preferences etc.
When the site has a non-English localization (at least a Swedish one) they are not translated.
![Skärmav...When creating a new person/household/organisation there are foldable sections for details, address, communication preferences etc.
When the site has a non-English localization (at least a Swedish one) they are not translated.
![Skärmavbild_2023-08-11_kl._13.38.33](/uploads/effa60ca9aa352a2d735ddfe89bb8d79/Skärmavbild_2023-08-11_kl._13.38.33.png)
I'm contributing to the Swedish translation so I know that the strings are translated in Transifex ;-). I have `uplang` installed and it seems to update other translations (although I would love a way to explicitly trigger the download, see https://lab.civicrm.org/extensions/uplang/-/issues/2).https://lab.civicrm.org/dev/core/-/issues/4492(regression) Add/Edit Scheduled Reminders page does not load if CiviContribut...2023-09-02T05:11:57ZJonGold(regression) Add/Edit Scheduled Reminders page does not load if CiviContribute is disabledWorks on 5.63, not on 5.64. Hard to bisect because `getDefaultEntity()` becomes a required method somewhere along the line.
Easy to replicate:
* Disable CiviContribute.
* Try to create a scheduled reminder.
You'll get this error:
```...Works on 5.63, not on 5.64. Hard to bisect because `getDefaultEntity()` becomes a required method somewhere along the line.
Easy to replicate:
* Disable CiviContribute.
* Try to create a scheduled reminder.
You'll get this error:
```
Error: Class "Civi\Api4\ContributionRecur" not found in CRM_Contribute_Tokens->getRelatedTokens() (line 59 of /home/jon/local/civicrm-buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Contribute/Tokens.php).
```
Seems related to #4123 (pinging @seamuslee) but that was merged in 5.63 and it seems fine in 5.63.
I'd throw a conditional into `CRM_Contribute_Tokens->getRelatedTokens()` to fix this but given all the work on moving to extensions, I suspect this is a deeper issue that needs looking at.https://lab.civicrm.org/dev/core/-/issues/4491Document - Modifying Afform Editor UI2023-08-17T14:17:17ZseamusleeDocument - Modifying Afform Editor UIInspired by Kevin's comments here https://chat.civicrm.org/civicrm/pl/86tae1m6ijfiuf7ejewi9q8wxo It made me think about if I was doing an email submission handling as an extension how I would go about it
We already have the afformSubmis...Inspired by Kevin's comments here https://chat.civicrm.org/civicrm/pl/86tae1m6ijfiuf7ejewi9q8wxo It made me think about if I was doing an email submission handling as an extension how I would go about it
We already have the afformSubmission event which can be used to trigger the sending of the email. However I would imagine end users would want some level of customisations on a per form basis, e.g. the to email address, The email body, the subject line and maybe the from email address. What I don't know is if we have good documentation about how to modify the afform editor interface to include such fields that can then be stored somewhere sensible and I don't know where that storage would be either.
I figure we should have some documentation here as to the correct way to do this as others may want to add their own submission events on e.g. posting to a zapier end point or maybe throwing a webhook somewhere right?colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/4490Feature request - Queue api should respect maintenance mode2023-09-20T02:39:21ZeileenFeature request - Queue api should respect maintenance modeProposal to add a maintenance mode setting that is respected by the Queue api such that it would not permit `claimItems` while this setting is enabled - except for possibly upgrade tasks?
Note that when coworker respects this it should ...Proposal to add a maintenance mode setting that is respected by the Queue api such that it would not permit `claimItems` while this setting is enabled - except for possibly upgrade tasks?
Note that when coworker respects this it should log a message with a priority of `warning` so that a sysadmin can see that although the process is running no tasks are.
Chat discussion to date https://chat.civicrm.org/civicrm/pl/9h93yabz33g17qa3apcet8irdy
The summary of the chat is that `claimItem` api should be the place where maintenance mode is checked & heeded. This would be for 'persistent queues' - ie `CRM_Queue_Queue_Memory` would not check it.
- [ ] The claim item/s functions should call a symfony listener - returning false in this piece of code if an external listener (threshold check) sets the status to false
- [ ] we should add a setting for Maintenance mode (keep it simple) - call it `queue_maintenance_mode`? ClaimItem should return FALSE if this is TRUE
**Notes**
1) the following query will determine whether all queues have finished once maintenance mode is enabled:
`SELECT * FROM civicrm_queue_item where release_time > NOW()`
If future scheduling is in use (civi-rules?) then this might not suffice and if that ever arises as a feature someone wants to work on they could add a suitable field to the `civicrm_queue_item` table (`is_future_scheduled` ?)
2) I can't recall what we decided re should claimItems support an override - ie if you took everything else down in order to keep one queue running & want that queue to still claim items.... perhaps I'll find ithttps://lab.civicrm.org/dev/core/-/issues/4489FormBuilder UX general improvements2023-08-17T14:15:48ZbrienneFormBuilder UX general improvementsOverview
----------------------------------------
This feature request stems from the monthly FormBuilder meeting and some product research of other form building tools, such as Webform (Drupal) and WPForms (WordPress).
Current behavio...Overview
----------------------------------------
This feature request stems from the monthly FormBuilder meeting and some product research of other form building tools, such as Webform (Drupal) and WPForms (WordPress).
Current behaviour
----------------------------------------
There are several aspects of the FormBuilder UI that are not as user friendly as they could be. Taking on the UI overall is quite a big project, but it can be parsed into smaller portions that can be easier to tackle, such as making the listing of Entities span the width of the screen so that the user has more real estate to see what they've added to the form.
Proposed behaviour
----------------------------------------
I've created a [wireframe](https://briennekordis957225.invisionapp.com/freehand/FormBuilder-gEujDK3pw?dsid_h=9f8d5b19659b2874dcac52af00d939a53fd8db4d67516799d42d559da618ca25&uid_h=02b042cff858bbdbc3946e1968bcbe6a1445c788c050f33252bf8876878fb775) with some ideas the meld an improved design of FormBuilder's current layout with some of the better features of WebForm and WPForms.
![Selection_016](/uploads/8994c626ba5ad0f628dd42cc7417a2f6/Selection_016.png)
![Selection_017](/uploads/790e8de4193c486023eaeed94c073994/Selection_017.png)
![Selection_018](/uploads/6ef75e5b76588b89dadc36722603e5c2/Selection_018.png)https://lab.civicrm.org/dev/core/-/issues/4488Supporter Profile is a required field2023-11-23T07:48:29Zkiwi_BrogrammerSupporter Profile is a required fieldOverview
----------------------------------------
When editing contribution pages, if you click on the personal campaign tab and save (without changes) you get a warning about supporter profile being required field.
replicated this on d...Overview
----------------------------------------
When editing contribution pages, if you click on the personal campaign tab and save (without changes) you get a warning about supporter profile being required field.
replicated this on dmaster site.
civichat discussion : https://chat.civicrm.org/civicrm/pl/b8gp5g6u63dr7d6d8oqrrrc5nr
Environment information
----------------------------------------
* __CiviCRM:__ 5.62.1.
* __PHP:__ 8.1.20
* __CMS:__ Drupal 10.1.1
* __Database:__ MariaDB 10.5.19https://lab.civicrm.org/dev/core/-/issues/4487Contribution pages with extra URL parameters lead to incorrect AJAX URL const...2023-08-10T14:20:50ZsebalisContribution pages with extra URL parameters lead to incorrect AJAX URL constructed in buildPaymentBlock – users cannot proceed to payHi,
I encountered an error while building an Engish version of a contribution page on a system that mostly operates in German. While entering translated texts for all elements, I was told that some elements (button captions, the “total”...Hi,
I encountered an error while building an Engish version of a contribution page on a system that mostly operates in German. While entering translated texts for all elements, I was told that some elements (button captions, the “total” text) cannot be configured in the contribution page or the profiles and price sets it includes (for all of which I built translated copies). Instead, they are supplied by core itself so we need to signal to core that they should be produced in English, too.
By default, the language for these elements seems to be determined by the browser language, but I was interested in overriding this and was advised (by @Detlev) that I could add a (Drupal-specific) GET parameter `language=en` to the URL for that purpose. This does work – up to the point where users want to choose their payment options.
My contribution page (on a Drupal 9 system) has a choice between the PayPal and SEPA processors. When users click the respective radio button, an AJAX request is issued to a URL like
`<host>/civicrm/payment/form?formName=Main&is_back_office=&id=14&pre_profile_id=78&processor_id=&language=en3&payment_instrument_id=undefined¤cy=EUR&snippet=json`
Notice that the value for `language` has been extended from `en` to `en3` and the URL parameter for processor_id is empty. This leads to a popup with a complaint about a network error, and users cannot proceed. Inspecting the communication reveals that the AJAX request returns a 500 status, and the Civi log contains information about the empty value for `processor_id` being the problem.
It turns out that the page has some inline JavaScript code that tries to build the processor ID into the AJAX URL in the `buildPaymentBlock` function. It does this by concatenating the parameter `type` to a partial URL that itself is produced using the crmURL smarty tag. On my payment page, the offending line was this:
```
var dataUrl = "/civicrm/payment/form?formName=Main&is_back_office=&id=14&pre_profile_id=78&processor_id=&language=en" + type;
```
This is rendered by the following line in `templates/CRM/common/paymentBlock.tpl`:
```
var dataUrl = "{crmURL p='civicrm/payment/form' h=0 q="formName=`$form.formName``$urlPathVar``$isBackOfficePathVar``$profilePathVar``$contributionPageID``$preProfileID`processor_id="}" + type;
```
It is obviously assumed that the string produced by crmURL ends with `processor_id=`. However, if extra parameters such as `language=en` are present, these end up at the end of the string produced by crmURL, although the parameters in the call to the Smarty tag do not indicate this. Some further lines in the code add other parameters, leading to the full list of parameters given above. But this line is where the problem is created. The line was executed with `type` set to 3 (the ID of the SEPA processor in my setup) and this is how the `language` value became `en3` and `processor_id` remained empty.
I am going to submit a pull request with a solution with this issue. Since we apparently cannot know where `type` should be inserted, the solution had to involve some kind of templating instead of string concatenation. I would have preferred some templating function provided by one of the JavaScript libraries that are already included on the page. The only candidate library I found was Lodash which provides `CRM._.template`. The syntax to use would have been `<%= type %>`, but that gets URL-escaped by the Smarty tag. Correcting this would become messy, so I resorted to a hand-crafted call to String.replace using `__type__` as the placeholder, in the hope that there is no real risk of this string appearing somewhere else in `dataURL` by accident. Edit: I have made the replacement more specific in a second commit, so the risk of it applying in the wrong place should now be vanishingly small.
I hope that this is an acceptable solution. The problem seems generic enough to affect other people too. I encountered and patched this on an old system (5.58.1, there are issues that prevent us from immediately updating), but the line in `templates/CRM/common/paymentBlock.tpl` is unchanged in the current master branch and I assume that the way the crmURL Smarty tag works hasn’t changed either.https://lab.civicrm.org/dev/core/-/issues/4484Feature request: New contact buttons on the API 4 autocomplete widget2023-11-01T18:20:41ZbrienneFeature request: New contact buttons on the API 4 autocomplete widgetOverview
----------------------------------------
For using the APIv4 autocomplete widget, such as for the *Existing Contact* field, it would be useful to be able to create new contacts, as is possible with the Select2 drop downs, such a...Overview
----------------------------------------
For using the APIv4 autocomplete widget, such as for the *Existing Contact* field, it would be useful to be able to create new contacts, as is possible with the Select2 drop downs, such as for selecting a Contributor on a backend contribution.
![Selection_015](/uploads/30fc0ecdd3268ebc5906ce0aa06dae9a/Selection_015.png)
Example use-case
----------------------------------------
1. Add the *Existing Contact* field to a FormBuilder form
1. A user can look up a contact to select, but if there are no results/a new one is needed, they can click a **New Individual** button to add one without being redirected from the original form
Current behaviour
----------------------------------------
The APIv4 autocomplete widget does not allow for creating new contacts.
![Selection_014](/uploads/d97659f7dddfd4858bd316acb0dda2b6/Selection_014.png)
Proposed behaviour
----------------------------------------
The APIv4 autocomplete widget should have feature parity when it comes to creating new contacts on the spot as the Select2 optionhttps://lab.civicrm.org/dev/core/-/issues/4483(regression) SearchKit doesn't handle delegated access permissions correctly2023-09-02T22:17:28ZJonGold(regression) SearchKit doesn't handle delegated access permissions correctlyA git bisect traced this to https://github.com/civicrm/civicrm-core/pull/25969. It works in 5.60.
When a user does not have the 'all CiviCRM permissions and ACLs', making a contact field in-line editable that isn't on the primary entit...A git bisect traced this to https://github.com/civicrm/civicrm-core/pull/25969. It works in 5.60.
When a user does not have the 'all CiviCRM permissions and ACLs', making a contact field in-line editable that isn't on the primary entity causes a crash (and no search results returned).
**Steps to Replicate**
* Create a new user without 'all CiviCRM permissions and ACLs' permission, but otherwise an administrator. This may not be necessary on non-Drupal systems - but user 1 having all permissions blocks replication.
* Create the SearchKit query in the screenshot below (I've exported it for easier use).
* Create a table display, make the "Gender" field in-line editable.
* Press "Preview"
**Expected Result**
You see search results.
**Actual Result**
500 error - `getFieldValue failed`.
The issue is in `CRM_Contact_BAO_Contact::_checkAccess()`. This attempts to access `$record['id']` but after PR #25969, the record is passing `id_01.id`.
![Selection_1999](/uploads/5e6a7126c09291fc5c1cf4eb6e87c300/Selection_1999.png)
```json
[
[
"SavedSearch",
"save",
{
"records": [
{
"name": "delegated_permission_test",
"label": "delegated permission test",
"form_values": null,
"mapping_id": null,
"search_custom_id": null,
"api_entity": "Participant",
"api_params": {
"version": 4,
"select": [
"id",
"Participant_Contact_contact_id_01.display_name",
"Participant_Contact_contact_id_01.gender_id:label"
],
"orderBy": [],
"where": [],
"groupBy": [],
"join": [
[
"Contact AS Participant_Contact_contact_id_01",
"LEFT",
[
"contact_id",
"=",
"Participant_Contact_contact_id_01.id"
]
]
],
"having": []
},
"expires_date": null,
"description": null
}
]
}
],
[
"SearchDisplay",
"save",
{
"records": [
{
"name": "delegated_permission_test_Table_1",
"label": "delegated permission test Table 1",
"saved_search_id.name": "delegated_permission_test",
"type": "table",
"settings": {
"description": null,
"sort": [],
"limit": 50,
"pager": [],
"placeholder": 5,
"columns": [
{
"type": "field",
"key": "id",
"dataType": "Integer",
"label": "Participant ID",
"sortable": true
},
{
"type": "field",
"key": "Participant_Contact_contact_id_01.display_name",
"dataType": "String",
"label": "Participant Contact: Display Name",
"sortable": true,
"title": "Participant Contact: Display Name"
},
{
"type": "field",
"key": "Participant_Contact_contact_id_01.gender_id:label",
"dataType": "Integer",
"label": "Participant Contact: Gender",
"sortable": true,
"editable": true
}
],
"actions": true,
"classes": [
"table",
"table-striped"
]
},
"acl_bypass": false
}
]
}
]
]
```colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/4482Action schedule effective start and end dates ignored when using an absolute ...2023-08-09T13:56:33ZjamieAction schedule effective start and end dates ignored when using an absolute trigger dateHere's an action schedule that did not go as expected:
![image](/uploads/8205f1e5dbba0c9f0b056b72d4f6c261/image.png)
Notice how there is an absolute date as the "When (trigger) date" *that does not allow you to enter a time* and also a...Here's an action schedule that did not go as expected:
![image](/uploads/8205f1e5dbba0c9f0b056b72d4f6c261/image.png)
Notice how there is an absolute date as the "When (trigger) date" *that does not allow you to enter a time* and also an "Effective Start Date" that *does allow you to enter a time.*
In the [code](https://github.com/civicrm/civicrm-core/blob/4e4de633c452fd2e9a36df61bdbdb258b9f88ed7/Civi/ActionSchedule/RecipientBuilder.php#L418) we seem to ignore the effective start and end dates when an absolute date is specified.
So, this email was sent at 12:05 am on August 5th instead of 8:05 am on August 5th.
I get it. If you are specifying an absolute start date, why would you need an effective start date?
Well, in this case it's because you are fine-tuning with a time.
I see three options:
1. Change the UI so that the effective start and end dates are greyed out if you enter an absolute date. This seems like the easiest to implement.
2. Change the code so that we don't ignore the effective start and end date when using an absolute date. I'm not crazy about messing with the Action Schedule code. But, this seems like it could be pulled off without a lot of work or risk.
3. Allow setting an absolute date with a time attached to it (and also doing number two). I would rather have a root canal than be responsible for this one. But, it does seem like the best optionhttps://lab.civicrm.org/dev/core/-/issues/4479When a contact with a shared address from another contact updates their addre...2023-08-06T18:48:45ZlarsssandergreenWhen a contact with a shared address from another contact updates their address via profile, address data can be lost or inconsistentIf you set Bob to use Julie's address and then Julie updates her address in a profile, Bob's address is updated as expected. However if Bob updates his address via profile, then Bob's address will be updated, but Bob's address will still...If you set Bob to use Julie's address and then Julie updates her address in a profile, Bob's address is updated as expected. However if Bob updates his address via profile, then Bob's address will be updated, but Bob's address will still be shown as using Julie's address (will still have the master_id, even though it is now different than the master address). This is inconsistent as Bob's address is actually now different from Julie's, so they no longer share an address.
If you then edit Bob's address and save it, Bob's address will be set back to Julie's address, losing the perhaps more current address that Bob had input in the profile (though at least in this case you can see what will happen if you are paying attention). Even worse, if you use Edit from the Contact Summary and save this form, you'll also revert Bob's address back to Julie's without it being evident that this is happening at all.
Two possibilities for the expected behaviour here:
1. Both Bob and Julie should be able to update their shared address. In this case, if Bob submits a profile, we should update the shared address (even though it belongs to Julie).
1. Bob should not be able to update the shared address, only Julie should be able to update the address. When Bob submits a profile with address fields, we compare the submitted values to the DB values and if they are different, we updated Bob's address only and change it so it is no longer a shared address (remove master_id).
I think option 1 is probably best, otherwise we would end up with shared addresses that become unshared frequently because someone will submit a profile anonymously that is deduped to an existing contact but they will write 3rd St instead of Third St or some other small change. I can see that some might want to have a shared address that can only be updated by the "owner" of the address, but I think it would be best to implement option 1 as the default behaviour and then if someone wants option 2, that could be implemented as a global and/or per address setting.https://lab.civicrm.org/dev/core/-/issues/4478(D8+) Strange handling of `$initialized` leads to crash in civix2023-09-27T04:51:47Ztotten(D8+) Strange handling of `$initialized` leads to crash in civixSteps to Reproduce
-------------------
Create a site running D9/D10. (*I focused my triage on D10, but the same arises on D9, and I suspect it would affect D8.*)
Then:
```bash
cd web/sites/default/files/civicrm/ext/civicrm
wget https...Steps to Reproduce
-------------------
Create a site running D9/D10. (*I focused my triage on D10, but the same arises on D9, and I suspect it would affect D8.*)
Then:
```bash
cd web/sites/default/files/civicrm/ext/civicrm
wget https://download.civicrm.org/civix/civix-23.08.0.phar -O civix.phar
php ./civix.phar generate:module foobar
## Answer "Y" to question about enabling the extension
```
It crashes with:
```
TypeError: htmlentities(): Argument #1 ($string) must be of type string, array given in /home/totten/bknix/build/d10/vendor/civicrm/civicrm-core/CRM/Utils/System.php on line 284 #0 /home/totten/bknix/build/d10/vendor/civicrm/civicrm-core/CRM/Utils/System.php(284): htmlentities(Array)
#1 /home/totten/bknix/build/d10/vendor/civicrm/civicrm-core/CRM/Core/Menu.php(445): CRM_Utils_System::url('civicrm/tag', 'reset=1', false, NULL, true, false, true)
#2 /home/totten/bknix/build/d10/vendor/civicrm/civicrm-core/CRM/Core/Menu.php(265): CRM_Core_Menu::buildBreadcrumb(Array, 'civicrm/tag/edi...')
#3 /home/totten/bknix/build/d10/vendor/civicrm/civicrm-core/CRM/Core/Menu.php(296): CRM_Core_Menu::build(Array)
#4 /home/totten/bknix/build/d10/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(389): CRM_Core_Menu::store()
#5 /home/totten/bknix/build/d10/vendor/civicrm/civicrm-core/CRM/Extension/Manager.php(319): CRM_Core_Invoke::rebuildMenuAndCaches(true)
#6 /home/totten/bknix/build/d10/vendor/civicrm/civicrm-core/api/v3/Extension.php(42): CRM_Extension_Manager->install(Array)
```
Analysis
--------
* The apparent error stems from `\CRM_Utils_System_Drupal8->url()`. It [swallows an exception](https://github.com/civicrm/civicrm-core/blob/5.64/CRM/Utils/System/Drupal8.php#L291-L305) and returns a malformed `$url` instead. The malformed `$url` is not a `string` and cannot be handled by `htmlentities()`.
* The underlying exception is raised by [`\Drupal\civicrm\Civicrm->initialize()`](https://github.com/civicrm/civicrm-drupal-8/blob/5.64/src/Civicrm.php#L45-L49). It tries to load `civicrm.settings.php` and fails.
* In the big picture, the underlying exception makes no sense. Look at the callstack: CiviCRM is already running. The `civicrm.settings.php` has already been loaded. The file exists.
* __Why are we initializing again?__ Because [CivicrmPathProcessor](https://github.com/civicrm/civicrm-drupal-8/blob/5.64/src/PathProcessor/CivicrmPathProcessor.php#L21-L22) repeatedly creates new instances of `Drupal\civicrm\Civicrm`. This negates the [`$initialized` guard](https://github.com/civicrm/civicrm-drupal-8/blob/5.64/src/Civicrm.php#L27-L29).
* To visualize this, you can apply https://gist.github.com/totten/e983d23439addeb7f76b0d7f52679031 and run `cv flush`.
* __Why is the file missing?__ The CWD changed.
* In the original CLI, the CWD is `DRUPALSITE/web/sites/default/files/civicrm/ext/civicrm`
* During bootstrap, CWD changes to the web-root (`DRUPALSITE/web`). The chosen path for `$settingsFile` is relative to that.
* But `civix` needs to create files in the original CWD. After bootstrap, it returns to the original CWD.
* But `$settingsFile` is relative -- and not valid in this new path.https://lab.civicrm.org/dev/core/-/issues/4477Pay later instructions for offline event registration2023-08-07T01:50:54ZlarsssandergreenPay later instructions for offline event registrationIf you register a contact for an event on the back end, you can select Pending (Pay later) as the participant status and Pending as the contribution status. However, despite what you might expect the pay later instructions for the event ...If you register a contact for an event on the back end, you can select Pending (Pay later) as the participant status and Pending as the contribution status. However, despite what you might expect the pay later instructions for the event will not be sent in the offline event registration email, as `$is_pay_later` does not exist for offline registrations.
Presumably because it is copy-pasted from the online template, the offline event registration template does contain two conditionals for `$is_pay_later` (and so we get PHP warnings).
Option one, we remove `$is_pay_later` from the offline registration template. Simplification! No more warnings.
Option two, if participant status is Pending (pay later) and contribution status is Pending and the pay later instructions text exists for the event, we add the pay later instructions to the email. This is nice because it does what the user probably expects and it gives the registrant useful information to complete the payment. The downside is we are further perpetuating the arguably bad pay later concept, though we don't directly use is_pay_later. There is also added complexity for something that is probably not that common.https://lab.civicrm.org/dev/core/-/issues/4476Autocomplete-Select input box does not display in FormBuilder2023-08-17T14:14:15ZbrienneAutocomplete-Select input box does not display in FormBuilderOverview
----------------------------------------
In trying to review [PR 26841](https://github.com/civicrm/civicrm-core/pull/26841), I came across a different issue; the input box- let alone the values to be selected- for Autocomplete-S...Overview
----------------------------------------
In trying to review [PR 26841](https://github.com/civicrm/civicrm-core/pull/26841), I came across a different issue; the input box- let alone the values to be selected- for Autocomplete-Select custom fields do not display within the FormBuilder editor nor on the afform itself.
![Selection_007](/uploads/ab2b92b6a0b67c640706af99f1e975af/Selection_007.png)
Reproduction steps
----------------------------------------
1. Create or edit an existing custom field to have a data type of Autocomplete-Select
1. Create a FormBuilder form with that custom field
1. Only the title of the custom field is displayed
1. Click on the gear of the custom field and you'll notice that the *Type* field appears empty, as the first option is blank
![Selection_008](/uploads/a3fb08b4dc07b6b7775bf6a6d41ff5a4/Selection_008.png)
Current behaviour
----------------------------------------
Only the title of the Autocomplete-Select custom field displays when that field is added to an afform.
While you can use a work around for the custom field by changing the *Type* mentioned in the last reproduction step, that defeats the purpose of having the custom field be an Autocomplete-Select.
Expected behaviour
---------------------------------
An input box that allows for typing/selection should display when an Autocomplete-Select custom field is added to an afform.
Environment information
----------------------------------------
Tested on CiviCRM 5.63.2, 5.64.0, and 5.66.alpha1,https://lab.civicrm.org/dev/core/-/issues/4475Feature request: Searchkit – Add Contains one off2023-08-09T19:47:06ZdavidFeature request: Searchkit – Add Contains one offOverview
----------------------------------------
PleaseFiltering for e.g. multiply participant roles is complicated and look not very nice compared to filtering for a participant status. The way the filtering of the two fields works is ...Overview
----------------------------------------
PleaseFiltering for e.g. multiply participant roles is complicated and look not very nice compared to filtering for a participant status. The way the filtering of the two fields works is completely different. In contrast, the selection (in the backend form participant) of role and status is very similar, both are set in a selection field. For search it should be also as same as possible.
Example use-case
![grafik](/uploads/3c6e273b903997ec94e4fa9d3454febb/grafik.png)
Until 5.63 I used “is one of”, what is not longer available for participant role. (what is ok, because it is not working 100%, how I learned here: https://lab.civicrm.org/dev/core/-/issues/1321#note_58735
Proposed behaviour
----------------------------------------
Feature request:
Is it possible to integrate a “contains on of” operator?
Is it possible to change “contains” to allows multiple values?
So it would be the same look and feel like “is one of”, what is much easier than using or/and groups and it would also fit to the data input for backend users, to have only one field to search.
Comments
----------------------------------------
I played a little bit around. If I loop throw the values in Api4SelectQuery->createSQLClause and connecting the singe pattern with or / and, it seems to work in seachrkit for participant role, but I am not skilled enough to implement finally and to understand the consequence.
```
protected function createSQLClause($fieldAlias, $operator, $value, $field, int $depth) {
//...
if ($operator === "CONTAINS" || $operator === "NOT CONTAINS" || $operator === "CONTAINS ONE OF" || $operator === "NOT CONTAINS ONE OF") {
if ($operator === "CONTAINS ONE OF") {
$operator = "CONTAINS";
$binding = " OR ";
} else if ($operator === "NOT CONTAINS ONE OF") {
$operator = "NOT CONTAINS";
$binding = " OR ";
} else {
$binding = " AND ";
}
if (is_array($value)) {
$querString = "";
foreach ($value as $v) {
if ($querString !== "") {
$querString .= $binding;
}
$querString .= $this->createSQLClause($fieldAlias, $operator, $v, $field, $depth);
}
return $querString;
}
//...
}
```https://lab.civicrm.org/dev/core/-/issues/4474Searchkit: Where clause doesn't handle financial types with commas in the name2023-08-25T02:21:36ZDaveDSearchkit: Where clause doesn't handle financial types with commas in the namee.g. suppose you have "Donations, Canada" and "Donations, US" as financial types. If you do a searchkit and in the where clause put "is one of" and choose your types, it separates them by commas so then the search doesn't find them, e.g....e.g. suppose you have "Donations, Canada" and "Donations, US" as financial types. If you do a searchkit and in the where clause put "is one of" and choose your types, it separates them by commas so then the search doesn't find them, e.g. the debug info looks like this:
```
"financial_type_id:name",
"IN",
[
"Donations",
"Canada"
]
```https://lab.civicrm.org/dev/core/-/issues/4471`updateRelatedMemberships` does not fire "pre" and "post" hooks2023-08-07T12:12:48Zmasetto`updateRelatedMemberships` does not fire "pre" and "post" hooksThe method `updateRelatedMemberships` in file `CRM/Member/BAO/Membership.php` does not call "pre" and "post" hooks. Is it a bug or is it intentional
This is the function:
```php
public static function updateRelatedMemberships($ownerMe...The method `updateRelatedMemberships` in file `CRM/Member/BAO/Membership.php` does not call "pre" and "post" hooks. Is it a bug or is it intentional
This is the function:
```php
public static function updateRelatedMemberships($ownerMembershipId, $params) {
$membership = new CRM_Member_DAO_Membership();
$membership->owner_membership_id = $ownerMembershipId;
$membership->find();
while ($membership->fetch()) {
$relatedMembership = new CRM_Member_DAO_Membership();
$relatedMembership->id = $membership->id;
$relatedMembership->copyValues($params);
$relatedMembership->save();
}
}
```
The effect is, because I'm using the `hook_civicrm_post` hook, I don't have the update hook of related memberships.
I propose to change it as:
```php
public static function updateRelatedMemberships($ownerMembershipId, $params) {
$membership = new CRM_Member_DAO_Membership();
$membership->owner_membership_id = $ownerMembershipId;
$membership->find();
while ($membership->fetch()) {
CRM_Utils_Hook::pre('edit', 'Membership', $membership->id, $params);
$relatedMembership = new CRM_Member_DAO_Membership();
$relatedMembership->id = $membership->id;
$relatedMembership->copyValues($params);
$relatedMembership->save();
CRM_Utils_Hook::post('edit', 'Membership', $membership->id, $relatedMembership);
}
}
```https://lab.civicrm.org/dev/core/-/issues/4470Allow disabling household contact type2023-08-04T03:59:56ZlarsssandergreenAllow disabling household contact typeCurrent proposal:
Make it possible to disable household contact type.
Initial: These cannot be disabled. It would be nice to be able to disable them, especially households as many orgs do not use them. I know Spark has households disab...Current proposal:
Make it possible to disable household contact type.
Initial: These cannot be disabled. It would be nice to be able to disable them, especially households as many orgs do not use them. I know Spark has households disabled, so at least disabling households shouldn't break anything. Organizations might be different though and less important to allow disabling. Maybe worth trying to allow disabling households first and then see.https://lab.civicrm.org/dev/core/-/issues/4469Add Price Field path is wrong2023-09-02T05:11:54ZlarsssandergreenAdd Price Field path is wrongIf you create a price set, afterwards you get a pop-up with the form to create a price set - but you should get the form to create a price field. Same if you go to an existing price set and click Add Price Field - you get the form to add...If you create a price set, afterwards you get a pop-up with the form to create a price set - but you should get the form to create a price field. Same if you go to an existing price set and click Add Price Field - you get the form to add a price set, not a price field.
This is due to [#26929](https://github.com/civicrm/civicrm-core/pull/26929), so paging @ayduns.