Reviewing a mass email in EspoCRM creates "opened" action record

[mfliorko]

While reviewing a list of actions related to a contact in a mass email campaign I figured out that initially there was one "Sent" record in the campaign log:



When I clicked on an email sent to the contact and then returned back to the contact details page, I figured out two records - and a new "Opened" was just created:



It misleads who opened the emails - contacts themselves or EspoCRM users. So, we cannot trust campaign statistics.

EspoCRM should not count email openings when users review the emails inside of EspoCRM.

[yuri]

It's tricky to fix. One may rely on this while testing and wondering why it's not reported as Opened. As email opens stats is something that does not work reliable nowadays and maybe even not legal in some countries, this feature is not is a high priority.

[mfliorko]

>> One may rely on this while testing and wondering why it's not reported as Opened.

For this matter, the one may open the email in an external email client.


>> As email opens stats is something that does not work reliable nowadays

It's still a valuable feature (otherwise it wouldn't be in EspoCRM and other CRM and mass emailing systems).
Despite it's not reliable approach, the current behaviour of EspoCRM is confusing. And IMHO, it should be fixed.


Other mass email systems don't have such drawbacks.


Technically, it's easy to fix - do not load specific EspoCRM resources mentioned in HTML of emails sent from EspoCRM.

[yuri]

I'm against of using open tracking feature from the etic perspective, I see it as an invasion of privacy. Had I developed the Mass Email feature today, there wouldn't have been this feature.

If you have ideas how to implement the fix without breaking separation of concerns, a PR is welcomed. Here's the class: https://github.com/espocrm/espocrm/b...rackOpened.php

[yuri]

Maybe such a check would work:

if (!$this->user->isSystem()) {
return;
}

[yuri]

Also need to add the $user in the constructor:

__construct(
private EntityManager $entityManager,
private LogService $service.
private \Espo\Entities\User $user, // added
)

[yuri]

BTW. If anyone have ideas how we could block open tracking for emails opened is Espo (not those that are sent from Espo), please let me know. Currently I'm very busy with work, but in the future I'd like to add such a functionality.

[item]

Hi Yuri,
is out of my skill and not use MassEmail but maybe :

use Espo\Core\Api\Request;

public function getHeader(string $name): ?string;
public function getCookieParam(string $name): ?string;

There are certainly some difference between open by User in espoCrm and open by not a Espo User

Maybe or i say "n'importe quoi"

[yuri]

Hi, I mean to prevent email tracking sent from other systems. When I open an email in Espo, a sender should not track it.

I didn't have a chance to investigate techniques. I suspect that big email providers just pre-load and replace all assets negating the tracking trick. Maybe they also block small images.

[item]

Hi Yuri,
what a incredible job you try to do.. (all asset, css, js, img, .... to transform to inline..but a img can be a tracker)
maybe make a "pool" and ask if espo Users will this as extension.

for my opinion, we are tracked everywhere.. all users, all applications.. so tracked in espoCrm or in web..."je m'en fous"
As you say, any feature need maintenance.. this will be very hard to maintain i think..
This feature need all "working/testing/maintenance time" .. this is the question i think.. with my little skill

[yuri]

This should work: https://github.com/espocrm/espocrm/c...4a4a2c7918d089

[mfliorko]

Let's split it into two threads.

The original one - Improve EspoCRM functionality to not log email opening by internal users.
Do you like the feature or not, it exists and should work properly.
In addition, we can add an option to configure tracking of mass emails openings - for the whole EspoCRM system or per campaign.

The second question - Prevent tracking of opening 3rd-party emails in EspoCRM (as an email program).
The first (and most obvious) step is to let users decide to load external resources mentioned in email HTML or not.
Not loading external resources can distort an email view - usually, it ok but user should decide.

[yuri]

> Do you like the feature or not, it exists and should work properly.

It's an open source and free feature. There's no obligation on how properly it should work. "As is, no warranties". After putting so much years and effort into the product, statements implying our obligation for free features are perceived as coarse. They urge not to open source further work. After all, features can even be removed by developers. No feature – no issue.

Have you already tried the fix from the post above? Does it work?

[mfliorko]

In the "it exists and should work properly" phase, the word "should" is a recommendation and does not mean any insults or obligations.

It's more about precision work, adherence to best practices, and respect for users - I believe we should all follow that.

Unfortunately, I don't have the resources to dig into the source code and maintain custom changes.


P.S.
I'm a payable client of EspoCRM, btw.

[rabii]

you don't need resource for this small change. you just need to find the file and make the changes. don't use any custom changes, just make changes to the original file.

[yuri]

This fix is not a custom fix, it's already applied in the repository.

[yuri]

This fix has a downside, that it won't allow to test email opens from Espo. Quite a few users use Espo as their only 'email client'. But I think it's not that big problem (as the feature itself is not reliable by design).