CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-09-14T12:58:32Zhttps://lab.civicrm.org/dev/core/-/issues/4570Proposal: More logging in Form Builder2023-09-14T12:58:32ZAndreasandreas.howiller@civiservice.deProposal: More logging in Form BuilderOverview
----------------------------------------
This issue explains a new proposal for the "Other improvements" section in the [Form Builder roadmap](https://lab.civicrm.org/dev/core/-/issues/3761): Extending the existing submission lo...Overview
----------------------------------------
This issue explains a new proposal for the "Other improvements" section in the [Form Builder roadmap](https://lab.civicrm.org/dev/core/-/issues/3761): Extending the existing submission log and adding a debug log.
Current behaviour
----------------------------------------
Currently, there is a simple log for submissions that does not contain submission data.
Proposed behaviour
----------------------------------------
There is already a submission log per form, but it only records the submitter and the time.
With some additional capabilities of FormBuilder, it becomes more important for both reporting and debugging to capture more information about the submissions themselves on the one hand, but also about their processing on submission on the other hand (examples: deduplication, processing by Form Processor etc.).
There should therefore be two logs:
1. the submission log should contain the actual submission data in addition to the metadata (cf. #3744).
2. an additional debug log should contain information about the processing of the data (like the CMRF log in WordPress or Drupal for [CiviMcRestFace](https://github.com/CiviMRF) submissions).
Comments
----------------------------------------
For reasons of data protection, it should be configurable by form whether no logging, logging of metadata or extended logging is desired.https://lab.civicrm.org/dev/core/-/issues/4569Proposal: Adding confirmation messages flexibly to Form Builder2023-09-14T15:03:30ZAndreasandreas.howiller@civiservice.deProposal: Adding confirmation messages flexibly to Form BuilderOverview
----------------------------------------
This issue explains a new proposal for the "Support more workflows" section in the [Form Builder roadmap](https://lab.civicrm.org/dev/core/-/issues/3761): Add confirmation messages flexib...Overview
----------------------------------------
This issue explains a new proposal for the "Support more workflows" section in the [Form Builder roadmap](https://lab.civicrm.org/dev/core/-/issues/3761): Add confirmation messages flexibly as we know it from Drupal webforms or Caldera Forms.
Current behaviour
----------------------------------------
Currently, there is no success message at all when I submit a form - as a user, I do not receive any feedback as to whether my data has really been processed.
Proposed behaviour
----------------------------------------
There should be a message for a successful submission resp. a message for errors.
For simple use cases such as editing data in the backend, the definition of messages per form (cf. #2957) is certainly sufficient. For more complex applications, more flexibility would also make sense in view of other features on the Form Builder roadmap, e.g. displaying messages after forwarding to a multi-step form (cf. #4574) or modal forwarding. To put it short: We should do it the way webforms does:
![confirmation_webforms](/uploads/74fa65d8d384b1f6b5de1da76be0e56c/confirmation_webforms.png)
Comments
----------------------------------------
1. There should probably be a translated fallback / standard message as well.
2. In order to be able to design success messages more individually, it should be possible to include form entries in the success message. Example: Dear Frank, thank you for signing our petition. In Caldera Forms, for example, this is comfortably solved via slugs / "magic tags":
![grafik](/uploads/097c919b39a4b575a524cf4b96b4f50a/grafik.png)
Cf. "post-submit tokens" on Form Builder roadmap and #4576https://lab.civicrm.org/dev/core/-/issues/4549Proposal: Remove Transaction ID from message templates2023-09-05T03:28:22ZlarsssandergreenProposal: Remove Transaction ID from message templatesSix message templates (event online and offline, contribution online and offline, membership and payment/refund) include Transaction #. I don't think this is useful information for the recipient, as it is just a long string of characters...Six message templates (event online and offline, contribution online and offline, membership and payment/refund) include Transaction #. I don't think this is useful information for the recipient, as it is just a long string of characters. So my proposal is to remove it, to simplify the templates and only send pertinent information to the recipient.
The only potential use I can think of would be in some edge case where perhaps you can't find a contribution for some reason and you could in that case search by transaction ID, but that seems rare and easily covered by having the exact time, amount, etc. If we did want to have something for that purpose, contribution ID would make a lot more sense, but I don't think we need either. Has anyone ever used the transaction ID from a receipt for any purpose?https://lab.civicrm.org/dev/core/-/issues/4547SearchKit: Edit in place for display name should be possible2023-09-03T00:16:46ZlarsssandergreenSearchKit: Edit in place for display name should be possibleIf you have a contact id in a SK display, enabling edit in place will show an autocomplete with contact names when clicked, but the field will show the contact id before clicking, which is confusing UI. On the other hand, a display name ...If you have a contact id in a SK display, enabling edit in place will show an autocomplete with contact names when clicked, but the field will show the contact id before clicking, which is confusing UI. On the other hand, a display name field shows the contact name as desired, but doesn't allow editing. So if you want to have an edit in place and show the contact name, you need both a contact id field and a display name field, which is confusing for the end user.
![image](/uploads/76c8542e1f32afac6074e817252e87ba/image.png)
Why should I click on the random integer on the right to edit the contact, instead of the name on the left?
Could we either make it possible to edit in place on the display name or make it possible to show the display name for the contact id field? Or maybe change the contact id field so it shows the display name by default, rename it to just contact, and add a separate field just for showing the contact id (which is probably a fairly rare need)?https://lab.civicrm.org/dev/core/-/issues/4545Events - Self service and change options after initial registration2023-09-06T13:20:42ZtreseroEvents - Self service and change options after initial registrationThis is a common scenario, and I'm not sure why CiviEvents doesn't support it.
Scenario 1: Joe signs up for a multi-day event and pays for the registration. A month later, the event organizers add a golf tournament fundraiser option, Jo...This is a common scenario, and I'm not sure why CiviEvents doesn't support it.
Scenario 1: Joe signs up for a multi-day event and pays for the registration. A month later, the event organizers add a golf tournament fundraiser option, Joe wants to add this to his registration.
Scenario 2: Joe now realizes that he wants to add his wife.
Scenario 3: Joe's friend Jeff wants to go, and also play golf.
You get the idea.
As Events is now, there is no way to adjust your registration and it has to be done manually. That is not an option for 700 - 800 registrations run by all volunteers (i.e. we don't have any paid staff). Another issue is we can't make the payment required as it would have to be paid when there is a "new" change. Making it optional, well, you can see the problem.
My thinking would be to look up email, or something and populate the form etc. We already require them to create a wordpress account so that could also be used. It's just not there.
Also, we have 25,000+ constituents that were imported from a legacy system. They don't have any accounts, but it would be nice if there were a way to match emails (where possible, I know not all have updated/current emails), but this is a less important scenario.
I have coding skills, but as we are all volunteers, I don't have much time. There is some money to budget for a developer. All code will be added back to the public.
![image.png](/uploads/9e7d2100f9b61ee6b871d0467d58338d/image.png)
As you can see, this is an example. Of course, none is not an option. but if we added other additions, or they want to add another person, it has to be manually done.https://lab.civicrm.org/dev/core/-/issues/4534Price set discount by date back office issues2023-08-24T18:33:09ZlarsssandergreenPrice set discount by date back office issuesThese are probably not a priority for anyone, but I ran into these while testing @eileen's recent PR, so thought I might as well note them:
1. Discount set shows as a select on edit participant, but only in certain circumstances (haven'...These are probably not a priority for anyone, but I ran into these while testing @eileen's recent PR, so thought I might as well note them:
1. Discount set shows as a select on edit participant, but only in certain circumstances (haven't quite worked this out, but something to do with number of discount sets and/or whether the dates are current or in the past). It also seems to be wrong, showing the current discount set based on the current date, not the one for the participant. Regardless, it shouldn't be changeable here as that does nothing. It should either always show as frozen or never show at all.
2. On the other hand, discount set should always be selectable on Change Selections, with the default set to the discount set that the participant currently has (then if you change from adult to student ticket or something, they still get the discount based on date, but you also can change the discount if needed).
3. Discount set is selectable when registering a single participant from back office, but not on the Register search task for multiple participants. It should be.https://lab.civicrm.org/dev/core/-/issues/4517Show a message to let event registrants know that additional participants wil...2023-08-24T14:00:38ZlarsssandergreenShow a message to let event registrants know that additional participants will receive an email confirming their registrationWhen you register additional participants for an event and enter an email for those additional participants, an email confirmation is sent to the additional participants' emails. We should include text on the additional participants scre...When you register additional participants for an event and enter an email for those additional participants, an email confirmation is sent to the additional participants' emails. We should include text on the additional participants screen indicating that this confirmation email will be sent when there is an email field on the page, something like:
"An email confirming registration will be sent to the email address provided below."https://lab.civicrm.org/dev/core/-/issues/4516Rethinking 20 minutes QF session timeouts2023-10-05T15:27:38ZJonGoldRethinking 20 minutes QF session timeoutsThe 20 minute timeout has been a part of Civi for as long as I can remember. It's also caused lost donations, frustrated applicants, and so on. Reading an [article about why short session timeouts aren't helpful](https://www.sjoerdlang...The 20 minute timeout has been a part of Civi for as long as I can remember. It's also caused lost donations, frustrated applicants, and so on. Reading an [article about why short session timeouts aren't helpful](https://www.sjoerdlangkemper.nl/2023/08/16/session-timeout/) made me think about this for Civi.
* What is the original reason? Is it still valid?
* If we lengthen the timeout, do we need to make special arrangements around event registration when there's a maximum number of seats available?https://lab.civicrm.org/dev/core/-/issues/4511Allow multiple 'Added By' for an activity2023-09-08T20:35:49ZyashodhaAllow multiple 'Added By' for an activityThe way some clients are using the CRM, the 'Added By' person(s) is/are really the person(s) responsible for making the activity happen, and the 'Assigned To' are people that participate in the activity but are not directly responsible f...The way some clients are using the CRM, the 'Added By' person(s) is/are really the person(s) responsible for making the activity happen, and the 'Assigned To' are people that participate in the activity but are not directly responsible for it.
The issues is that the CRM only allows ONE Added By, so they rely on some custom contact reference fields 'Partnered With' to supplement the Added By. But this is not a good solution and has many limitations e,g not being able to see the activity in Partner tab etc.
Therefore the best way to move forward is to allow multiple 'Added By' for an activity. The database schema already allows for that with the _activity_contact_ table.
From technical perspective, I reckon it was an oversight to not allow multiple contacts for Contact Source as we had moved civicrm_activity.source_contact_id (single), civicrm_activity_target.contact_id, civicrm_activity_assignee.contact_id (dropped civicrm_activity_target/civicrm_activity_assignee tables) in favor of civicrm_activity_contact table.
Screens that need to be modified:
- Activity tab in the Contact screen
- Activity View screen
- Activity Edit screen
- Activities reports
- Activities resultyashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/4496Event template fix-ups2023-08-17T14:18:50ZeileenEvent template fix-upsGenerally the goal is to make event templates not dependent on the form layer (using tokens & the MessageTemplate harness)
I'm creating this tracking issue to load up some screen shots for comparisonsGenerally the goal is to make event templates not dependent on the form layer (using tokens & the MessageTemplate harness)
I'm creating this tracking issue to load up some screen shots for comparisonshttps://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/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/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/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/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/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/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)