Outbound email settings being overwritten when app is restarted

[ccfu]

@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.

[ccfu]

@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)?

[nebulon]

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.

[ccfu]

@nebulon Thanks for the explanation. Then I can see why it is good to write the configuration on a restart but I would then like to request the flag to maintain settings in the app also be added to Espo.

[nebulon]

Yes, I have added to my list.

[ccfu]

@nebulon Thank you!

[ccfu]

@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.

[girish]

@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?

[ccfu]

@girish I would also be happy with the former. I suspect most people have 2- or 3-digit port numbers so this has not been an issue for the developers up to now.

[imc67]

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

[ccfu]

@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]

@ccfu in the config.php it shows as:

'smtpPort' => '2525',

so I guess it's just a GUI "thing"?

[girish]

@ccfu yes, can you please test again and let us know?

[nebulon]

I have just hit this problem as well on a fresh installation while looking at customer one. Not yet clear what the issue is but will keep this updated.

[nebulon]

https://github.com/espocrm/espocrm/issues/3010 is for the UI fixes, but seems like upstream can't actually reproduce this...

[girish]

Looks like https://github.com/espocrm/espocrm/issues/3010 got fixed

[ccfu]

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.