Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-02-26T05:03:39Zhttps://lab.civicrm.org/dev/core/-/issues/1657Intermittent bug on processing membeships2023-02-26T05:03:39ZeileenIntermittent bug on processing membeshipsI'm opening this to track https://github.com/civicrm/civicrm-core/pull/16811 - as the test demonstrates there is a logic bug in the static for that code. However, we don't know how to replicate this in the wild & it's off my priority lis...I'm opening this to track https://github.com/civicrm/civicrm-core/pull/16811 - as the test demonstrates there is a logic bug in the static for that code. However, we don't know how to replicate this in the wild & it's off my priority list so let's track in gitlab
https://github.com/civicrm/civicrm-core/pull/16811https://lab.civicrm.org/dev/core/-/issues/1644Merge related activities not deleted when permanently deleting a contact2023-02-26T05:03:38ZeileenMerge related activities not deleted when permanently deleting a contactWhen a contact is merged into a another contact the following happens
- the data is moved over
- the merged contact is 'deleted'
- an activity is created of type 'Contact Merged' - source is logged in contact, target is the retained...When a contact is merged into a another contact the following happens
- the data is moved over
- the merged contact is 'deleted'
- an activity is created of type 'Contact Merged' - source is logged in contact, target is the retained contact
- If the merged contact is being deleted to trash an activity is created of type 'Contact Deleted by Merge' - source is logged in contact, target is deleted contact
When we later fully delete the contact deleted-by-merge only activities linked to no other contact are deleted - in other words the 'Contact Deleted by Merge' activity remains, linked to the source contact.
I believe this activity should be deleted on true-death , as it would not be present had they been fully deleted in the first instance
@pfigel @DaveDhttps://lab.civicrm.org/dev/joomla/-/issues/35[Joomla 4.0] Cannot access/set user permissions2023-02-25T12:13:56Znicol[Joomla 4.0] Cannot access/set user permissionsClicking the Joomla access control link (/administrator/index.php?option=com_config&view=component&component=com_civicrm) via either Civi (administrator/?option=com_civicrm&task=civicrm/admin/access&reset=1) or Joomla (administrator/inde...Clicking the Joomla access control link (/administrator/index.php?option=com_config&view=component&component=com_civicrm) via either Civi (administrator/?option=com_civicrm&task=civicrm/admin/access&reset=1) or Joomla (administrator/index.php?option=com_config#page-permissions) gives a fatal error. Without setting ACLs, the front end Civi links won't display - so this looks like a blocker for Joomla 4.0 compatibility.
According to Joomla 4's debugger the issue is:
`Compile Error: require_once(): Failed opening required '/Applications/MAMP/htdocs/Joomla_4.0.2/libraries/joomla/form/fields/rules.php' (include_path='.:/Applications/MAMP/bin/php/php7.3.7/lib/php')`
`
FatalError in /Joomla_4.0.2/administrator/components/com_civicrm/civicrm/joomla/libraries/joomla/form/fields/civiperms.php (line 6)
<?php
defined('JPATH_PLATFORM') or die;
// for some reason Joomla doesn't autoload JFormFieldRules in this context
require_once JPATH_SITE . '/libraries/joomla/form/fields/rules.php';
class JFormFieldCiviperms extends JFormFieldRules {
/**
* @var CRM_Core_Config
`Joomla 4 Integrationseamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/1582Display preferences settings "Do not notify assignees for" and "Include ICal ...2023-02-25T05:03:39ZDaveDDisplay preferences settings "Do not notify assignees for" and "Include ICal Invite to Activity Assignees" are only implemented in the form layerI'm unlikely to work on this but logging that these two display preferences are tied to the form layer and only referenced (either directly or indirectly) via CRM/Activity/Form/Activity.php, and so are ignored when using the api.
This i...I'm unlikely to work on this but logging that these two display preferences are tied to the form layer and only referenced (either directly or indirectly) via CRM/Activity/Form/Activity.php, and so are ignored when using the api.
This is not recent. I'm sure it has always been this way.https://lab.civicrm.org/dev/core/-/issues/692Unable to use url search arguments in 'Advanced Search' using force=12023-02-25T05:03:38ZMonish DebUnable to use url search arguments in 'Advanced Search' using force=1Currently, it is not possible to use URL search arguments in 'Advanced Search' using force=1 to load search results. This is no longer working except for mailing params which are manually handled [here](https://github.com/civicrm/civicrm...Currently, it is not possible to use URL search arguments in 'Advanced Search' using force=1 to load search results. This is no longer working except for mailing params which are manually handled [here](https://github.com/civicrm/civicrm-core/blob/5.10/CRM/Contact/Form/Search.php#L636L647).
Following are the steps to support URL search arguments Civi component-wise:
1. All the search forms extends the parent class ```CRM_Core_Form_Search``` that will define a new function ```loadSearchParamsFromUrl()```. Definition as follows
```php
function loadSearchParamsFromUrl() {
// In case no component is defined then lookout for basic contact search fields + all enanbled components search fields
if (!$this->_component) {
if (method_exists('CRM_Contact_Form_Search', 'setSearchParamFromUrl')) {
CRM_Contact_Form_Search::setSearchParamFromUrl($this);
}
foreach ($enabledComponents as $component) {
$searchClass = $component->namespace . '_Form_Search';
if (method_exists($searchClass, 'setSearchParamFromUrl')) {
$searchClass::setSearchParamFromUrl($form);
}
}
}
elseif (array_key_exists($this->_component, $enabledComponents)) { // $_component = 'CiviMail'
$searchClass = $enabledComponents[$this->_component]->namespace . '_Form_Search';
if (method_exists($searchClass, 'setSearchParamFromUrl')) {
// call CRM_Mailing_Form_Search::setSearchParamFromUrl()
$searchClass::setSearchParamFromUrl($form);
}
}
}
```
2. This function will be called by respective search form to find the search arguments from URL and set them accordingly. And will be handled in ```SearchClass::setSearchParamFromUrl($form);``` as:
```php
class CRM_Contact_Form_Search {
...
public static function setSearchParamFromUrl(&$form) {
foreach (CRM_Contact_Form_Search_Criteria::getBasicSearchFields() as $name => $type) {
if ($value = CRM_Utils_Request::retrieve($name, $type)) {
$form->_formValues[$name] = $value;
}
}
$form->_params = CRM_Contact_BAO_Query::convertFormValues($form->_formValues);
$form->set('formValues', $form->_formValues);
$form->set('queryParams', $form->_params);
}
}
```
The intent is to generalize the workflow and let each component's search form decide and hosts its list of search arguments (on basis of enabled component) rather than manually handling them in different places.5.11Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/4143Smarty bus errors2023-02-24T22:05:21ZeileenSmarty bus errorsSmarty can show bus errors under load
See
Truncating a compiled template leads to concurrency issues if another process is including the same file. See also CRM-11189 for a description of the "bus error" encountered when one of the co...Smarty can show bus errors under load
See
Truncating a compiled template leads to concurrency issues if another process is including the same file. See also CRM-11189 for a description of the "bus error" encountered when one of the concurrent processes dies.
CRM-19013: Compiled templates are truncated
CRM-11189: When CiviMail renders smarty templates for mailing, it saves them to disk
https://github.com/civicrm/civicrm-packages/pull/158https://lab.civicrm.org/dev/core/-/issues/4139Form Builder: Display only field fixes for date, checkbox, radio, select and ...2023-02-24T07:10:42ZKurund JalmiForm Builder: Display only field fixes for date, checkbox, radio, select and entity ref fieldsCurrently, display only fields shows raw values which works well only for text fields.
We need to fix the display for the following data types:
- Date
- Select
- Checkbox
- Radio
- Select
- Entity RefCurrently, display only fields shows raw values which works well only for text fields.
We need to fix the display for the following data types:
- Date
- Select
- Checkbox
- Radio
- Select
- Entity RefKurund JalmiKurund Jalmihttps://lab.civicrm.org/dev/core/-/issues/1570when formatting params for deduping, we do a case sensitive check for Primary2023-02-24T05:03:59Zjamiewhen formatting params for deduping, we do a case sensitive check for PrimaryI've run into a problem - when I call the `Profile.getfields` with `api_action=submit` and a profile_id, I get a nice list of fields in that profile, notably - the primary email field name is lowercased to `email-primary`.
When I fill o...I've run into a problem - when I call the `Profile.getfields` with `api_action=submit` and a profile_id, I get a nice list of fields in that profile, notably - the primary email field name is lowercased to `email-primary`.
When I fill out those fields and submit them to `CRM_Contact_BAO_Contact::getDuplicateContacts` I fail to find the duplicates that should be found.
It turns out that's because `getDuplicateContacts` calls `Dedupe_Finder::formatParams` which does some nice magic on primary style fields by finding them with:
`preg_match('/(.*)-(primary-[\d+])$|(.*)-(\d+|Primary)$/', strtolower($key), $matches)`
The capital P is what causes the problem.
I think it's safe to convert that to a lowercase check.jamiejamiehttps://lab.civicrm.org/dev/core/-/issues/1653Civi::paths() - Allow bare variable lookup via getUrl/getPath2023-02-24T05:03:58ZtottenCivi::paths() - Allow bare variable lookup via getUrl/getPathOverview
----------------------------------------
The `Civi::paths()->getUrl(...)` and `Civi::paths()->getPath(...)` have a quirky interpretation of bare variable expressions (eg `getPath('[civicrm.packages]')`).
Example use-case
------...Overview
----------------------------------------
The `Civi::paths()->getUrl(...)` and `Civi::paths()->getPath(...)` have a quirky interpretation of bare variable expressions (eg `getPath('[civicrm.packages]')`).
Example use-case
----------------------------------------
```
# (A) With a file/folder/subpath
cv ev "echo Civi::paths()->getUrl('[civicrm.packages]/foo/bar');"
# (B) No slash, no dot
cv ev "echo Civi::paths()->getUrl('[civicrm.packages]');"
# (C) With a slash
cv ev "echo Civi::paths()->getUrl('[civicrm.packages]/');"
# (D) With a slash and dot
cv ev "echo Civi::paths()->getUrl('[civicrm.packages]/.');"
```
Current behavior
----------------------------------------
In scenarios (A), (C), and (D), the value of `[civicrm.packages]` is substituted. But in situation (B), it is treated as a literal file-name and given the default prefix.
```
$ cv ev "echo Civi::paths()->getUrl('[civicrm.packages]');"
http://site/[civicrm.packages]
```
Proposed behavior
----------------------------------------
All examples -- including (B) -- should do substitution.
The `Civi\Core\PathsTest` should be expanded to check scenario (B).
Comments
----------------------------------------
[Historically](https://lab.civicrm.org/dev/wordpress/issues/47#note_33046), when `getPath()`/`getUrl()` were first drafted to support expressions like `[civicrm.files]/persist/contribute`, the primary concerns were (1) backward compatibility for older absolute+relative expressions (without any `[foo]` expressions) and (2) new use-cases like (A). The `[foo]` notation was conceived as an *optional prefix* (with an *implied default*) - and not as a straight-up *variable*. And if you *just* wanted a raw variable, I'd've imagined it'd be faster to call `getVariable()` (bypass the string-munging with `getPath()` etc).
OTOH, if you learned of this API by skimming docblocks or examples (without that historical context), then it'd be natural to assume that (B) would work, and it really is a more approachable interface that way.
Strictly speaking, it is a change in the contract for an obscure edge-case: if you had a file named `/var/www/sites/default/files/civicrm/[foo]`, and if you requested `getPath('[foo]')`, then it currently resolves to the file. With this change, it would interpret `[foo]` as a variable - the variable is probably undefined, which leads to an exception. You'd have to rewrite the call as `getPath('[civicrm.files]/[foo]')`. That's an exceedingly marginal edge-case, and I don't really think it's worth preserving.https://lab.civicrm.org/dev/core/-/issues/4126CiviCase Dashboard exports all records instead of the results2023-02-24T00:31:53ZJamesStephensCiviCase Dashboard exports all records instead of the resultsReferencing this post on StackExchange:
https://civicrm.stackexchange.com/questions/43508/civicase-dashboard-exports-all-cases-instead-of-the-results
When I try to export cases from the Case dashboard by clicking on one of the options, ...Referencing this post on StackExchange:
https://civicrm.stackexchange.com/questions/43508/civicase-dashboard-exports-all-cases-instead-of-the-results
When I try to export cases from the Case dashboard by clicking on one of the options, and if All Cases, is selected, it exports all statuses and types instead of the status and type selected.5.60.0https://lab.civicrm.org/dev/core/-/issues/4131Searchkit not loading pledge ID's2023-02-23T22:27:08ZChabadrichmondSearchkit not loading pledge ID's<p>This seems to be a regression, <br />When creating a search for pledges, I add a search for contacts that have a pledge,<br />I add pledge where pledge id = and when I try to choose a pledge ID it just says loading failed.<br />It see...<p>This seems to be a regression, <br />When creating a search for pledges, I add a search for contacts that have a pledge,<br />I add pledge where pledge id = and when I try to choose a pledge ID it just says loading failed.<br />It seems to be working fine in civicrm Version 5.53 however when testing it in 5.57.1 and on (could be earlier as well but upto even 5.60 on the DMASTER demo site)</p>
![searchkit_gif](/uploads/7d5c971b3ba6c2ee2dbcb261bc4deaa9/searchkit_gif.gif)https://lab.civicrm.org/dev/core/-/issues/2669Target contact missing for automatically generated case activities2023-02-23T16:00:45ZAndreasandreas.howiller@civiservice.deTarget contact missing for automatically generated case activitiesOverview
----------------------------------------
Some actions on cases leave automatically generated activities in the case activity log, but have no target contacts. Examples: Change case title, change case tags. As a result, they cann...Overview
----------------------------------------
Some actions on cases leave automatically generated activities in the case activity log, but have no target contacts. Examples: Change case title, change case tags. As a result, they cannot be edited through the user interface. While this is a minor issue, some users may want to leave notes about the activity (for example, why they changed a case title) and therefore need to edit it.
Reproduction steps
----------------------------------------
1. Open any case in CiviCRM and change the case title.
2. Tap edit for the corresponding activity in the activity timeline.
3. Tap save.
Current behaviour
----------------------------------------
The dialog will freeze while the CiviCRM logo keeps turning. A fatal error "DB Error: constraint violation" will be filed in the logs.
If you add any contact as a target contact in the database or in the edit screen the error won't appear anymore.
What is confusing, too: When editing the activity the client contact already wrongly shows up as target contact in this dialog and if you'd like to change it there you need to search the contact (the link to choose the client contact below the search field won't do the change here).
Expected behaviour
----------------------------------------
The Client contact is filed as target contact by default and connected problems disappear. E.g. editable activities can be saved after edit through UI now.
Environment information
----------------------------------------
* __CiviCRM:__ _5.35.2_ and _5.38.0_
* __CMS:__ _WordPress 5.7.2_https://lab.civicrm.org/dev/core/-/issues/2450Activity contact is not updated when contribution contact is changed2023-02-23T16:00:44ZPatrick Figelpfigel@greenpeace.orgActivity contact is not updated when contribution contact is changedPrior to 5.34, when the `contact_id` of a contribution was updated, `CRM_Contribute_BAO_Contribution` would also update the source or target contact of the corresponding contribution activity. In 5.34, [a change was merged](https://githu...Prior to 5.34, when the `contact_id` of a contribution was updated, `CRM_Contribute_BAO_Contribution` would also update the source or target contact of the corresponding contribution activity. In 5.34, [a change was merged](https://github.com/civicrm/civicrm-core/pull/19202) that causes this update to be skipped. This leads to the contribution activity being stuck with the wrong/old contact.
This seems to affected at least one extension: https://github.com/lcdservices/biz.lcdservices.movecontrib5.37.0https://lab.civicrm.org/dev/core/-/issues/1116Changing a civicase activity's label breaks the max_instances check2023-02-23T14:16:28ZDaveDChanging a civicase activity's label breaks the max_instances check1. Configure a case type so that some activity type (other than open case) has a max_instances set.
2. Create a case.
3. Change the activity type's label.
4. On manage case, create a second activity of that type.
5. You should get the ma...1. Configure a case type so that some activity type (other than open case) has a max_instances set.
2. Create a case.
3. Change the activity type's label.
4. On manage case, create a second activity of that type.
5. You should get the max_instances warning but it doesn't.https://lab.civicrm.org/dev/core/-/issues/1642Installer should check for Joomla/CMS version compatibility2023-02-23T05:03:48ZtottenInstaller should check for Joomla/CMS version compatibilityOverview
----------------------------------------
The install process checks system requirements. One of those requirements should be the CMS version.
Reproduction steps
----------------------------------------
1. Install an older versi...Overview
----------------------------------------
The install process checks system requirements. One of those requirements should be the CMS version.
Reproduction steps
----------------------------------------
1. Install an older version of Joomla (eg 3.7.4)
2. Install a recent version of CiviCRM (eg 5.22.1)
3. Do something with Civi (eg create a contribution page and try to view the public side)
Current behaviour
----------------------------------------
The install succeeds - but then things randomly fail. (In my case, public-facing Civi pages would fail with "Class 'Joomla\CMS\Factory' not found ".)
Expected behaviour
----------------------------------------
During installation, it should complain if your version of the CMS is too old to run this version of Civi.
Comments
----------------------------------------
I inadvertently stepped into this edge-case - I used the `joomla` CLI tool to download the `latest` release (`joomla site:download . --release="latest" --www="$PWD/web"`), but it actually gave me a much older version... because `joomla` had cached some very old metadata. That edge-case isn't a Civi issue... but the behavior of the installer on unsupported versions is...https://lab.civicrm.org/dev/core/-/issues/1633Proposal - add an optional access_arguments key to setting spec2023-02-22T05:03:56ZeileenProposal - add an optional access_arguments key to setting specCurrently when calling Setting.get or Setting.getoptions you need 'administer CiviCRM' permission
I recently found that an angular form was broken for users without this & digging into it I'm using the hook as a short term solution...Currently when calling Setting.get or Setting.getoptions you need 'administer CiviCRM' permission
I recently found that an angular form was broken for users without this & digging into it I'm using the hook as a short term solution - ie
```
if ($entity === 'setting' &&
(($action === 'get' && isset($params['return']) && $params['return'] === 'deduper_equivalent_name_handling')
|| ($action === 'getoptions' && $params['field'] === 'deduper_equivalent_name_handling'))
) {
$permissions['setting']['get'] = [['merge duplicate contacts', 'administer CiviCRM']];
}
```
But this relies on the setting being accessed this way - so it's very brittle. I'm not sold on just lowering the whole permission level.
My feeling is that we should extend the metadata spec - ie add optional key of
'access_arguments' => ['default' => 'be amazing', 'get' => 'be fair to middling']
- this would mean only amazing people can create the setting (when check_permissions are enabled) but fair to middling people could get the setting.
In all cases the default is still 'Administer CiviCRM' if nothing is set
@colemanw @totten @seamuslee @mattwirehttps://lab.civicrm.org/dev/core/-/issues/1612Extension life-cycle bug for managed entities of a type declared in the exten...2023-02-22T05:03:55ZMichael McAndrewExtension life-cycle bug for managed entities of a type declared in the extensionLets say I have an extension that defines a new **entity type** Ocean.
And also declares some Oceans as **managed entities** (Atlantic, Pacific).
When I install it, everything works nicely. The managed oceans are created.
But when I d...Lets say I have an extension that defines a new **entity type** Ocean.
And also declares some Oceans as **managed entities** (Atlantic, Pacific).
When I install it, everything works nicely. The managed oceans are created.
But when I disable it, I start to experience problems because (I presume) attempts to manage the oceans are happening after CiviCRM no longer knows what an ocean is.
Proposed solution: ensure that entity types defined by disabled extensions are always available during attempts to manage entities.https://lab.civicrm.org/dev/core/-/issues/1271Event scheduled reminders not sending with fixed date2023-02-21T05:04:08ZjoewickertEvent scheduled reminders not sending with fixed dateI've been doing a bunch of testing on this on my site running Civicrm 5.13.5 and Drupal 7 after my event scheduled reminders were not working.
And after posting on stackexchange it was replicated on 5.17.4; Drupal 7.67 by ericg
https:/...I've been doing a bunch of testing on this on my site running Civicrm 5.13.5 and Drupal 7 after my event scheduled reminders were not working.
And after posting on stackexchange it was replicated on 5.17.4; Drupal 7.67 by ericg
https://civicrm.stackexchange.com/questions/33101/event-scheduled-reminders-not-sending-with-fixed-date
From what i can work out, if the original reminder has a fixed date (eg, 19th Sept 2019) the first email goes out but no subsequent repeats go out. No errors in the cron log.
But if the original reminder has a date like "1 hour after event start date", the repeats work.
The steps I used to reproduce were:
1. Make sure cron is working and schedule reminders set to hourly
2. create a test event
3. make a scheduled reminder with fixed date and repeat every hour till a year after event start.
4. only the first reminder is delivered
5. set a reminder with relative date (1 hour after start date) repeat every hour until a year after start date.
6. works as expected.https://lab.civicrm.org/dev/core/-/issues/1407CiviContribute Confirm Text2023-02-21T05:04:08ZanilpremlallCiviContribute Confirm TextOverview
----------------------------------------
Minor text change for clarity. Replace Continue with Make Contribution
Example use-case
----------------------------------------
1. Enable "Use a confirmation page?" option on Contributi...Overview
----------------------------------------
Minor text change for clarity. Replace Continue with Make Contribution
Example use-case
----------------------------------------
1. Enable "Use a confirmation page?" option on Contribution Page
2. Launch a test-drive contribution
3. Enter required fields and click "Confirm Contribution"
4. Help text in reference is at the top of the confirmation page
Current behaviour
----------------------------------------
Text: Please verify the information below carefully. Click **Go Back** if you need to make changes. To complete your contribution, click the **Continue** button below.
Proposed behaviour
----------------------------------------
Text: Please verify the information below carefully. Click **Go Back** if you need to make changes. To complete your contribution, click the **Make Contribution** button below.
Comments
----------------------------------------
Thank you for looking into this![CiviContribute-Text](/uploads/350d742bc23b81bc337b0c07cdb63434/CiviContribute-Text.png)https://lab.civicrm.org/dev/backdrop/-/issues/78error: data posting not working PHP8... array_merge(): Argument #1 must be of...2023-02-20T15:53:07Zrockandrollererror: data posting not working PHP8... array_merge(): Argument #1 must be of type array, null givenWhoops!! I see these kind of errors / warnings all over the place! Testing BackDrop install on PHP8
TypeError: array_merge(): Argument #1 must be of type array, null given in array_merge() (line 48 of /var/www/backdrop/modules/civicrm/...Whoops!! I see these kind of errors / warnings all over the place! Testing BackDrop install on PHP8
TypeError: array_merge(): Argument #1 must be of type array, null given in array_merge() (line 48 of /var/www/backdrop/modules/civicrm/backdrop/modules/civicrm_rules/civicrm_rules.module).
======================
Backdrop CMS 1.24.0
MySQL Database
MySQL, MariaDB, or equivalent version 10.3.35-MariaDB
PHP
Version: 8.0.20 (PHP information)
Telemetry
Enabled more
Web server
Apache/2.4.37 (rocky) OpenSSL/1.1.1k
CiviCRM
5.58.0
also see warnings
Warning: Undefined array key "title" in include() (line 92 of /var/www/backdrop/files/civicrm/templates_c/en_US/%%6A/6AB/6ABE93E6%%Address.tpl.php).
Warning: Undefined array key "location_type_id" in include() (line 25 of /var/www/backdrop/files/civicrm/templates_c/en_US/%%72/729/7299F1C8%%Email.tpl.php).
Warning: Trying to access array offset on value of type null in include() (line 25 of /var/www/backdrop/files/civicrm/templates_c/en_US/%%72/729/7299F1C8%%Email.tpl.php).
Warning: Undefined array key "isAddSignatureFields" in include() (line 27 of /var/www/backdrop/files/civicrm/templates_c/en_US/%%72/729/7299F1C8%%Email.tpl.php).
Warning: Undefined array key "on_hold" in include() (line 45 of /var/www/backdrop/files/civicrm/templates_c/en_US/%%72/729/7299F1C8%%Email.tpl.php).
Warning: Trying to access array offset on value of type null in include() (line 45 of /var/www/backdrop/files/civicrm/templates_c/en_US/%%72/729/7299F1C8%%Email.tpl.php).
Warning: Undefined array key "is_bulkmail" in include() (line 47 of /var/www/backdrop/files/civicrm/templates_c/en_US/%%72/729/7299F1C8%%Email.tpl.php).
Warning: Trying to access array offset on value of type null in include() (line 47 of /var/www/backdrop/files/civicrm/templates_c/en_US/%%72/729/7299F1C8%%Email.tpl.php).
Warning: Undefined array key "is_primary" in include() (line 50 of /var/www/backdrop/files/civicrm/templates_c/en_US/%%72/729/7299F1C8%%Email.tpl.php).
Warning: Trying to access array offset on value of type null in include() (line 50 of /var/www/backdrop/files/civicrm/templates_c/en_US/%%72/729/7299F1C8%%Email.tpl.php).
Warning: Trying to access array offset on value of type null in include() (line 50 of /var/www/backdrop/files/civicrm/templates_c/en_US/%%72/729/7299F1C8%%Email.tpl.php).