CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-03-22T03:13:00Zhttps://lab.civicrm.org/dev/core/-/issues/5103Saving checkbox custom fields via APIv4 fails for custom/dynamic entities2024-03-22T03:13:00ZjensschuppeSaving checkbox custom fields via APIv4 fails for custom/dynamic entities## Steps to reproduce
* For a custom/dynamic entity type (e.g. using the [_Entity Construction Kit_](https://github.com/systopia/de.systopia.eck)), add a custom field with HTML type `CheckBox`
* Try to create/save an entity with that fi...## Steps to reproduce
* For a custom/dynamic entity type (e.g. using the [_Entity Construction Kit_](https://github.com/systopia/de.systopia.eck)), add a custom field with HTML type `CheckBox`
* Try to create/save an entity with that field with APIv4, e.g. using the _ECK_ Afform forms (whether the field has a value is irrelevant)
## Expected behavior
Entity saved, field has selected (or no) value
## Actual behavior
Entity not saving, error is `Error: Class name must be a valid object or a string in civicrm_api3_generic_getoptions() (line 442 of /path/to/civicrm/civicrm-core/api/v3/Generic.php).`
## Technical details
* `DAOActionTrait` calls the global (APIv3) function `formatCheckBoxField()` for fields with an HTML type of `CheckBox` [here](https://github.com/civicrm/civicrm-core/blob/018741e09162a29f34a01d04141e3f96ddcade19/Civi/Api4/Generic/Traits/DAOActionTrait.php#L260-L263)
* That function calls APIv3 `getoptions` with the given entity (`Eck_*`)
* APIv3 "normalizes" entity names, stripping the `_` which results in the APIv3 entity being `Eck*`
* Resolving the entity to a DAO class fails at the latest in `_civicrm_api3_get_DAO()` due to the "normalized" entity name
* Finally, when calling `$dao::buildOptions()` on `null`, the error occurs
## Proposed solution
As commented in `DAOActionTrait` for the call of `formatCheckBoxField()`: `this function should be part of a class` - and re-implemented using APIv4 `getFields` with `loadOptions=TRUE` for the given `custom_field_id`.https://lab.civicrm.org/dev/core/-/issues/2994Support oEmbed for external facing pages2024-03-21T18:50:44ZJoeMurraySupport oEmbed for external facing pagesAn important evolution of CiviCRM is to better support remote sites exposing CiviCRM forms and content.
Many platforms including WordPress and Drupal core since 8.6 support oEmbed, which allows a site to pull in content from a different...An important evolution of CiviCRM is to better support remote sites exposing CiviCRM forms and content.
Many platforms including WordPress and Drupal core since 8.6 support oEmbed, which allows a site to pull in content from a different site that exposes its content as oEmbed.
There is a good list of oEmbed providers, and CiviCRM should aspire to join it: https://oembed.com/providers.json
We should expose the following 'pages' as oEmbed content, using appropriate standard markup for use in WordPress and Drupal 8.6+ sites, and support the workflow for confirmation, thank you, and search results as appropriate:
1. Phase 1
1. Contribution page
2. Event info page
3. Event registration page
2. Phase 2
1. Something like a profile create/edit page that does not involve a payment but allows submission of a form to create a contact and activity and perhaps more (eg parent-child relationship)
2. Search Kit page
3. Petition page
3. Phase 3
1. Personal Campaign Page
2. Pages from extensions, eg Grant Application Page
3. CiviSurvey pages
Note: I haven't done the research to understand the details of oEmbed and potential challenges. I think this could be done through extension(s).
I'm posting this in order to generate discussion for a possible Roadmap item.https://lab.civicrm.org/dev/core/-/issues/3449Afform: checkboxes should have default false value2024-03-21T05:03:28ZRichAfform: checkboxes should have default false valueOverview
----------------------------------------
If you have a checkbox used, for example, for "is_test" on a contribution search table but without explictly configuring a default value, the UI shows an un-checked checkbox, which *shou...Overview
----------------------------------------
If you have a checkbox used, for example, for "is_test" on a contribution search table but without explictly configuring a default value, the UI shows an un-checked checkbox, which *should* be the visual representation of "is_test = 0" but is actually representing *no filter on is_test*.
After operating the checkbox the UI and the meaning are in-sync.
While this can be solved by the form builder designer setting an explicit default value, there is no logical sense to *not* having a default value when the form element is binary.
Current behaviour
----------------------------------------
If person who built the form forgets / does not know to include a default value on a checkbox, the UI is initially broken, results are misleading.
Proposed behaviour
----------------------------------------
A checkbox should insist on a default value, defaulting to false, so that the UI and the meaning of the filter are always in sync.
Comments
----------------------------------------
https://chat.civicrm.org/civicrm/pl/9613mtpi6j8ypxf879p7eyyz5ahttps://lab.civicrm.org/dev/core/-/issues/2941Follow-up task - Remove the CiviCRM Connections functionality from CiviCRM co...2024-03-21T05:03:26Zjustinfreeman (Agileware)Follow-up task - Remove the CiviCRM Connections functionality from CiviCRM core (Task 2 of 2) - Remove the codeThis is a follow-up task to https://lab.civicrm.org/dev/core/-/issues/2910 - which was changed to only remove the menu item from the menu as an intermediary step.
To complete this work, this task will remove the CiviCRM Connections func...This is a follow-up task to https://lab.civicrm.org/dev/core/-/issues/2910 - which was changed to only remove the menu item from the menu as an intermediary step.
To complete this work, this task will remove the CiviCRM Connections functionality from CiviCRM core. This concept was already approved on https://lab.civicrm.org/dev/core/-/issues/2910
Agileware Ref: CIVIBLD-286https://lab.civicrm.org/dev/core/-/issues/5102Allow access to API params from Api4Query2024-03-20T13:55:38ZMichael McAndrewAllow access to API params from Api4QueryContext:
* I am adding an 'extra' calculated field to a spec provider for a custom entity.
* The value of this extra calculated field depends on a parameter passed to the get action.
* I have access to the query in the setSqlRenderer me...Context:
* I am adding an 'extra' calculated field to a spec provider for a custom entity.
* The value of this extra calculated field depends on a parameter passed to the get action.
* I have access to the query in the setSqlRenderer method (which contains a _protected_ API object) but there doesn't appear to be a way to access the API parameters.
Adding the following method to Api4Query allows read only access to API params and seems inline with other methods like `getSelect()`, but feel free to let me know if I am doing it wrong and there is a better approach.
```php
/**
* @return mixed
*/
public function getParam(string $param) {
return call_user_func([$this->api, 'get'.ucfirst($param)]);
}
```
PR coming up...https://lab.civicrm.org/dev/core/-/issues/4154Number field input validation does not respect decimal separator setting2024-03-20T10:36:25ZnoahNumber field input validation does not respect decimal separator settingOverview
----------------------------------------
This issue has to do with "number" (float) custom fields on some edit forms. When you enter a number containing any character other than a digit or a period (full stop) into such a field,...Overview
----------------------------------------
This issue has to do with "number" (float) custom fields on some edit forms. When you enter a number containing any character other than a digit or a period (full stop) into such a field, validation fails. This happens even if the offending character has been set as the decimal separator in Civi's localization settings.
Reproduction steps
----------------------------------------
1. Under Administer > Localization > Languages, Currency, Locations, set "Decimal Delimiter" to "," (comma).
1. Create a custom field extending Activities. Data type: Number.
1. Add a new activity. In the number field, enter a number that includes a comma, such as "123,45" (one hundred twenty three and forty-five one-hundredths).
1. Press Save.
Current behaviour
----------------------------------------
Validation fails with the error message "[Custom Field Label] must be a number (with or without decimal point)."
Expected behaviour
----------------------------------------
The form should save the entered amount as (float) one hundred twenty three and forty-five one-hundredths.
Environment information
----------------------------------------
CiviCRM 5.60 (current master HEAD).
Comments
----------------------------------------
Somewhat entangled with #41525.68.0https://lab.civicrm.org/dev/core/-/issues/3773Deprecated function: Required parameter $sortCriteria follows optional parame...2024-03-20T05:03:26ZTobias KrauseDeprecated function: Required parameter $sortCriteria follows optional parameter $countEverytime cron runs I see this message in logs:
`Deprecated function: Required parameter $sortCriteria follows optional parameter $count in include() (line571 in /var/www/civi_live/vendor/composer/ClassLoader.php)`
After searching a li...Everytime cron runs I see this message in logs:
`Deprecated function: Required parameter $sortCriteria follows optional parameter $count in include() (line571 in /var/www/civi_live/vendor/composer/ClassLoader.php)`
After searching a little bit the only place which makes sense for this message is ezcMailImapTransport->sortFromOffset() in vendor/zetacomponents/mail/src/transports/imap/imap_transport.php
My setup:
- drupal 9.3.19
- CiviCRM 5.51.1
- PHP 8.0
I don't knowwhere this dependency comes from but this library needs an update for PHP 8.0 - or it should be considered to use another dependency. For IMAP handling I have good experiences with https://github.com/ddeboer/imaphttps://lab.civicrm.org/dev/core/-/issues/3770Figure out how to offer preferredLanguage in api explorer with options2024-03-20T05:03:26ZeileenFigure out how to offer preferredLanguage in api explorer with optionsFrom discussion of adding preferredLanguage - options should be explorer-discoverable
https://github.com/civicrm/civicrm-core/pull/24116#pullrequestreview-1057986655From discussion of adding preferredLanguage - options should be explorer-discoverable
https://github.com/civicrm/civicrm-core/pull/24116#pullrequestreview-1057986655https://lab.civicrm.org/dev/core/-/issues/5096SearchKit displays break hook_civicrm_links implementations2024-03-20T02:49:14ZAndie HuntSearchKit displays break hook_civicrm_links implementations[hook_civicrm_links](https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_links/) allows extension developers to modify the action links (e.g. View, Edit, Delete, etc.) at the ends of rows in a display. However, SearchKit doesn't se...[hook_civicrm_links](https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_links/) allows extension developers to modify the action links (e.g. View, Edit, Delete, etc.) at the ends of rows in a display. However, SearchKit doesn't seem to have a way to handle this.
As a consequence, the project of marching through all of the listing displays and replacing them with SearchKit forms means that we're in the process of systematically breaking nearly every implementation of hook_civicrm_links and providing no way to resolve it.
Ideally, the same `$op` strings would be used so that existing extensions could continue working as-is, but I'm not seeing how to provide all the necessary arguments to the hook.
Alternatively, it would be very useful to have a way for an extension to modify the links without reimplementing the entire display (or else we'll inevitably see them start to clash).
But at the very least, we need to have clear guidance for how to reimplement an extension for more recent versions of CiviCRM. We've noticed it in contact summary Relationships tab extensions, but soon it will be a lot.https://lab.civicrm.org/dev/core/-/issues/5101Search Builder: Contact not in Tag don't takes contacts without tags into acc...2024-03-19T20:35:27ZglanzelSearch Builder: Contact not in Tag don't takes contacts without tags into accountOverview
----------------------------------------
In Search Generator When searching for not in Tag(s) it don't takes contacts without tags into account.
Reproduction steps
----------------------------------------
Click Search -> Sear...Overview
----------------------------------------
In Search Generator When searching for not in Tag(s) it don't takes contacts without tags into account.
Reproduction steps
----------------------------------------
Click Search -> Search Builder
and there choose
Contact -> Tags -> not in -> TagX.
as Search parameter.
Current behaviour
----------------------------------------
Only Persons with minimum one Tag but without TagX gets displayed.
Expected behaviour
----------------------------------------
Any Contact with Tags other than TagX **and** all Contacts without any Tag should be displayed.
Environment information
----------------------------------------
* CiviCRM:CiviCRM 5.73.alpha1
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/3769Change the default font family to sans-serif in print.css2024-03-19T20:19:43ZwmortadaChange the default font family to sans-serif in print.cssThe font family is set as `DejaVu Sans` but the fallback is `serif` in `print.css`. Surely this should be `sans-serif`?
See https://github.com/civicrm/civicrm-core/blob/master/css/print.css#L23
```
#crm-container {
overflow: visible ...The font family is set as `DejaVu Sans` but the fallback is `serif` in `print.css`. Surely this should be `sans-serif`?
See https://github.com/civicrm/civicrm-core/blob/master/css/print.css#L23
```
#crm-container {
overflow: visible !important;
font-family: DejaVu Sans, serif;
margin: 0px 10px 0px 10px;
}
```https://lab.civicrm.org/dev/core/-/issues/5077civicrm.css loaded on front end when frontend theme set to 'None - Unstyled'2024-03-19T07:32:11ZMichael McAndrewcivicrm.css loaded on front end when frontend theme set to 'None - Unstyled'Wondering if I have found a bug or am just misunderstanding/mistaken or I have missed a decision to change things but I have reproduced this on 5.70 and 5.71. It was not happening in 5.64.4
Steps to reproduce:
1. Clean CiviCRM on WordP...Wondering if I have found a bug or am just misunderstanding/mistaken or I have missed a decision to change things but I have reproduced this on 5.70 and 5.71. It was not happening in 5.64.4
Steps to reproduce:
1. Clean CiviCRM on WordPress install
2. Set front end theme to **automatic**
3. Go to a front end page, e.g. /civicrm/mailing/subscribe
4. Notice that /wp-content/plugins/civicrm/civicrm/css/civicrm.css has been loaded - **good!**
5. Set front end theme **none - unstyled**
6. Go to a front end page, e.g. /civicrm/mailing/subscribe
7. Notice that /wp-content/plugins/civicrm/civicrm/css/civicrm.css has been loaded **- bad!**https://lab.civicrm.org/dev/core/-/issues/3757Users with administer_reports should be able to delete dashlets from the dash...2024-03-19T05:03:27ZandyburnsUsers with administer_reports should be able to delete dashlets from the dashboardThe current behavior I see is anyone with `administer_reports` can access the "Access" tab in a given report in CiviReport. Therefore, they can create dashlets. However, upon making a dashlet available for the dashboard, these can not be...The current behavior I see is anyone with `administer_reports` can access the "Access" tab in a given report in CiviReport. Therefore, they can create dashlets. However, upon making a dashlet available for the dashboard, these can not be removed by that same user, potentially resulting in a cluttered dashboard and user frustration.
Non-admins are missing trash can delete function:
![image](/uploads/206f154220c69227a784cc2d40e87a39/image.png)
Admin sees trash can:
![image](/uploads/21dbc1ca9cc3247a4752324df98a68b2/image.png)
Sure, interest in civireport is quite low now but this same behavior affects dashlets created from search kit.
For search kit, I would set that `administer data` or maybe `administer_reports` would be the needed permission to remove dashlets. Currently, it is not enough.https://lab.civicrm.org/dev/core/-/issues/4052Problem with custom group fields when cache get returns NULL from 'CRM_Core_D...2024-03-18T23:41:32ZLeanderJCCProblem with custom group fields when cache get returns NULL from 'CRM_Core_DAO_CustomGroup_QueryMultipleFields *' cache keyOverview
----------------------------------------
We had a problem where we did an APIv3 call on participants where it would cause an error resulting in a 500 response.
Some stack tracing showed us that in CRM/Core/BAO/CustomGroup.php t...Overview
----------------------------------------
We had a problem where we did an APIv3 call on participants where it would cause an error resulting in a 500 response.
Some stack tracing showed us that in CRM/Core/BAO/CustomGroup.php the code `$multipleFieldGroups = $cache->get($multipleFieldGroupCacheKey);` returned NULL (line 576). Since there is no check that says that it should not be NULL the code continues and errors on `if (in_array($table, $multipleFieldGroups) &&` because
> Argument #2 ($haystack) must be of type array, null given in in_array().
Reproduction steps
----------------------------------------
Could not specifically reproduce this with a clean install.
Current behaviour
----------------------------------------
Our page where the APIv3 Participant call was made would return a 500.
```
TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in in_array() (line 611 of /var/www/html/vendor/civicrm/civicrm-core/CRM/Core/BAO/CustomGroup.php)
#0 /var/www/html/vendor/civicrm/civicrm-core/CRM/Core/BAO/CustomGroup.php(611): in_array('civicrm_value_r...', NULL)
#1 /var/www/html/vendor/civicrm/civicrm-core/api/v3/utils.php(1449): CRM_Core_BAO_CustomGroup::getTree('Participant', Array, 1982, NULL, Array, NULL, true, NULL, true, false)
#2 /var/www/html/vendor/civicrm/civicrm-core/api/v3/Participant.php(154): _civicrm_api3_custom_data_get(Array, NULL, 'Participant', '1982', NULL)
#3 /var/www/html/vendor/civicrm/civicrm-core/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_participant_get(Array)
#4 /var/www/html/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke(Array)
#5 /var/www/html/vendor/civicrm/civicrm-core/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest(Array)
#6 /var/www/html/vendor/civicrm/civicrm-core/api/api.php(133): Civi\API\Kernel->runSafe('Participant', 'get', Array)
```
Expected behaviour
----------------------------------------
The page should load as normal.
Environment information
----------------------------------------
* __CiviCRM:__ _5.55.1_
* __PHP:__ _8.0.24_
* __CMS:__ _Drupal 9.4.8_
* __Database:__ _8.0.26_
* __Web Server:__ _nginx/1.20.2_
Comments
----------------------------------------
We fixed this issue by switching to APIv4 so it would no longer automatically get the custom groups and fields for the participant, but this still seemed a general issue to report.
I believe an if, at line 578 after settings the variable, would fix this issue.
```
if ($multipleFieldGroups === NULL) {
$multipleFieldGroups = [];
}
```https://lab.civicrm.org/dev/core/-/issues/5090Display of autocomplete multi-select custom fields for events is broken2024-03-18T23:14:49ZDetlev SieberDisplay of autocomplete multi-select custom fields for events is broken## Overview
For events, the display of autocomplete multi-select fields does not work anymore.
## Reproduction steps
1. Create a custom field for events:
1. Data Type Alphanumeric
2. Field Input Type: autocomplete
3. Multi-Se...## Overview
For events, the display of autocomplete multi-select fields does not work anymore.
## Reproduction steps
1. Create a custom field for events:
1. Data Type Alphanumeric
2. Field Input Type: autocomplete
3. Multi-Select: check
4. Add two options (e.g. "value1", "value2")
2. Edit an event, select "value1", Save.
3. Open the event again: the selected value(s) are not displayed (however, they are stored in the database).
## Current behaviour
Stored values of autocomplete multi-select fields for events are not displayed.
(This might create problems, because when you save, then the existing values are overwritten/nulled)
## Expected behaviour
Stored values of autocomplete multi-select fields for events should be displayed.
## Environment information
* This worked well with CiviCRM 5.64.4, but since some time it is broken.
* Tested here with 5.71.1
## Workaround
* Field input type can be changed to "checkbox(es)" - which however might be ugly and un-usable if there are many option.5.71.2https://lab.civicrm.org/dev/core/-/issues/4969Angular manager module caching issue (TypeError in_array)2024-03-18T21:46:01ZJKingsnorthAngular manager module caching issue (TypeError in_array)Related question was raised here: https://civicrm.stackexchange.com/questions/46379/typeerror-in-array-angular-managerresolvedefaultmodules-civicrm-version-5
I think this is a recent change which might have caused the issues (or highlig...Related question was raised here: https://civicrm.stackexchange.com/questions/46379/typeerror-in-array-angular-managerresolvedefaultmodules-civicrm-version-5
I think this is a recent change which might have caused the issues (or highlighted them): https://github.com/civicrm/civicrm-core/commit/604cca726c6a238e0530b5f660ab0e11596da090#diff-b26b657986ef8b8163e79bcaf85afe628f6d5457193253bc6ff4c009cca44bf5
---
We're seeing an intermittent issue where pages fail to load with a fatal error. The only path we've detected it on is /civicrm/transact .
It's caused by `\Civi\Angular\Manager::resolveDefaultModules` looking for the 'basePages' array for a module definition, but it's not there. After some checking, it looks like the value is just null (ie, there's no definition set).
Digging back through \Civi\Angular\Manager::getModules we can see that this checks to see if `$this->cache->get('moduleNames');` is null. If it is, it rebuilds the list of modules and saves it to the cache, and then goes through each module and saves the definition to the cache - using separate cache key entries (I guess because otherwise the cache entry would be too big?)
```
$angularModules = $this->resolvePatterns($angularModules);
$this->cache->set('moduleNames', array_keys($angularModules));
foreach ($angularModules as $moduleName => $moduleInfo) {
$this->cache->set("module $moduleName", $moduleInfo);
}
```
If `moduleNames` is already set, then it rehydrates the data from the cache:
```
// Rehydrate modules from cache
else {
foreach ($moduleNames as $moduleName) {
$angularModules[$moduleName] = $this->cache->get("module $moduleName");
}
```
The problem I think we're seeing intermittently is that `$this->cache->get('moduleNames');` is set but the individual module definitions (or some of them at least) are not set `$this->cache->get("module $moduleName");` . This means the value is set as 'NULL', which is causing the original error.
I'm struggling to find the exact steps to recreate this issue, but I think the related code could do with tightening up in either case?
It doesn't look like we can rely on the 'module ...' cache entries being set if the 'moduleNames' entry is set?
Ping @colemanwhttps://lab.civicrm.org/dev/core/-/issues/5085Incorrect fee level saved when editing event participant2024-03-18T19:23:47Zchrisgaraffachris@aghstrategies.comIncorrect fee level saved when editing event participantOverview
----------------------------------------
Editing an event participant changes the fee level and amount listed, seemingly at random.
Reproduction steps
----------------------------------------
- Register a contact for an event ...Overview
----------------------------------------
Editing an event participant changes the fee level and amount listed, seemingly at random.
Reproduction steps
----------------------------------------
- Register a contact for an event that uses a price set for fees (I'm using Summer Solstice Day Concert from dmaster in this example). Doesn't matter if they register online or an admin adds their registration
- Select Bass - $ 25.00
- Save the event registration
- Edit the event registration
- Change nothing
- Click Save
Current behaviour
----------------------------------------
The Fee level on the participant changes to something else - the specific value seems random on the first save, then doesn't seem to change.
Settings for adding the event registration:
![image](/uploads/04829e0ca7f423daf94a29b56883da07/image.png)
Display after creating the registration:
![image](/uploads/028cb9da80776075397f2df2541ee7a5/image.png)
Display after editing the registration, changing nothing, and saving:
![image](/uploads/5e63e0f24e9de983944a6c0e5873e577/image.png)
Expected behaviour
----------------------------------------
The fee level shouldn't change
Environment information
----------------------------------------
* __CiviCRM:__ Reproduced on 5.70.2, 5.71.0, dmaster (5.73.alpha1)https://lab.civicrm.org/dev/core/-/issues/5099SearchKit UX: Rename the query tabs2024-03-18T18:23:24ZJonGoldSearchKit UX: Rename the query tabsWhen I saw the new tabbed interface for SK queries, I meant to submit a UX note. Today, one of my savvier clients was tripped up by the tab labels, which reminded me to come back.
Their particular error - they tried to add new columns ...When I saw the new tabbed interface for SK queries, I meant to submit a UX note. Today, one of my savvier clients was tripped up by the tab labels, which reminded me to come back.
Their particular error - they tried to add new columns with the "Select Fields" tab.
* We should relabel that - I like "Field Transformations", but that conflicts with the rewrite on displays. Bikeshedding welcome, but this is better in than out.
* "Query Info" is ambiguous - I recommend "Debugging" or "Developer Info".
* "Configure Settings" is also ambiguous but I struggle for something better. This is query metadata, but I don't know a good non-technical term to unambiguously communicate that. The best I have is "Save Options" but most people would read "Save" as a verb, not a noun.
* You can select fields under the "Select Fields" tab that aren't a column in the search, which leads to a crash on save. Is there a valid case for that? If not, we should limit the list. But that probably should be its own issue.https://lab.civicrm.org/dev/core/-/issues/5086Ability to export FormBuilder forms from the UI2024-03-18T15:35:22ZherbdoolAbility to export FormBuilder forms from the UIWe've got an export link for SearchKit, but if a saved search is wrapped up in a FormBuilder form there's no easy way to also export those files. I can imagine a modal with the text from the forms files (`*.html`, `*.json`) and a link to...We've got an export link for SearchKit, but if a saved search is wrapped up in a FormBuilder form there's no easy way to also export those files. I can imagine a modal with the text from the forms files (`*.html`, `*.json`) and a link to copy it. Or even ability to save the files as a zip file.
And I suppose we'd need an import link as well to import on a different site (similar to SearchKit's link).https://lab.civicrm.org/dev/core/-/issues/5082CiviCRM 5.70.0, 5.71.0 - With URL tracking enabled, a personalised "View in y...2024-03-18T15:33:44Zjustinfreeman (Agileware)CiviCRM 5.70.0, 5.71.0 - With URL tracking enabled, a personalised "View in your browser" link incorrectly replaces ? with & which causes CiviCRM to respond with error: "You do not have permission to access this page"CiviCRM 5.70.0, 5.71.0 - With URL tracking enabled, a personalised "View in your browser" link incorrectly replaces ? with & which causes CiviCRM to respond with error: "You do not have permission to access this page".
This happens when...CiviCRM 5.70.0, 5.71.0 - With URL tracking enabled, a personalised "View in your browser" link incorrectly replaces ? with & which causes CiviCRM to respond with error: "You do not have permission to access this page".
This happens when using a personalised "View in your browser" URL like this in the mailing, note the use of tokens:
https://goodcause.org.au/civicrm/mailing/view?id={mailing.key}&{contact.checksum}&cid={contact.contact_id}
Which is then incorrectly converted to - this only happens with URL tracking enabled. When URL tracking is disabled, no problems at all.
https://goodcause.org.au/civicrm/mailing/view&id=38&cs=838eae033aa8c2edb56f25b54a1edde5_1709775006_2880&cid=389
And then CiviCRM to respond with error: "You do not have permission to access this page"
The fix and workaround for this issue is to instead just use this token as the URL, which will render correctly.
{mailing.viewUrl}
It's not unreasonable to expect the personalised "View in your browser" URL will work, the first URL parameter should not be converted in this way. This may have implications for other types of URLs too.
Agileware Ref: CIVICRM-2230