Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-10-13T05:03:26Zhttps://lab.civicrm.org/dev/core/-/issues/816Contribution Details Report double amount when Credit Card Type Column is sho...2022-10-13T05:03:26ZScottyPspulver@ibafriends.orgContribution Details Report double amount when Credit Card Type Column is shown and Contribution was changedWhen running a Contribution Details report it seems to double the amount of the contribution when you enable the Credit Card Type column and have changed the Contribution amount. See in the attached screenshot from Sandbox. But I can rep...When running a Contribution Details report it seems to double the amount of the contribution when you enable the Credit Card Type column and have changed the Contribution amount. See in the attached screenshot from Sandbox. But I can replicated in 5.11 and 5.10.3 with Drupal 7.65 on Apache with PHP 5.6.39 and 5.5.62 MySQL.
To replicate:
1) Enter Contribution with Total amount for $5 then save
2) Edit Contribution with Total amount to $10 then save
3) Run Contribution Details with Credit Card Type column (screenshot with ($20) and without $10)
Hopefully I'm not missing something and this is actually a bug. Thanks!
![WithCreditCardType](/uploads/0181982614aa26c60e5da0fa43b33fac/WithCreditCardType.png)
![WithoutCreditCardType](/uploads/bc2bd115149d90b9c10eb119b03fe59f/WithoutCreditCardType.png)
![Contribution](/uploads/020b93143fc4d5ff5360bd839990c1fa/Contribution.png)https://lab.civicrm.org/dev/core/-/issues/817META - improve code quality2024-02-29T20:06:14ZeileenMETA - improve code qualityI'm writing this as a place to group together various efforts to improve our code quality - this means we can link towards other issues that reflect where we are going code-wise.
In general from a product maintenance point of view the ...I'm writing this as a place to group together various efforts to improve our code quality - this means we can link towards other issues that reflect where we are going code-wise.
In general from a product maintenance point of view the goals we have are
1) ongoing improvement in code stability through
- adding test coverage,
- fixing things 'the right way' rather than hack-fixes
- addressing buggy coding
- improving code commenting
- addressing underlying logic problems
- cleaning up known bad patterns
- extracting smaller functions out of larger functions
- improving code readability
- not adding new functionality (fields, logic etc and even bug fixes) to dirty code (either cleaning it up first or leaving well enough alone).
Note that is IS harder to get changes accepted into parts of the code which are nasty - this is a feature not a bug. It's also harder to get changes reviewed & accepted into areas with poor test coverage. As I write this prs to alter sending out invoices and code impacting on imports are notably stagnating. This reflects an unwillingness to touch those code areas unless unit tests are being added as they have almost no coverage. (of course we also want tests on more tested code areas...)
2) ongoing improvement in performance through
- removing bad joins & bad queries
- php improvements
3) ensuring secure code practices are used
4) adapting the code to new versions of mysql & php as they become relevant
6) laying the ground work for LeXIM through
- moving logic out of the form layer and into the BAO, api xml or other metadata where appropriate
- improving api interaction with the code (making more stuff api-accessible & making it more logical & consistent)
- adding hooks, regions etc, although not into dirty code as that locks in suboptimal fixes.
- improving hook consistency
There are other goals for CiviCRM as a product - in the Leap By Extension / funded projects part of the LeXIM picture which are outside the scope of the concerns of product maintenance. It should be noted that the there is limited capacity to review PRs submitted to core so fit with these will affect how high a priority product mtce reviewers give to PRs. Of course other things play into the prioritisation like whether the submitter has been actively reviewing other PRs.
I'm going to start adding / linking issues that relate to cleaning up known bad patterns here
**Related issues**
~~Remove ->free calls https://lab.civicrm.org/dev/core/issues/562~~
~~Performance - done, remove use of mysql LOWER~~
Switch core forms to Entity Forms https://lab.civicrm.org/dev/core/issues/818 - also https://lab.civicrm.org/dev/core/issues/115
~~Get rid of jcalendar https://lab.civicrm.org/dev/core/issues/561~~
Use TempTable class for all temp tables - https://lab.civicrm.org/dev/core/issues/183
Consolidate settings & preference forms onto being metadata driven https://lab.civicrm.org/dev/core/issues/495
Consolidate recurring forms https://lab.civicrm.org/dev/core/issues/846
Use guzzle to get http requests https://lab.civicrm.org/dev/core/issues/849 (for testability)
Get rid of nullArray usage https://lab.civicrm.org/dev/core/issues/1047
Remove non-std contribution_invoice_settings https://lab.civicrm.org/dev/core/issues/1558https://lab.civicrm.org/dev/core/-/issues/818CQ: Switch core forms to be Entity Forms2022-10-31T05:03:14ZeileenCQ: Switch core forms to be Entity FormsWe have switched some forms already to use the EntityFormTrait as part of the following goals
1) move data about the fields on the forms into the schema xml - this will be important to help us migrate away from quick form
2) support cus...We have switched some forms already to use the EntityFormTrait as part of the following goals
1) move data about the fields on the forms into the schema xml - this will be important to help us migrate away from quick form
2) support custom data on a wide range of entities - several entities already support custom data as a result of having been switched to entity forms - relationship type form, membership status, financial type, price set etc
3) support parameters passed through the url in a non ad-hoc way - we have a history of security issues are url parameters so any new retrieval should be stdised & we need to work to remove existing ones
4) support extension intervention in the fields displayed - this is particularly supported by the tpl changes in the entity form structure
5) generalised reduction in unecessary code
6) improving translation consistency
What is involved in the Entity Form is best understood by looking at existing examples but basically it consists of
- using the EntityFormTrait
- ensuring the relevant things are declared on the class to support that
- declaring all the fields that can be added through metadata in the metadata array
- working towards simplifying the tpl to a single line {include file="CRM/Core/Form/EntityForm.tpl"}
Generally in any change we can take steps towards this rather than fully implement ithttps://lab.civicrm.org/dev/core/-/issues/819Search results: Actions: Export contacts: DB Error: Syntax error occurs when ...2019-03-27T20:08:45ZPradeep Nayakpradpnayak@gmail.comSearch results: Actions: Export contacts: DB Error: Syntax error occurs when not all necessary fields are selectedSTR:
* Navigate to "Search→Find Contacts"
* Leave the search fields empty and click "Search"
* Select any Individual
* Click the "Actions" dropdown
* Select "Export Contacts"
* Click the "Select fields for export" radio button
* Click ...STR:
* Navigate to "Search→Find Contacts"
* Leave the search fields empty and click "Search"
* Select any Individual
* Click the "Actions" dropdown
* Select "Export Contacts"
* Click the "Select fields for export" radio button
* Click "Continue"
* On the Select Fields to Export step, click the "Select record type" dropdown
* Select "Individual"
* Leave the "Select field" dropdown empty
* Click "Export"
**Result:** DB Error: syntax error occurs. Please take a look at the attachment
![ExportError-Before](/uploads/e97b8cb4b4dfb1ae5fed72dafcd4e459/ExportError-Before.gif)5.13.0https://lab.civicrm.org/dev/core/-/issues/820Send cancel request checkbox is tightly coupled to the ability to cancel recu...2022-10-14T05:03:25ZeileenSend cancel request checkbox is tightly coupled to the ability to cancel recurring contributions- but probably shouldn't beThe checkbox is shown because of
```
if ($this->_paymentProcessorObj->supports('cancelRecurring')) {
$params['send_cancel_request'] = 1;
}
```
However for many, perhaps most recurring subscriptions the checkbox is...The checkbox is shown because of
```
if ($this->_paymentProcessorObj->supports('cancelRecurring')) {
$params['send_cancel_request'] = 1;
}
```
However for many, perhaps most recurring subscriptions the checkbox is inappropriate as we are just changing the value in the contribution_recur table. We should be able to toggle those separately....
@mattwire add a new supportsNotifyGatewayOfRecurringChanges ?https://lab.civicrm.org/dev/core/-/issues/821Activity: Assigned to: It is not possible to search by the "refine search" dr...2019-03-27T02:24:04ZPradeep Nayakpradpnayak@gmail.comActivity: Assigned to: It is not possible to search by the "refine search" drop-downSteps:
* Find and open a profile of the contact from the precondition
* Click "Actions" → "Meeting"
* Open the "Assigned to" drop-down
* Choose e.g. the "Contact Type" option to the "refine search" list
* Try to choose some option to th...Steps:
* Find and open a profile of the contact from the precondition
* Click "Actions" → "Meeting"
* Open the "Assigned to" drop-down
* Choose e.g. the "Contact Type" option to the "refine search" list
* Try to choose some option to the "select" drop-down (e.g. Individual)
**Actual result:** It is not possible to search by the "refine search" drop-down.
**Expected result:** It is possible to search by the "refine search" drop-down
Possible regression : https://lab.civicrm.org/dev/core/issues/6775.12.0https://lab.civicrm.org/dev/core/-/issues/823Value in the "Contact Type" field disappears when the user tries to edit Cont...2019-05-09T21:44:17ZPradeep Nayakpradpnayak@gmail.comValue in the "Contact Type" field disappears when the user tries to edit Contact DetailsContact sub type is not pre-populated when trying to update contact using profile.Contact sub type is not pre-populated when trying to update contact using profile.https://lab.civicrm.org/dev/core/-/issues/824What to do with the merge screen2022-10-20T05:03:33ZeileenWhat to do with the merge screenI'm looking for ideas here. We have some requests to 'tweak' the merge screen. I'm mindful we could quickly hit the point where it would be easier to re-write it in angular so I don't want to slip into any significant re-write of the qui...I'm looking for ideas here. We have some requests to 'tweak' the merge screen. I'm mindful we could quickly hit the point where it would be easier to re-write it in angular so I don't want to slip into any significant re-write of the quickform code.
The issues basically boil down to
1) I'd like to be able to see the most salient details right at the top.
2) I'd like to be able to tweak the contacts from that screen more easily
Currently the details at the top of the screen are just name & modified date - the extra fields we would visible here are created_date and a custom field. Someone on chat said external_identifier would meet their requests. So we are not in the 'everyone agrees we should just stick this field there territory
![Screenshot_2019-03-27_15.52.19](/uploads/9d96565cb7fd753b30527ed9d6559081/Screenshot_2019-03-27_15.52.19.png)
Both needs would be somewhat met if we could replace the modified row (or add another row) with details coming out of a profile - in our case the summary-overlay profile would be just fine, and if that profile could be opened into edit more - as happens with the contact layout editor. However, I recall those blocks are not that re-usable & perhaps a modal edit launch is what we need.
In any case I'm leaning towards thinking that there is no sensible cleanup or core change I can do here, no pattern we are trying to roll out & perhaps just adding a mergeSummary region to the Merge.tpl & doing it by assigning a new region is the cleanest thing I can do? Alternatively instead of getting the details for the most-recent block through smarty calls we could assign from php - which feels cleaner at the smarty level (it also makes us less-committed to supporting it than a region does which I think it an OK compromise)
@colemanw @seamuslee @mattwire @jkingsnorth I'm interested in ideas herehttps://lab.civicrm.org/dev/core/-/issues/825Post help is shown differently for custom fields and profiles.2022-10-14T05:03:26ZyashodhaPost help is shown differently for custom fields and profiles.Post help is shown differently for custom fields and profiles.
For custom fields :
Pre help is displayed inline on the form (above the field). Post help is displayed in a pop-up - users click the help balloon to view help text.
![cust...Post help is shown differently for custom fields and profiles.
For custom fields :
Pre help is displayed inline on the form (above the field). Post help is displayed in a pop-up - users click the help balloon to view help text.
![custom_data](/uploads/5fa6144f7c9839e122448835af5fa4e1/custom_data.png)
For profiles :
Pre help and post help are explanatory text displayed to users for this field before and after fields respectively.
![profile](/uploads/e8cc5faf8cd5314e503e5716270ee00b/profile.png)
I think the standard should be followed with the profiles where post help is shown as a pop-up to keep it consistent. Users do get confused why the post help is not a pop-up.https://lab.civicrm.org/dev/core/-/issues/826Reports show " " in filters with child-groups2019-10-14T08:03:58ZCésarReports show " " in filters with child-groupsHi,
Im using CiviCRM 5.10.4 and I see in all reports ``` ``` when I use child-groups in filters.
![error_view](/uploads/7c72af518ab6a5c68ff00e0b21a4a7d3/error_view.png)Hi,
Im using CiviCRM 5.10.4 and I see in all reports ``` ``` when I use child-groups in filters.
![error_view](/uploads/7c72af518ab6a5c68ff00e0b21a4a7d3/error_view.png)https://lab.civicrm.org/dev/core/-/issues/827Error on showing Smart Groups2021-07-03T00:10:47ZbjoernError on showing Smart GroupsCiviCRM-Version 5.10.3
MySQL-Version: 5.7.25
PHP-Version: 7.2
Usecase: Select a contact, select the "Groups" Tab, then click on the SmartGroups accordeon.
Error message:
`Sorry an error occurred
One of parameters (value: ) is not of t...CiviCRM-Version 5.10.3
MySQL-Version: 5.7.25
PHP-Version: 7.2
Usecase: Select a contact, select the "Groups" Tab, then click on the SmartGroups accordeon.
Error message:
`Sorry an error occurred
One of parameters (value: ) is not of the type CommaSeparatedIntegers`
Debug message:
`/sites/all/modules/contrib/civicrm/CRM/Utils/Type.php(554): CRM_Core_Error::fatal("One of parameters (value: ) is not of the type CommaSeparatedIntegers")
/sites/all/modules/contrib/civicrm/CRM/Contact/BAO/Query.php(3255): CRM_Utils_Type::validate("", "CommaSeparatedIntegers")
`
The error appears in the function `public function tag(&$values)`
The delivered array for `$values` is:
```
... (Array, 5 elements)
0 (String, 3 characters ) tag
1 (String, 8 characters ) IS EMPTY
2 (String, 0 characters )
3 (Integer) 1
4 (Integer) 0
```
The parameter `$value` is set to `$values[2]`, here an empty string.
I think the error than happens on line 3253:
`
// implode array, then remove all spaces and validate CommaSeparatedIntegers
$value = CRM_Utils_Type::validate(
str_replace(' ', '', implode(',', (array) $value)),
'CommaSeparatedIntegers'
);
`
But as you can see in line 3289
```
if (in_array($op, array('IS NULL', 'IS NOT NULL', 'IS EMPTY', 'IS NOT EMPTY'))) {
$this->_where[$grouping][] = "({$etTable}.tag_id $op OR {$etCaseTable}.tag_id $op OR {$etActTable}.tag_id $op)";
}
```
the parameter `$value` is not used anyway, so I think it is OK for it beeing empty.https://lab.civicrm.org/dev/core/-/issues/828Child groups not visible in multisite using HTTP request, while ajax refresh ...2022-10-15T05:03:24Zjakub-sirokyChild groups not visible in multisite using HTTP request, while ajax refresh shows themIf you go to ?page=CiviCRM&q=civicrm/group&reset=1 using normal request, no groups are displayed.
The user has the right role assigned, which in turn has all rights applied: CiviCRM Multisite: view all contacts in domain,
CiviCRM Multi...If you go to ?page=CiviCRM&q=civicrm/group&reset=1 using normal request, no groups are displayed.
The user has the right role assigned, which in turn has all rights applied: CiviCRM Multisite: view all contacts in domain,
CiviCRM Multisite: edit all contacts in domain, CiviCRM Multisite: list all groups in domain
The groups show after (un)ticking any filters.
It only happen if the groups are children of current domain group. If the user creates a group without parent, it is shown.https://lab.civicrm.org/dev/core/-/issues/829Swaziland has changed its name to Eswatini2019-03-28T20:07:12Zlord_tSwaziland has changed its name to EswatiniSwaziland country has changed name to Eswatini so in CiviCRM it also has to be changed.
> On 19 April 2018, King Mswati III announced that the Kingdom of Swaziland had renamed itself the Kingdom of Eswatini, reflecting the extant Swazi...Swaziland country has changed name to Eswatini so in CiviCRM it also has to be changed.
> On 19 April 2018, King Mswati III announced that the Kingdom of Swaziland had renamed itself the Kingdom of Eswatini, reflecting the extant Swazi name for the state eSwatini, to mark the 50th anniversary of Swazi independence. The new name, **Eswatini**, [...]
Source: https://en.wikipedia.org/wiki/Eswatini#Independence_(1968%E2%80%93present)
Patch: https://github.com/civicrm/civicrm-core/pull/139025.13.0https://lab.civicrm.org/dev/core/-/issues/830Proposal - add cancel_reason field to civicrm_contribution_recur table2020-07-13T00:08:49ZeileenProposal - add cancel_reason field to civicrm_contribution_recur tableWe have a request to add a field cancel_reason to the civicrm_contribution_recur table.
The main reason to consider putting this in core (as opposed to a custom field) is that it would provide consistency with the civicrm_contribution ...We have a request to add a field cancel_reason to the civicrm_contribution_recur table.
The main reason to consider putting this in core (as opposed to a custom field) is that it would provide consistency with the civicrm_contribution table which has cancel_date & cancel_reason (the latter being toggled for visibility based on the former).
Associated cleanup
- I think it's kind of a condition of adding any UI feature / functionality/ new field to core that some sort of tangental cleanup is also done - I think probably the related area that could most do with some love is to add the field to the contribution search & add unit test coverage for the recurring contribution fields - they currently are not covered by any searches.
Review
- If we do this I will trade review with someone - probably Matt Wire as I don't assume someone will 'just review it'https://lab.civicrm.org/dev/core/-/issues/831Add permissions for edit (reserved) option groups2022-10-15T05:03:23Zmattwiremjw@mjwconsult.co.ukAdd permissions for edit (reserved) option groupsCurrently you require "Administer CiviCRM" permission to edit option groups. But then you can edit ALL option groups including reserved ones that may break the system.
I propose adding the following two permissions:
* Edit Option Group...Currently you require "Administer CiviCRM" permission to edit option groups. But then you can edit ALL option groups including reserved ones that may break the system.
I propose adding the following two permissions:
* Edit Option Groups
* Edit Reserved Option Groups
This is similar to permissions for tags/groups etc.
We could also add a tabbed interface to option groups so that reserved/non-reserved are on separate tabs (And the reserved view could be hidden if you don't have permission?).
## Use cases:
A counselling organisation manages a number of venues. Those venues change regularly and they update the option group that specifies those venues as required. They have no interest in any other option groups and certainly don't want to change reserved ones.
A "Teams" organisation has a set of attributes that they associate with teams. These need to be updated occasionally to add new attributes. The attributes are configured as option groups.https://lab.civicrm.org/dev/core/-/issues/832Long running sql queries from CiviCase2019-04-27T02:07:11ZPradeep Nayakpradpnayak@gmail.comLong running sql queries from CiviCaseWe have seen recently several sites with long running sql queries after upgrading to 5.10.3 that seem to relate to civicase.
```
Found slow query:
Id: 2479160
User: xxxx
Host: localhost
db: xxxxx
Command: Query
Time: 86
State: Copying t...We have seen recently several sites with long running sql queries after upgrading to 5.10.3 that seem to relate to civicase.
```
Found slow query:
Id: 2479160
User: xxxx
Host: localhost
db: xxxxx
Command: Query
Time: 86
State: Copying to tmp table
Info: SELECT COUNT(*) FROM (SELECT civicrm_case.id as case_id, civicrm_case.subject as case_subject, civicrm_contact.id as contact_id, civicrm_contact.sort_name as sort_name, civicrm_phone.phone as phone, civicrm_contact.contact_type as contact_type, civicrm_contact.contact_sub_type as contact_sub_type, t_act.activity_type_id, c_type.title as case_type, civicrm_case.case_type_id as case_type_id, cov_status.label as case_status, cov_status.label as case_status_name, t_act.status_id, civicrm_case.start_date as case_start_date, case_relation_type.label_b_a as case_role, t_act.desired_date as case_activity_date, t_act.id as case_activity_id, t_act.act_type_name as case_activity_type_name, t_act.act_type AS case_activity_type FROM civicrm_case
INNER JOIN civicrm_case_contact ON civicrm_case.id = civicrm_case_contact.case_id
INNER JOIN civicrm_contact ON civicrm_case_contact.contact_id = civicrm_contact.id LEFT JOIN
(
SELECT ca4.case_id, act4.id AS id, act4.activity_date_time AS desired_date, act4.activity_type_id, act4.status_id, aov.name AS act_type_name, aov.label AS act_type
FROM civicrm_activity act4
LEFT JOIN civicrm_case_activity ca4
ON ca4.activity_id = act4.id
AND act4.is_current_revision = 1
LEFT JOIN civicrm_option_group aog
ON aog.name='activity_type'
LEFT JOIN civicrm_option_value aov
ON aov.option_group_id = aog.id
AND aov.value = act4.activity_type_id
) AS t_act
ON t_act.case_id = civicrm_case.id
LEFT JOIN civicrm_phone ON (civicrm_phone.contact_id = civicrm_contact.id AND civicrm_phone.is_primary=1)
LEFT JOIN civicrm_relationship case_relationship
ON ( case_relationship.contact_id_a = civicrm_case_contact.contact_id AND case_relationship.contact_id_b = 17662
AND case_relationship.case_id = civicrm_case.id )
LEFT JOIN civicrm_relationship_type case_relation_type
ON ( case_relation_type.id = case_relationship.relationship_type_id
AND case_relation_type.id = case_relationship.relationship_type_id )
LEFT JOIN civicrm_case_type c_type
ON civicrm_case.case_type_id = c_type.id
LEFT JOIN civicrm_option_group cog_status
ON cog_status.name = 'case_status'
LEFT JOIN civicrm_option_value cov_status
ON ( civicrm_case.status_id = cov_status.value
AND cog_status.id = cov_status.option_group_id )
WHERE (1) AND civicrm_case.is_deleted = 0 AND civicrm_contact.is_deleted <> 1 AND civicrm_case.status_id != 2 GROUP BY case_id ORDER BY case_activity_date ASC ) temp
```
Looks like the query is generated from CRM_Case_BAO_Case::getCaseActivityQuery(). Any idea what changed in Civicase since 5.4?5.14.0https://lab.civicrm.org/dev/core/-/issues/833(DX) Make backtraces for API exceptions useful2022-10-16T05:04:38Ztotten(DX) Make backtraces for API exceptions usefulThe current API architecture began with this calling convention for checking errors:
```php
$result = civicrm_api(...);
if ($result['is_error']) ...
```
It quickly became a common problem that callers forgot to check the result for suc...The current API architecture began with this calling convention for checking errors:
```php
$result = civicrm_api(...);
if ($result['is_error']) ...
```
It quickly became a common problem that callers forgot to check the result for success/failure, so a thin wrapper was introduced which generated an exception instead of returning an error-value:
```php
try {
$result = civicrm_api3(...);
}
catch (API_Exception $e) {...}
```
This generally surfaces errors better, but then the next step is: what caused the error? How do I get a backtrace?
The backtrace always points to the wrapper function. If you want the real backtrace, you need to switch back to `civicrm_api()`, set `debug=1`, and inspect the output for `trace` info.
I don't have a quick solution. Questions to elicit thoughts/planning:
* Can one generate a synthetic exception?
* If the initial problem is reported as an exception, and if the error is reported to the consumer as an exception, is there some way to pass that along?
* What are the implications for an existing consumer which uses `civicrm_api3()` and looks for `API_Exception`?
* What are the implications for an existing consumer which uses `civicrm_api()` and looks for a `trace`?
* How does this fit into the lifecycle of API kernel (e.g. of events/listeners using `civi.api.exception`)?https://lab.civicrm.org/dev/core/-/issues/834Please add Option to define a sender for emailing a report for not to use de...2022-10-17T05:03:54ZtapashPlease add Option to define a sender for emailing a report for not to use default email address always.I have a report that is sending successfully every week. Only issue is I was not able to set FROM email address for the report. It’s always sent from default email address, but I would like to send it from different email. I wasn’t sure...I have a report that is sending successfully every week. Only issue is I was not able to set FROM email address for the report. It’s always sent from default email address, but I would like to send it from different email. I wasn’t sure if that functionality is available in CiviCRM or not. It would be nice to add this feature.
Thankshttps://lab.civicrm.org/dev/core/-/issues/835Expose Registered by Participant Name field to participant report2022-10-19T05:03:47ZyashodhaExpose Registered by Participant Name field to participant reportExpose *Registered by Participant Name* field to participant reportExpose *Registered by Participant Name* field to participant reportyashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/836Do not track CSS urls2019-03-31T20:27:29ZseamusleeDo not track CSS urlsAt the moment in Civimail if someone inserts a link tag like
```
<link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:400,700|Zilla+Slab:500,700' rel='stylesheet' type='text/css'>
```
CiviMail will convert it into a tr...At the moment in Civimail if someone inserts a link tag like
```
<link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:400,700|Zilla+Slab:500,700' rel='stylesheet' type='text/css'>
```
CiviMail will convert it into a trackable url5.13.0