Development issueshttps://lab.civicrm.org/groups/dev/-/issues2021-08-18T19:57:08Zhttps://lab.civicrm.org/dev/core/-/issues/2770Allow dedupe by websites2021-08-18T19:57:08ZJonGoldAllow dedupe by websitesOverview
----------------------------------------
I have imports of records with Facebook etc. profiles, which are imported as websites of type "Facebook". However, there's currently no option to dedupe by Facebook profile.
Comments
--...Overview
----------------------------------------
I have imports of records with Facebook etc. profiles, which are imported as websites of type "Facebook". However, there's currently no option to dedupe by Facebook profile.
Comments
----------------------------------------
Given the clever design of these classes, this literally is possible with two lines of code.5.42.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2769CiviCRM email validation failing incorrectly2022-02-24T00:33:56ZeileenCiviCRM email validation failing incorrectlyWe have an email address that we can't save. It looks like
`name.-o-.i.10@example.com`
It took a while to figure out because it turned out we [hacked the quickform rule to be 'less restrictive'](https://issues.civicrm.org/jira/browse/C...We have an email address that we can't save. It looks like
`name.-o-.i.10@example.com`
It took a while to figure out because it turned out we [hacked the quickform rule to be 'less restrictive'](https://issues.civicrm.org/jira/browse/CRM-16313) and specifically to support domains like test@ēxāmplē.co.nz
We further hacked this hack to be more workable in dev/core#1469
We actually have a rule in civicrm that calls ``return (bool) filter_var($value, FILTER_VALIDATE_EMAIL);`` and is maintained as part of php.
My plan is
1) figure out how to add the email such that quickform doesn't implement it's rule
2) add it such that our rule is called
3) unhack the quickform package - we should be bypassing it by the time this is sorted out but having the hack there made this quite a bit harder to figure out so I think it makes sense to undo our damage - this appears to be the upstream https://github.com/pear/HTML_QuickForm/blob/trunk/QuickForm/Rule/Email.php#L50
@seamuslee - thoughts5.42.0https://lab.civicrm.org/dev/core/-/issues/2768APiv4 - where did getLanguage go?2021-08-26T02:06:48ZeileenAPiv4 - where did getLanguage go?I have an api that works on 5.39 but fails on 5.41 which was using `setLanguage` and `getLanguage` by inheritance
```
*
* @package Civi\Api4
*/
class Save extends \Civi\Api4\Generic\AbstractAction {
```
I will probably re-write the ...I have an api that works on 5.39 but fails on 5.41 which was using `setLanguage` and `getLanguage` by inheritance
```
*
* @package Civi\Api4
*/
class Save extends \Civi\Api4\Generic\AbstractAction {
```
I will probably re-write the code making this call & perhaps no-one else will hit it - but I'm a bit mystified at the disappearance5.41.0https://lab.civicrm.org/dev/core/-/issues/2767Contribution campaign is not propagated to activity campaign under certain ci...2021-08-17T20:46:55ZPatrick Figelpfigel@greenpeace.orgContribution campaign is not propagated to activity campaign under certain circumstancesWhen existing contributions with a non-completed activity status are updated via e.g. API3, and no explicit `campaign_id` parameter is set in the API request (because the campaign has already been set previously), `campaign_id` is not pr...When existing contributions with a non-completed activity status are updated via e.g. API3, and no explicit `campaign_id` parameter is set in the API request (because the campaign has already been set previously), `campaign_id` is not propagated to the created contribution activity. This is a common code path e.g. in CiviBanking.
This was introduced in 5.29 with [this](https://github.com/civicrm/civicrm-core/pull/17881), so it's not a particularly recent regression.
PR: https://github.com/civicrm/civicrm-core/pull/211675.42.0https://lab.civicrm.org/dev/core/-/issues/2766No way to distinguish the core and custom fields on Find and Merge Duplicate...2021-10-06T11:45:32ZyashodhaNo way to distinguish the core and custom fields on Find and Merge Duplicate Contacts pageThere is no way to distinguish the core and custom fields on _Find and Merge Duplicate Contacts_ page.
This is particularly confusing as one of the clients had a custom field named email and created the rule using this custom field and e...There is no way to distinguish the core and custom fields on _Find and Merge Duplicate Contacts_ page.
This is particularly confusing as one of the clients had a custom field named email and created the rule using this custom field and every time someone registered an event which was configured with this aforesaid rule it was attributed to a new contact.
![email](/uploads/e6e8d94daf35826701d57495c24f46b8/email.png)
We should be using _Custom Field: Custom Group_ format to avoid confusion as we do elsewhere in Import mapping screens, etc.
![email](/uploads/0f5542067f01fdce77705353eb9d5628/email.png)yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/2765Revisit the decision to enforce the CMS new user account option, allow CiviCR...2023-09-26T05:03:25Zjustinfreeman (Agileware)Revisit the decision to enforce the CMS new user account option, allow CiviCRM to create CMS user accounts when CMS has public registrations disabledRaising this a request to revisit the decision [originating in 2009 (CRM-4036)](https://issues.civicrm.org/jira/browse/CRM-4036.html) to enforce the CMS new user account option and instead **allow CiviCRM to create CMS user accounts when...Raising this a request to revisit the decision [originating in 2009 (CRM-4036)](https://issues.civicrm.org/jira/browse/CRM-4036.html) to enforce the CMS new user account option and instead **allow CiviCRM to create CMS user accounts when CMS has public registrations disabled**.
There are three key reasons to have this functionality:
1. Public registrations on websites attract spamming and therefore require moderation and anti-spam systems to be in place.
2. For member-only websites, the method to because a member is using the membership sign-up form (CiviCRM) and when the membership fee is paid, that's when the corresponding CMS user account should be created. And not by any other means.
3. With user account creation disabled, a separate and in some cases manual process needs to be performed to create the corresponding user account for members - which is a waste of effort.
With the current logic where CiviCRM uses the CMS configuration, the site must be open for public user registrations to support CiviCRM registering a member user account.
The change is relatively simple and would be removing the check of the user registration option for each supported CMS. Thus CiviCRM Profiles can be used to create CMS accounts.
See also related, _User Profiles, the User account registration option is displayed even when the CMS has the "User can register" option disabled_ - https://lab.civicrm.org/dev/user-interface/-/issues/41
Agileware Ref: CIVICRM-1809https://lab.civicrm.org/dev/user-interface/-/issues/41User Profiles, the User account registration option is displayed even when th...2021-08-18T20:53:13Zjustinfreeman (Agileware)User Profiles, the User account registration option is displayed even when the CMS has the "User can register" option disabledUser Profiles, the User account registration option is displayed even when the CMS has the "User can register" option disabled. This does not make sense - the logic in CiviCRM is to not allow CMS users to be created and this is not expla...User Profiles, the User account registration option is displayed even when the CMS has the "User can register" option disabled. This does not make sense - the logic in CiviCRM is to not allow CMS users to be created and this is not explained at all on this form.
The [originating task in 2009 (CRM-4036)](https://issues.civicrm.org/jira/browse/CRM-4036.html) even said: "For above scenarios we should also hide user creation option via profile." - which I interpret, perhaps incorrectly as referring to the CiviCRM Profile form.
The change required here is to **hide** the **user account registration options** that are currently shown on the CiviCRM Profile, if the CMS does not allow user registrations.
![Screenshot_20210817_172343](/uploads/b8706c59e1095be9d56440aef1b4a1c1/Screenshot_20210817_172343.png)
![Screenshot_20210817_172110](/uploads/23cd652a9c901af3c912de7dc775bc4b/Screenshot_20210817_172110.png)
Agileware Ref: CIVICRM-1809https://lab.civicrm.org/dev/core/-/issues/2764User Profiles, the User account registration option is displayed even when th...2021-08-17T07:25:35Zjustinfreeman (Agileware)User Profiles, the User account registration option is displayed even when the CMS has the "User can register" option disabledUser Profiles, the User account registration option is displayed even when the CMS has the "User can register" option disabled. This does not make sense - the logic in CiviCRM is to not allow CMS users to be created and this is not expla...User Profiles, the User account registration option is displayed even when the CMS has the "User can register" option disabled. This does not make sense - the logic in CiviCRM is to not allow CMS users to be created and this is not explained at all on this form.
The [originating task in 2009 (CRM-4036)](https://issues.civicrm.org/jira/browse/CRM-4036.html) even said: "For above scenarios we should also hide user creation option via profile." - which I interpret, perhaps incorrectly as referring to the CiviCRM Profile form.
![Screenshot_20210817_172343](/uploads/5e2135d33dc0e5edb43f78eb2d567039/Screenshot_20210817_172343.png)
![Screenshot_20210817_172110](/uploads/437f72da326e2aafa2b3061f6272894c/Screenshot_20210817_172110.png)
Agileware Ref: CIVICRM-1809https://lab.civicrm.org/dev/core/-/issues/2763Caching issue on apiv4 + install2021-08-17T23:07:14ZeileenCaching issue on apiv4 + installI'm hitting issues updating to 5.41 with caching of api entities - the issue is that `init` is being called before the entities are added and then after - but it's early exiting after. I'm not 100% sure why it has changed but it is causi...I'm hitting issues updating to 5.41 with caching of api entities - the issue is that `init` is being called before the entities are added and then after - but it's early exiting after. I'm not 100% sure why it has changed but it is causing fatals when
registering managed entities - even though I check that SearchKit is installed before declaring search displays they fail to install as it failes to find the DAO
I assume this is related to caching work @colemanw did in some way
The issue is occurring with the command
```
cv en --ignore-missing search_kit wmf-civicrm
```
which is including a SearchDisplay but ONLY IF
```
civicrm_api3('Extension', 'getcount', [
'full_name' => 'org.civicrm.search_kit',
'status' => 'installed',
]
```
However, - the newly installed does not have a 'dao' SearchDisplay entity
The back trace is
![image](/uploads/34349b2c6efbf9abf8ac2915b7a98cfa/image.png)
![image](/uploads/3c34136e0b16e67e4e991c5772ac49fe/image.png)https://lab.civicrm.org/dev/core/-/issues/2762CRM_Core_BAO_CustomField::getChangeSerialize always returns a change2021-08-18T16:28:02ZbenmoreassyntCRM_Core_BAO_CustomField::getChangeSerialize always returns a changeOverview
----------------------------------------
Editing certain types of custom field where multi-select in possible results in page hanging and fatal error returned by Ajax. This results in CiviCRM attempting to use the "CRM_Core_DAO:...Overview
----------------------------------------
Editing certain types of custom field where multi-select in possible results in page hanging and fatal error returned by Ajax. This results in CiviCRM attempting to use the "CRM_Core_DAO::VALUE_SEPARATOR" character to concatenate MySQL fields which may be integers. At that point MySQL throws an error for (eg) [nativecode=1067 ** Invalid default value for 'myintegerfield_year_142'] because the code is trying to enter a non-integer 'serialized' value.
[Problem originally identified on Stack Exchange](https://civicrm.stackexchange.com/questions/39591/illegal-text-in-mysql-queries)
Although this is a bug on all platforms, I have only been able to trigger the error on a Windows server. I presume this relates somehow to encoding of the "CTRL-A" character used as a serialization separator, which is converted to a string representation (eg '\x01').
Reproduction steps
----------------------------------------
1. Create a custom date field or select field via Administer > Custom Fields.
1. Ensure that any select field does NOT have 'multi-select' enabled.
1. Ensure that the field type to be stored is not a string (ie DATETIME or INT).
1. Save.
1. Edit the field you have just created. Change anything, but leave multi-select disabled as before.
1. Click save.
Current behaviour
----------------------------------------
Page appears to hang with a spinning 'activity happening' cursor.
Consulting data returned by Ajax call and logs reveals a fatal MySQL error arising from attempting to save a string into an integer field.
Extract from error log (full error attached)[error.txt](/uploads/015249119ad1dabf46fed1269313696d/error.txt):
```
"UPDATE `civicrm_value_tax_history_7` SET `date_completed_173` = SUBSTRING_IND...", "1292 ** Incorrect datetime value: '�%' for column 'date_completed_173' at row 1
```
Expected behaviour
----------------------------------------
Updated custom field should save without errors.
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.47.2, master
* PHP 7.3
* Wordpress 5.8
* MySQL 5.7.34
* Apache 2.4.48
Suggested fix/patch
----------------------------------------
The following code appears not to account for a serialization status passed in as 'null' (which is passed to the method in the $params array as a string, rather than a null value) instead of boolean 0.
**Current code**
```php
protected static function getChangeSerialize($params) {
if (isset($params['serialize']) && !empty($params['id'])) {
if($params['serialize'] == 'null'){
$params['serialize'] = 0;
}
if ($params['serialize'] != CRM_Core_DAO::getFieldValue('CRM_Core_DAO_CustomField', $params['id'], 'serialize')) {
return (int) $params['serialize'];
}
}
return NULL;
}
```
**Suggested fix**
```php
protected static function getChangeSerialize($params) {
if (isset($params['serialize']) && !empty($params['id'])) {
if($params['serialize'] == 'null'){
$params['serialize'] = 0;
}
if ($params['serialize'] != CRM_Core_DAO::getFieldValue('CRM_Core_DAO_CustomField', $params['id'], 'serialize')) {
return (int) $params['serialize'];
}
}
return NULL;
}
```
It's possible that the fix would be better handled wherever a '0' value for a `civicrm_custom_field`.`serialize` field is converted to (string)'null' rather than an INT, but the fix above resolved the problem for me.
[Suggested patch](/uploads/699365c91b0c8fda4f5bc1a69474ad2b/patch)5.42.0https://lab.civicrm.org/dev/translation/-/issues/71Full Month Names: avoid relying on the operating system's locale for translation2021-09-07T14:23:31ZbgmFull Month Names: avoid relying on the operating system's locale for translationThis kind of question comes up from time to time:
https://civicrm.stackexchange.com/questions/35468/date-in-english-even-when-page-is-set-to-french/40170
> "The date is always uses English month and day names regardless of the interfa...This kind of question comes up from time to time:
https://civicrm.stackexchange.com/questions/35468/date-in-english-even-when-page-is-set-to-french/40170
> "The date is always uses English month and day names regardless of the interface language. How do I fix this?"
The main issue is because currently translating the month name relies on the operating system. The non-English locale must be enabled so that `strftime` outputs the correct month name (ex: "janvier" not "January").
Most people somewhat control their hosting environment, and can enable it once they know how, but since the default CiviCRM date format uses `%B` (full month name), it gives a bad first impression. Considering we already have those strings in Transifex, it would be easy to just hardcode the list of months and translate using 'ts'.5.43.0bgmbgmhttps://lab.civicrm.org/dev/financial/-/issues/1805.41 rc - order api stores totals incorrectly when line items not passed in2021-08-27T05:28:36ZKarinG5.41 rc - order api stores totals incorrectly when line items not passed inReproduced on automated testing ->
5.41rc fails ->
![image](/uploads/9b90e5365869ca73f41a5f32b53ff22d/image.png)
We'll need to check if 5.40 is ok - more later!Reproduced on automated testing ->
5.41rc fails ->
![image](/uploads/9b90e5365869ca73f41a5f32b53ff22d/image.png)
We'll need to check if 5.40 is ok - more later!5.41.0https://lab.civicrm.org/dev/core/-/issues/2760Proposal: Stop storing file ids in two tables2023-04-17T15:39:24ZcolemanwProposal: Stop storing file ids in two tablesFile fields in CiviCRM are strange.
When you upload a file to a custom field, it stores a record in the `civicrm_file` table. Then it stores that id in **two** other tables. Once in the custom value column for that field, as you'd expec...File fields in CiviCRM are strange.
When you upload a file to a custom field, it stores a record in the `civicrm_file` table. Then it stores that id in **two** other tables. Once in the custom value column for that field, as you'd expect, and then it also adds a record in the `civicrm_entity_file` table.
https://github.com/civicrm/civicrm-core/blob/5.40/CRM/Core/BAO/CustomValueTable.php#L161-L171
From a data archetecture POV, there's no upside to storing the same value twice in two places, it just creates problems.https://lab.civicrm.org/dev/core/-/issues/2758Membership Dashboard - Fatal Error starting with 5.41.beta12021-08-18T10:27:08ZkcristianoMembership Dashboard - Fatal Error starting with 5.41.beta1Go to Membership Dashboard - http://wpcvrc.test/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fmember&reset=1
Expected result is seeing recent memberships.
Actual result - Fatal Error
```
[15-Aug-2021 15:01:30 America/New_York] PHP Fatal...Go to Membership Dashboard - http://wpcvrc.test/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fmember&reset=1
Expected result is seeing recent memberships.
Actual result - Fatal Error
```
[15-Aug-2021 15:01:30 America/New_York] PHP Fatal error: Uncaught TypeError: Argument 1 passed to CRM_Core_Task::getTitlesFilteredByPermission() must be of the type array, null given, called in /srv/www/buildkit/wpcvrc/web/wp-content/plugins/civicrm/civicrm/CRM/Member/Task.php on line 154 and defined in /srv/www/buildkit/wpcvrc/web/wp-content/plugins/civicrm/civicrm/CRM/Core/Task.php:204
Stack trace:
#0 /srv/www/buildkit/wpcvrc/web/wp-content/plugins/civicrm/civicrm/CRM/Member/Task.php(154): CRM_Core_Task::getTitlesFilteredByPermission(NULL, true)
#1 /srv/www/buildkit/wpcvrc/web/wp-content/plugins/civicrm/civicrm/CRM/Member/Form/Search.php(126): CRM_Member_Task::permissionedTaskTitles(1)
#2 /srv/www/buildkit/wpcvrc/web/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php(642): CRM_Member_Form_Search->buildQuickForm()
#3 /srv/www/buildkit/wpcvrc/web/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Display.php(76): CRM_Core_Form->buildForm()
#4 /srv/www/buildkit/wpcvrc/web/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM in /srv/www/buildkit/wpcvrc/web/wp-content/plugins/civicrm/civicrm/CRM/Core/Task.php on line 204
```
This is a regression in the RC as this error does not occur on stable (5.40.1)5.41.0https://lab.civicrm.org/dev/core/-/issues/2757Api v4 contact delete bug2022-01-19T14:47:09ZeileenApi v4 contact delete bugApiv4 Contact.delete is doing it's own thing rather than calling the BAO delete actions that need to run when a contact is deleted.
@colemanw I thought we'd fixed this? But it turns out the lack of a v4 membership api meant that it was ...Apiv4 Contact.delete is doing it's own thing rather than calling the BAO delete actions that need to run when a contact is deleted.
@colemanw I thought we'd fixed this? But it turns out the lack of a v4 membership api meant that it was switching back to v3 in the tests & hence giving us a false sense of security in v4
https://github.com/civicrm/civicrm-core/pull/21137https://lab.civicrm.org/dev/core/-/issues/2756Money - Regression? Edit contribution not possible with "," as decimal separator2021-08-14T03:56:46ZDetlev SieberMoney - Regression? Edit contribution not possible with "," as decimal separatorOverview
----------------------------------------
Money brick has had a large discussion recently.
With 5.40 at least one problem reappeared: If we have "," as decimal separator, saving of edited contribution is not possible - unless yo...Overview
----------------------------------------
Money brick has had a large discussion recently.
With 5.40 at least one problem reappeared: If we have "," as decimal separator, saving of edited contribution is not possible - unless you enter a decimal point instead of comma.
Reproduction steps
----------------------------------------
1. Menu: Administer > Localisation > Languages ...
1. Enter Thousands Separator = "." and Decimal Delimiter = ","
1. Search for a contribution of type donation, click on "edit"
1. Without changing anything, click "save" -> php errors, save won't work
1. Redo step 1 - 3
1. Change total amount to something with "." as decimal delimiter, "save" -> correct amount will be saved.
Current behaviour
----------------------------------------
Saving an amount with the correct decimal delimiter is not possible
Expected behaviour
----------------------------------------
Saving an amount should be possible without hacking the decimal delimiter
Environment information
----------------------------------------
* __CiviCRM:__ This bug was reproducable on CiviCRM 5.40.1. It does not happen on CiviCRM 5.39.0
* __PHP:__ _7.3/7.4_
* __CMS:__ _WordPress_
Comments
----------------------------------------
(none)5.42.0https://lab.civicrm.org/dev/core/-/issues/2755Proposal: add `civicrm_contact.image_file_id` column2023-04-20T00:24:59ZcolemanwProposal: add `civicrm_contact.image_file_id` columnProblem
-----------
Handling of contact images is nonstandard and difficult to work with.
Current Behavior
--------------
**Uploading a contact image will:**
1. Store the file in (by default) `civicrm/custom`.
2. Update the `civicrm_...Problem
-----------
Handling of contact images is nonstandard and difficult to work with.
Current Behavior
--------------
**Uploading a contact image will:**
1. Store the file in (by default) `civicrm/custom`.
2. Update the `civicrm_contact.image_URL` column with a link to an ajax callback for accessing the image.
3. Not create a record in the `civicrm_file` table.
4. Not create a record in the `civicrm_entity_file` table.
**Deleting a contact image in the UI will:**
1. Not delete the file.
2. Set `civicrm_contact.image_URL` to `null`.
Proposed New Behavior
-------------------
*Add a `civicrm_contact.image_file_id` column, FK to `civicrm_file.id`.*
**Uploading a contact image will:**
1. Store the file as before.
2. Update the `civicrm_contact.image_URL` column as before.
3. Create a record in the `civicrm_file` table.
4. Store the file id in the `civicrm_contact.image_file_id` column
5. *Undecided:* should an entry also be created in `civicrm_entity_file`? See #2760
**Deleting a contact image in the UI will:**
1. Delete the file if an id is present in `image_file_id` column.
2. Set `civicrm_contact.image_URL` and `civicrm_contact.image_file_id` to `null`.
See PR https://github.com/civicrm/civicrm-core/pull/21141https://lab.civicrm.org/dev/translation/-/issues/70Multi-lingual: Contact Type label is cached regarless of language2021-08-28T04:51:08ZbgmMulti-lingual: Contact Type label is cached regarless of languageTo reproduce:
* Enable multi-lingual
* Add a second language
* View a contact record, switch to the other language, then view the contact record again.
Note that the "Contact Type" will always be the same in both languages.
![contactt...To reproduce:
* Enable multi-lingual
* Add a second language
* View a contact record, switch to the other language, then view the contact record again.
Note that the "Contact Type" will always be the same in both languages.
![contacttype-2021-08-12_15-29](/uploads/d72800debe08abdc071edfd036113a88/contacttype-2021-08-12_15-29.png)
The root of the bug is in `CRM/Contact/Page/View/Summary.php` `getAllContactTypes`, the cache does not take language into account:
```
protected static function getAllContactTypes() {
if (!Civi::cache('contactTypes')->has('all')) {
$contactTypes = (array) ContactType::get(FALSE)
->setSelect(['id', 'name', 'label', 'description', 'is_active', 'is_reserved', 'image_URL', 'parent_id', 'parent_id:name', 'parent_id:label'])
->execute()->indexBy('name');
```
@eileen Would it make sense to add the language to `has('all')`? I'm not too familiar with the cache service, and suspect there will be similar issues in other places.5.42.0https://lab.civicrm.org/dev/core/-/issues/2754Change Do Not SMS privacy icon2022-07-16T20:24:21ZandyburnsChange Do Not SMS privacy iconThe Do Not SMS fa icon (fa-mobile) is misleading on the phone block. It looks like a smart phone which nearly everyone has and misleadingly conveys users that it is do not phone. Additionally, it's interesting to note that even if it is ...The Do Not SMS fa icon (fa-mobile) is misleading on the phone block. It looks like a smart phone which nearly everyone has and misleadingly conveys users that it is do not phone. Additionally, it's interesting to note that even if it is a landline phone type the do not SMS flag still shows there. That's a smaller issue here.
![image](/uploads/0844e5c6e276122f8711f0b149f5dc93/image.png)
This should be switched to something like `fa-comments-o` icon.
![image](/uploads/c70f959cf8eda20e6fe52e1da9767215/image.png)
I can't find where this is changed, https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/Contact/Page/Inline/Phone.tpl#L22 would like to switch out soon.https://lab.civicrm.org/dev/user-interface/-/issues/38Edit Contact: Hide email signatures for contacts that do not have a user/CMS ...2021-08-13T13:44:57ZbgmEdit Contact: Hide email signatures for contacts that do not have a user/CMS accountWhen editing a contact, we have an option to add an email signature which is then used when sending emails from CiviCRM (via Contact > Actions > Email).
It looks something like this:
![civicrm-signature-2021-08-11_17-13](/uploads/52db1...When editing a contact, we have an option to add an email signature which is then used when sending emails from CiviCRM (via Contact > Actions > Email).
It looks something like this:
![civicrm-signature-2021-08-11_17-13](/uploads/52db12ee39ab5eac17e2e24cf37de1be/civicrm-signature-2021-08-11_17-13.png)
Expanding the signature block displays a WYSIWYG and text field to enter an email signature.
This small link is easy to overlook by experienced CiviCRM users, but pretty overwhelming to new CiviCRM users. Not only does expanding explode the UI in a pretty scary way, it's also in an area of CiviCRM that is very overwhelming (location type, On Hold, Mass Mail?, Primary?, Delete). Have you ever looked in the eyes of a user when they first see those options?
Anyway, small tiny improvement proposal: let's hide 'signature' for contacts-that-are-not-users, because it would have no purpose.
@justinfreeman Pinging you because I feel you may have thoughts on this.
Notes for me: `signature_html` in `CRM/Contact/Form/Edit/Email.php`, and add an 'if' in the tpl.5.42.0