Duplicate system emails?

[BastianHammer]

I’ve tried multiple approaches now - with inbound, without inbound, with default, without default - but it always works like expected.
The user can only see her/his outbound personal account.

I cannot replicate the issue you’re seeing.
Can you try it on a different / new installation and see whether you can find out how to replicate it?

[creativologist]

@BastianHammer I see no benefit vs the headache to doing an entire new installation.

Sounds like there isn’t a solution to this for us.

[creativologist]

A Google search shows this

Historically, in older versions of SuiteCRM (pre-8.9): Users might have seen the system email account in the “From” dropdown list when composing emails, even if they were not authorized to use it. This was a known issue that could lead to confusion.

In SuiteCRM versions 8.9 and later:
This issue has been addressed. The “From” dropdown list in the compose email view now primarily displays outbound email accounts to which the user has access, including personal accounts and group accounts.
The system email will only appear in this list if the “Users may send as this account’s identity” option is explicitly enabled in the Administration > Email Settings page.

Somehow my upgrade from 8.8.1 to 8.9 did NOT resolve that previous issue, the exact issue I am encountering now in 8.9 and “users may send as this account’s identity” is unchecked.

[BastianHammer]

Can you find the issue on Github?

SuiteCRM/SuiteCRM-Core

Or the bugfix in the release notes?

Releases

Then you can check the code differences and see, whether your current system contains that fix.
If not, you can create an issue ticket (best only if you can reproduce the issue on other systems as well).

[LionSolution]

@creativologist

Background (8.x Architecture)

In SuiteCRM 8+, outbound email accounts are managed through the service layer, mainly in:

core/backend/OutboundEmail/Service/OutboundEmailConfigurationService.php

The dropdown of “From” addresses in the email composer is built using the method:

OutboundEmailConfigurationService::getUserConfigurations()

That method aggregates:

• User accounts
• Group accounts
• System account(s)

…but does not always check $currentUser->is_admin.

---

Strategy

We’ll create a custom extension to override or decorate the OutboundEmailConfigurationService so that:

• If the user is not admin, we remove any configuration whose type is system.

---

File Structure

Create this file in your instance:

extensions/custom/OutboundEmail/Service/CustomOutboundEmailConfigurationService.php
`

(If /extensions/custom/OutboundEmail/Service/ doesn’t exist, create the directories.)

Patch Code

Step 1

<?php

namespace App\Extensions\Custom\OutboundEmail\Service;

use SuiteCRM\Core\OutboundEmail\Service\OutboundEmailConfigurationService;
use SuiteCRM\Core\OutboundEmail\Entity\OutboundEmailConfiguration;
use SuiteCRM\Core\User\User;

/**
 * Custom service to filter system outbound accounts for non-admin users
 */
class CustomOutboundEmailConfigurationService extends OutboundEmailConfigurationService
{
    /**
     * Override to remove system outbound accounts for non-admin users
     */
    public function getUserConfigurations(User $currentUser): array
    {
        $configs = parent::getUserConfigurations($currentUser);

        if (!$currentUser->isAdmin()) {
            $configs = array_filter($configs, function (OutboundEmailConfiguration $config) {
                $type = $config->getType(); // usually: 'system', 'group', or 'user'
                return $type !== 'system';
            });
        }

        return array_values($configs); // reindex array
    }
}

Step 2 — Register the Override

In SuiteCRM 8, custom service overrides must be registered via a Service Provider.

Create the file:

extensions/custom/OutboundEmail/Service/CustomOutboundEmailServiceProvider.php

and add:

<?php
namespace App\Extensions\Custom\OutboundEmail\Service;

use Illuminate\Support\ServiceProvider;
use SuiteCRM\Core\OutboundEmail\Service\OutboundEmailConfigurationService;

class CustomOutboundEmailServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->app->extend(OutboundEmailConfigurationService::class, function ($service, $app) {
            return new CustomOutboundEmailConfigurationService(
                $app['SuiteCRM\Core\OutboundEmail\Repository\OutboundEmailConfigurationRepository'],
                $app['SuiteCRM\Core\User\UserService'],
                $app['SuiteCRM\Core\Service\ConfigurationService']
            );
        });
    }
}

Step 3 — Rebuild Cache

Run (from your SuiteCRM 8 root):
php bin/console cache:clear php bin/console cache:warmup
or through Admin → Repair → Rebuild Backend Cache

---

HTH

[creativologist]

Sigh - NO CHANGE

1. I created extensions/custom/OutboundEmail/Service/CustomOutboundEmailConfigurationService.php

2. I created extensions/OutboundEmail/CustomOutboundEmailServiceProvider.php

Cleared cache AND did rebuild

3. Also did TWO previous changes you told me prior, I did not reverse them, don’t know if I am supposed to or if it doesn’t matter.

4. Is the PATH correct on the second file? No custom folder?

5 . Is it possible that there is a missing step to tell the system about these custom files?

6 . Are these actual paths? They do NOT exist in my instance. My root is CRM not Suitecrm and within Core, none of those folders exist

use SuiteCRM\Core\OutboundEmail\Service\OutboundEmailConfigurationService;
use SuiteCRM\Core\OutboundEmail\Entity\OutboundEmailConfiguration;
use SuiteCRM\Core\User\User;