Problem/Motivation

Empty recipient fields on sync clients prevent the default recipients from being used. Even though it says so on the form: Leave empty to use the default recipients

This is because in SyncClientBase::setConfiguration you have NestedArray::mergeDeep() . This always processes arguments left→right; later arrays override earlier ones whenever the key exists, even when the later value is an empty string or NULL. A sync client plugin-specific config already contains recipients_* keys set to '' , so those scalars overwrite the non-empty arrays coming from the baseConfigurationDefaults.

We noticed this because we didn't receive any e-mails when the sync went into forced pause mode.

Steps to reproduce

Implement a sync client.
Fill in recipients on the Global Sync Client Settings form.
Leave the recipients empty on the specific sync client form.
No emails are sent out because no recipient email address can be resolved.

Proposed resolution

Remove empty strings from all variables passed to NestedArray::mergeDeep(), this prevents the empty overrides.

Remaining tasks

User interface changes

API changes

Data model changes

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

stefdewa created an issue. See original summary.

stefdewa’s picture

Added an MR that does just this: Remove empty strings from all variables passed to NestedArray::mergeDeep()

I didn't check any performance impact, or 'works by designed' overrides that wanted to remove default values.

andreasderijcke made their first commit to this issue’s fork.

  • andreasderijcke committed 340b0c29 on 1.1.x
    Issue #3569186 Removes empty string values from configuration arrays...
andreasderijcke’s picture

Status: Active » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.