CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-08-17T14:15:48Zhttps://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/4485Replace Event Total by Total Amount on confirm/thankyou pages2023-08-11T23:03:31ZyashodhaReplace Event Total by Total Amount on confirm/thankyou pagesReplace _Event Total_ by _Total Amount_ on confirm/thankyou pagesReplace _Event Total_ by _Total Amount_ on confirm/thankyou pages5.66.0yashodhayashodhahttps://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/4467Import caching issue2023-08-03T12:58:44ZeileenImport caching issueSteps to replicate
1) Enable Civi-import
2) Import the attached file 'import.csv' (Contributions-\>import contributions) - be sure to create an import template on the mapping screen
![image.png](/uploads/31373d18b7c61b4d81e17c3c256f6a7...Steps to replicate
1) Enable Civi-import
2) Import the attached file 'import.csv' (Contributions-\>import contributions) - be sure to create an import template on the mapping screen
![image.png](/uploads/31373d18b7c61b4d81e17c3c256f6a7f/image.png)
3) After doing that first import use the import template & try to import the second attached file (import_with_source.csv)
![image.png](/uploads/9c0149213e4c31c4eea70bd7e10ae5ca/image.png)
4) Update the mapping & choose to save it
![image.png](/uploads/3d4669537b10f7c947f716b47b862e18/image.png)
5) after updating try to re-use with the same csv & the error still pops up
![image.png](/uploads/7f24d75f78a4c71784b2f6eb35ff0f30/image.png)
6) I have ALSO been experiencing issues with the import template updates not 'saving' when the cache is warm. However, I couldn't replicate today when trying to - but the error in 5 was consistent. @larssg also reported it not saving here https://github.com/civicrm/civicrm-core/pull/26867#issuecomment-1640580102 & that day I couldn't replicate & then another day I could.... and now I can't
[import.csv](/uploads/35ffcf0f7778417e4ea63fe55f5165a3/import.csv)
[import_with_source.csv](/uploads/b60901676b4f90c480d9bba7c2b49cd5/import_with_source.csv)https://lab.civicrm.org/dev/core/-/issues/4464Authentication tokens: session already active - different user2023-08-04T12:51:21Zaydunsaidan.saunders@squiffle.ukAuthentication tokens: session already active - different userOverview
----------------------------------------
See #4463 and https://lab.civicrm.org/dev/core/-/issues/4462 This improvement issue relates to handling the case where the new user is different to that of the existing session.
From [t...Overview
----------------------------------------
See #4463 and https://lab.civicrm.org/dev/core/-/issues/4462 This improvement issue relates to handling the case where the new user is different to that of the existing session.
From [this chat](https://chat.civicrm.org/civicrm/pl/n4cr3jownifexnjda3k45qhura):
@totten says:
- if the active session is same user, then no problems. just proceed.
- if the active session user differs from the requested user, then you kinda have to choose between:
- killing the old session and starting a new one
- changing the userID of the live session. (but then you're liable to leak session-data in hard-to-predict ways)
- aborting the request
For the already active session with different user - I think it would be ideal to show a prompt and confirm that they want to logout/switch-user.https://lab.civicrm.org/dev/core/-/issues/4463Authentication tokens: session already active - same user2023-08-03T14:23:35Zaydunsaidan.saunders@squiffle.ukAuthentication tokens: session already active - same userOverview
----------------------------------------
If a user clicks an authenticated link a second time the result is an error message stating: `HTTP 401 Cannot login. Session already active.`
See [this chat](https://chat.civicrm.org/civ...Overview
----------------------------------------
If a user clicks an authenticated link a second time the result is an error message stating: `HTTP 401 Cannot login. Session already active.`
See [this chat](https://chat.civicrm.org/civicrm/pl/n4cr3jownifexnjda3k45qhura)
and https://lab.civicrm.org/dev/core/-/issues/4462
Reproduction steps
----------------------------------------
1. Create a FormBuilder form and enable the Token option
1. Send a mail using the form token. This link includes "_authx=Bearer..."
1. Click the link on the received mail. - Should work and creates an authenticated session.
1. Click the link again - fails with `HTTP 401 Cannot login. Session already active.`
Expected behaviour
----------------------------------------
There are two scenarios depending on whether it is the same user. This bug issue relates to the case where the user is the same. See #4464 for handling this where the user is different.
It the user is the same, it should just continue to the form without error.https://lab.civicrm.org/dev/core/-/issues/4462Transactional Authentication (Page-level auth tokens)2024-03-01T19:59:17Zaydunsaidan.saunders@squiffle.ukTransactional Authentication (Page-level auth tokens)Overview
----------------------------------------
Improve the support for transactional approaches in the authentication framework. The current implementation of authentication tokens is more suited to a portal approach than a transacti...Overview
----------------------------------------
Improve the support for transactional approaches in the authentication framework. The current implementation of authentication tokens is more suited to a portal approach than a transactional one.
See [this snippet](https://lab.civicrm.org/-/snippets/92 ) for the background describing how to use authenticated links with forms. This documents the resulting conversation with @totten [here](https://chat.civicrm.org/civicrm/pl/trubx7xwui878nsz3w6ujmf6oc):
(@totten says:) I'd like some language to describe two ways of approaching customized UX for constituents.
- Hypothetical scenario
- You send an email 12 months after a prior donation. You thank the donor for the previous contribution. The message includes some links to update communication preferences, browse past donations, or make a new donation.
- UX Approaches
1. **Transactional Approach / One form at a time / Strict Pageflow / Page-Level Auth**: The email has 3x hyperlinks. Each goes to different form/page. Each link has diff auth code (which confers access to exactly one form).
2. **Portal Approach / Multiple forms at discretion / Open Pageflow / Session-Level Auth**: The email has 3x hyperlinks. All go to pages within the same portal. The user opens the first page which takes their interest. On that page, there are more links (eg via prose or navbar) to go checkout the others.
I don't know a good/simple way to say that one is better than the other. but they are different. I suspect there's some Venn diagram of organizational-scenarios (some better suited to 1; some to 2; some to either 1 or 2)
The current auth-code mechanism is better for "Portal Approach/Open Pageflow" -- and it's worse for Transactional Approach/Strict Pageflow"
(that's not b/c "Open Pageflow" is better -- but at the time of its writing, it was the easier one to support)
From a low-level POV, the auth-codes for them would differ like this:
- For portal/open pageflow, it generates this token -- which is basically a login-token
- -The custom forms use "Role-based" security-(Maybe either security model is ok in this context...)
- For transactional/strict pageflow, you might expect...
- It needs a fine-grained token like this (pseudocode)
```
$bearerToken = "Bearer " . $jwt->encode([
'exp' => $expires,
'sub' => "cid:" . $contactId,
'scope' => 'api4',
'api4.whitelist' => [
['Afform', 'prefill', ['name' =>'xyz']],
['Afform', 'submit', ['name' =>'xyz']],
]);
```
- In PHP, need a mechanism to accept those tokens
- In JS/HTML, need a mechanism to relay that token
- The custom forms use "Form-based" security
See also
--------
- #4463: Authentication tokens: session already active - same user
- #4464: Authentication tokens: session already active - different userhttps://lab.civicrm.org/dev/core/-/issues/4460Feature request: Force recurring-only2023-08-11T06:35:18ZMariaVFeature request: Force recurring-onlyI would like to propose a feature for contribution pages.
There is already an [extension (ca.civicrm.contributionrecur)](https://github.com/adixon/ca.civicrm.contributionrecur/) with this feature (and a lot more) but unfortunately it do...I would like to propose a feature for contribution pages.
There is already an [extension (ca.civicrm.contributionrecur)](https://github.com/adixon/ca.civicrm.contributionrecur/) with this feature (and a lot more) but unfortunately it does not work properly anymore.
It is possible to force recurring payments only - which is very useful for i.e. membership pages.
When this option is selected, it is not possible to uncheck the checkbox:
![image](/uploads/d3898e4c576b669018029e7b4da3cb08/image.png)https://lab.civicrm.org/dev/core/-/issues/4458Error when viewing contact-info profile without "view deleted contacts" permi...2023-08-07T12:11:55ZcolemanwError when viewing contact-info profile without "view deleted contacts" permissionThe change in b7edabe813db467aff6dd1ea083d798089198655 switched the profile to use APIv4 to fetch email id for constructing an email link. The API call looks like this:
```php
$emailID = Email::get()->setOrderBy(['is_primary' => 'DES...The change in b7edabe813db467aff6dd1ea083d798089198655 switched the profile to use APIv4 to fetch email id for constructing an email link. The API call looks like this:
```php
$emailID = Email::get()->setOrderBy(['is_primary' => 'DESC'])->setWhere([['contact_id', '=', $this->_id], ['email', '=', $email], ['on_hold', '=', FALSE], ['contact_id.is_deceased', '=', FALSE], ['contact_id.is_deleted', '=', FALSE], ['contact_id.do_not_email', '=', FALSE]])->execute()->first()['id'];
```
It was reported on SE that this fails for users without "view deleted contacts", however I'm unable to reproduce.
See https://civicrm.stackexchange.com/questions/45313/invalid-field-contact-id-is-deceased-apiv4
This should have already been double-fixed by:
- [Revert "Add permission metadata to contact is_deleted field" #22203](https://github.com/civicrm/civicrm-core/pull/22203)
- [APIv4 - Silently ignore non-permissioned fields instead of throwing exceptions #20724](https://github.com/civicrm/civicrm-core/pull/20724)https://lab.civicrm.org/dev/core/-/issues/4457Entity Reference Custom Field not working as filter in "regular" search2023-10-03T21:46:14ZjensschuppeEntity Reference Custom Field not working as filter in "regular" searchFollow-up to #3721. @fabian_SYSTOPIA found out that filtering doesn't work correctly.
Not sure this is to be fixed, as it's related to the "old-style" searches ...
## Steps to reproduce
* Create an Entity Reference Custom Field on the...Follow-up to #3721. @fabian_SYSTOPIA found out that filtering doesn't work correctly.
Not sure this is to be fixed, as it's related to the "old-style" searches ...
## Steps to reproduce
* Create an Entity Reference Custom Field on the *Participant* entity for referencing an *Event* entity
* Edit a participant and fill out the field by selecting an event
* Use the *Find Participants* search and try to limit the search result to participants with the event previously selected in that field
* Notice that all participants are being found, not only that one with the entity reference field being filledhttps://lab.civicrm.org/dev/core/-/issues/4454Proposal: Rename "Scheduled Reminders"2023-10-09T22:42:58ZJonGoldProposal: Rename "Scheduled Reminders"From a UX perspective, "Scheduled Reminders" is a poor name. It has uses far beyond reminders, and it's unintuitive to create a birthday email or "welcome series" of emails using a feature called "Scheduled Reminders".
I don't 100% h...From a UX perspective, "Scheduled Reminders" is a poor name. It has uses far beyond reminders, and it's unintuitive to create a birthday email or "welcome series" of emails using a feature called "Scheduled Reminders".
I don't 100% have a term decided on, though everyone loves a good bikeshed. I considered "Scheduled Messages" or "Scheduled Communications" - but I would expect a scheduled CiviMail or SMS to fall under that label (but maybe so does "Scheduled Reminders"?). "Automated Messages" overlaps with the System Messages. "Scheduled Message Rules" is better but long (if we ignore CiviRules momentarily).
Does anyone else have thoughts? I could live with "Scheduled Messages" as an improvement, but perhaps there's something better.