CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-11-10T07:20:20Zhttps://lab.civicrm.org/dev/core/-/issues/3959Event Scheduled Reminder Behavior2022-11-10T07:20:20ZLKuttnerEvent Scheduled Reminder BehaviorI am wondering if this behavior has been changed-- I did not see any online mention of a change with Scheduled Reminders.
Scenario: A schedule event reminder was set for 24 hours before the event start time 4:00 PM Tuesday.
On Monday at...I am wondering if this behavior has been changed-- I did not see any online mention of a change with Scheduled Reminders.
Scenario: A schedule event reminder was set for 24 hours before the event start time 4:00 PM Tuesday.
On Monday at 4:00 PM, 24 Hours before the event, the reminder is successfully sent to registered attendees.
On Tuesday, the day of the event, additional contacts register.
Expected behavior: The scheduled reminder that was sent on the previous day is NOT sent to new registrants.
Experienced behavior: The reminder scheduled for the previous day is sent ten minutes after a new contact registered.
I do not find any explanation for the later sent reminder emails.
This is with CiviCRM 5.45.7 on Drupal 7 with PHP 7.3.29https://lab.civicrm.org/dev/core/-/issues/3944SearchKit: Show count on both top and bottom of display2022-10-27T20:47:07ZlarsssandergreenSearchKit: Show count on both top and bottom of displayCurrently, the count of results in a SearchKit display is only shown on the bottom of the page. In core, totals are usually shown at the top and bottom of the page in search results. I think it would be more usable to also show the total...Currently, the count of results in a SearchKit display is only shown on the bottom of the page. In core, totals are usually shown at the top and bottom of the page in search results. I think it would be more usable to also show the total count in SearchKit displays at the top of the page, beside the Actions drop down menu. It's a good sanity check for users to be able to see how many entities they are doing an action on before doing so - they shouldn't have to scroll to the bottom of the page and then back up to see the count. It's also not always easy to see how many are selected or if you've selected just one page of results or the whole list.
Something simple like this, which would also show NNN selected of NNN results when some are selected.
![image](/uploads/0587e86d7faed05a9ecf441a64f93378/image.png)
This could be disabled by disabling show count for the display.https://lab.civicrm.org/dev/core/-/issues/3937Importing "No" values to Boolean field results in empty2023-04-03T02:21:49ZelilisseckImporting "No" values to Boolean field results in emptyOverview
----------------------------------------
Contact imports to custom "Yes or No" fields work with values 1 or 0. "Yes" also appears to work.
If you import a "No" value, however, the field will be blank for that contact instead o...Overview
----------------------------------------
Contact imports to custom "Yes or No" fields work with values 1 or 0. "Yes" also appears to work.
If you import a "No" value, however, the field will be blank for that contact instead of having the "No"/0 label/value.
Technical details
----------------------------------------
["strtoboolstr"](https://github.com/civicrm/civicrm-core/blob/4ce53ba3de860a5d9aac1b1bbd22b7a29e839af2/CRM/Utils/String.php#L424) gets run twice on this data. [Once on the raw value returning a boolean](https://github.com/civicrm/civicrm-core/blob/902fc38d0d6cd9d09ee02f30cc6621747151a06a/CRM/Import/Parser.php#L1602) and [once later in the code here](https://github.com/civicrm/civicrm-core/blob/902fc38d0d6cd9d09ee02f30cc6621747151a06a/CRM/Contact/Import/Parser/Contact.php#L328)
When you run this on a boolean value (you shouldn't, according to the comments, but perhaps we should check for this), "Yes"/true will _look_ like it's working okay because the preg_match will match for (bool)true but it won't match for (bool)false. I'm sure this has something to do with a PHP oddity I know nothing about but related to the fact that `strlen((bool)true)` is `1` and `strlen((bool)false)` is `0`.
Proposed solution is:
1) Don't run strtoboolstr twice. We don't need that second iteration of it because it's already been run on the data. I'm not sure of any other impacts for this so also:
2) Write a test for importing to a Yes/No field with the 6 values that should work (1,0,yes,no,true,false). I've started writing this test following examples but i'm having trouble getting my import data actually in properly to run the assertEquals on. I will open a WIP PR with this test.
Any other thoughts welcome!
Reproduction steps
----------------------------------------
1. Create a custom field with data type "Yes or No"
2. Create a csv to import first,last,custom_fieldID with data for your custom field "Yes" and "No"
3. Run the import normally through the GUI in the Contacts > Import Contacts workflow
4. Observe custom field results on the imported contacts
Expected behaviour
----------------------------------------
According to code comments, this type of field import should accept "1", "0", "Yes", "No", "true", "false" and they should all fill a "Yes or No" field correctly.
Environment information
----------------------------------------
This was reproduced on the master branch in d9 (5.56.alpha1)5.61.0https://lab.civicrm.org/dev/core/-/issues/3936Import contributions (update existing) extremely slow2022-12-24T14:42:08ZDetlev SieberImport contributions (update existing) extremely slowOverview
----------------------------------------
On a large database, importing updates of existing contributions is extremely slow (about 10 times slower than inserting new contributions).
This is new with 5.53 or 5.54.
Reproduction ...Overview
----------------------------------------
On a large database, importing updates of existing contributions is extremely slow (about 10 times slower than inserting new contributions).
This is new with 5.53 or 5.54.
Reproduction steps
----------------------------------------
Reproducing requires large database with many contributions. Therefore not yet reproducible on sandbox.
Current behaviour
----------------------------------------
Inserting new contributions works on this specific production environment at a rate of 140 contributions per minute.
Updating existing contributions is at an average of only 13 contributions per minute.
Expected behaviour
----------------------------------------
Previously, updating existing contributions was slightly faster than inserting new contributions.
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:__ _Firefox 105.0.3
* __CiviCRM:__ _5.54.0 (was working well with 5.52.x)
* __PHP:__ _7.4
* __CMS:__ _Drupal 7.52
* __Database:__ _MariaDB 10.5.15_
Comments
----------------------------------------
_none_https://lab.civicrm.org/dev/core/-/issues/3935PHP Notice: Undefined offset in _civicrm_member_roles_sync()2022-12-01T02:47:03ZAndrew WassonPHP Notice: Undefined offset in _civicrm_member_roles_sync()Overview
----------------------------------------
This is an issue that I have noticed in several Drupal 7 / CiviCRM websites. When the CiviCRM Member Roles Synch activity takes place, my recent log messages get inundated with PHP Notice...Overview
----------------------------------------
This is an issue that I have noticed in several Drupal 7 / CiviCRM websites. When the CiviCRM Member Roles Synch activity takes place, my recent log messages get inundated with PHP Notices:
> Notice: Undefined offset: x in _civicrm_member_roles_sync() (line 607 of /civicrm/drupal/modules/civicrm_member_roles/civicrm_member_roles.module).
Reproduction steps
----------------------------------------
1. Enable civicrm member roles sync.
1. Add a rule to synch some member type to a role.
1. Configure to run at Drupal Cron
1. Run Cron and observe as Reports -> Recent Log Messages get filled with notices.
Steps to Resolve
----------------------------------------
line 607 of /civicrm/drupal/modules/civicrm_member_roles/civicrm_member_roles.module contains the following statement:
`if (is_array($memberroles[$membership['membership_type_id']])) {`
If the array is not set then the notice will be raised so if we check it first as follows, the notice goes away:
`if (isset($memberroles[$membership['membership_type_id']]) && is_array($memberroles[$membership['membership_type_id']])) {`
Environment information
----------------------------------------
* __CiviCRM:__ _5.54.0_
* __PHP:__ _7.4/8.1__
* __CMS:__ _Drupal 7.92_
* __Database:__ _MySQL 5.7.4_
* __Web Server:__ _Apache 2.x_5.57.0https://lab.civicrm.org/dev/core/-/issues/3933Subscription history is not set when GroupContact is deleted via API42022-11-07T01:41:44ZlarsssandergreenSubscription history is not set when GroupContact is deleted via API4If a contact is deleted from a group via API4 (by deleting the GroupContact), no subscription history is recorded. I think it should be, as it is recorded if done via the UI or API3.
Tested on dmaster.
Edit: Removed some discussion abo...If a contact is deleted from a group via API4 (by deleting the GroupContact), no subscription history is recorded. I think it should be, as it is recorded if done via the UI or API3.
Tested on dmaster.
Edit: Removed some discussion about API3 that turned out to be a red herring.https://lab.civicrm.org/dev/core/-/issues/3931Blank Invoice.pdf appearing when doing Offline contributions2023-05-18T23:35:49ZshaneonabikeBlank Invoice.pdf appearing when doing Offline contributionsHi there,
Recently, my client noticed that Offline contributions made via ```Submit a Credit Card Membership``` were sending out blank Invoice pdfs. I don't think that this was happening previously.
## How to reproduce
1. Go to new me...Hi there,
Recently, my client noticed that Offline contributions made via ```Submit a Credit Card Membership``` were sending out blank Invoice pdfs. I don't think that this was happening previously.
## How to reproduce
1. Go to new member contact record and select "Membership" tab
1. Choose "Submit credit card membership"
1. Enter membership details and select "Save"
1. Receipt is automatically sent to member
## CiviCRM details
+ CiviCRM 5.49.4
+ Drupal 7
## Log Error message
```
2022/10/21 09:48:39 [error] 25282#25282: *7533568 FastCGI sent in stderr: "emplate.php).PHP message: [notice] [php] [209.169.169.221] [uid:1] [https://test.org/civicrm/contact/view/membership] [https://test.org/civicrm/contact/view/membership?reset=1&action=add&cid=107793&context=membership&mode=test] Notice: Undefined variable: html in CRM_Contribute_Form_Task_Invoice::printPDF() (line 516 of /sites/all/modules/civicrm/CRM/Contribute/Form/Task/Invoice.php).
PHP message: [notice] [php] [209.169.169.221] [uid:1] [https://test.org/civicrm/contact/view/membership] [https://test.org/civicrm/contact/view/membership?reset=1&action=add&cid=107793&context=membership&mode=test] Notice: Only variable references should be returned by reference in CRM_Mailing_Event_BAO_Delivered::create() (line 34 of /sites/all/modules/civicrm/CRM/Mailing/Event/BAO/Delivered.php)" while reading response header from upstream, client: 209.169.169.221, server: test.org, request: "POST /civicrm/contact/view/membership HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php7.3-fpm.sock:", host: "test.org", referrer: "https://test.org/civicrm/contact/view/membership?reset=1&action=add&cid=107793&context=membership&mode=test"
```https://lab.civicrm.org/dev/core/-/issues/3930Managed entity: creating custom fields with same label causes fatal error bec...2022-10-24T09:18:16ZherbdoolManaged entity: creating custom fields with same label causes fatal error because of db index.Overview
----------------------------------------
It seems a bit over the top to have fatal errors when custom field labels are not unique. This would (likely) only appear if someone had a managed entity for the custom field. Or if they...Overview
----------------------------------------
It seems a bit over the top to have fatal errors when custom field labels are not unique. This would (likely) only appear if someone had a managed entity for the custom field. Or if they were using the API directly.
Example use-case
----------------------------------------
1. Create a custom group. Add a custom field.
2. Go to API4, choose CustomField, create. Create a new custom field with the same label.
Current behaviour
----------------------------------------
> DB Error: already exists
Proposed behaviour
----------------------------------------
Remove the index from the database for the label. The custom field index on the name should be enough. The UI will still have validation to prevent duplicate labels, but that's necessary because there's no way to specify the label and name separately in the UI.https://lab.civicrm.org/dev/core/-/issues/3926Need to increase data size for 'url' column on 'civicrm_website' table2022-10-28T15:46:49ZyashodhaNeed to increase data size for 'url' column on 'civicrm_website' tableOverview
----------------------------------------
Currently _url_ column of the _civicrm_website_ table is of maxlength 124. This is not sufficient for some website in which case it truncates and renders them useless.
Proposed behavio...Overview
----------------------------------------
Currently _url_ column of the _civicrm_website_ table is of maxlength 124. This is not sufficient for some website in which case it truncates and renders them useless.
Proposed behaviour
----------------------------------------
The Proposal is to change the maxlength of the _url_ column of the _civicrm_website_ table to 255 instead of 124.5.56.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/3924Afform linter has only been running on core-core2022-10-20T07:29:10ZtottenAfform linter has only been running on core-coreOverview
----------------------------------------
There is a linting test for Civi's Angular-HTML files (`tests/phpunit/Civi/Angular/PartialSyntaxTest.php`). However, the linting is not applied consistently, and several files are not in...Overview
----------------------------------------
There is a linting test for Civi's Angular-HTML files (`tests/phpunit/Civi/Angular/PartialSyntaxTest.php`). However, the linting is not applied consistently, and several files are not in compliance.
Having files which pass the linter ensures that:
* Modified/forked files can be easily compared to their originals.
* Files can be filtered/processed via `hook_alterAngular`.
Current behaviour
----------------------------------------
`PartialSyntaxTest` scans all available Angular modules at the time of test. In effect, it scans `civicrm-core:ang/**.html`.
When the test runs, `search_kit` and `afform` are not active, so not `civicrm-core:ext/search_kit/ang/**.html` and `civicrm-core:ext/afform/*/ang/**.html` are not scanned.
NOTE: This mechanism is built on top of PHP's `DOMDocument` (generally) and `phpQuery` (specifically). To test an HTML partial, we basically say:
```php
$doc = (new DOMDocument(...))->loadHTML($inputString);
$outputString = $doc->saveHTML();
assert $inputString === $outputString
```
So a document is considered good if it is stable/consistent across reads+writes.
Expected behaviour
----------------------------------------
All Angular HTML in `civicrm-core.git` should be scanned by a linter.
All files should pass.
Comments
----------------------------------------
There is a helper script `tools/scripts/check-angular.php` which can validate+reformat file. The script is not super-sophisticated -- but just to get a sense of it, one might call:
```
php tools/scripts/check-angular.php --colordiff $PWD/ext/search_kit/ang/crmSearchTasks/crmSearchTaskUpdate.html
```
In principal, we could run this on all the HTML files and simply commit the reformatted version. Then we might rework `PartialSyntaxTest` to plug the hole in the workflow.
But...
There's the issue of the actual changes in the formatting. It is important to note that PHP's `DOMDocument` has two formatting modes -- HTML and XML. The parser here has to use one or the other. These differ in several small ways -- eg some notations work the same in both, but some notations are rejected by one while accepted by the other. Going from memory (*based on testing yesterday*), here are some notable differences:
| Topic | Example | HTML Mode Support | XML Mode Support | Comment |
| -- | -- | -- | -- | -- |
| Standard tag, text | `<div>Hello</div>` | :white_check_mark: Read-write | :white_check_mark: Read-write | `div`, `span`, `p`, etc |
| Standard tag, empty-text | `<div></div>` | :white_check_mark: Read-write | :warning: Read-only<br/> (Prefer `<div/>`) | `div`, `span`, `p`, etc |
| Standard tag, self-closing | `<div/>` | :warning: Read-only<br/> (Prefer `<div></div>`) | :white_check_mark: Read-write | `div`, `span`, `p`, etc |
| Standard tag, self-closing, implicit | `<input>` | :white_check_mark: Read-write | :octagonal_sign: Error | `input`, `img`, `hr`, `br`, etc |
| Standard tag, self-closing, explicit | `<input/>` | :warning: Read-only<br/>(Prefer `<input>`) | :white_check_mark: Read-write | |
| Custom tag, text | `<custom>my text</custom>` | :white_check_mark: Read-write | :white_check_mark: Read-write | |
| Custom tag, empty-text | `<custom></custom>` | :white_check_mark: Read-write | :warning: Read-only<br/>(Prefer `<custom/>`) | |
| Custom tag, self-closing | `<custom/>` | :warning: Read-only<br/>(Prefer `<custom></custom>`) | :white_check_mark: Read-write | |
| Value-less attributes (custom or standard) | `<foo ng-list>` | :white_check_mark: Read-write | :octagonal_sign: Error | |
| Value for `disabled` | `<foo disabled="abcd">` | :octagonal_sign: Discard value | :white_check_mark: Read-write | |
(*I wanted to see this table because I had the nagging feeling that we were boxed in somehow -- and this does show that there are errors in either case. But these can be worked through...*)
I believe that running the auto-format (*at this moment*) would pose a few issues:
* For HTML mode (status-quo), it would discard the `disabled="..."` that appears in ~5 components. (*I suspect that this status-quo is actually a bug -- but only symptomatic when using `alterAngular`.*) We could update affected files. This may require changing some contracts.
* For XML mode, it would fail to parse `<input>`, `<foo ng-list>`, and similar. We could update these (`<input/>` and `<foo ng-list=",">`), though this would affect many more lines of code.
* In either mode, some files need to flip between `<foo></foo>` and `<foo/>`. Regex can control this a bit more tightly, though. We would need to choose which form we like.
There's also the possibility (out of left field) to replace the current parser or formatter or validator. But that feels like an even bigger rabbit hole.https://lab.civicrm.org/dev/core/-/issues/3923Search Kit does not populate Tag Name(s) when the condition is set to "Is One...2023-02-11T18:39:59ZbrienneSearch Kit does not populate Tag Name(s) when the condition is set to "Is One Of"Overview
----------------------------------------
When creating a search in Search Kit, the list of tag names to select does not populate when the Contact Tag entity is chosen and a condition of Tag Name "Is One Of"
Reproduction steps
-...Overview
----------------------------------------
When creating a search in Search Kit, the list of tag names to select does not populate when the Contact Tag entity is chosen and a condition of Tag Name "Is One Of"
Reproduction steps
----------------------------------------
1. Make sure that you have a Contact Tag with which to test (which can be set up via **Contacts >> Manage Tags >> Add Tag).
1. Go to **Search Kit** and click **New Search**
2. Make sure that the primary entity is *Contact*, then click **+Entity** and select **Contact Tags**
3. Under the *Contact Tags* entity, click **Add Condition** and select **Tag Name** and **Is One Of**
4. When you click in the select box to select the tag names, however, there are no drop down options nor auto-complete selects as you start typing.
Current behaviour
----------------------------------------
When you add a Contact Tag entity in Search Kit, and include a condition that uses "Is One Of" to limit the tag names, a list of those available tag names does not appear. While the features does still work if you type the full and exact name of the tag into the list, that shouldn't be necessary.
![Selection_076](/uploads/96c85e6ba9db93533b726f7bfa414c20/Selection_076.png)
*Note that in this photo, I am searching for a tag named "contact tag 1" that does not appear when typed into the text box, nor do any other options show before typing*
Expected behaviour
----------------------------------------
A drop down list of available tag names should appear when `Tag Name Is One Of` is set as the condition, and as you type in the text box the drop down list should filter accordingly.
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.55alpha1https://lab.civicrm.org/dev/core/-/issues/3919User-selected Field Transformations in Search Kit can cause a DB constraint v...2022-10-20T07:30:18ZbrienneUser-selected Field Transformations in Search Kit can cause a DB constraint violation errorOverview
----------------------------------------
Within Search Kit, a user is not always limited to what type of Field Transformation they can use on a particular column, which can result in a DB constraint violation error.
Reproductio...Overview
----------------------------------------
Within Search Kit, a user is not always limited to what type of Field Transformation they can use on a particular column, which can result in a DB constraint violation error.
Reproduction steps
----------------------------------------
1. Go to **Search > Search Kit** and click **NEW SEARCH**
1. Create a Search with *Contributions* as the primary Entity. Name and Save the search.
1. Click **Entity+** to add *Contribution Contacts* as a second Entity
1. Click **Group By** and select **Contact ID**
1. Expand *Field Transformations* and select **Sum** from the drop down menu on the Contact ID column
1. Click **+Add** underneath the highlighted *Compose Search* block, and select **Smart Group**
1. Give the group a title and make sure the *Contact Column* has **Contact ID** selected
1. Go to **Contacts > Manage Groups** and click on **Contacts** in the row of your test Smart Group
1. Got an error "**Fatal error: DB error**".
Current behaviour
----------------------------------------
This issue was discovered when a client set a transformation of "Sum" on the Contact ID field within a Search Kit search with Contributions as the primary entity, Grouped By Contact Id, and then created a Smart Group from that search. When the user went to **Manage Groups** and clicked on **Contacts** next to the Smart Group in question, they received an error screen with a DB constraint violation. Within the ConfigandLog, the error was as follows:
```json
+message: "DB Error: constraint violation"
+userinfo: """
INSERT INTO civicrm_group_contact_cache (contact_id, group_id)\n
SELECT contact_id, group_id FROM civicrm_tmp_e_gccache_bcc919fe8bd625701eed1c8b83638db1\n
GROUP BY contact_id,group_id\n
[nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`client_civi`.`civicrm_group_contact_cache`, CONSTRAINT `FK_civicrm_group_contact_cache_contact_id` FOREIGN KEY (`contact_id`) REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE)]
```
This happened because the the Sum transformation was selected on the Contact ID field, as shown within Search Kit below:
![Selection_068](/uploads/b4c5bfd830ccdcc6e719e698daa02a3e/Selection_068.png)
![Selection_069](/uploads/1e09d9de5bc15ba1a88ebed3b23bc2ce/Selection_069.png)
Expected behaviour
----------------------------------------
Field Transformations on columns that should only return a singe value (i.e. Contact ID) should be restricted so that a user does not inadvertently cause a constraint violation via Search Kit.
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.53.0https://lab.civicrm.org/dev/core/-/issues/3917Incorrect currency displayed for contribution2023-11-23T07:47:00ZKurund JalmiIncorrect currency displayed for contributionCreate a contribution page and set the currency other than default currency.
Confirm and thank you page displays default currency instead of one that's configured.Create a contribution page and set the currency other than default currency.
Confirm and thank you page displays default currency instead of one that's configured.Kurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/3914Missing getRoleNames() method in WordPress System Utility2022-11-01T08:51:34ZBastien HoMissing getRoleNames() method in WordPress System UtilityOverview
----------------------------------------
Some extensions use the `CRM_Core_Config::singleton()->userSystem->getRoleNames()` method, which is not implemented for WordPressOverview
----------------------------------------
Some extensions use the `CRM_Core_Config::singleton()->userSystem->getRoleNames()` method, which is not implemented for WordPresshttps://lab.civicrm.org/dev/core/-/issues/3912Recreate core screens as Search Displays2024-03-01T22:32:39ZwmortadaRecreate core screens as Search DisplaysSee also dev/core#3761 for the SK/FB roadmap.
This is a meta issue for the work required to recreate many core screens using SearchKit and FormBuilder.
These new screens are in one of three locations:
1. Directly in core ([list](#core...See also dev/core#3761 for the SK/FB roadmap.
This is a meta issue for the work required to recreate many core screens using SearchKit and FormBuilder.
These new screens are in one of three locations:
1. Directly in core ([list](#core-replacements)): these screens replace the old screens, and often the old code is removed. There is no option to revert to the old versions.
2. In the [CiviCRM Administration UI](https://github.com/civicrm/civicrm-core/tree/master/ext/civicrm_admin_ui) extension ([list](#adminui)): these screens replace the old screens but administrators can either disable the extension, or disable individual screens (by removing the URL in FormBuilder). These will eventually become the standard screens and old code removed - but need a bit more testing and verification.
3. In the [CiviCRM Search UI](https://github.com/civicrm/civicrm-core/tree/master/ext/civicrm_search_ui) extension ([list](#searchui)): these screens don't have the full functionality of the screens they will eventually replace. In some cases, new features in SK are needed before they can fully replace existing screens. They are still useful and are a basis for further development. These may eventually migrate into AdminUI.
We welcome contributions from anyone who wants to get involved with this. If you need any help getting started, ask in the \~AdminUI channel on Mattermost.
It builds on the work started by Coleman to create the [CiviCRM Administration UI](https://github.com/civicrm/civicrm-core/tree/master/ext/civicrm_admin_ui) extension. Many more screens were created during the Manchester Sprint in October 2022.
Notes:
1. Join the \~AdminUI channel on Mattermost.
2. If you want to work on any of these, please add your name to the item and keep it updated as work progresses.
3. Look at the screens that have already been converted and try to follow a similar format.
4. The aim is to include all the functionality of the existing screens but without twisting SK in knots to exactly reproduce an existing screen.
5. Each screen will have at least three files: `.aff.html` and `.aff.json` copied from the `<civicrm.files>/ang` directory and `.mgd.php` exported from API Explorer.
6. If you can't reproduce some aspect of an existing screen, create a WIP (Work in Progress) PR and note it below. Someone else may know how to do that, or it may need a new feature adding to SK.
7. Some people found creating the PR harder than creating the new screen. We don't want that to be a barrier to getting these screens converted so if you don't want to create the PR, just [email me](mailto:aidan.saunders@squiffle.uk?subject=%22AdminUI%22) with the 3 files to and I'll do the PR.
8. There are more screens to do than those below. If you want to do something else, please add it to this page.
## AdminUI pages
| Form | URL | Status | PR | Who | Notes |
|------|-----|--------|----|-----|-------|
| Profiles | `civicrm/admin/uf/group` | Merged | [24715](https://github.com/civicrm/civicrm-core/pull/24725) | Alain | |
| Location Types | `civicrm/admin/locationType` | Merged | [24722](https://github.com/civicrm/civicrm-core/pull/24722) | @wmortada | |
| Financial Types | `civicrm/admin/financial/financialType` | Submitted | [24720](https://github.com/civicrm/civicrm-core/pull/24720) | Nicolas | |
| Financial Accounts | `civicrm/admin/financial/financialAccount` | Merged | [24730](https://github.com/civicrm/civicrm-core/pull/24730) | Dave J | |
| Relationship Types | `/civicrm/admin/reltype` | Merged | [24709](https://github.com/civicrm/civicrm-core/pull/24709) | Damilare | |
| Grant Status Options | `/civicrm/admin/options/grant_status` | Submitted | [24729](https://github.com/civicrm/civicrm-core/pull/24729) | Damilare | |
| Grant Type | `/civicrm/admin/options/grant_type` | Submitted | [24729](https://github.com/civicrm/civicrm-core/pull/24729) | Damilare | |
| Option Values | `civicrm/admin/options` | Blocked | | Patrick | To be used for all option values |
| Import/Export Mappings | civicrm/admin/mapping | Submitted | [28509](https://github.com/civicrm/civicrm-core/pull/28509) | @pradeep | |
| Label Formats | civicrm/admin/labelFormats | Done | [28513](https://github.com/civicrm/civicrm-core/pull/28513) | @dewymercerais | |
| Manage Premiums | civicrm/admin/contribute/managePremiums | Submitted | [28540](https://github.com/civicrm/civicrm-core/pull/28540) | @AllenShaw | |
| Personal Campaign Pages | civicrm/admin/pcp | Done | [29541](https://github.com/civicrm/civicrm-core/pull/29541) | @kcristiano | |
| Print Page (PDF) Formats | civicrm/admin/pdfFormats | done | [28520](https://github.com/civicrm/civicrm-core/pull/28520) | @usha.makoa | |
| Settings - SMS Provider | civicrm/admin/sms/provider | Submitted | [28512](https://github.com/civicrm/civicrm-core/pull/28512) | @pradeep | |
| Event Templates | civicrm/admin/eventTemplate | Submitted | [28514](https://github.com/civicrm/civicrm-core/pull/28514) | @pradeep | |
| Event Name Badge Layouts | civicrm/admin/badgelayout | Done | [28518](https://github.com/civicrm/civicrm-core/pull/28518) | @dewymercerais | |
| Settings - Payment Processor | civicrm/admin/paymentProcessor | done | | | |
| Headers, Footers, and Automated Messages | civicrm/admin/component | | [28484](https://github.com/civicrm/civicrm-core/pull/28484) | @kcristiano @19ATF72 | |
| Message Templates | civicrm/admin/messageTemplates | done | | | |
| Membership Types | civicrm/admin/member/membershipType | WIP | | @ayduns | |
| Membership Status Rules | civicrm/admin/member/membershipStatus | Done | [28480](https://github.com/civicrm/civicrm-core/pull/28480) | @usha.makoa | |
| Campaigns | the search doesn't exist in core (the dashboard does and is already in SearchUI) | abandonned | | | |
| Discounts | civicrm/cividiscount | | | Coleman | [CiviDiscount MR](https://lab.civicrm.org/extensions/cividiscount/-/merge_requests/284 "Convert all tables to SearchKit displays") |
| Dedupe Exceptions | civicrm/dedupe/exception | | | | see [comment](https://github.com/civicrm/civicrm-core/pull/25522#issue-1575266329) |
| Contact Types | civicrm/admin/option/subtype | done | | | |
| Joblogs | civicrm/admin/joblog | Merged | [26732](https://github.com/civicrm/civicrm-core/pull/26732) | @ayduns | |
| Mail Accounts | civicrm/admin/mailSettings | Merged | [26733](https://github.com/civicrm/civicrm-core/pull/26733) | @ayduns | Does not yet support oauth-client method to add mail accounts |
| Participant Status | civicrm/admin/participant_status | | | @ayduns | see [conditional in-place edit](https://lab.civicrm.org/dev/core/-/issues/4406 "SearchKit: make 'inplace edit' conditional") |
| Payment Processor Type | civicrm/admin/paymentProcessorType | | | | Doesn't exist in menus. Don't think this is needed as processor types added by extensions, not UI. |
| Date Preferences | civicrm/admin/setting/preferences/date | | [28483](https://github.com/civicrm/civicrm-core/pull/28483) | @pradpnayak | |
| ACL Assign Users to Roles | civicrm/admin/acl/entityrole | Merged | [26925](https://github.com/civicrm/civicrm-core/pull/26925) | @ayduns | |
More challenging:
| Form | URL | Status | PR | Who | Notes |
|------|-----|--------|----|-----|-------|
| Message Templates | civicrm/admin/messageTemplates | On hold | [24981](https://github.com/civicrm/civicrm-core/pull/24981) | @ayduns | There is a new Message Admin Core extension. See comments on PR |
| Option Groups/Values | civicrm/admin/options | In progress | [25387](https://github.com/civicrm/civicrm-core/pull/25387) | @colemanw | |
| Schedule Reminders | civicrm/admin/scheduleReminders | Merged | [26896](https://github.com/civicrm/civicrm-core/pull/26896) | @colemanw | |
| Settings - Scheduled Jobs | civicrm/admin/job | Merged | [26060](https://github.com/civicrm/civicrm-core/pull/26060) | @ayduns | |
| Price Sets | civicrm/admin/price | WIP | | @ayduns | |
| Price set fields | civicrm/admin/price/field | WIP | | @ayduns | |
| Manage Contribution Pages | civicrm/admin/contribute | Merged | [24937](https://github.com/civicrm/civicrm-core/pull/24937) | @ayduns | |
| Manage Events | civicrm/event/manage | Merged | [28476](https://github.com/civicrm/civicrm-core/pull/28476) | @alainb (Alain Benbassat) | |
| CiviCRM Reports | civicrm/report/list | WIP - need PR (see wip [28511](https://github.com/civicrm/civicrm-core/pull/28511)) to add a pseudo field with components list | [28480](https://github.com/civicrm/civicrm-core/pull/28480) | @usha.makoa | |
| Create New Report from Template | civicrm/admin/report/template/list | | | | The Report Templates Entity lacks in SK |
| Manage Groups | civicrm/group | Merged | [26261](https://github.com/civicrm/civicrm-core/pull/26261) | @samuelsov | |
Other Option Values (when main Option Values is done):
| Form | URL | Status | PR | Who | Notes |
|------|-----|--------|----|-----|-------|
| Accepted Credit Cards Options | civicrm/admin/options/accept_creditcard | | | | |
| Activity Type Options | civicrm/admin/options/activity_type | | | | |
| Addressee Type Options | civicrm/admin/options/addressee | | | | |
| Communication Style Options | civicrm/admin/options/communication_style | | | | |
| Custom Search Options | civicrm/admin/options/custom_search | | | | |
| Email Greeting Type Options | civicrm/admin/options/email_greeting | | | | |
| From Email Address Options | civicrm/admin/options/from_email_address | | | | |
| Gender Options | civicrm/admin/options/gender | | | | |
| Individual contact suffixes Options | civicrm/admin/options/individual_suffix | | | | |
| Instant Messenger (IM) screen-names Options | civicrm/admin/options/instant_messenger_service | | | | |
| Languages Options | civicrm/admin/options/languages | | | | |
| Mobile Phone Providers Options | civicrm/admin/options/mobile_provider | | | | |
| Payment Methods Options | civicrm/admin/options/payment_instrument | | | | |
| Phone Type Options | civicrm/admin/options/phone_type | | | | |
| Postal Greeting Type Options | civicrm/admin/options/postal_greeting | | | | |
| Preferred Communication Method Options | civicrm/admin/options/preferred_communication_method | | | | |
| Soft Credit Types Options | civicrm/admin/options/soft_credit_type | | | | |
| Website Type Options | civicrm/admin/options/website_type | | | | |
| Word Replacements | civicrm/admin/options/wordreplacements | | | | |
## SearchUI
These searches should be placed in the SearchUI extension rather than AdminUI. When the new search fully replaces the functionality of the core page it can override the existing URL. Otherwise, create an alternate URL and place a menu entry under Experimental.
<table>
<tr>
<th>Form</th>
<th>URL</th>
<th>Status</th>
<th>PR</th>
<th>Who</th>
<th>Notes</th>
</tr>
<tr>
<td>Find Contacts</td>
<td>civicrm/contact/search</td>
<td>Merged</td>
<td>
[26381](https://github.com/civicrm/civicrm-core/pull/26381)
</td>
<td>
@samuelsov
</td>
<td>
</td>
</tr>
<tr>
<td>Advanced Search</td>
<td>civicrm/contact/search/advanced</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>it doesn't make sense since we can create appropriate searches with SK</td>
</tr>
<tr>
<td>Find Contributions</td>
<td>civicrm/contribute/search</td>
<td>Merged, needs more work</td>
<td>
[26746](https://github.com/civicrm/civicrm-core/pull/26746)
</td>
<td>
@ayduns
</td>
<td>
</td>
</tr>
<tr>
<td>Find Mailings</td>
<td>civicrm/mailing civicrm/mailing/browse/scheduled civicrm/mailing/browse/archived civicrm/mailing/browse/unscheduled</td>
<td>WIP</td>
<td>
[26532](https://github.com/civicrm/civicrm-core/pull/26532)
</td>
<td>
@samuelsov
</td>
<td>
</td>
</tr>
<tr>
<td>Find Memberships</td>
<td>civicrm/membership/search</td>
<td>Submitted</td>
<td>
[29064](https://github.com/civicrm/civicrm-core/pull/29064)
</td>
<td>
@jitendra
</td>
<td>
</td>
</tr>
<tr>
<td>Find Participants</td>
<td>civicrm/event/search</td>
<td>Done</td>
<td>
[28477](https://github.com/civicrm/civicrm-core/pull/28477)
</td>
<td>
@breheret
</td>
<td>
it's staying :
- Add the 'fee level' field which I was unable to put
- Add custom group fields linked to an event/participant
- Add actions that are not native to Searchkit:
- Cancel registration
- Email - send now
- Group - add contacts
- Group - create smart group
- Name badges - print
- PDF letter - print for participants
- Participant status - change
- Print selected rows
- Update multiple participants
</td>
</tr>
<tr>
<td>Find Activities</td>
<td>civicrm/activity/search</td>
<td>Done</td>
<td>
[28480](https://github.com/civicrm/civicrm-core/pull/28480)
</td>
<td>
@usha.makoa
</td>
<td>
</td>
</tr>
<tr>
<td>Cases Dashboard</td>
<td>civicrm/case</td>
<td>Done</td>
<td>
</td>
<td>
@ayduns and @simon.hermann
</td>
<td>
https://lab.civicrm.org/extensions/casesummary/-/merge_requests/3
</td>
</tr>
<tr>
<td>Single Case View</td>
<td>civicrm/contact/view/case</td>
<td>WIP</td>
<td>
</td>
<td>
@simon.hermann
</td>
<td>
</td>
</tr>
</table>
## Core replacements
| Form | URL | Status | PR | Who | Notes |
|------|-----|--------|----|-----|-------|
| Contact summary: Notes tab | civicrm/note | Merged | [27610](https://github.com/civicrm/civicrm-core/pull/27610) | @colemanw | |
| Contact summary: Relationships tab | civicrm/contact/view/rel | Merged | [27701](https://github.com/civicrm/civicrm-core/pull/27701) | @colemanw | |
| Campaign Dashboard | civicrm/campaign, civicrm/petition, civicrm/survey | Merged | [27271](https://github.com/civicrm/civicrm-core/pull/27271) | @colemanw | |
| Contact summary: Membership tab | civicrm/ | Merged | [28810](https://github.com/civicrm/civicrm-core/pull/28810) | @jitendra | |
| Contact summary: Event tab | civicrm/ | Submitted | [29570](https://github.com/civicrm/civicrm-core/pull/29570)| @guyiac | |https://lab.civicrm.org/dev/core/-/issues/3911civix upgrade fails on afform extension with mgd mixin incompatible version e...2022-10-21T07:23:20Zaydunsaidan.saunders@squiffle.ukcivix upgrade fails on afform extension with mgd mixin incompatible version errorOn master, go to `civicrm/ext/afform/core` run `civix upgrade`
Error:
```
General upgrade
===============
In Mixlib.php line 147:
Received incompat...On master, go to `civicrm/ext/afform/core` run `civix upgrade`
Error:
```
General upgrade
===============
In Mixlib.php line 147:
Received incompatible version (expected="mgd-php@1.1.0", actual="mgd-php@1.0.0")
```
`info.xml` includes:
```
<mixin>mgd-php@1.1.0</mixin>
```tottentottenhttps://lab.civicrm.org/dev/core/-/issues/3910afform: Support url-params and other config options for Values in Submmission...2022-11-03T17:23:57ZAllenShawafform: Support url-params and other config options for Values in Submmission formsPer conversations with @kurund , @totten , and @colemanw at the 2022 Manchester sprint:
Submission forms currently offer configuration of Values as a way to ensure a certain value is submitted for a given property of the submitted entit...Per conversations with @kurund , @totten , and @colemanw at the 2022 Manchester sprint:
Submission forms currently offer configuration of Values as a way to ensure a certain value is submitted for a given property of the submitted entity, without displaying a field to the form user. Currently it's only possible to specify a static value for each Value. This issue covers work to increase this functionality by allowing the specification of more options for each value. As a start, we're aiming to support these: a default value; and a value defined by URL parameter (overriding the default value). Future efforts may allow for defining a mechanism for on-page calculation of the value; specifying that the submitted value should not be applied if updating an existing entity (could be useful e.g. for Source field); and more.
## New attributes:
At the start we aim to support only these:
- `default`: the default value
- `urlparam`: the name of a URL parameter from which the value can be taken (which value, if given, will override the `default` value)
We're also aiming to make decisions now which would facilitate adding other attributes in the future.
## UI changes:
- Move the Values section out of the "pallette" pane in the left, to a new "Values" tab in the "canvas" pane on the right:
![values](/uploads/4a5fb8bd7c29c136ddb18ebc191e7201/values.png)
- For each defined Value, support configuration of various attributes, probably through a pop-up accessed through a gear icon, similar to that already in use under for fields under the Fields tab:
![gear2](/uploads/6c850f34b123efd4651720ff50ef30e1/gear2.png)
Rationale:
- We currently have the "Values" configuration appearing at the top of the left-side "pallette" pane. This leaves limited space for configuration options on each Value, whereas there will be more room for that in the "canvas" pane.
- It would make for a more consisten user experience to treat the left-side "pallette" only as a pool of available entity properties (fields), and the right-side "canvas" as the place for configuring those properties which one has selected for use in the form.
## Form storage/schema changes:
Values are currently stored in the form markup within the `data` attribute of each `<af-entity>` tag; e.g. this line indicates that the do_not_email field should be forced to "yes":
```
<af-entity data="{contact_type: 'Individual', do_not_email: '1'}" type="Contact" name="Individual1" label="Individual 1" actions="{create: true, update: true}" security="RBAC" />
```
To store these additional config options, we make some changes to this schema:
- Values will be stored as an `<af-field>` element within the `<af-entity>` container, so that the above-mentioned `<af-entity>` tag would be represented like so:
```
<af-entity data="{contact_type: 'Individual'}" type="Contact" name="Individual1" label="Individual 1" actions="{create: true, update: true}" security="RBAC">
<af-field name="do_not_email" default="1" />
</af-entity>
```
Rationale:
- The `<af-field>` tag is appropriate here because these "entity properties" are in fact fields -- though they won't be presented as _form_ fields, they will be submitted as _API_ fields (consider the "getFields" api action).
- Storing as attributes of an `<af-field>` tag is an alternative to cramming arrays of increasing complexity into the `data` attribute of the `<af-entity>` tag, and this alternative facilitates easier validation.
- When parsing the stored form markup for display, it should be pretty easy to identify `<af-field>` tags within an `<af-entity>` container, then avoid formatting them as displayed form fields, and ensure they're attributed to the correct entity upon submission.https://lab.civicrm.org/dev/core/-/issues/3908Permission to view Subscription History in SearchKit2022-11-22T09:40:51ZwmortadaPermission to view Subscription History in SearchKitOverview
----------------------------------------
I've created a saved search using SearchKit to show contacts that have recently signed up to a mailing list. This search works fine for users with full administer permissions to CiviCRM ...Overview
----------------------------------------
I've created a saved search using SearchKit to show contacts that have recently signed up to a mailing list. This search works fine for users with full administer permissions to CiviCRM but doesn't show any results for users with more limited permissions to CiviCRM.
Reproduction steps
----------------------------------------
1. Create a search using SearchKit that uses the Contact Subscription Histories entity - see below
2. View the search as a user with access to CiviCRM but not the 'administer CiviCRM' permission
![image](/uploads/7ec66c8b8ae197ebb4c6d0c5a847cb36/image.png)
Current behaviour
----------------------------------------
The results don't load for the user with limited permissions. Note that the column headings are also missing.
![image](/uploads/aa2eadeac7872d9ff9432d0c6fcb0d4f/image.png)
Expected behaviour
----------------------------------------
The results should load
![image](/uploads/6a430f08519863c1cf05fb8f19b06bf8/image.png)
Environment information
----------------------------------------
CiviCRM 5.56.alpha1https://lab.civicrm.org/dev/core/-/issues/3906FormBuilder URL Filter dropdown with multiple values are only filterd with fi...2022-10-21T07:28:15ZdavidFormBuilder URL Filter dropdown with multiple values are only filterd with first valueOverview
----------------------------------------
If a URL filter with multiple values is used in formbuilder, all values are picked up and shown in the multiselect, but the search is only filterd with the first value.
e.g. /civicrm/for...Overview
----------------------------------------
If a URL filter with multiple values is used in formbuilder, all values are picked up and shown in the multiselect, but the search is only filterd with the first value.
e.g. /civicrm/forms/fzt-suche/#?event_type_id=2,3,4
![Unbenannt](/uploads/10a0f5f22f4acd9aaa2a2912743ae71a/Unbenannt.JPG)
Environment information
----------------------------------------
* __Browser:__ Firefox 105
* __CiviCRM:__ 5.54.0
* __PHP:__ 7.3
* __CMS:__ Drupal 7https://lab.civicrm.org/dev/core/-/issues/3905Need to increase data size for 'data' column on 'civicrm_job_log' table2022-10-12T13:27:08ZyashodhaNeed to increase data size for 'data' column on 'civicrm_job_log' tableOverview
----------------------------------------
Currently _data_ column of the _civicrm_job_log_ table is of data type TEXT. This is sufficient for running most jobs. However we have a some comprehensive log for mailchimp sync extensio...Overview
----------------------------------------
Currently _data_ column of the _civicrm_job_log_ table is of data type TEXT. This is sufficient for running most jobs. However we have a some comprehensive log for mailchimp sync extension and it would throw errors when running the job.
`INSERT INTO civicrm_job_log (domain_id , job_id , name , command , ...", "1406 ** Data too long for column 'data' at row 1`
Proposed behaviour
----------------------------------------
The Proposal is to change the data type of the _data_ column of the _civicrm_job_log_ table to LONGTEXT instead of TEXT.5.56.0yashodhayashodha