Outbound email settings being overwritten when app is restarted
-
@girish Thanks for replying. Yes, the use case is to configure a different outbound mailer in Espo. Espo differentiates between outbound settings for system emails (configured by Cloudron) and outbound settings for individual mail accounts. You can actually deactivate the SMTP settings for system emails to use the settings from another mail account but this configuration is then also overwritten.
If it is indeed trivial to do, I would very much appreciate the option being added here.
-
@girish Thanks for replying. Yes, the use case is to configure a different outbound mailer in Espo. Espo differentiates between outbound settings for system emails (configured by Cloudron) and outbound settings for individual mail accounts. You can actually deactivate the SMTP settings for system emails to use the settings from another mail account but this configuration is then also overwritten.
If it is indeed trivial to do, I would very much appreciate the option being added here.
@ccfu said in Outbound email settings being overwritten when app is restarted:
Espo differentiates between outbound settings for system emails (configured by Cloudron) and outbound settings for individual mail accounts.
So, your use case is to select an existing email account (in EspoCRM) as the system mail configuration ? Trying to understand why the system mail cannot use Cloudron mail itself.
-
@girish It can in theory use Cloudron for system mail but there is a bug in Espo which converts 4-digit port numbers to amounts with a thousand separator: 2525 -> 2,525 so the settings are invalid. Independently from that, however, we want to be able to use an external mailserver configuration here and not have it overwritten.
-
@girish Just following up on this, I wonder whether it wouldn't in fact make sense (not just for Espo) to only writing the email settings on initial install. I may be missing something of course, but I don't see any obvious reason to write the setting on app restarts since if they have been changed in the app there was probably a reason for doing so, and if they haven't been changed they don't need updating. Alternatively, would it not be worth considering setting the flag to "app manages email" for all apps as a rule (unless there is a good reason not to) rather than only for some apps (unless there is a good reason to do so)?
-
The Cloudron packages are written in a way so they always try to ensure the expected state on every restart. This helps if apps crash mid-way or the user accidentally misconfigured something. Also the platform may change the addon (database/mail/..) details without the app knowing. So it would restart the app and the new settings will be applied.
For cases where the admin explicitly wants to maintain those settings on their own, we have this optional flag where it makes sense. So far this wasn't asked for espo yet.
-
@nebulon Any ETA on this? The latest app update once again overwrote the mail settings and because the port is still being saved as 2,525, the default settings don't work either.
@ccfu I guess we have two options . We report issue upstream and can also submit a fix upstream to fix the port separator issue. Alternately, we have to make email configuration optional in the Cloudron package. We prefer the former since the larger project will benefit . What do you think?
-
Strange that you experienced issues with the port number, ours (2 EspoCRM instances) never had any issue and the port number is automatically set at 2.525
-
@imc67 Interesting it works for you. Maybe I need to revisit this this. Perhaps it makes a difference that in your case it is 2.525 and in ours 2,525 because of our settings, but either would be invalid port numbers.
-
@imc67 Interesting it works for you. Maybe I need to revisit this this. Perhaps it makes a difference that in your case it is 2.525 and in ours 2,525 because of our settings, but either would be invalid port numbers.
-
Apologies for forgetting to reply again in this thread and confirm the problem still existed. Thanks for reporting it upstream. Looks like it could in fact be reproduced and has been fixed.
The group account solution is what I had been using up to now but this had to be reset every time there was an update or the app was restarted.
