Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-10-20T07:16:47Zhttps://lab.civicrm.org/dev/core/-/issues/3928Additional languages 'en_IN', 'en_SA', en_NZ, en_SG2022-10-20T07:16:47ZeileenAdditional languages 'en_IN', 'en_SA', en_NZ, en_SGCurrently in our database we have languages for
![image](/uploads/bdc8b1342d339599954b3c4f77ba00c3/image.png)
I think we should add additional variants for English where we know that English is the or an official language - as they ha...Currently in our database we have languages for
![image](/uploads/bdc8b1342d339599954b3c4f77ba00c3/image.png)
I think we should add additional variants for English where we know that English is the or an official language - as they have formatting associated with them - e.g both NZ & India use dd/mm/yyyy as the date format.
We could likely only do on new installs
I'm not imagining being incredibly thorough but these ones popped uphttps://lab.civicrm.org/dev/core/-/issues/4567Address CiviCRM Mailing table complexity - make queries easier & data more pr...2023-09-27T01:01:44ZeileenAddress CiviCRM Mailing table complexity - make queries easier & data more prunableIssue
----------------------------------------
1) on large databases the civicrm_mailing screen is slow-to-impossible to load as the query cannot get the status of the mailing from the civicrm_mailing table and must do a many-to-one joi...Issue
----------------------------------------
1) on large databases the civicrm_mailing screen is slow-to-impossible to load as the query cannot get the status of the mailing from the civicrm_mailing table and must do a many-to-one join with DISTINCT to get the status of the mailing. This is not well suited to paging because of the many to 1 so many more records are retrieved than are needed
2) the mailing job records are really just a form of queue management. ie their logic is temporary and related to active sending. Once the send has happened it should be possible to delete them - but the mailing_job records are the only way the civicrm_mailing_event_queue table links to Bounce entries
3) the verp hash needs to be of limited length. While efforts were made in the past to reduce the length the ids of the values in the hash can get large enough to start to blow it up. It really doesn't need to have a queue_id AND a job_id along with the hash
4) complexity complexity complexity. The mailing_job has fields like 'parent_id' and job_type' = 'child'. It's just confusing as well as bloated and unnecessary to refer to it outside it's 'real' function - tracking the actual sending
5) I have some historical nervousness about the civimail system sending out stuff it shouldn't - I feel like great transparency about loading from civicrm_mailing & then processing would be possible with
Proposal
----------------------------------------
**Stage 1**
1) adding the field mailing_id to civicrm_mailing_event_queue
2) altering the verp calculation to stop including the job_id on new mailings(we would need to handle it's presence for a while in bounce processing)
3) altering the job_id index in civicrm_event_queue to set to NULL on delete
4) add columns for status_id, start_date, end_date to civicrm_mailing, update as appropriate.
5) add a batch script to allow people to populate the columns above in their own time.
6) use more efficient queries on sites that have fully migrated (eg. conditional on status_id being populated for all mailings then the civicrm_mailing dashboard could use a more performant query)
<details>
<summary>Handy query for getting row counts in these tables</summary>
```
SELECT 'civicrm_mailing' as mailing_table, COUNT(*) as number_rows
FROM civicrm_mailing
UNION
SELECT 'civicrm_mailing_job' as mailing_table, COUNT(*) as number_rows
FROM civicrm_mailing_job
UNION
SELECT 'civicrm_mailing_event_queue' as mailing_table, COUNT(*) as number_rows
FROM civicrm_mailing_event_queue
UNION
SELECT 'civicrm_mailing_event_bounce' as mailing_table, COUNT(*) as number_rows
FROM civicrm_mailing_event_bounce
UNION
SELECT 'civicrm_mailing_event_confirm' as mailing_table, COUNT(*) as number_rows
FROM civicrm_mailing_event_confirm
UNION
SELECT 'civicrm_mailing_event_delivered' as mailing_table, COUNT(*) as number_rows
FROM civicrm_mailing_event_delivered
UNION
SELECT 'civicrm_mailing_event_forward' as mailing_table, COUNT(*) as number_rows
FROM civicrm_mailing_event_forward
UNION
SELECT 'civicrm_mailing_event_opened' as mailing_table, COUNT(*) as number_rows
FROM civicrm_mailing_event_opened
UNION
SELECT 'civicrm_mailing_event_reply' as mailing_table, COUNT(*) as number_rows
FROM civicrm_mailing_event_reply
UNION
SELECT 'civicrm_mailing_event_subscribe' as mailing_table, COUNT(*) as number_rows
FROM civicrm_mailing_event_subscribe
UNION
SELECT 'civicrm_mailing_event_trackable_url_open' as mailing_table, COUNT(*) as number_rows
FROM civicrm_mailing_event_trackable_url_open
UNION
SELECT 'civicrm_mailing_event_unsubscribe' as mailing_table, COUNT(*) as number_rows
FROM civicrm_mailing_event_unsubscribe
```
</details>
**Stage 2**
1) deprecate the field civicrm_mailing.is_completed
6) set up some processes around deleting mailing_job records once no longer needed.
8)remove the interim queries for the partially migrated mailing records
*Stage 3*
7) eventually the civicrm_mailing.is_completed column could go
8) stop handling the job id in the verp (probably after a few years)
9) add self-cleanup on civicrm_mailing_job records (how would we ideally clean them up once completed?)
10) migrate mailing_job to our queue system
**Technical notes**
The way in which mailing events link back to the mailing looks like (eg. for bounce)
- civicrm_mailing_event_bounce.event_queue_id => civicrm_mailing_event_queue.id
- civicrm_mailing_event_queue.job_id => civicrm_mailing_job.id
- civicrm_mailing_job.mailing_id => civicrm_mailing.id
A similar pattern is followed for
civicrm_mailing_event_delivered
civicrm_mailing_event_forward
civicrm_mailing_event_opened
civicrm_mailing_event_reply
civicrm_mailing_event_subscribe
civicrm_mailing_event_confirm links back through civicrm_mailing_event_subscribe
**Still confusing**
How do civicrm_mailing_recipients & civicrm_mailing_event_queue relate to each other?**** UPDATE - it seems like mailing_event_recipients doesn't add much extra over civicrm_mailing_event_queue but it is used to serve 2 purposes
1) it fulfills the role of a temp table when generating the entries for civicrm_mailing_queue
2) it is used for include / exclude queries - this could be done by event_queue too but perhaps would be more blocking
It does feel like it doesn't add anything that just using queue wouldn't, if we pointed the various queries at queue
What is the status with this historic evilness https://lab.civicrm.org/dev/core/-/issues/4385https://lab.civicrm.org/dev/backdrop/-/issues/66Admin role not granted all Civi permissions on install.2022-10-21T07:36:12ZbgmAdmin role not granted all Civi permissions on install.*Created by: jenlampton*
After running the Civi Installer, I am redirected to the 'civicrm/setup' where the first message says "Backdrop user permissions have been automatically set - giving anonymous and authenticated users access to p...*Created by: jenlampton*
After running the Civi Installer, I am redirected to the 'civicrm/setup' where the first message says "Backdrop user permissions have been automatically set - giving anonymous and authenticated users access to public CiviCRM forms and features. We recommend that you review these permissions to ensure that they are appropriate for your requirements".
However, when I navigate to the permissions matrix, the "Administrative role" is not granted all CiviCRM permissions. When a new module is installed that provides permissions, this role is granted all permissions available, so that an administrator does not need to go through and check all the boxes. (This role is usually for developers, or people who setting up the site for others to use).
<img width="2504" alt="Screen Shot 2021-05-25 at 10 32 50 AM" src="https://user-images.githubusercontent.com/397895/119542675-a9418000-bd44-11eb-874b-a764281d824e.png">
Civi creates a LOT of new permissions, so it's more painful to correct this issue with Civi permissions than for pretty much any other module.https://lab.civicrm.org/dev/core/-/issues/5106Admin UI extension breaks contact summary if CiviMember extension is disabled2024-03-27T15:25:42ZKurund JalmiAdmin UI extension breaks contact summary if CiviMember extension is disabledContact summary results in fatal error if Admin UI extension is enabled and CiviMember extension is disabled.
```bash
Civi\API\Exception\NotImplementedException: API (Membership, get) does not exist (or the extension it belongs to is no...Contact summary results in fatal error if Admin UI extension is enabled and CiviMember extension is disabled.
```bash
Civi\API\Exception\NotImplementedException: API (Membership, get) does not exist (or the extension it belongs to is not enabled). in Civi\API\Request::create() (line 51 of /var/www/html/sites/all/modules/civicrm/Civi/API/Request.php).
```https://lab.civicrm.org/dev/core/-/issues/4693Admin UI: Maturation model2023-10-20T07:49:58ZtottenAdmin UI: Maturation model(**This issue is `type:exploration`. It is intended to discuss/explain/invite comment. It is not a singular action-item for implementation. The discussion may lead to other more concrete things. We can close the discussion when the appro...(**This issue is `type:exploration`. It is intended to discuss/explain/invite comment. It is not a singular action-item for implementation. The discussion may lead to other more concrete things. We can close the discussion when the approach is agreed; it doesn't need every possible follow-up task.**)
Context
-------
* Much of CiviCRM UI was originally built with one particular architecture. (Key concepts: `HTML_Quickform`, `Smarty`, `Selector`, `StateMachine`.) (Short-hand: "Civi-Quickform" or "CQF")
* We're in the middle of a multiyear project to convert large swaths of the CiviCRM UI to another architecture. (Key concepts: APIv4, Form Builder, SearchKit, Angular, Managed Entities.) (Short-hand: "SearchKit/FormBuilder" or "SKFB")
* The "Admin UI" extension (`civicrm_admin_ui`) is a bundle of SKFB screens (which replace CQF screens). The bundle currently provides ~20 screens.
Question
--------
As the screens in "Admin UI" mature, how do we roll them out to the user-base?
Opinions/Thoughts
--------
* The great thing about "Admin UI" extension is this: we can "move fast and break things" while keeping the ship "pointed in one direction" and also allowing "real-world testing".
* For site-builders, it's an opt-in that doesn't interfere with their existing screens. They can try new-screens and easily switch back to the familiar screens.
* For developers, it lowers the effort to get started -- you don't need perfection. You can do a first-pass in February -- it's a "good/decent" screen with a couple quirks or missing-features. You can take some time to get feedback or think-through the quirks. Then in May, you come back and make a better version.
* `civicrm_admin_ui` is accumulating a set of viable replacements.
* But they're not *all* equally viable.
* There are still many screens that don't have replacements -- screens which will need their own maturation time.
* There was some discussion about whether we're ready to enable `civicrm_admin_ui` by default. Some options are:
* __No, keep it disabled by default__ (until the entire UI has been re-done). But then a lot users don't get the benefit of perfectly good (*improved*) screens. And developers still have to maintain both the old+new variant of each.
* __Yes, enable it by default__ (while conversions are on-going). But then it puts more pressure for new screens to be perfect. You can't merge a replacement unless you've addressed all the features of the original.
Proposal
--------
Replacement-screens go through process of incubation/graduation, mediated by `civicrm_admin_ui`.
1. __Incubation__: When a new replacement is written in SKFB, put it in `civicrm_admin_ui`. Allow 3-9 months for additional development, real-world usage, etc.
2. __Graduation__: When the replacement is sufficiently mature, move it to a standard/universal folder. (Ex: A new CiviContribute SKFB screen will go to `ext/civi_contribute/`.)
3. __Cleanup__: Three months after graduation, delete the old screen.https://lab.civicrm.org/dev/core/-/issues/4255AdminUI breadcrumb links are confusing and unhelpful2023-05-02T07:14:25ZlarsssandergreenAdminUI breadcrumb links are confusing and unhelpfulOverview
----------------------------------------
The breadcrumb links for AdminUI pages are incorrect and confusing for users.
Current behaviour
----------------------------------------
For example for profile fields, the breadcrumb li...Overview
----------------------------------------
The breadcrumb links for AdminUI pages are incorrect and confusing for users.
Current behaviour
----------------------------------------
For example for profile fields, the breadcrumb links are:
`Home › CiviCRM › Admin › FormBuilder › Edit Form › Profile Fields`
If a user clicks the breadcrumb link for Profile Fields, they get all profile fields for all profiles, not just the profile fields for their profile. They also cannot go back to the main profiles page or the settings for the profile they are editing the fields for.
This is the same for custom fields and other AdminUI pages.
Expected behaviour
----------------------------------------
The breadcrumb links should be:
`Home › CiviCRM › Admin › Profiles › PROFILENAME › Profile Fields`
Clicking the breadcrumb links should lead to the expected pages.
Environment information
----------------------------------------
dmasterhttps://lab.civicrm.org/dev/core/-/issues/4371AdminUI: Find contact should follow the setting "Search Primary Details Only"2023-06-20T13:19:52ZsamuelsovAdminUI: Find contact should follow the setting "Search Primary Details Only"The new "Find Contacts" shipped with Admin UI search only for Primary Email but we should take he setting "Search Primary Details Only" into account the way it is without AdminUI :
![ksnip_20230616-141644](/uploads/9441fba97690e6df4bc88...The new "Find Contacts" shipped with Admin UI search only for Primary Email but we should take he setting "Search Primary Details Only" into account the way it is without AdminUI :
![ksnip_20230616-141644](/uploads/9441fba97690e6df4bc883613ac9eb27/ksnip_20230616-141644.png)samuelsovsamuelsovhttps://lab.civicrm.org/dev/core/-/issues/4513AdminUI: In 5.64 new basic search shows group names to users who, according t...2024-02-05T21:58:15ZAndy ClarkAdminUI: In 5.64 new basic search shows group names to users who, according to ACLs, don't have access to those groupsThe new basic search ('Find Contacts') in 5.64 that uses SK correctly restricts visibility of contacts for users with access limited by ACLs, but still shows the group names that those users should not be able to see. If the user then se...The new basic search ('Find Contacts') in 5.64 that uses SK correctly restricts visibility of contacts for users with access limited by ACLs, but still shows the group names that those users should not be able to see. If the user then searches those groups, they appear to have zero contacts which is confusing. Users with access limited by ACLs should only be able to see those group names that they have access to. Disabling the AdminUI extension and restoring the old basic search solves the problem - those groups are not then displayed.colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/4607AdminUI: Scheduled Jobs Log: missing name of job and Execute Now button when ...2023-09-23T05:00:19ZcomposerjkAdminUI: Scheduled Jobs Log: missing name of job and Execute Now button when viewing a single scheduled job logOverview
----------------------------------------
In the newer AdminUI Scheduled Jobs single job log view, the following are missing:
- Name of the job log being viewed.
- `Execute Now` button to run the scheduled job.
Related to issue ...Overview
----------------------------------------
In the newer AdminUI Scheduled Jobs single job log view, the following are missing:
- Name of the job log being viewed.
- `Execute Now` button to run the scheduled job.
Related to issue #3912 and [PR 26060](https://github.com/civicrm/civicrm-core/pull/26060) by @ayduns.
Reproduction steps
----------------------------------------
1. Enable `AdminUI` extension.
1. Go to _CiviCRM > Administer > System Settings > Scheduled Jobs_
1. Select _View joblog_ for a single job.
1. Notice the job name missing and lack of the `Execute Now` button.
Current behaviour
----------------------------------------
AdminUI SearchKit replacement of Scheduled Jobs single job log view **without the job name nor the Execute Now button:**
![AdminUI SearchKit replacement of Scheduled Jobs single job log view](/uploads/f2fae4452c29db11bdfe0d6a19548342/image.png)
Expected behaviour
----------------------------------------
Should include the job name and the `Execute Now` button, assuming the goal is to recreate the existing Scheduled Jobs experience.
Original Scheduled Jobs view of single job log **with job name and Execute Now button:**
![Original Scheduled Jobs view of single job log with Execute Now button](/uploads/65b32b2690569d84eb6bfb646381522d/image.png)
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 59.0.1/Chrome 78.0.3904/Safari 13_
* __CiviCRM:__ 5.65.1
* __PHP:__ 8.0.30
* __CMS:__ WordPress 6.2.2
* __Database:__ MariaDB 10.6.3https://lab.civicrm.org/dev/core/-/issues/4113Afform - Can't display default value for deceased field2023-08-01T20:14:31ZGhost UserAfform - Can't display default value for deceased fieldOverview
----------------------------------------
When you create a Search Kit and want to set a default value to the deceased field in the Form Builder, it doesn't show.
Reproduction steps
----------------------------------------
1. C...Overview
----------------------------------------
When you create a Search Kit and want to set a default value to the deceased field in the Form Builder, it doesn't show.
Reproduction steps
----------------------------------------
1. Create a Search Kit based on Contact and create a Form.
2. In the Form add the 'Is deceased' field into the Form Layout and select a default value. Also add a route to be able to see the Form. See image below:
![image](/uploads/c19e8c240e4c53e1ad662cb30953fbc2/image.png)
3. Go to the Page that you created and you see that the default value is not selected.
![image](/uploads/5c85d8a8dcd614967a9ab67210561f7b/image.png)
Expected behaviour
----------------------------------------
In the created Page the default value should be already selected, which it isnt't the case.
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 109.0.1/Chrome 109.0.5414.120
* __CiviCRM:__ 5.60.alpha1
* __Site:__ [dmaster](https://dmaster.demo.civicrm.org/)https://lab.civicrm.org/dev/core/-/issues/4753Afform - Custom fields of type YesNo (boolean): Defaults not displayed and ch...2024-03-10T20:37:04Zmattwiremjw@mjwconsult.co.ukAfform - Custom fields of type YesNo (boolean): Defaults not displayed and changes not savedTo reproduce set up a simple submission form:
1. Add Individual
2. Add "is_deceased" field (a Yes / No radio field) (optional)
3. Add a contact custom field of type "YesNo" (optional)
Create a contact and set the contact is_deceased = t...To reproduce set up a simple submission form:
1. Add Individual
2. Add "is_deceased" field (a Yes / No radio field) (optional)
3. Add a contact custom field of type "YesNo" (optional)
Create a contact and set the contact is_deceased = true and custom field "YesNo" = true
Load the form with URL parameter eg. #?Individual1=169 to load that contact
See that is_deceased field is set to Yes but the customfield is not set.
Now set the customfield to "No" and submit the form.
Reload the form and see that it did not save the value of the custom field :-(
So two issues:
1. Custom field value is not displayed: It is retrieved via prefill as a bool but the field is added with radios that have values 0,1.
2. Custom field value is not saved: It is converted to int (0 or 1) once submitted whether submitted as "false" or 0.
I've been round and round trying to work out how this should be fixed but have hit a dead end!
The display issue can be "fixed" by either not passing the options to the form or by passing them with true/false instead of 0,1. But the value still doesn't save.
@colemanw Any ideas?https://lab.civicrm.org/dev/core/-/issues/3478Afform - email delivery2023-06-29T15:47:01Zaydunsaidan.saunders@squiffle.ukAfform - email deliveryOverview
----------------------------------------
Add an action to enable scheduled Email Delivery of SearchKit results.
Reports provides settings to enable scheduled Email Delivery of reports. The lack of an option to do the same dete...Overview
----------------------------------------
Add an action to enable scheduled Email Delivery of SearchKit results.
Reports provides settings to enable scheduled Email Delivery of reports. The lack of an option to do the same deters some people from using SearchKit - see https://civicrm.stackexchange.com/q/41966/225
Comments
----------------------------------------
Not a high priority item but noting for parity with Reports functionality.https://lab.civicrm.org/dev/core/-/issues/3453Afform - relationships fill from other entity2022-12-07T01:43:54ZsamuelsovAfform - relationships fill from other entityFollow-up from https://github.com/civicrm/civicrm-core/pull/23296#issuecomment-1119014194
Let say we want to do a form that allow an employer to update :
- the main contact of the organization
- all the employees
Thanks to https://lab....Follow-up from https://github.com/civicrm/civicrm-core/pull/23296#issuecomment-1119014194
Let say we want to do a form that allow an employer to update :
- the main contact of the organization
- all the employees
Thanks to https://lab.civicrm.org/dev/core/-/issues/3117 it's now possible to do a form that will allow to create in one step :
- the organization
- the main contact as Individual 1 with a relationship between the organization and Individual 1
- the employees as Individual 2 with a relationship between the organization and Invividual 2 (which is multiple)
However, there is no way to have an edit mode for such a form. It's possible to add the organization id as an argument but we also need a way to pre-populate the main contacts / list of employees as an option based on the relationships definition.colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/4871Afform - Reset button click does not refresh the search result table with emp...2023-12-20T19:19:39ZjitendraAfform - Reset button click does not refresh the search result table with empty filtersTo replicate:
- Create a search kit to search for contacts.
- Add a form builder with a filter input Display Name. Also enable Reset button.
- View the search form and search for display name:
![image](/uploads/61162fab96405b82341a39ddb...To replicate:
- Create a search kit to search for contacts.
- Add a form builder with a filter input Display Name. Also enable Reset button.
- View the search form and search for display name:
![image](/uploads/61162fab96405b82341a39ddb461d9d6/image.png)
- Click Reset and search again.
**Expected**: The search refreshes the table with empty displayname and returns all contacts.
**Actual**: The search does not refresh the table.
![image](/uploads/7b807b8aee9ee97d3b8c5b5c98a133aa/image.png)
Note: If i clear the textbox manually and hit search, the search is working fine.https://lab.civicrm.org/dev/core/-/issues/4834Afform conditionnal fields based on checkboxes2023-12-06T23:59:18ZbgmAfform conditionnal fields based on checkboxes- Create a custom field of type checkbox, add a few options
- Create an Afform using that conditional field
- Add a field condition on another field (ex: lastname) that depends on a specific checkbox being checked
Result: field is not d...- Create a custom field of type checkbox, add a few options
- Create an Afform using that conditional field
- Add a field condition on another field (ex: lastname) that depends on a specific checkbox being checked
Result: field is not displayedhttps://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/4364Afform: Adding forms to menu is not compatible with Customize Navigation Menu2023-10-19T23:44:23ZlarsssandergreenAfform: Adding forms to menu is not compatible with Customize Navigation MenuIf you add a menu item for a form directly in the form, it shows up sort of where you want it (though the interface to set the order is pretty unhelpful, because you basically are guessing what the weight of existing items in the menu mi...If you add a menu item for a form directly in the form, it shows up sort of where you want it (though the interface to set the order is pretty unhelpful, because you basically are guessing what the weight of existing items in the menu might be). However, if you later go to Customize Navigation Menu, you can move the menu item you created around and it looks like it works and it will work for a while, but then later, it will move back to the location and weight set in the form.
This is confusing for users and frustrating if you don't know what's going on. Seems like we need to have just one way to edit the menu. Maybe it makes sense to simply remove the add to menu option from forms and let users add the menu item manually? Or alternately, we need a way for the menu location and weight to only be used on inserting the menu item and to be uneditable in the form afterwards, maybe with a help text that tells you to edit this directly in the menu.https://lab.civicrm.org/dev/core/-/issues/5110afform: Display option "Remember Filters" not keeping value2024-03-25T15:01:10Zjensschuppeafform: Display option "Remember Filters" not keeping value## Overview
The display option "Remember Filters" in search displays does not retain its value when the configuration form is being reloaded.
## Reproduction steps
1. Create a _SearchKit_ search with a search form
2. Add a form displa...## Overview
The display option "Remember Filters" in search displays does not retain its value when the configuration form is being reloaded.
## Reproduction steps
1. Create a _SearchKit_ search with a search form
2. Add a form display (e.g. _Table_)
3. add some exposed filters
4. Check _Remember Filters_
5. Reload the configuration form for that form display
## Current behaviour
The option seems to be stored and filter values are being stored per user. The option field (checkbox) however is not set when reloading the config form of the form display. Saving the config form without changing that option still seems to retain its value (still storing filter values). So the config form does not reflect the actual option value.
## Expected behaviour
The option should be set when re-visiting the form display config form. Saving the form should respect the value (unchecked: unset the option).
## Environment information
* **Browser:** _Chromium 123.0.6312.58_
* **CiviCRM:** _5.71.0_https://lab.civicrm.org/dev/core/-/issues/3493Afform: Failed to find key by ID or tag (SIGN)2022-12-19T21:18:09ZandyburnsAfform: Failed to find key by ID or tag (SIGN)I created a simple afform submitting a name and it just spins and shows this console error. On Civi 5.50.0, WP 5.8.4 and multisite. I had this issue on 5.46.3 as well. It does submit the contact even though it appears not to.
![image](/...I created a simple afform submitting a name and it just spins and shows this console error. On Civi 5.50.0, WP 5.8.4 and multisite. I had this issue on 5.46.3 as well. It does submit the contact even though it appears not to.
![image](/uploads/98a9537c12d29cda91345959e268d8a0/image.png)
Sometimes only the angular error:
![image](/uploads/4e77c2cbad1b88909dc62e7b4e3d4500/image.png)
No error reported to civi logs.https://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.