Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-06-07T05:38:36Zhttps://lab.civicrm.org/dev/core/-/issues/2255Proposal, Allow the CiviCRM CKEditor to be disabled for specific components a...2023-06-07T05:38:36Zjustinfreeman (Agileware)Proposal, Allow the CiviCRM CKEditor to be disabled for specific components as there is only a global on/off capability currently. We need CKEditor to be disabled for Message Templates, but not for Mailings, Events etc.Proposal, Allow the CiviCRM CKEditor to be disabled for specific components as there is only a global on/off capability currently. We need CKEditor to be disabled for Message Templates, but not for Mailings, Events etc.
CKEditor is alwa...Proposal, Allow the CiviCRM CKEditor to be disabled for specific components as there is only a global on/off capability currently. We need CKEditor to be disabled for Message Templates, but not for Mailings, Events etc.
CKEditor is always displayed for custom Message Templates which in our experience reliably mangles the HTML and Smarty Tags. CKEditor is NOT disabled for "System" Message Templates and therefore does not have this issue.
Agileware Ref: CIVICRM-1609 CIVICRM-1608https://lab.civicrm.org/dev/financial/-/issues/196Proposal: Account for new Mastercard regulations for recurring contributions2022-09-20T17:19:38ZJonGoldProposal: Account for new Mastercard regulations for recurring contributionsThere's an article here:
https://www.allaboutadvertisinglaw.com/2021/11/new-mastercard-requirements-for-subscription-and-negative-option-billing-models.html
But here are the highlights:
* Must send a confirmation email at the time of en...There's an article here:
https://www.allaboutadvertisinglaw.com/2021/11/new-mastercard-requirements-for-subscription-and-negative-option-billing-models.html
But here are the highlights:
* Must send a confirmation email at the time of enrollment that includes the terms of the subscription and instructions on how to cancel the subscription
* Send a receipt after every successful billing attempt that includes instructions for how to cancel this subscription (this can be instructions to call customer service)
* Provide an online cancellation method (similar to unsubscribing from emails) – that can be instructions to call customer service
* For any subscription/recurring payment plan that bills a cardholder less frequently than every six months, the merchant must send a notification at least seven days prior to the billing date that includes the terms of the subscription and instructions on how to cancel the subscription
* Merchants have until Sept 21, 2022, to meet this requirement.
It seems like `civicrm_contribution_recur.is_email_receipt` should be ignored if the card type is Mastercard. It also seems like a new Scheduled Job is necessary for folks who have recurring contributions that are less frequent than six months.https://lab.civicrm.org/dev/financial/-/issues/190Proposal: Add `created_id` to `civicrm_contribution`2021-11-23T17:28:24ZJonGoldProposal: Add `created_id` to `civicrm_contribution`This is fairly straightforward as a proposal. I think it's a good idea generally (for those who lack advanced logging) but could also solve financial#49 - it's impossible to know what individual gave on behalf of an organization based o...This is fairly straightforward as a proposal. I think it's a good idea generally (for those who lack advanced logging) but could also solve financial#49 - it's impossible to know what individual gave on behalf of an organization based on the existing data.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4033Proposal: Add optional separate mailing label format for organizations2023-01-11T23:31:32ZlarsssandergreenProposal: Add optional separate mailing label format for organizationsOften, I find myself editing the mailing label format when making mailing labels for organizations. In this case, we want Addressee and Name (the name of the person at the org plus the name of the org on the next line), while for individ...Often, I find myself editing the mailing label format when making mailing labels for organizations. In this case, we want Addressee and Name (the name of the person at the org plus the name of the org on the next line), while for individuals we just want the Addressee (otherwise, it would say their name twice). I imagine we aren't alone in this.
In order to avoid this hassle, it would make sense to have an option to add a second mailing label format for organizations. If there is a format specified in this field, it would be used for organizations. If this field is left blank, the default label format would be used for organizations. I think that would keep it simple and wouldn't change anything unless someone intentionally added an organizational label format. We could also add a format for households if desired - would that be valuable to anyone?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/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/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/4606Proposal: Allow selection of all fields from an entity referenced via a calcu...2023-09-26T12:14:01ZnoahProposal: Allow selection of all fields from an entity referenced via a calculated fieldWhen an API4 calculated field defines a join to another entity, all of that other entity's fields can be accessed through API4. However, in SearchKit, currently only the "label" field can be displayed.
In many cases, it's desirable to u...When an API4 calculated field defines a join to another entity, all of that other entity's fields can be accessed through API4. However, in SearchKit, currently only the "label" field can be displayed.
In many cases, it's desirable to use fields other than the "label" field from the referenced entity.
Technical details: I'm talking about joins defined via the `api.schema_map.build` event. For example, [an Activity entity can reference a Case entity](https://github.com/civicrm/civicrm-core/blob/5.66/Civi/Api4/Event/Subscriber/ActivitySchemaMapSubscriber.php#L31-L35). The SearchKit code's [current mechanism](https://github.com/civicrm/civicrm-core/blob/5.66/ext/search_kit/Civi/Search/Admin.php#L232) only adds one field to the list of "selectable" fields.
See [recent discussion](https://chat.civicrm.org/civicrm/pl/g3p8sb4s6pr89bdjyf7jt3gcrw) between @noah and @colemanwhttps://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/2761Proposal: Change Pay Later Billing Address to look up a profile rather than a...2022-10-04T21:07:14ZBarijohnProposal: Change Pay Later Billing Address to look up a profile rather than a coded block.Overview
----------------------------------------
Currently on the pay later option when you use the option of Billing Address the fields are hard coded. This would be better to use a profile then it could be edited by the end user witho...Overview
----------------------------------------
Currently on the pay later option when you use the option of Billing Address the fields are hard coded. This would be better to use a profile then it could be edited by the end user without having to mess with the code.
Example use-case
----------------------------------------
Click on Pay Later Option and enable Billing Fields. This shows multiple fields that might not be required depending on the part of the world. So in that case there could be a reserved profile just for billing fields. This could have a help field to show where this profile is saved, so it would easily amended.
Current behaviour
----------------------------------------
Currently this is set in Core/Payment.php and /civicrm/templates/CRM/Core/BillingBlock.tpl (based on communications with our devs).
Proposed behaviour
----------------------------------------
Make this block look up a billing address profile instead.
Comments
----------------------------------------
Currently this field asks for information that isn't required in the UK and most of our clients would like to be able to edit this directly.https://lab.civicrm.org/dev/core/-/issues/960Proposal: Change supervised dedupe rules to name(s) OR email2023-03-18T04:52:01ZJonGoldProposal: Change supervised dedupe rules to name(s) OR emailI've done countless Civi trainings on deduping, many at CiviCamps and other "official" places. And each time, I need to explain that "yes, unsupervised rules should be more strict than supervised rules. Also yes, the default individual...I've done countless Civi trainings on deduping, many at CiviCamps and other "official" places. And each time, I need to explain that "yes, unsupervised rules should be more strict than supervised rules. Also yes, the default individual supervised rule is far more strict than the default unsupervised rule."
Surely I'm not the only one who feels the same - and yet none of us noticed, because before Civi 5.3/CRM-20565, the supervised rule was basically unused.
Now, there's a code comment that says, [CRM-20565 - Need a good default matching rule before using the dedupe engine for checking on-the-fly.](https://github.com/civicrm/civicrm-core/blob/1eca040f3f6efa0a8a43575cd0a08bae242a95f3/templates/CRM/Contact/Form/Contact.tpl#L334).
I'm proposing we fix this by changing the default supervised rule. The current on-the-fly checking is both a) a default, and b) very poor UX.
I'm also proposing that we do this as the new default for everyone. I'm mindful of the changes to existing systems, and we should probably put in an upgrade note or something - but honestly anyone who's never changed the default supervised rules isn't very likely to be using them.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3900Proposal: Check mailings for fixed personalization (without tokens) before su...2022-10-25T11:46:58ZlarsssandergreenProposal: Check mailings for fixed personalization (without tokens) before submittingSometimes, people copy a link that was personalized to them with cid and cs and insert it into a mailing (i.e. with their contact ID and checksum instead of the appropriate tokens), then they send out a personalized link for their contac...Sometimes, people copy a link that was personalized to them with cid and cs and insert it into a mailing (i.e. with their contact ID and checksum instead of the appropriate tokens), then they send out a personalized link for their contact to a large group of people.
In order to prevent this, we could check for URLs that include something in the form of a checksum plus cid=integer or cid1=integer (this will support Webform CiviCRM too). Optionally, we could even validate the checksum, but that seems overkill. I think this would make the most sense at submission time, to keep things simple with Mosaico and Traditional mailings.
I'm not sure what the best way to handle the UI for this is. An error that prevents sending seems too strong, but just a warning while still submitting seems too weak. Is there a better UI solution for this?https://lab.civicrm.org/dev/core/-/issues/3961Proposal: Create stub extensions for civicrm core + all components2023-07-13T10:41:05ZcolemanwProposal: Create stub extensions for civicrm core + all components*Edited to reflect the current state of things, some comments reply to an earlier revision*
**Motivation 1:**
Require SearchKit in core. This has been [solved in a different way](https://github.com/civicrm/civicrm-core/pull/24739) so i...*Edited to reflect the current state of things, some comments reply to an earlier revision*
**Motivation 1:**
Require SearchKit in core. This has been [solved in a different way](https://github.com/civicrm/civicrm-core/pull/24739) so is no longer relevant to this issue.
**Motivation 2**
We are starting to package SearchKit displays as replacements for Smarty/DataTables in the UI. This has worked out great for CiviGrant: now that it's an extension we can easily package Afforms, SavedSearches and other managed entities with it. But other components are not extensions and so have no mechanism for including their own managed entities, afforms, etc. Components are less modular and more monolithic than extensions.
**Motivation 3**
Currently an extension has no way to require a component, e.g. an extension cannot declare a dependency on CiviEvent.
**Motivation 4**
Extensions and Components are similar but not the same, and this is confusing to new users and new developers. In most respects Extensions are better than Components, and it would be great to "some day" have all components simply be extensions.
**Proposal**
Given the experience of converting CiviGrant to an extension was a "harder than expected" undertaking, I think converting all other components to extensions at once is not a realistic goal. It would need to be a slow, iterative process, and I propose this as the first iteration:
1. Create a small stub extension for each component (CiviEvent, CiviContribute, etc).
2. Use hooks to sync between the `civicrm_extension` table and the `civicrm_component` table, so that enabling the "CiviEvent" extension also enables the "CiviEvent" component, and vice-versa.
3. Get rid of the "Manage Components" screen. Admins can enable/disable components via the "Manage Extensions" screen.https://lab.civicrm.org/dev/core/-/issues/3835Proposal: Deprecate profile standalone listing mode2023-11-30T17:03:40ZJonGoldProposal: Deprecate profile standalone listing modeProfile standalone listing code is deeply entangled with the query BAOs, and produces weird and wonderful bugs like #3834.
I don't think they're widely used in modern CiviCRM, they seem to have been a stopgap before Views integration, a...Profile standalone listing code is deeply entangled with the query BAOs, and produces weird and wonderful bugs like #3834.
I don't think they're widely used in modern CiviCRM, they seem to have been a stopgap before Views integration, and later for non-Drupal users to get a Views-esque experience. But Search Kit has effectively replaced them - they have feature parity and then some.
I think we can improve the query code if we no longer needed to worry about standalone listing mode.
Proposal:
* Remove the ability to create standalone listings on new installations of CiviCRM.
* Create a check for profiles using standalone listing mode, warning admins if they use it.
We can deprecate this over a long period of time, so the impact should be gentle.
If this proposal is approved, we may also want to consider a function that converts profile listings to SK searches. This will have added utility as we deprecate other uses of profiles (e.g. once SK replaces Advanced Search, Search Profiles will go away).https://lab.civicrm.org/dev/core/-/issues/4725Proposal: Don't include "I am contributing on behalf of an organization" on c...2023-11-23T07:51:08ZlarsssandergreenProposal: Don't include "I am contributing on behalf of an organization" on contribution pages when the current contact is an organizationIf an organization receives a personalized link to a contribution page, the user may not realize they are already using the form as an organization (especially because the billing details will show their first and last name if they used ...If an organization receives a personalized link to a contribution page, the user may not realize they are already using the form as an organization (especially because the billing details will show their first and last name if they used them in the past). If they then select "I am contributing on behalf of an organization", they will get a error: `Payment Processor Error message :Invalid Relationship .`
This is because we are attempting to create a new organization with an employer of relationship to the current contact, which fails when the current contact is an organization as this is not allowed.
I think the simplest and most logical way to fix this is simply to not include the on behalf of option on the contribution page if the current contact is an organization and instead show the organization profile by default. If the user wants to contribute on behalf of the current contact organization, then this is fine. If they are contributing on behalf of a different organization or as an individual, they should click the not you link.https://lab.civicrm.org/dev/drupal/-/issues/76Proposal: Don't migrate drush commands to D82020-06-19T16:21:14ZJonGoldProposal: Don't migrate drush commands to D8CiviCRM drush commands are incompatible with modern versions of drush.
I investigated this, and each command will need to be rewritten for drush 9/D8. I've created a framework and ported a couple of my most used commands (e.g. `drush c...CiviCRM drush commands are incompatible with modern versions of drush.
I investigated this, and each command will need to be rewritten for drush 9/D8. I've created a framework and ported a couple of my most used commands (e.g. `drush civicrm-sql-cli`, `drush civicrm-sql-dump`) but there's a compelling argument to simply not rewriting drush and instead making sure that `cv` has feature parity.
For those who DO think we should continue to maintain the drush commands, I have a branch here: https://github.com/MegaphoneJon/civicrm-drupal-8
Klaas has also submitted a PR to add `drush civicrm-api` to this branch.https://lab.civicrm.org/dev/core/-/issues/3014Proposal: Explore adding hooks to allow plugins to track database queries, e....2023-04-23T20:13:36ZBradley TaylorProposal: Explore adding hooks to allow plugins to track database queries, e.g. to enable integration with plugins like Query MonitorOne of my favourite plugins in the WordPress space is [Query Monitor](https://wordpress.org/plugins/query-monitor/). Among other things it allows you to monitor at a glance what database calls have been made for a specific request, makin...One of my favourite plugins in the WordPress space is [Query Monitor](https://wordpress.org/plugins/query-monitor/). Among other things it allows you to monitor at a glance what database calls have been made for a specific request, making it easy to spot inefiencient code and queries.
Currently CiviCRM does not have anything analogous to this. The [CiviCRM docs recommend using the MySQL query log](https://docs.civicrm.org/dev/en/latest/tools/debugging/#viewing-a-query-log-from-mysql), but this isn't easy to view at a glance, and it doesn't make it easy to correlate queries to sepecific web requests. CiviCRM's database queries don't show in Query Monitor because CiviCRM does not use WordPress' `WPDB` class. Therefore, I've been looking to see if it would be possible to extend Query Monitor to know about CiviCRM's database queries. Its reasonably easy to make this work if you patch the `CRM_Core_DAO::query` method to the following:
```
public function query($query, $i18nRewrite = TRUE) {
// rewrite queries that should use $dbLocale-based views for multi-language installs
global $wpdb, $dbLocale, $_DB_DATAOBJECT;
if ( defined( 'SAVEQUERIES' ) && SAVEQUERIES ) {
$wpdb->timer_start();
}
if (empty($_DB_DATAOBJECT['CONNECTIONS'][$this->_database_dsn_md5])) {
// Will force connection to be populated per CRM-20541.
new CRM_Core_DAO();
}
$conn = &$_DB_DATAOBJECT['CONNECTIONS'][$this->_database_dsn_md5];
$orig_options = $conn->options;
$this->_setDBOptions($this->_options);
if ($i18nRewrite and $dbLocale) {
$query = CRM_Core_I18n_Schema::rewriteQuery($query);
}
$ret = parent::query($query);
if ( defined( 'SAVEQUERIES' ) && SAVEQUERIES ) {
$wpdb->num_queries++;
$wpdb->queries[] = array(
$query,
$wpdb->timer_stop(),
$wpdb->get_caller(),
$wpdb->time_start,
array(),
'trace' => new QM_Backtrace( array(
'ignore_frames' => 1,
)),
'result' => is_countable($ret) ? count($ret) : 1
);
}
$this->_setDBOptions($orig_options);
return $ret;
}
```
Esentially the `$wpdb->queries` array is being populated with knowledge of the CiviCRM database queries, which query monitor can then read.
With this in place you can start to see some interesting insights. For example, we can see that the new mailing screen contains a number of database queries that are reapeated 40 times each, which is probably ripe for optimisation:
![Screenshot_2022-01-02_at_14.13.41](/uploads/117036cbf7cb970e93c7399eeb436f64/Screenshot_2022-01-02_at_14.13.41.png)
The WordPress admin bar shows the total count of queries (243) combined from both CiviCRM and WordPress.
Hacking the core files works for my purposes, but obviously doesn't allow for this to be packaged into a distributable plugin. Therefore, I think it'd be cool if there were a generic hook at the end of `CRM_Core_DAO::query` which could be used to save the query information in a format ameanable to Query Monitor. Alternatively CiviCRM could copy WordPress idea of the `$wpdb->queries` array, creating an array of queries which plugins like Query Monitor could make use of (in WordPress this is behind a flag so there is no performance hit when not in a development environment).
I've not given too much thought to exactly how this hook should look, but before I take this further (e.g. to the Pull Request state) it'd be good to get some views from the community:
- Is this something others in the community would find useful if this were distributed as a plugin?
- Does anyone know of plugins similar to Query Monitor in the Drupal or Joomla space which may benifit from this type of solution?
- Would people find this sort of hook useful for other use cases - for example, for writing debugging tools native to CiviCRM.
Keen to get others views on this one. I'll be interested to know what people think.https://lab.civicrm.org/dev/core/-/issues/2081Proposal: Extension upgrades should reconcile managed entities2023-01-19T22:49:26ZJonGoldProposal: Extension upgrades should reconcile managed entitiesWhen you install a new extension, `CRM_Extension_Manager::install()` contains this line:
```php
CRM_Core_Invoke::rebuildMenuAndCaches(TRUE);
```
However, no equivalent code runs on extension upgrade.
I propose that on extension up...When you install a new extension, `CRM_Extension_Manager::install()` contains this line:
```php
CRM_Core_Invoke::rebuildMenuAndCaches(TRUE);
```
However, no equivalent code runs on extension upgrade.
I propose that on extension upgrade, we run this code.
Recently, I've had two different extensions fail to work on deployment because the upgrade process doesn't reconcile managed entities. I imagine I'm not alone.https://lab.civicrm.org/dev/core/-/issues/4627Proposal: Membership type label2023-10-01T19:23:57Zmattwiremjw@mjwconsult.co.ukProposal: Membership type labelThe membership type table only has "name" and you cannot specify a separate label/title for display. This makes it problematic for portability/import/export as well as translation.
Proposal: Add new field "label" to MembershipType which...The membership type table only has "name" and you cannot specify a separate label/title for display. This makes it problematic for portability/import/export as well as translation.
Proposal: Add new field "label" to MembershipType which is used for display instead of the name.https://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.