Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-03-23T20:11:09Zhttps://lab.civicrm.org/dev/core/-/issues/4196hook_civicrm_links - are the docs wrong or the code?2023-03-23T20:11:09ZJonGoldhook_civicrm_links - are the docs wrong or the code?The docs for `hook_civicrm_links` provides this signature:
```php
hook_civicrm_links(string $op, string $objectName, int $objectID, array &$links, int &$mask, array &$values)
```
However, the type hinting isn't always correct. I've fo...The docs for `hook_civicrm_links` provides this signature:
```php
hook_civicrm_links(string $op, string $objectName, int $objectID, array &$links, int &$mask, array &$values)
```
However, the type hinting isn't always correct. I've found:
* PCP pages pass `NULL` for `$mask`.
* The extensions page passes a string for `$objectID`.
Should we change the docs or the code?https://lab.civicrm.org/dev/core/-/issues/4198Access to undeclared variable in merge code2023-03-23T14:06:20ZRichAccess to undeclared variable in merge codeAt:
https://lab.civicrm.org/dev/core/-/blob/96d550c70dd1f406851895ddfe236fbfd718ab77/CRM/Dedupe/Merger.php#L1376
we reference `$migrationData` which is not declared. I have a hunch it should be `$migrationInfo`?
Ping @eileenAt:
https://lab.civicrm.org/dev/core/-/blob/96d550c70dd1f406851895ddfe236fbfd718ab77/CRM/Dedupe/Merger.php#L1376
we reference `$migrationData` which is not declared. I have a hunch it should be `$migrationInfo`?
Ping @eileenhttps://lab.civicrm.org/dev/core/-/issues/4203add end date to petition2023-03-27T06:52:21Zjamieadd end date to petitionOverview
----------------------------------------
This proposed feature would add a new field to petitions called: End date. If someone tries to sign a petition that has an end date in the past, they would get a friendly error warning t...Overview
----------------------------------------
This proposed feature would add a new field to petitions called: End date. If someone tries to sign a petition that has an end date in the past, they would get a friendly error warning them that the petition is no longer active.
Current behaviour
----------------------------------------
Now, we can create petitions and manually disable them. However there are two problems:
1. If you disable a petition it no longer shows up in advanced search so you can no longer find signatories.
2. It's easy to forget to disable a petition. That means these potentially spam-collecting forms can live on for too long
3.
Proposed behaviour
----------------------------------------
By adding an end date when you create the petition, you can set it up and forget about it.
Comments
----------------------------------------
I'm open to taking a crack at implementing, but wanted to first get feedback to see if this is the best way to go about it or if there are any potential pitfalls.https://lab.civicrm.org/dev/core/-/issues/4208Generating invoices generates an error with version >= 0.12.6 of wkhtmltopdf.2023-04-04T08:44:14ZeileenGenerating invoices generates an error with version >= 0.12.6 of wkhtmltopdf.Full detail in https://github.com/civicrm/civicrm-core/pull/23055 - am creating this to track that issue as the patch is not mergeable as isFull detail in https://github.com/civicrm/civicrm-core/pull/23055 - am creating this to track that issue as the patch is not mergeable as ishttps://lab.civicrm.org/dev/core/-/issues/4209Form builder does not load activity 'details' in pop-up edit mode2023-04-04T08:44:40ZScottMasonForm builder does not load activity 'details' in pop-up edit mode1. Create a form builder for an activity including the 'details' field
2. Add an activity using the form
3. Create a SK display for activities with a menu item 'edit' configured to load the form in popup mode
4. Select edit from the SK d...1. Create a form builder for an activity including the 'details' field
2. Add an activity using the form
3. Create a SK display for activities with a menu item 'edit' configured to load the form in popup mode
4. Select edit from the SK display - the form is loaded with all data except for the details field which is blank.
Strangely when tested on dmaster demo the popup appears to load the details data on the first load but not any subsquent attempts.
![image](/uploads/9149c476f4563d457425512dd024398a/image.png)https://lab.civicrm.org/dev/core/-/issues/4210Only possible to add A-B relationships types or B-A relationship types (not b...2023-04-04T08:45:11ZScottMasonOnly possible to add A-B relationships types or B-A relationship types (not both) to new contact using Form BuilderWhen using Form Builder to create a new contact and then add relationships to that contact using a single form it appears that it is only possible to select to add A-B relationship or B-A relationships but not both. For example, if creat...When using Form Builder to create a new contact and then add relationships to that contact using a single form it appears that it is only possible to select to add A-B relationship or B-A relationships but not both. For example, if creating a new Individual the form can be configured to allow users to add 'Child of' relationships or 'Parent of' relationships but not both.
1. Create a new contact form using form builder
2. Add a relationship fieldset
3. Set as a default value either Contact A or Contact B as 'Organisation1' (i.e. the new contact being created) - see image below.
![image](/uploads/49caec4139d87f8e17878e4785fabec3/image.png)
4. Quite understandably if Organisation1 is set as 'Contact A' only A-B relationship types can be selected in the form and if Organisation1 is set to 'Contact B' only B-A relationship types can be selected. For example, in our case if adding a new company it is possible to add 'Parent of' relationships to the new company but not 'Subsidiary of' relationships.
![image](/uploads/bf24ad54c5fff2ff4c3011d7c8900ca4/image.png)
This is logical given the way the form has been configured, so I am not sure if this is necessarily a 'bug' but I wondered if there was a way of configuring the form so that I user can select both A-B and B-A relationship types when adding relationships using form builder?
Thanks
Scotthttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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>
```