CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2020-09-29T20:07:08Zhttps://lab.civicrm.org/dev/core/-/issues/2063Eliminate "No extensions available for this version of CiviCRM"2020-09-29T20:07:08ZJonGoldEliminate "No extensions available for this version of CiviCRM"This error is a possible outcome of the "checkExtensions" system check. I propose we eliminate it:
* There's never going to be another version of CiviCRM that has no extensions available, so the message is wrong.
* The error pretty much...This error is a possible outcome of the "checkExtensions" system check. I propose we eliminate it:
* There's never going to be another version of CiviCRM that has no extensions available, so the message is wrong.
* The error pretty much exclusively happens when there's an error on the c.o side, like an outage.
* There are no actionable steps for someone receiving this message.
* My personal gripe: When c.o goes down, I get this message from a gazillion sites at once.
While I'm aware it's theoretically possible that someone could define an alternate extension directory source from c.o, to my knowledge that a) has never been done, b) if you do that, you shouldn't need a warning in the UI to tell you no extensions are available.
Happy to take this on if folks approve.5.31.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1867Report time defaults to 12:00AM no matter what2020-07-16T21:08:49ZwortfmReport time defaults to 12:00AM no matter whatOverview
----------------------------------------
When entering a time range within a date selection, time reverts to 12:00AM. This makes it difficult to select a single day since even putting in 12:00AM to 11:59PM the report returns no...Overview
----------------------------------------
When entering a time range within a date selection, time reverts to 12:00AM. This makes it difficult to select a single day since even putting in 12:00AM to 11:59PM the report returns no results. WordPress 5.4.2 and CiviCRM 5.26.2
![civicrmResults](/uploads/6b16263085ee555e9159393423214f7c/civicrmResults.png)
![civicrmRange](/uploads/1243a86c5551d7ca0634dff246a0f58e/civicrmRange.png)
Inquired at https://civicrm.stackexchange.com/questions/36100/choose-by-date-range-always-at-1200am
Reproduction steps
----------------------------------------
1. Click on Select Date Range.
2. Select/Enter July 1, 2020 at 12:00AM until July 1, 2020 at 11:59PM.
3. No results are returned and the selection criteria is shown as going until July 1, 2020 at 12:00AM (see screen grab above)
Current behaviour
----------------------------------------
See Reproduction steps.
No error messages in browser, but the web console shows that date_format is undefined.
![civicrm_dateformat](/uploads/b243f322d1520189deef62123c60280d/civicrm_dateformat.png)
The query shows receive_date >= 20200701000000) AND ( receive_date <= 20200701000000
```
Expected behaviour
----------------------------------------
_What should happen._
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__All Browsers
* __CiviCRM:__ _Master/5.20.0/5.19.1/5.18.2/..._ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__7.3
* __CMS:__ WordPress 5.4.2
* __Database:__ MariaDB 10.4
* __Web Server:__ _Apache 2.4
Comments
----------------------------------------
This could entirely be some configuration incorrect, but was directed here by those on stackexchange.https://lab.civicrm.org/dev/core/-/issues/1587Show full description under select2 options2020-02-12T02:11:04ZMonish DebShow full description under select2 optionsOverview
----------------------------------------
Show full description under select2 options
Current behavior
----------------------------------------
Visit the export field option or Event name select2 filter in 'Find Participant' se...Overview
----------------------------------------
Show full description under select2 options
Current behavior
----------------------------------------
Visit the export field option or Event name select2 filter in 'Find Participant' search form. It trims the description with a teaser.
![Screen_Shot_2020-02-11_at_8.29.30_PM](/uploads/ec0400cff8072e1a25f31aeeda449b5f/Screen_Shot_2020-02-11_at_8.29.30_PM.png)
![Screen_Shot_2020-02-11_at_8.30.03_PM](/uploads/3237148bddd75af1a1fc497a9139990a/Screen_Shot_2020-02-11_at_8.30.03_PM.png)
Proposed behavior
----------------------------------------
Show the full description of select2 options. Make the change option by introducing a special attribute and handle accordingly in js and css to support that. For further details check next section.
Technical details
----------------------------------------
Introduce a special boolean setting attribute to select2 option array (in PHP) say ```fullDescription``` = TRUE/FALSE. Based on these setting it will add a CSS class say ```crm-select2-row-full-description``` via js and then make style changes to show full description.5.24.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/1559Use markdown in php docblocks2023-02-05T05:03:36ZcolemanwUse markdown in php docblocks**tl;dr:** I propose we standardize the format of our docblocks to use markdown.
To-date, docblocks in CiviCRM haven't been very visible (or very much of anything). The APIv4 Explorer is starting to change that. For example, this docblo...**tl;dr:** I propose we standardize the format of our docblocks to use markdown.
To-date, docblocks in CiviCRM haven't been very visible (or very much of anything). The APIv4 Explorer is starting to change that. For example, this docblock:
```php
/**
* ACL (Access Control List).
*
* An ACL record consists of:
*
* - an Operation (e.g. 'View' or 'Edit')
* - a set of Data that the operation can be performed on (e.g. a group of contacts)
* - and a Role that has permission to do this operation.
*
* Creating a new ACL requires at minimum a entity table, entity ID and object_table.
*
* @see https://docs.civicrm.org/user/en/latest/initial-set-up/permissions-and-access-control
* @package Civi\Api4
*/
class ACL extends Generic\DAOEntity {
```
Displays in the explorer like this:
![image](/uploads/2a04dad923b43fc4f5e739bef6feb064/image.png)
I've been doing my best to make them render nicely, for example it turns ticks into bullets, `@see` annotations into links, and double-line-breaks into paragraphs... but that's about it so far. It would be really nice if we could fully support markdown for formatting, lists, tables, code blocks, etc. etc.
Apparently using markdown in PHP docblocks is gaining popularity. [PHPStorm now supports it, as does PHPDocumentor](https://blog.jetbrains.com/phpstorm/2014/04/phpstorm-8-markdown-support-in-phpdoc-blocks/).
I suggest we jump on that bandwagon. If there's no objections I'll add a markdown parser to the APIv4 Explorer and start using markdown syntax in more docblocks.https://lab.civicrm.org/dev/core/-/issues/1403Change "Contribution Received Date" to be "Contribution date" where is exists...2024-01-28T01:17:26ZJamie Novick - CompucoChange "Contribution Received Date" to be "Contribution date" where is exists and basically sort this Contribution dates mess out once and for allOk... sorry if this comes across as a bit of a rant but as a qualified accountant this has been driving me crazy for years and I think we've been skirting around this issue for sometime. I wanted to put in a gitlab to start a discussion ...Ok... sorry if this comes across as a bit of a rant but as a qualified accountant this has been driving me crazy for years and I think we've been skirting around this issue for sometime. I wanted to put in a gitlab to start a discussion to allow us to sort this out once and for all.
**Overview:**
----------------------------------------
CiviCRM has a core field on the contribution called "receive_date". This shows up on various screens and has led to significant debate about whether it should be a required field or not, and what it's real use case is. For example discussions below where debate has raged on how it should work:
https://lab.civicrm.org/dev/core/issues/1057
https://lab.civicrm.org/dev/core/issues/680
https://lab.civicrm.org/dev/core/issues/1140 - slightly different but related re: accruals accounting
https://lab.civicrm.org/dev/core/issues/1402
**The issue:**
----------------------------------------
So... there are a few problems with this field:
a) The idea of a "received date" is a bit meaningless (and confusing to users) when you have a pending contribution. You haven't quite received anything yet.
b) The idea of a "received date" conflicts with the payments dates if you have multiple payments (or could even be made to be different from the payment date) again which is nonsensical.
I assume contribution received date was a field that pre-dated the CiviCRM accounting implementation and hence perhaps hasn't kept up with the reality of the situation. In any case I believe this is causing some real issues now and should be sorted out.
Note the field is used:
1) As the date when initial accounting transactions are made. i.e. create a new pending contribution it will be the date of the Debit and Credits / transaction recorded in CiviCRM and hence by default it is the "revenue recognition date" for account purposes for the income.
This then leads to a multitude of other issues:
a) If I "complete" a pending membership contribution for a new membership by recording a payment, what should the start date of the membership be? (see: https://lab.civicrm.org/dev/core/issues/1402)
b) We've then introduced another field called "revenue_recognition_date", which should actually be field 1 above - as that is when we are recognising the transactions. We shouldn't have another field for this.
c) For some reason we now have a field on the invoice called "invoice date" which prints todays date which again is incorrect as it should be the same as item 1 above. The invoice should reflect the revenue recognition date. https://civicrm.stackexchange.com/questions/21128/how-do-i-print-the-received-date-on-an-invoice
**Proposed solution:**
----------------------------------------
The solution is relatively simple. We should change the "received_date" field to simply be the "Contribution date".
| Invoicing? | Contribution status | What the field means | Changes required to CiviCRM |
| ------ | ------ | ------ | ------ |
| Not using invoices | Pending | Represents the date the contribution was recorded on the system. | When later marking the contribution as completed give users the option to update the date or better still don't offer the option to complete a contribution and simply only allow users to enter the payment separately.
| Not using invoices | Completed | Represents the date the contribution was recorded on the system but also record a payment on the same date.
| Using invoices | Pending | Represents the date the invoice was recorded on the system and hence the invoice date and the revenue recognition date. | We should update the invoices to use this date as the invoice date. This field should not be updated when marking the invoice as complete (or better still don't offer the option to complete a contribution and simply only allow users to enter the payment separately.)
| Using invoices | Completed | Represents the date the invoice was recorded on the system but also the date the payment for that invoice was received. Ideally we would split the invoice and payment sections from each other on the "create new" form.
**Future:**
----------------------------------------
At some date in the future it would then be good to properly decouple payments from contributions and get rid of the terrible contribution status field once and for all.
Basically the contribution would reflect an order or invoice object, i.e. the obligation to pay for something. The payment transaction then would be separate and would represent the actual payment of that obligation. Accounting software has done this correctly for years so it's about time CiviCRM did too!
@mattwire @eileen @KarinG @dylan-circle @jaapjansma @JoeMurray @ErikHommel @fabian_SYSTOPIA and a few Compucorp names also - @omar_compucorp @Miya27
I'm sure you will all have opinions on this...https://lab.civicrm.org/dev/core/-/issues/1166Update Country list: change Macedonia, Republic of into North Macedonia2019-12-03T08:07:43ZBetty DolfingUpdate Country list: change Macedonia, Republic of into North MacedoniaI understand ([see stackexchange question](https://civicrm.stackexchange.com/questions/31577/countries-up-to-date)) that the country list in CiviCRM is [maintained manually](https://github.com/civicrm/civicrm-core/blob/5.15.2/xml/templat...I understand ([see stackexchange question](https://civicrm.stackexchange.com/questions/31577/countries-up-to-date)) that the country list in CiviCRM is [maintained manually](https://github.com/civicrm/civicrm-core/blob/5.15.2/xml/templates/civicrm_country.tpl#L172).
In the iso 3166-1 list, Macedonia, Republic of is now called: **North Macedonia**
Can this be changed in the country list in CiviCRM?5.21.0seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/1160Events with templates but no custom field values don't save custom fields2021-04-07T01:44:01ZJonGoldEvents with templates but no custom field values don't save custom fieldsThis is closely related to core#553, but the fix for #553 doesn't solve this.
In core#553, if you have an event template that DOES specify values for custom fields, they don't get copied to a new event.
In this case, if you have an eve...This is closely related to core#553, but the fix for #553 doesn't solve this.
In core#553, if you have an event template that DOES specify values for custom fields, they don't get copied to a new event.
In this case, if you have an event template that does NOT specify values for custom fields, then any values you enter for custom fields are ignored.
This is true both with and without [PR #14063](https://github.com/civicrm/civicrm-core/pull/14063) so it's not an unreleased regression.https://lab.civicrm.org/dev/core/-/issues/882ACLs don't work on "Tab with table" custom field groups2023-05-31T05:03:19ZJonGoldACLs don't work on "Tab with table" custom field groupsTo replicate on master:
* Create a new role, "Read Only".
* Give the role only the "Access CiviCRM" permission.
* Create a new group "Read Only" of type "Access Control".
* Create a multi-record custom group with display type of "Tab wit...To replicate on master:
* Create a new role, "Read Only".
* Give the role only the "Access CiviCRM" permission.
* Create a new group "Read Only" of type "Access Control".
* Create a multi-record custom group with display type of "Tab with table".
* Create a new user, give them the "Read Only" role and place them in the "Read Only" group.
* Configure an ACL that grants "View" access to one or more contacts. Since "Edit own contact" is a special case, ensure that one of the contacts doesn't belong to the user.
* Configure an ACL that grants "View" access to the multi-record custom group.
Expected result:
* This user shouldn't be able to edit a contact's data.
Actual result:
* This user can edit custom fields that are on a "tab with table".
There's a few things that need fixing, I intend to move at least some of these forward:
* The template doesn't have a permission check on the "Add" button.
* The class doesn't have a permission check on the action links.
* The class doesn't have a permission check on postProcess.
Finally, the "Edit" ACL for custom fields don't seem to be respected - but this is out of scope for this issue.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/818CQ: Switch core forms to be Entity Forms2022-10-31T05:03:14ZeileenCQ: Switch core forms to be Entity FormsWe have switched some forms already to use the EntityFormTrait as part of the following goals
1) move data about the fields on the forms into the schema xml - this will be important to help us migrate away from quick form
2) support cus...We have switched some forms already to use the EntityFormTrait as part of the following goals
1) move data about the fields on the forms into the schema xml - this will be important to help us migrate away from quick form
2) support custom data on a wide range of entities - several entities already support custom data as a result of having been switched to entity forms - relationship type form, membership status, financial type, price set etc
3) support parameters passed through the url in a non ad-hoc way - we have a history of security issues are url parameters so any new retrieval should be stdised & we need to work to remove existing ones
4) support extension intervention in the fields displayed - this is particularly supported by the tpl changes in the entity form structure
5) generalised reduction in unecessary code
6) improving translation consistency
What is involved in the Entity Form is best understood by looking at existing examples but basically it consists of
- using the EntityFormTrait
- ensuring the relevant things are declared on the class to support that
- declaring all the fields that can be added through metadata in the metadata array
- working towards simplifying the tpl to a single line {include file="CRM/Core/Form/EntityForm.tpl"}
Generally in any change we can take steps towards this rather than fully implement ithttps://lab.civicrm.org/dev/core/-/issues/779Support token for participant id in scheduled reminder2021-10-12T02:22:06ZyashodhaSupport token for participant id in scheduled reminderCurrently, the participant id token is not available for scheduled reminder.
This is especially useful if the user need to be sent Self-service Registration Update forms
https://yoursite/civicrm/event/selfsvcupdate?reset=1&pid=xCurrently, the participant id token is not available for scheduled reminder.
This is especially useful if the user need to be sent Self-service Registration Update forms
https://yoursite/civicrm/event/selfsvcupdate?reset=1&pid=x5.43.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/773Proposal: Don't allow deleting custom fields that are used in a smart group2022-11-07T05:03:58ZJonGoldProposal: Don't allow deleting custom fields that are used in a smart groupI'm inspired by [this SE question](https://civicrm.stackexchange.com/questions/28713/how-to-troubleshoot-expected-one-customfield-but-found-0-error/28731). I can't think of a reason why we'd allow someone to delete a custom field used i...I'm inspired by [this SE question](https://civicrm.stackexchange.com/questions/28713/how-to-troubleshoot-expected-one-customfield-but-found-0-error/28731). I can't think of a reason why we'd allow someone to delete a custom field used in a smart group. The downside is we'd need to use an unindexed search on `civicrm_saved search` (e.g. `LIKE %"custom_1"%`) but I'm guessing that most folks don't have thousands of smart groups, and this would happen fairly infrequently.https://lab.civicrm.org/dev/core/-/issues/767Add 'Cancelled / Refunded Date' and 'Cancellation / Refund Reason' in the Det...2019-03-04T13:47:10ZGhost UserAdd 'Cancelled / Refunded Date' and 'Cancellation / Refund Reason' in the Detail Contributions ReportAdd the fields and filters 'Cancelled / Refunded Date' and 'Cancellation / Refund Reason' in the Detail Contributions Report.Add the fields and filters 'Cancelled / Refunded Date' and 'Cancellation / Refund Reason' in the Detail Contributions Report.yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/766New Event using a template - clicking "Continue" doesn't save custom data2022-04-22T16:22:26ZkenNew Event using a template - clicking "Continue" doesn't save custom dataWhen creating a New Event from an Event Template, and entering custom data for the event, hitting "Continue" doesn't save the custom data. This happens for me on 5.10.4, on the CiviHosting demo which is running 5.10.0, and the CiviCRM Sa...When creating a New Event from an Event Template, and entering custom data for the event, hitting "Continue" doesn't save the custom data. This happens for me on 5.10.4, on the CiviHosting demo which is running 5.10.0, and the CiviCRM Sandbox running 5.12.alpha1.
**How to reproduce**
1. Add a custom field to Event entities
2. Click _Events > New event_
3. Choose an Event Template
4. Enter the mandatory fields _and_ the custom data
5. Click _Continue_
6. Reload the page to force CiviCRM to fetch the event from the database
7. Visit the _Info and Settings_ tab
8. The custom data is unset
**Hint**
In my debugger I had a breakpoint in my implementation of _hook_civicrm_pre()_ and this didn't trigger when _Continue_ was pressed, but did when _Save_ or _Save and Done_ were pressed. If _Continue_ bypasses _pre()_ then perhaps it skips the Custom Data too?5.39.0https://lab.civicrm.org/dev/core/-/issues/756Error on Contributions tab with soft credits in multiple currencies2019-02-28T05:28:10ZdavisagliError on Contributions tab with soft credits in multiple currencieshttps://github.com/civicrm/civicrm-core/commit/5fb64d515190821c017c6ea8d3ffcf148bcb9f6f added an explicit check for valid currency codes in the crmMoney smarty plugin.
In CiviCRM 5.10.4 I'm getting this error "Invalid currency "CAD, USD...https://github.com/civicrm/civicrm-core/commit/5fb64d515190821c017c6ea8d3ffcf148bcb9f6f added an explicit check for valid currency codes in the crmMoney smarty plugin.
In CiviCRM 5.10.4 I'm getting this error "Invalid currency "CAD, USD" when trying to view the contributions for a contact with soft credits in multiple currencies. Viewing the source, it's actually a non-breaking space between the two currency codes. I think that's coming from here: https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/BAO/ContributionSoft.php#L2835.11https://lab.civicrm.org/dev/core/-/issues/735Query performance - suppress 'product' and related fields where products are ...2019-04-26T06:50:00ZeileenQuery performance - suppress 'product' and related fields where products are not in the databaseMost people hate the fact we waste an output field on premium on the contribution tab. They all think it should be replaced - but all have different replacements.
I don't want to solve that - I think the right solution for that is to f...Most people hate the fact we waste an output field on premium on the contribution tab. They all think it should be replaced - but all have different replacements.
I don't want to solve that - I think the right solution for that is to find funding to leap the interface.
What I DO think we can solve is the fact we are doing unnecessary joins / queries / processing to generate & display premiums - regardless of whether the site uses them. I think we could short-circuit that pretty cleanly by just doing a quick
"select id FROM civicrm_product_premium LIMIT 1' (cached) before adding product fields to our default return properties (with a small tpl tweak too)5.13.0https://lab.civicrm.org/dev/core/-/issues/660Fatal DB Error: already exists on event registration/contribution pages when ...2019-01-17T11:24:07ZdavejFatal DB Error: already exists on event registration/contribution pages when profile has user creation**Steps to replicate**
1. In Drupal account settings, set *Who can register accounts? = Visitors* and un-tick *Require e-mail verification when a visitor creates an account.*
2. In standard *Your Registration Info* profile settings, set ...**Steps to replicate**
1. In Drupal account settings, set *Who can register accounts? = Visitors* and un-tick *Require e-mail verification when a visitor creates an account.*
2. In standard *Your Registration Info* profile settings, set *Drupal user account registration option? = Account creation required*.
3. Create a basic event with no fees, allowing online registration, using above profile.
4. As an anonymous user, register for the event, using email address and username that do not exist in the Civi or Drupal databases.
**Expected behaviour**
Contact created and registered for event, user created.
**Actual behaviour**
Fatal DB Error: already exists
```
[debug_info] => INSERT INTO civicrm_uf_match (domain_id , uf_id , uf_name , contact_id ) VALUES
( 1 , 5 , 'blah@blah.blah' , 207 ) [nativecode=1062 ** Duplicate entry 'blah@blah.blah' for key 'UI_uf_name_domain_id']
```
2 contacts created with same email address:
- first (by id) with display name = provided name, has participant record, no UF match record.
- second (by id) with display name = email, no participant record, has UF match record.
User created.
Similar past issues:
- [CRM-16234 User Creation via profile fails with DB Error](https://issues.civicrm.org/jira/browse/CRM-16234)
- [CRM-19195 Duplicate entry in civicrm_uf_match when forcing account creation](https://issues.civicrm.org/jira/browse/CRM-19195)
Replicated on 5.9.0/Drupal 7 and current local dmaster.
On local civibuild drupal-demo 5.8.2: the contact, participant, user & UF match records were created successfully.https://lab.civicrm.org/dev/core/-/issues/644"From" address on membership renewal notices is wrong2019-03-13T23:50:20ZJonGold"From" address on membership renewal notices is wrongFound on [Stack Exchange](https://civicrm.stackexchange.com/q/27905/12). I don't think this is replicable on the demo server because you need to be able to send email to replicate.
### Steps to Replicate
* If using civicrm-buildkit, en...Found on [Stack Exchange](https://civicrm.stackexchange.com/q/27905/12). I don't think this is replicable on the demo server because you need to be able to send email to replicate.
### Steps to Replicate
* If using civicrm-buildkit, enable sending mail by temporarily deleting `<buildkit-root>/app/civicrm.settings.d/100-mail.php`.
* You can still set your outgoing mail to redirect to database - but `CIVICRM_MAIL_LOG` shouldn't be defined.
* Create a new non-lifetime membership on any contact.
* Select **Renew** next to the membership.
* Check the **Send Confirmation and Receipt** checkbox.
* Pres the **Renew** button.
![Selection_752](/uploads/5e877fd67625a9ca8edcd7d3e70788ba/Selection_752.png)
### Expected Result
In the "From" header, the email should have the display name of the contact selected in **Receipt From**.
### Actual Result
In the "From" header, the email has the contact ID of the contact selected in **Receipt From**.5.11JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/522Add case tokens to email activities2021-09-13T00:04:33ZeileenAdd case tokens to email activitieshttps://lab.civicrm.org/dev/core/-/issues/500CiviCase: dashboard summary count includes cases from inactive relationships2019-11-24T19:59:34ZbgmCiviCase: dashboard summary count includes cases from inactive relationshipsHow to reproduce:
* Create a case
* Assign it to someone, view their dashboard, it will show X cases
* Then re-assign it to someone else, view their dashboard, it will still show X cases (instead of X-1).How to reproduce:
* Create a case
* Assign it to someone, view their dashboard, it will show X cases
* Then re-assign it to someone else, view their dashboard, it will still show X cases (instead of X-1).5.11bgmbgmhttps://lab.civicrm.org/dev/core/-/issues/495CQ: Migrate simple Preferences & Settings forms to using a Generic class.2023-06-27T05:03:25ZeileenCQ: Migrate simple Preferences & Settings forms to using a Generic class.Per https://github.com/civicrm/civicrm-core/pull/13023 @mattwire & myself have recently worked on consolidating some of the setting form metadata handling. This is mostly done however our end goal is worth spelling out.
Basically the cl...Per https://github.com/civicrm/civicrm-core/pull/13023 @mattwire & myself have recently worked on consolidating some of the setting form metadata handling. This is mostly done however our end goal is worth spelling out.
Basically the class 'CRM_Admin_Form_Preferences_Event' and all classes that don't need special sauce would be removed & the xml would be altered to
```
<item>
<path>civicrm/admin/setting/preferences/event</path>
<title>CiviEvent Component Settings</title>
<page_callback>CRM_Admin_Form_Generic</page_callback>
</item>
```
This page would load settings based on filtering setting metadata - so any fields with a key in their metadata like this
```
settings_pages => [
'event' => ['weight' => 10]
]
```
would show up at the url above (note the last value on the url is the filter).
Extensions could use the existing alterSettingMetadata hook to add & remove fields from any pages that use the Generic form to choose their settings and extensions could add settings pages by just adding an xml entry & their metadata
We would convert simple forms & for more complex forms we would attempt to break the inheritance on the 2 existing forms (CRM_Admin_Form_Preferences & CRM_Admin_Form_Setting) in favour of using just the CRM_Admin_Form_SettingTrait in an attempt to grandfather them out.