Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-12-13T20:08:15Zhttps://lab.civicrm.org/dev/core/-/issues/4231Contact Import will not accept State/Province outside the Default Country2023-12-13T20:08:15ZStoobContact Import will not accept State/Province outside the Default CountryTo reproduce on dmaster
1. within [Localization Settings](https://dmaster.demo.civicrm.org/civicrm/admin/setting/localization?reset=1)
a. set default country to United States
b. Ensure that for Available Countries box on the right i...To reproduce on dmaster
1. within [Localization Settings](https://dmaster.demo.civicrm.org/civicrm/admin/setting/localization?reset=1)
a. set default country to United States
b. Ensure that for Available Countries box on the right is blank in such that all countries are available for selection
2. go to Import Contacts
3. attempt import a file such as the one attached below that contains Country as a mapped column
4. note that Canada (and presumably another non-default) country is deemed invalid in the error report
[test-country.csv](/uploads/fb97a20935d51e0b9c72530fa12d663b/test-country.csv)
![import-errors-canada_province](/uploads/0b647875367fc261ff6a8fb134595d98/import-errors-canada_province.jpg)https://lab.civicrm.org/dev/core/-/issues/4230Some times custom fields data are set from wrong contact2023-04-12T07:30:30ZPradeep Nayakpradpnayak@gmail.comSome times custom fields data are set from wrong contactOn membership signup form on page load by default custom field are set with wrong data i.e from a different contact. This has raised big concern for our clients as their confidential data are exposed to others.
This happens when the mem...On membership signup form on page load by default custom field are set with wrong data i.e from a different contact. This has raised big concern for our clients as their confidential data are exposed to others.
This happens when the membership id for the [contact is used as contact id to fetch the detail](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Main.php#L285)s.
Steps to replicate on dmaster:
1. Create a custom field for a contact, add to profile and include the profile on membership signup/renewal form.
2. [Find membership](https://dmaster.demo.civicrm.org/civicrm/member/search?reset=1)
3. Look for any contact Smith, Rodrigo. Check for contact id and membership id for the contact. For now the cid=75 and mid=11
4. Edit the contact cid=11 and update the custom field created at step 1.
5. visit the membership renewal/signup form for cid=75 https://dmaster.demo.civicrm.org/civicrm/contribute/transact?cid=75&reset=1&id=2
Actual result:
Custom field is populated for cid=11 instead cid=75
Expected result:
Custom field is populated for cid=75https://lab.civicrm.org/dev/core/-/issues/4229Cannot edit and save EntityRef custom fields2024-01-12T15:48:38ZbrienneCannot edit and save EntityRef custom fieldsOverview
----------------------------------------
In testing [PR 25927](https://github.com/civicrm/civicrm-core/pull/25927), I ran into a bug when trying to edit an EntityRef custom field, which then prevents saving those changes.
Repro...Overview
----------------------------------------
In testing [PR 25927](https://github.com/civicrm/civicrm-core/pull/25927), I ran into a bug when trying to edit an EntityRef custom field, which then prevents saving those changes.
Reproduction steps
----------------------------------------
1. Create a custom field of type *EntityRef* with any entity.
1. Click **Edit Field**.
1. Click **Save**, with or without making changes, on the pop up editor.
1. The field is not saved and instead the user is told 'Selecting an entity is required'.
Current behaviour
----------------------------------------
A user cannot edit an EntityRef custom field becuase CiviCRM thinks that an entity is not selected, even though it already has been. A user also cannot select the field to try to 're-select' the chosen entity.
![Selection_069](/uploads/1cb884e4b1210c5a4e0bb3a4e1665e44/Selection_069.png)
Expected behaviour
----------------------------------------
A user should be able to edit and save an EntityRef custom field, i.e. CiviCRM should recognize that an entity has been selected.
Environment information
----------------------------------------
* **CiviCRM:** 5.61.alpha1, \_Master/5.62.alpha1https://lab.civicrm.org/dev/core/-/issues/4227Contact import (new) deletes contact fields2023-07-11T16:34:41ZBjörn EndresContact import (new) deletes contact fieldsOverview
----------------------------------------
It seems like the "new importer" that has been implemented with [5.51](https://lab.civicrm.org/groups/dev/-/issues/?sort=updated_desc&state=closed&milestone_title=5.51.0&label_name%5B%5D=...Overview
----------------------------------------
It seems like the "new importer" that has been implemented with [5.51](https://lab.civicrm.org/groups/dev/-/issues/?sort=updated_desc&state=closed&milestone_title=5.51.0&label_name%5B%5D=comp%3AImport&first_page_size=100) has slightly changed its behaviour: if you import/update contacts with empty fields these fields will be deleted, where they used to be ignored (pre 5.51).
Reproduction steps
----------------------------------------
1. Import test contact using the "Import Contacts" menu item with [this file](/uploads/5c56a58c83b7a1fcd5f69ddab02a5c23/ISSUE-4227_step1.csv) and check whether the contact was created.
2. Update the contact by using the import again with [this file](/uploads/62ef3aa3a3c6b975d2dbfa7d060248fc/ISSUE-4227_step2.csv), setting the "For Duplicate Contacts" setting to "Update"
3. Observe, that the birthday field in the new contact was deleted.
Current behaviour
----------------------------------------
Currently, the contact's birthday field is deleted.
Expected behaviour
----------------------------------------
Contact's birthday field should be left untouched, as was the behaviour pre ``5.51.0`` (tested with ``5.40.2``).
Environment information
----------------------------------------
Reproduced on ``dmaster``.
----------------------------------------
This might be an intentional change in behaviour, but I haven't found any documentation on this.5.62.0https://lab.civicrm.org/dev/core/-/issues/4226Mapping.mapping_id does not resolve in api v4 explorer2023-04-12T07:28:35ZeileenMapping.mapping_id does not resolve in api v4 explorer@colemanw what is the right approach here - there is a foreign key - but civicrm_mapping only has name, not label etc -(I kinda see this table being deprecated over time too)
![image](/uploads/618ea8286b9b6792ccad8de319ff311f/image.png)...@colemanw what is the right approach here - there is a foreign key - but civicrm_mapping only has name, not label etc -(I kinda see this table being deprecated over time too)
![image](/uploads/618ea8286b9b6792ccad8de319ff311f/image.png)
```
<field>
<name>mapping_id</name>
<type>int unsigned</type>
<title>Mapping ID</title>
<required>true</required>
<comment>Mapping to which this field belongs</comment>
<html>
<label>Mapping</label>
</html>
<add>1.2</add>
</field>
<foreignKey>
<name>mapping_id</name>
<table>civicrm_mapping</table>
<key>id</key>
<add>1.2</add>
<onDelete>CASCADE</onDelete>
</foreignKey>
```https://lab.civicrm.org/dev/core/-/issues/4225Regression in 5.61rc - if CiviMember is not enabled then creating a relations...2023-05-03T23:58:45ZeileenRegression in 5.61rc - if CiviMember is not enabled then creating a relationship causes an erro@mattwire the switch to apiv4 is causing an authorization error - we can probably by pass the whole membership code if CiviMember disabled@mattwire the switch to apiv4 is causing an authorization error - we can probably by pass the whole membership code if CiviMember disabledhttps://lab.civicrm.org/dev/joomla/-/issues/49CIVI CRM Menu does not show output when SEF is ON - Joomlai2023-08-25T20:05:21ZjoomCIVI CRM Menu does not show output when SEF is ON - JoomlaiHi
i updated the website to Joomla 4 and also updated CIVI to latest version and
PHP to PHP 8.
all seems fine on updates but on frontend no CIVI CRM menu item is showing any output with Joomla 4.
If i use system URL it works fine.
No ch...Hi
i updated the website to Joomla 4 and also updated CIVI to latest version and
PHP to PHP 8.
all seems fine on updates but on frontend no CIVI CRM menu item is showing any output with Joomla 4.
If i use system URL it works fine.
No change if i downgrade PHP version and turn off mod rewrite as well.
With SEF OFF or if copy the menu system URL its works fine **/index.php?option=com_civicrm&view=Dashboard&task=civicrm/user&reset=1&itemid=294**![Screenshot_3](/uploads/672b1f3257e0a6f17963cbbf1f964b59/Screenshot_3.png)https://lab.civicrm.org/dev/core/-/issues/4224DB error message when creating new campaign with existing "External ID"2023-04-12T07:26:10ZDetlev SieberDB error message when creating new campaign with existing "External ID"Overview
----------------------------------------
When creating a new campaign, an external_id can be added. This external_id must be unique.
However, when a new campaign is entered with an external_id that already exists in the databas...Overview
----------------------------------------
When creating a new campaign, an external_id can be added. This external_id must be unique.
However, when a new campaign is entered with an external_id that already exists in the database, there is no error message giving the chance to enter another external_id, but we receive a database error:
```
Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred.
DB Error: already exists
```
Reproduction steps
----------------------------------------
1. Create a new campaign with External ID "10001"
2. Create another new campaign with another name but with the same External ID "10001"
3. Database error is displayed, leaving thu user puzzled.
Current behaviour
----------------------------------------
Database error, that gives the user no clue what happened.
Expected behaviour
----------------------------------------
There should be a message stating "External ID already exists", giving the user the chance to enter another external ID (or leave the field empty).
Environment information
----------------------------------------
* __CiviCRM:_Master/5.59.xhttps://lab.civicrm.org/dev/core/-/issues/4223To edit price sets CiviContribute access needed2023-04-12T07:25:37ZMariaVTo edit price sets CiviContribute access neededOverview
----------------------------------------
A user has limited permissions without access to CiviContribute but has access to CiviEvent and needs to set up price sets. It is possible to view price sets but they can not be edited or...Overview
----------------------------------------
A user has limited permissions without access to CiviContribute but has access to CiviEvent and needs to set up price sets. It is possible to view price sets but they can not be edited or created because of the financial type.
Reproduction steps
----------------------------------------
1. Create price set for Events (with a user without CiviContribute access)
2. Create price field (radio buttons)
3. Add options to this price field
4. Fill all needed information
5. Save
6. Error "financial type is mandatory"
Current behaviour
----------------------------------------
When I open a price set option it shows me this:
![image](/uploads/f5b1e1b6648bb6beb30cf36b3ab2fe7a/image.png)
(Zuwendungsart = financial type)
With administrator this:
![image](/uploads/b6fc64b239dad54bbf4ba68c72434241/image.png)
If I give "CiviContribute access" it works.
Expected behaviour
----------------------------------------
When CiviEvent access is given, users are allowed to create price sets.
Environment information
----------------------------------------
* __CiviCRM:__ _5.58.1
* __CMS:__ _Drupal 7https://lab.civicrm.org/dev/core/-/issues/4222Links with null data arguments are not displayed in SearchKit displays2023-05-23T19:59:14Zct_itsupportLinks with null data arguments are not displayed in SearchKit displaysOverview
----------------------------------------
A link item required in a List or Table display item in SearchKit will not be output if any data item or items in the link is/are missing. This issue arises from the following question as...Overview
----------------------------------------
A link item required in a List or Table display item in SearchKit will not be output if any data item or items in the link is/are missing. This issue arises from the following question asked on StackOverflow. See:
[Why are SearchKit links blank if a data item is missing?](https://civicrm.stackexchange.com/q/44750/6361)
Reproduction steps
----------------------------------------
1. Create a simple webform to edit aspects of a case type, ensuring you have more than one contact ID or activity ID update
2. Create a SearchKit search that lists the cases of that type and add a custom link to the webform, passing in the arguments link case ID, contact ID etc
3. Ensure some data is null in a couple of your cases
4. Look at the output of SearchKit links thst have data items missing
Current behaviour
----------------------------------------
A user viewing the SearchKit display will not see links - see screenshot:
![2023-04-06_09_20230405_CiviCRMS_SearchKit_issue_](/uploads/9c589ca3eb272d2066ee4264860fcdcf/2023-04-06_09_20230405_CiviCRMS_SearchKit_issue_.png)
Expected behaviour
----------------------------------------
I believe every link should be output, regardless of the null data. This is the current behaviour of the Drupal Views we use for the same purposes
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. -->
__CiviCRM:__ _5.9.3_
__PHP:__ _7.4.3_
__CMS:__ _Drupal 7.95_
__Database:__ _MySQL 5.7.35_
__Web Server:__ _Apache 2.4.38_https://lab.civicrm.org/dev/core/-/issues/4221SearchKit: calculating average of money value does not result in money2023-09-18T12:49:57ZjmargrafSearchKit: calculating average of money value does not result in moneyOverview
----------------------------------------
We use SearchKit to calculate the average membership contribution.
The input values are in €. In Version 5.50.4 the result was presented as money [in €].
But with an update to Version 5.5...Overview
----------------------------------------
We use SearchKit to calculate the average membership contribution.
The input values are in €. In Version 5.50.4 the result was presented as money [in €].
But with an update to Version 5.58.1 the result is presented as a number instead of as money [in €].
The represenation of the mean value should als be as money [in €].
presentation in 5.50.4:
![mean-value-old](/uploads/9e17c1c2f8ea52b8aad08960fd9faeab/mean-value-old.png)
presentation in 5.58.1:
![mean-value-new](/uploads/22f212e498fe82dd0dac0b6291fc97f2/mean-value-new.png)
Reproduction steps
----------------------------------------
The following SearchKit configuration is used:
![searchkit](/uploads/f6f8ec275d84c34fff59e5edb341f5a0/searchkit.png)
Current behaviour
----------------------------------------
mean value is represented as a value
Expected behaviour
----------------------------------------
mean value should be represented as money [in €]
Environment information
----------------------------------------
* __CiviCRM:__ 5.58.1
* __CMS:__ Drupal 9.4.8https://lab.civicrm.org/dev/core/-/issues/4220CiviCRM Activity Revisions - still some code that uses this in core2023-05-03T04:34:44Zluke.stewartCiviCRM Activity Revisions - still some code that uses this in coreFrom https://chat.civicrm.org/civicrm/pl/qxzsdqfjxf8i8cdtq31hdqnpzw and
https://chat.civicrm.org/civicrm/pl/k1pggukwfbdo9fzztjb33pikdo
There looks to be some places where is_current_revsion is still being set to 0/False.
A quick grep ...From https://chat.civicrm.org/civicrm/pl/qxzsdqfjxf8i8cdtq31hdqnpzw and
https://chat.civicrm.org/civicrm/pl/k1pggukwfbdo9fzztjb33pikdo
There looks to be some places where is_current_revsion is still being set to 0/False.
A quick grep suggests the following need attention:
```
CRM/Activity/Page/AJAX.php https://github.com/civicrm/civicrm-core/pull/26091 - merged
CRM/Case/Form/Activity.php https://github.com/civicrm/civicrm-core/pull/26037 - merged
CRM/Case/Form/Activity/ChangeCaseStartDate.php https://github.com/civicrm/civicrm-core/pull/26039 - merged
```https://lab.civicrm.org/dev/core/-/issues/4219Temp table column too short in legacycustomsearches2023-04-12T07:19:23ZcatorghansTemp table column too short in legacycustomsearchesI got a "DB Error: unknown error" in "Rebuild Smart Group Cache" in the Scheduled Jobs.
In the Log file it says
"[nativecode=1406 ** Data too long for column 'group_names' at row 1]"
Which started "civicrm/ext/legacycustomsearches/CRM/C...I got a "DB Error: unknown error" in "Rebuild Smart Group Cache" in the Scheduled Jobs.
In the Log file it says
"[nativecode=1406 ** Data too long for column 'group_names' at row 1]"
Which started "civicrm/ext/legacycustomsearches/CRM/Contact/Form/Search/Custom/Group.php(435)"
What happens there just above is:
```
$this->_iGTable->createWithColumns("id int PRIMARY KEY AUTO_INCREMENT, contact_id int, group_names varchar(64)");
if ($iGroups) {
$includeGroup = "INSERT INTO {$this->_iGTableName} (contact_id, group_names)
SELECT civicrm_contact.id as contact_id, civicrm_group.title as group_name
FROM civicrm_contact
INNER JOIN civicrm_group_contact
ON civicrm_group_contact.contact_id = civicrm_contact.id
LEFT JOIN civicrm_group
ON civicrm_group_contact.group_id = civicrm_group.id";
}
```
The issue is that civicrm_group.title is varchar(255) while group_names in this temp table is varchar(64).
We had one group title which was 77 chars. When I shortened it, it worked again.
So make it "group_names varchar(255)" and it should work (or use civicrm_group.name in the select, but I suspect a reason why that was not used here)https://lab.civicrm.org/dev/core/-/issues/4218Submitting CiviMailings is flaky2023-04-24T23:29:16ZJonGoldSubmitting CiviMailings is flakyI've noticed several times that when you press "Submit Mailing" you get an error that says that submission was unsuccessful. I thought it was just me but now I'm getting user reports about it. Do others see this? I realize this isn't ...I've noticed several times that when you press "Submit Mailing" you get an error that says that submission was unsuccessful. I thought it was just me but now I'm getting user reports about it. Do others see this? I realize this isn't a proper bug report but I'm guessing this is common enough that folks can share their experiences and we can move toward a proper report.https://lab.civicrm.org/dev/core/-/issues/4216Primary email adress gets overwritten by profile submissions2023-04-12T13:09:09ZTobias Voigttobias.voigt@civiservice.dePrimary email adress gets overwritten by profile submissionsBehaviour:
When a profile (e.g. for a newsletter subscription) is submitted, the system searches through possible duplicates by checking, if an email address (a@a.com) already exists. If it finds an existing secondary email adress (and ...Behaviour:
When a profile (e.g. for a newsletter subscription) is submitted, the system searches through possible duplicates by checking, if an email address (a@a.com) already exists. If it finds an existing secondary email adress (and the profile is configured to retrieve the primary email adress, which makes sense for a newsletter subscription form) it overwrites the primary email (b@b.com)of the corresponding contact with the (secondary) address it found (a@a.com). The result is a contact that has two entries for email adresses (primary and secondary) that are the same (a@a.com). The former primary email (b@b.com) gets lost.
Expected behaviour:
When the system finds an existing secondary email address, it should set the marker for "Bulk Mailings" for that address. The primary email address should remain untouched.https://lab.civicrm.org/dev/core/-/issues/4215CiviCRM geographical data is never accurate2023-06-17T22:10:12ZJonGoldCiviCRM geographical data is never accurateOverview
----------------------------------------
We are constantly finding problems with our lists of country names, state/province names, and state/province abbreviations. We're missing some, others are incorrect. Some folks [have th...Overview
----------------------------------------
We are constantly finding problems with our lists of country names, state/province names, and state/province abbreviations. We're missing some, others are incorrect. Some folks [have thought](https://forum.civicrm.org/index.php%3Ftopic=32877.0.html) it'd be nice to automate it.
Unfortunately, this isn't very straightforward. The ISO source we claim to follow isn't publicly available. Even at the country level - many official names differ from what we use (e.g. "United Kingdom" vs. "United Kingdom of Great Britain and Northern Ireland"). And even "official names" differ depending on whether we reference Wikipedia, the CIA, etc.
So some of our data is wrong by everyone's standard - but is it worth fixing state/provinces if we don't fix countries?
The code
----------------------------------------
For giggles, I wrote a dirty script to identify discrepancies between Civi data and published data called [civiregioncheck](https://github.com/MegaphoneJon/civiregioncheck). It's not complete because given the volume of necessary changes, I don't want to sink effort into finishing it if we can't take action on it.
Attached is a partial list of discrepancies:
* Country names that don't match ISO-3166-1.
* State/provinces that have a matching ISO-3166-1 country and ISO-3166-2 name, but the abbreviation is incorrect.
Ideally we also find state/provinces that are missing (or dissolved), and state/provinces with a matching abbreviation but incorrect name.
What next?
----------------------------------------
Are we really changing the UK (above) or "United States" to "United States of America"? And if not, where do we draw the line? ISO-3166-1 current specifies the official country name of Taiwan as "Taiwan, Province of China". And we include Kosovo despite it not having an official ISO 3166-1 code.
If this is too thorny to hash out, we'll go back to our patchwork process - but our data has hundreds of discrepancies.
[civi_geographic_discrepancies.csv](/uploads/b6a99ec66ef4f1affadab53b61027b1d/civi_geographic_discrepancies.csv)JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/4214Too many CiviCRM custom fields breaks logging resulting in mysterious errors2023-04-05T14:36:26Zluke.stewartToo many CiviCRM custom fields breaks logging resulting in mysterious errorsOverview
----------------------------------------
If for some strange reason you decide to create **_a lot_** of custom fields - and use detailed logging you can break stuff rather badly without getting a nice warning.
Reproduction ...Overview
----------------------------------------
If for some strange reason you decide to create **_a lot_** of custom fields - and use detailed logging you can break stuff rather badly without getting a nice warning.
Reproduction steps
----------------------------------------
1. Turn on detailed logging
1. Create yourself a custom field group - or use one you've prepared earlier.
1. Add a lot of text fields with max length. This probably depends on database settings - for mariadb what your database innodb_page_size variable is set to.
1. At some point you will be able to add new fields to the custom group - but the row size will be exceeded when these fields are added to the log_custom_group_value_thing_table.
1. From this point on any operation attempting to write data into that table will result in errors when Detail logging is turned on. However due to the joys of detailed logging it will say something like field X doesn't exist - however it does - but field Y will exist on that table but not on the log_table.
1. You will possibly notice a small error message showing when turning detailed logging on.
Current behaviour
----------------------------------------
You get errors like this when turning
```
[nativecode=1118 ** Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs]
```
Expected behaviour
----------------------------------------
You should probably not be able to create custom fields after a certain point. however perhaps more to the point - if there is an error turning detailed logging on and it relates to a schema mismatch then perhaps it would be better to - turn the detailed logging back off - return a Computer says no message - along with a list of log tables that don't match what they should.https://lab.civicrm.org/dev/core/-/issues/4213Make frontend_title consistently required and use it in all front end present...2023-04-04T08:46:17ZeileenMake frontend_title consistently required and use it in all front end presentationsWhen we added frontend_title it was an optional override for title, which would fall back to title but this has been confusing to manage and means things like the token `{group.frontend_title}` token don't work and usage is inconsistent....When we added frontend_title it was an optional override for title, which would fall back to title but this has been confusing to manage and means things like the token `{group.frontend_title}` token don't work and usage is inconsistent.
The affected entities are
- Contribution Page
- Group
- Profile (UFGroup)
- PaymentProcessor - but this already follows the schema in this proposal
We need to get to a more consistent space. Front end title is currently effectively required (as it falls back to title) & holds the contents of title, or frontend title so the scope of this change is to make that the case at the DB / form level and then fix front end usages to display the front end title (only).
This addresses the inconsistencies and means that by requiring people to enter front end title they will be prompted to think about what the public see when creating the title.
There are some requests to permit title to be blank - the difficulties around handling this are what has caused us not to embark on addressing the consistencies to date. However, part of that request is better addressed through Wordpress - ie https://lab.civicrm.org/dev/core/-/issues/4212 and the other articulated reason is to ensure people are not accidentally exposing inappropriate names (which making it required will do).
There might be other reasons that an 'allow blank' feature might make sense - but I think we need to separate that feature request from our need to get to a sane place with frontend titles - so the plan is for 5.61 we will
1) make all frontend title fields required at the DB level & form level
2) do a db upgrade to populate these fields with the values in title
3) ensure that front end references always just display frontend_title.https://lab.civicrm.org/dev/core/-/issues/4212Wordpress - allow suppressing CiviCRM title in profiles / contribution pages?...2023-04-04T08:45:49ZeileenWordpress - allow suppressing CiviCRM title in profiles / contribution pages? when displaying via short codeThere is a problem @justinfreeman has been reporting whereby you wind up with double-titles because the title is not optional on the CiviCRM or the Wordpress level.
I think the right fix for this is to handle in within the short code co...There is a problem @justinfreeman has been reporting whereby you wind up with double-titles because the title is not optional on the CiviCRM or the Wordpress level.
I think the right fix for this is to handle in within the short code configuration - do you have any thoughts on how to do that @kcristiano @haystack ?
![image](/uploads/e40555c9a25d0948ca0dc5f8d60daa1f/image.png)
![image](/uploads/0a1231cdc2be7d04feeb0801163b0d38/image.png)https://lab.civicrm.org/dev/core/-/issues/4211Afform: civi.afform.prefill never called within custom extension with Case2023-04-05T14:38:41ZshaneonabikeAfform: civi.afform.prefill never called within custom extension with CaseOverview
----------------------------------------
The population of two custom fields via ```civi.afform.prefill``` when a FormBuilder is rendered is not working properly. Technically, from my discussion on [Mattermost](https://chat.civ...Overview
----------------------------------------
The population of two custom fields via ```civi.afform.prefill``` when a FormBuilder is rendered is not working properly. Technically, from my discussion on [Mattermost](https://chat.civicrm.org/civicrm/pl/e5c17zxjxfyhxm3cynxtqf8chr) prefill should be called prior to field rendering.
Basically, we are attempting to create a Form that uses CiviCase to be able to allow members to request to change their membership type. The two custom fields that should be modified (on the fly are)
+ Current Membership (to store the existing membership)
+ Choose a Membership Type (a limited set of memberships that a person can change too)
Reproduction steps
----------------------------------------
1. Create a Custom Data Field set _used for_ Cases
1. Create a field _Current Membership_ with a DataType Alphanumeric Radio
1. Create a field _Choose a Membership Type_ with a DataType Integer Radio
![Selection_007](/uploads/7c1ec6e9d4379e5ed9d75413b0bcc82d/Selection_007.png)
1. Create a FormBuilder linked to a Case
1. Set _Case Clients_ to Current User
1. Set _Case Type_ to your new Case Type
1. Create a custom extension and add the code below
1. Enable extension
1. No fields are modified
### Custom code
```php
/**
* Implements hook_civicrm_config().
*
* @link https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_config/
*/
function myext_civicrm_config(&$config) {
_myext_civix_civicrm_config($config);
$dispatcher = Civi::dispatcher();
// Add FormBuilder Prefill
$dispatcher->addListener('civi.afform.prefill', 'myext_afform_prefill', 99);
}
``` php
/**
* Implements AfformPrefillEvent
* @link https://docs.civicrm.org/dev/en/latest/afform/afform-events/
*/
function myext_afform_prefill($event) {
Civi::log()->warning('Event here');
$form = $event->getAfform();
Civi::log()->warning('Form : '.var_export($form,true));
if ($form['name'] == 'abc') {
$entity_values = $event->getEntityValues();
Civi::log()->warning('Values : '.var_export($entity_values,true));
}
}
```
### Afform Markup
```html
<af-form ctrl="afform">
<af-entity data="{contact_id: ['user_contact_id'], case_type_id: '4', status_id: '4', subject: 'Request Form - Change Membership Type'}" actions="{create: true, update: false}" type="Case" name="Case1" label="Case 1" security="FBAC" />
<div class="af-markup">
</div>
<fieldset af-fieldset="Case1" class="af-container">
<af-field name="Request_Membership_Change.Current_Membership" defn="{label: 'Your Current Membership', required: true}" />
<af-field name="Request_Membership_Change.Choose_a_Membership_Type" defn="{label: 'Choose a New Membership Type', required: true}" />
<af-field name="Request_Membership_Change.Documentation" defn="{label: 'Supporting Documentation'}" />
<button class="af-button btn btn-primary" crm-icon="fa-check" ng-click="afform.submit()">Submit Request</button>
</fieldset>
</af-form>
```
Current behaviour
----------------------------------------
The ```civi.afform.prefill``` event never seems to be launched. I can confirm that it is being launched on the Validate hook so it should also work for prefill.
Expected behaviour
----------------------------------------
When loading the form the ```_prefill``` hook Event would be launched and we could modify the custom fields like we can with ```hook_civicrm_fieldOptions```
Environment information
----------------------------------------
* __CiviCRM:__ 5.60
* __CMS:__ Drupal 7
Comments
----------------------------------------
I wouldn't mind helping to debug this issue and/or provide a merge request. I would just need further pointers. When I tried to add logs in the actual afform prefill event creation there were no logs output. I could be doing something wrong but I have the impression it's not getting fired.
My gutt says it's because this is only presently setup for Autocomplete fields like Contacts Select list, but I could be totally off.