CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-03-07T00:52:44Zhttps://lab.civicrm.org/dev/core/-/issues/4849Shorten all Event iCal descriptions to match Add event to Google Calendar2024-03-07T00:52:44ZshaneonabikeShorten all Event iCal descriptions to match Add event to Google CalendarOverview
----------------------------------------
Presently, the _Add event to Google Calendar_ provide the ability to add a CiviCRM event into Google Calendars. The description is reduced down to the first paragraph and a link to the Ev...Overview
----------------------------------------
Presently, the _Add event to Google Calendar_ provide the ability to add a CiviCRM event into Google Calendars. The description is reduced down to the first paragraph and a link to the Event details is provided below. This is a lot cleaner than the present _Add event to iCalendar_, which includes all the Event description
![Selection_001](/uploads/33efb84cb475bfff4b087364d08d705c/Selection_001.png)
Example use-case
----------------------------------------
1. Create a New Event
1. Add a long description
1. View Event Info page
Current behaviour
----------------------------------------
The description provided in the ```ics``` and other formats is quite long.
Proposed behaviour
----------------------------------------
Reduce the description down to one paragraph with a link to the actual Event within the description. It would make it consistent and also probably a bit cleaner since most people (I think) don't read a full description after they have added something to their calendar but a reference is awesome!https://lab.civicrm.org/dev/core/-/issues/4842Allow bulk-enabling extensions through UI2023-12-08T13:17:56ZnoahAllow bulk-enabling extensions through UICurrent behaviour
----------------------------------------
On Administer > System Settings > Extensions, only one extension can be acted on at a time.
Proposed behaviour
----------------------------------------
It should be possible to...Current behaviour
----------------------------------------
On Administer > System Settings > Extensions, only one extension can be acted on at a time.
Proposed behaviour
----------------------------------------
It should be possible to select multiple extensions and perform the same action (Install, Disable, Uninstall) on all of them.https://lab.civicrm.org/dev/core/-/issues/4809Backend register for event via credit card has problematic pre-help text and ...2023-12-06T23:06:43ZDaveDBackend register for event via credit card has problematic pre-help text and should be completely removed and replaced with only a translation-friendly indicator of live vs testCopied from https://github.com/civicrm/civicrm-core/pull/28309
I think the [tpl line](https://github.com/civicrm/civicrm-core/blob/6c6fdea6429f39d552d0cc6bae0254d27daa4919/templates/CRM/Event/Form/Participant.tpl#L31) needs to be comple...Copied from https://github.com/civicrm/civicrm-core/pull/28309
I think the [tpl line](https://github.com/civicrm/civicrm-core/blob/6c6fdea6429f39d552d0cc6bae0254d27daa4919/templates/CRM/Event/Form/Participant.tpl#L31) needs to be completely replaced. I would remove the first sentence since it adds no value since right above it already says the name when it's present, and when it's not present is the cause of this notice, and then the second sentence is not correct in other languages (the "live"/"test" is always in english). Elsewhere the approach for that when there's a known list of values is to just hardcode the full sentences in an `{if}` block.
I do think it's important to identify if it's live or test, but since none of the above has been raised as an issue the help text itself seems very unimportant. Maybe it should just have some kind of icon indicating live or test and that's it.https://lab.civicrm.org/dev/core/-/issues/4765Add label field to OAuthClient entity2023-11-14T16:35:42ZjensschuppeAdd label field to OAuthClient entity## Overview
We came across a use-case for multiple _OAuthClient_ entites with the same _Client ID_, which makes differentiating them difficult in the UI. We'd like to propose adding a field for an administrative label to the _OAuthClien...## Overview
We came across a use-case for multiple _OAuthClient_ entites with the same _Client ID_, which makes differentiating them difficult in the UI. We'd like to propose adding a field for an administrative label to the _OAuthClient_ entity and defining it as the `label_field`. It might also be a good idea to make labels required.
## Proposed behaviour
We're currently building an API extension for synchronizing data from another CRM-like system that requires authorization via OAuth and differentiates multiple instances/sources by using different access tokens for the same client ID/secret.
Our sync API uses configurable profiles which have the OAuth client as a configuration option, so there's a field for selecting an OAuth client in the UI. The only attribute for differentiating OAuth clients in that field is their internal (CiviCRM) ID, as Client ID and secret are the same and the access token should not be exposed and might change. This is not convenient for admins, as they will have to remember which (internal) OAuth client ID corresponds to which instance, which is likely to cause misconfigurations and errors.
I guess this will need:
* the XML schema of the `OAuthClient` entity be extended with a `label` field
* `civix generate:entity-boilerplate`
* Upgrade script for applying schema changes - thanks @eileen!
* anything else?
Happy to hear your thoughts!https://lab.civicrm.org/dev/core/-/issues/4711Make it easier for extensions to add Navigation Menu items2023-10-24T14:13:07ZcolemanwMake it easier for extensions to add Navigation Menu itemsBackground
------
Extensions have a few ways of adding to the navigation menu, and none of them are great.
1. `hook_civicrm_navigationMenu()` - brute-forces an item into the menu. It's relatively easy to implement (thanks to some extra...Background
------
Extensions have a few ways of adding to the navigation menu, and none of them are great.
1. `hook_civicrm_navigationMenu()` - brute-forces an item into the menu. It's relatively easy to implement (thanks to some extra fudging that `civix` does for you) but defeats the whole configurability idea; users and administrators have no control over the item.
2. `install`/`uninstall` hooks - this is hard to implement as there are a lot of edge cases to consider (domains, weights, etc) and you have to manage the full lifecycle yourself (install, disable, enable, uninstall).
3. `hook_civicrm_managed()` - this handles the lifecycle for you, but not the domains, and the weights are completely by guesswork. Changes made by the user (e.g. deleting the menu item) might be undone by `Managed::reconcile`.
4. `.aff.php` - Afforms allow you to declare a navigation menu as part of the form - this gets delegated to `hook_civicrm_managed()`, with all the same problems that carries, plus the additional problem that user-changes to the item can lose sync with the Afform settings (see https://lab.civicrm.org/dev/core/-/issues/4364).
IMO items 1 and 2 are unfixable, but item 3 has promise, and item 4 could be deprecated in favor of 3.
Outstanding problems with Managed Navigation Menu Items.
----------
- [x] 1. ManagedEntities cannot be deleted. If a user deletes a managed Navigation item, it will respawn with the next `Managed::reconcile`.
- [x] 2. Navigation BAO doesn't even call hooks, defeating the ManagedEntity `update=unmodified` mode.
- [x] 3. ManagedEntities are not domain-aware; if you want your navigation item to appear on all domains (which you do, since your extension will be enabled globally - there are no per-domain extensions), you have to declare a managed navigation item once per domain (which is [a bit awkward](https://github.com/civicrm/civicrm-core/blob/f04bfacb5ed5131c9d29e8a9c0725c3059caeef0/ext/legacycustomsearches/managed/Navigation.mgd.php#L7)).
- [ ] 4. Picking a `weight` is pure guesswork. You just have to put in an integer and hope it lands in the right spot. Picking `0` will pretty reliably place it at the top; anything else is a roll of the dice.
Proposed Solutions
-------
1. Fixed via [ManagedEntities - Recreate deleted records at discretion of update policy](https://github.com/civicrm/civicrm-core/pull/27844).
2. Fixed via [dev/core#4364 Use writeRecord for Navigations so menu changes for managed entities don't reset](https://github.com/civicrm/civicrm-core/pull/27832).
3. Fixed via [ManagedEntity - Replicate multi-domain entities when multisite is enabled](https://github.com/civicrm/civicrm-core/pull/27876).
4. [Here is a PR](https://github.com/civicrm/civicrm-core/pull/27894) to add a `previous` and `next` join in APIv4 which would allow you to specify the name of the menu item you wish to insert next to. For example, to add a menu item just below the "Find Contacts" menu item, you'd say `['previous.name' => 'Find Contacts']` in your managed declaration (in lieu of `'weight' => 5').
5. To deprecate the Afform navigation handling, we can still support it in the Admin form, but instead of writing to the `.aff.json` file and that getting picked up by `afform_civicrm_managed()` the admin form could just save the navigation item directly. We can also teach the new [`civix export` command](https://github.com/totten/civix/pull/312) to generate a `.mgd.php` for every navigation menu item associated with an Afform.https://lab.civicrm.org/dev/core/-/issues/4620CiviEvent dashboard: start date is 7 days ago2023-09-26T12:23:49ZmasettoCiviEvent dashboard: start date is 7 days agoI follow up https://civicrm.stackexchange.com/questions/22424/how-to-customize-events-dashboard.
The event dashboard now shows recent and upcoming events (where start date is 7 days ago OR later).
It would be convenient if the numbe...I follow up https://civicrm.stackexchange.com/questions/22424/how-to-customize-events-dashboard.
The event dashboard now shows recent and upcoming events (where start date is 7 days ago OR later).
It would be convenient if the number of days was configurable in the preferences of CiviEvents (`civicrm/admin/setting/preferences/event`).
Do you think it is useful and required by others as well?https://lab.civicrm.org/dev/core/-/issues/4612Searchkit: copy MessageTemplate action2023-09-26T12:17:18Ztycho77Searchkit: copy MessageTemplate action## Overview
You want to create a copy of a message template directly from a Searchkit form, which you can then edit immediately.
## Example use-case
1. in a SearchKit-Form searching for **MessageTemplates**
2. there is a **menu-column...## Overview
You want to create a copy of a message template directly from a Searchkit form, which you can then edit immediately.
## Example use-case
1. in a SearchKit-Form searching for **MessageTemplates**
2. there is a **menu-column** added for selecting actions for one of the MessageTemplates shown
3. you want to select **Copy MessageTemplate**
## Current behaviour
1. you can already choose between CRUD functionalities for MessageTemplates
## Proposed behaviour
1. the copy takes the original name followed by " (copy)"
2. the search is reloaded, so that you can immediately see and edit the copy
## Comments
if this could be done with an hour's effort, there is concrete budget left for this.https://lab.civicrm.org/dev/core/-/issues/4609Smarty/token processing fails with embedded CSS2023-09-26T12:15:49ZlarsssandergreenSmarty/token processing fails with embedded CSSAfter upgrade to 5.65, sending scheduled reminders with embedded CSS in them fails because the parsing interprets something like `selector { attribute: value; }` as broken smarty. Not entirely sure when this problem was introduced, but l...After upgrade to 5.65, sending scheduled reminders with embedded CSS in them fails because the parsing interprets something like `selector { attribute: value; }` as broken smarty. Not entirely sure when this problem was introduced, but lots of reports after [5.65 was released](https://chat.civicrm.org/civicrm/pl/npfsiennxbytpygm6b67bqo41c), so that seems likely.
Embedding CSS in an email may or may not be wise, but it definitely is a valid thing to do, so our smarty/token parsing is broken if it fails on that.https://lab.civicrm.org/dev/core/-/issues/4581Define re-usable idiom for deferrable upgrade steps2023-09-19T13:05:13ZtottenDefine re-usable idiom for deferrable upgrade stepsOverview
----------------------------------------
In managing upgrade-steps, there is some tension between:
* Making the upgrades automatic for typical sysadmins
* Allowing very large deployments to schedule/manage expensive upgrade-st...Overview
----------------------------------------
In managing upgrade-steps, there is some tension between:
* Making the upgrades automatic for typical sysadmins
* Allowing very large deployments to schedule/manage expensive upgrade-steps
This proposes to balance those expectations by defining a _deferrable upgrade task_. Sysadmins can choose to approach them a few ways:
* "Just run the task like every other upgrade step" (*e.g. default; for average and small systems*)
* "Let me decide when to run it... but please don't make me figure out obscure incantations" (*for larger systems*)
* "Let me find a highly-optimized/bespoke way to accomplish the change" (*for extra-large systems with a team of admins*)
Example use-case
----------------------------------------
1. Take a table (like `civicrm_contact`, `civicrm_activity`, `civicrm_mailing_event_queue`) which can be very large on some deployments.
1. Define a schema change (e.g. add a column and an index)
1. Executing this change be quite slow.
1. In the long-term, all systems need the schema-change. If people skip it, then it will lead to problems/confusion/bug-reports/etc.
1. In the near-future, the schema change is not quite mandatory. (The new column isn't actively used; or its usages are limited+guarded.)
A sketch
----------------------------------------
* Designate a place to store a list of deferred upgrade steps (e.g. `civicrm_deferred_upgrade` or `civicrm_queue_item`)
* In the `CRM/Upgrade/` system, add some helpers to conditionally execute or defer a step. Ex:
```php
$this->addDeferrableTask(ts('Update CiviMail tracking'), 'doCiviMailQueueConversion');
```
```php
function addDeferrableTask($title, $funcName, $args) {
if (deferred upgrades enabled) {
// Add $title, $action, $args to a persistent TODO list
}
else {
$this->addTask($title, $funcName, $args);
}
}
```
* Add a system-status-check and post-upgrade message to warn if there are any of these things that need to run
* Add an API/job/command/UI to list/execute/skip/delete deferred stepshttps://lab.civicrm.org/dev/core/-/issues/4577Conditional use of Form Processors2023-09-14T13:01:14ZsebalisConditional use of Form ProcessorsOverview
----------------------------------------
This is a feature request somewhat related to conditional fields (see [PR #24699 on Github](https://github.com/civicrm/civicrm-core/pull/24699)), but this affects the backend as well: It ...Overview
----------------------------------------
This is a feature request somewhat related to conditional fields (see [PR #24699 on Github](https://github.com/civicrm/civicrm-core/pull/24699)), but this affects the backend as well: It should be possible to link a form to a Form Processor only if certain conditions are met. A way to link fields for that form processor to previous fields would be required.
Example use-case
----------------------------------------
A petition with a checkbox “Send me your newsletter as well”. If this is selected, a block for a corresponding form processor with any additional fields would appear depending, but some of these fields will be identical to previous fields (in the unconditional part of the form), such as the first name.
Proposed behaviour
----------------------------------------
It would have to be possible to fill these fields in the form processor block via identifiers (see other feature request #4576) that cause the values from the referred fields to be copied. Other fields that do not duplicate fields from the unconditional part of the form will have to appear as standard controls.
In the backend, the same condition will have to be used to decide whether that form processor should be used to process the submission.
Comments
----------------------------------------
This request is yet another result of this week’s CiviSprint in Zeitz near Leipzig, Germany. Forgive us :-)https://lab.civicrm.org/dev/core/-/issues/4576Proposal: Unique Identifier/Field references for input fields in Form Builder2023-09-14T13:23:58Zsimon.hermannProposal: Unique Identifier/Field references for input fields in Form Builder## Overview
We propose to add a way to reference fields via an unique identifier in order to use the field value elsewhere on the field, e.g. the success page proposed in issue #4569 or on another page of a multi-page form.
Proposed use...## Overview
We propose to add a way to reference fields via an unique identifier in order to use the field value elsewhere on the field, e.g. the success page proposed in issue #4569 or on another page of a multi-page form.
Proposed uses of this feature are:
* setting the value of another field
* setting input fields in a form processor
The field reference should be automatically generated when creating a new field but be editable, if needed.
## Use case
Donation form:
* set default value for account holder based on field values “first name”, “last name”
* show chosen amount of donation on the next page
* use “first name” and “last name” as well as “donation amount” for success page to confirm donation and say thank you
## Current behavior
Not implemented
## Proposed behavior
Every field has an auto-generated field reference. Using the field reference, the field value can be shown on the form.https://lab.civicrm.org/dev/core/-/issues/4575Proposal: Calculation element for Form Builder2023-09-14T13:00:10Zsimon.hermannProposal: Calculation element for Form Builder## Overview
We would like to have a new element that allows basic arithmetic operations with number fields.
The idea is to be able to sum up several number fields or compute an average. The implementation might make use of the field refe...## Overview
We would like to have a new element that allows basic arithmetic operations with number fields.
The idea is to be able to sum up several number fields or compute an average. The implementation might make use of the field references suggested in issue #4576.
It should also be possible to include constants in the computation.
## Use case
Trying to set up a scoring form for e.g. an event – it would be great to be able to compute the average score and store it in CiviCRM.
## Current behavior
No such behaviour currently exists.
## Proposed behavior
A computed form element is available that can use input fields as well as fixed values.https://lab.civicrm.org/dev/core/-/issues/4574Proposal: Suggestions for multi-page forms with Form Builder2023-09-14T12:59:56Zsimon.hermannProposal: Suggestions for multi-page forms with Form Builder## Overview
We are happy to see that there is a plan to implement multi-page forms. To enable the users to navigate the form efficiently, it would be great if the following two features are included
- Users should be allowed to navigat...## Overview
We are happy to see that there is a plan to implement multi-page forms. To enable the users to navigate the form efficiently, it would be great if the following two features are included
- Users should be allowed to navigate between pages, even if not all required fields on the current page are filled. This allows users to get an overview of the overall (multi-page) form.
- There should be an option to move to the next or previous page, but also an additonal menu that allows the users to move directly to a specific page of the form. It would also be great if the names of the pages could be set.
- (Optional) Have a representation of the current progress of the form. This should show on which page of the current form I am, in e.g. page 1 of 4 pages (maybe as a progress indicator as welll).
## Example use-case
1. Have additional buttons that allow moving forward or backward on the form
2. Have an option to add a navigation menu to a multi-page form where the names of the pages can be set as well.
3. Have an option for multi-page form, to add a progress indicator, with options to either show the current page number compared to the overall number of pages or similar to a graphical progress bar.
## Current behaviour
The option for multi page forms is not implemented yet.
## Proposed behaviour
Be able to separate the form into multiple pages. Have buttons to navigate to the next or previous page, even if not all required fields are filled and have an additional menu, which allows the user to navigate to one specific page. Have an option to add a progress indicator.https://lab.civicrm.org/dev/core/-/issues/4573Proposal: Add preliminary submission to the Form Builder2024-03-12T13:28:32Zsimon.hermannProposal: Add preliminary submission to the Form Builder## Overview
For longer and more complex forms, users may want to extend the process of filling out a submission form across several browser sessions. Therefore, it would be great to be able to submit/save a partially completed form as a...## Overview
For longer and more complex forms, users may want to extend the process of filling out a submission form across several browser sessions. Therefore, it would be great to be able to submit/save a partially completed form as a preliminary submission and finalise the data later. Complex forms, such as grant applications, could be started and then completed when all the required information is collected. We would suggest adding a "Continue Later" or "Preliminary Submission" button to allow submissions even if not all required fields are filled in.
There would be 2 options for handling the pre-submitted data.
Option 1: The data will be saved in a submission log, but not yet processed in CiviCRM. Using a unique identifier for the submission entry as an URL parameter will load the data from the submission log into the form.
Option 2: Data is processed and stored directly in CiviCRM, meaning contacts, cases or other entities are already created or updated. The form can be edited later using URL parameters and retrieval of defaults.
The user receives a personalised link that allows them to continue with the form. This means that fields such as an email address must be marked as 'required for preliminary submission'. We suggest that this additional option for any input field is only displayed if a "continue later" button is added to the form itself.
At our CiviSprint in Zeitz, Germany, there was a preference for the second option by clients who wanted to use this functionality for their grant application process. It is helpful for clients to be able to see a partially submitted application in order to support the applicant during the application process.
## Example use-case
1. Add an additional button called 'Resume later'.
2. This adds the option on each field to be 'required for preliminary submission'.
## Current behaviour
- When a form is submitted, all required fields have to be filled.
## Proposed behaviour
- There is a new button that allows a (preliminary) submission even if not all required fields are filled.
- Fields can be marked as be required when the new button is triggered.
- A personalised link is sent to the user, which allows to reopen the form with the pre-filled data.https://lab.civicrm.org/dev/core/-/issues/4572Proposal: Retrieval of Defaults w/ Form Builder and Form Processor2023-09-18T12:24:16ZMariaVProposal: Retrieval of Defaults w/ Form Builder and Form ProcessorOverview
----------------------------------------
At the CiviSprint in Germany we found out that Submission forms (Form Builder) currently do not support use cases such as self-service forms that allow users to check and change their exi...Overview
----------------------------------------
At the CiviSprint in Germany we found out that Submission forms (Form Builder) currently do not support use cases such as self-service forms that allow users to check and change their existing contact data.
A lot of Wordpress projects use CalderaForms together with Form Processor to transfer the data to CiviCRM. In CalderaForms there is an option to activate Retrieval of Defaults:
![grafik](/uploads/912921154b32fbf34052c77dcf79b597/grafik.png)
As well as in Form Processor:
![grafik](/uploads/8802a13e8aa75798be4a25bfa9126fcf/grafik.png)
Caldera Forms allows passing URL parameters to the form processor – e.g. a contact CiviCRM ID along with a checksum to prove that the user is allowed to see and edit data for this particular contact, as a way of authentication without requiring a login. These URLs look as follows:
_https//link.org/example-page/cid={contact.contact_id}&{contact.checksum}_
With this information the form processor can retrieve data from within CiviCRM when the form is loaded and prefill fields in the form.
What works in the Form Builder already?
----------------------------------------
- Adding Form Processor as an entity
- Using Form Processor fields for a form
- Submitting/Creating data entered in submission form
- Using the entity id as an URL parameter (requires login)
What is missing?
----------------------------------------
- Option to enable retrieval of defaults (like in CalderaForms) to fill forms with existing data.
- Forms that work for anonymous users, using a checksum for authentication
Comments
----------------------------------------
If you need any further information, please let me know.
I could assist in setting up an example in a test environment since I am not able to implement this function myself.https://lab.civicrm.org/dev/core/-/issues/4571Proposal: Add possibilty to assign custom CSS classes to containers in Form B...2024-03-12T13:14:12ZTobias Voigttobias.voigt@civiservice.deProposal: Add possibilty to assign custom CSS classes to containers in Form BuilderOverview
----------------------------------------
This issue intends to achieve more control and flexibility in styling the frontend appearance of form builder forms. To achieve this we suggest to add the possibility of assigning custom ...Overview
----------------------------------------
This issue intends to achieve more control and flexibility in styling the frontend appearance of form builder forms. To achieve this we suggest to add the possibility of assigning custom CSS classes to containers in the configuration backend / GUI of Form Builder.
This is meant to be an addition to the [Form Builder Roadmap](https://lab.civicrm.org/dev/core/-/issues/3761).
Current behaviour
----------------------------------------
Currently it is possible to select a predefined CSS class from the 'style' dropdown menu ("Panel Pane"). When this style is selected, an additional class is added to the div container ("af-container-style-pane").
![Screenshot](/uploads/306fe60b466b20d838972ff125ebb988/Bildschirmfoto_vom_2023-09-13_16-48-18.png)
Proposed behaviour
----------------------------------------
We propose to give users the possibilty to add custom CSS classes to form builder containers in a new input (text) field to allow more control and flexibility in styling the frontend appearance of form builder forms.
![Mockup](/uploads/047b3bc36039cf5f138dc9342834e25c/mockup-custom-css-classes.png)
Comments
----------------------------------------
Some major parts of the relevant code seems to be in these files:
https://github.com/civicrm/civicrm-core/blob/master/ext/afform/admin/ang/afGuiEditor/afGuiMenuItemStyle.component.js
https://github.com/civicrm/civicrm-core/blob/master/ext/afform/admin/ang/afGuiEditor/afGuiMenuItemStyle.htmlhttps://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/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/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.