Picking up global email settings

Not sure if this is a bug, or is working as designed, but there MIGHT be an issue around how the Send Email action picks up global SMTP settings. I changed the global SMTP settings while a project was running, but before the project reached any relevant Send Email actions. Should the running project have picked up the change before running a Send Email action that is tied to the global SMTP settings?

Also, this is what I think is a bug, but I cannot be sure:

  1. Set up global SMTP settings with port 465 and Explicit TLS
  2. Start project using task scheduler
  3. While project is running, change the global settings to port 587 and Require TLS
  4. Project runs with settings from #1 above (this is what I am talking about at the start of this post)
  5. When project completes (or maybe when it gets to the Send Email action?), the global SMTP settings are reverted to the settings that are being used by the running project.
  6. I go back to check the Global SMTP settings, and they are set per #1 above, not #3.

Again, I am not positive, but SOMETHING reverted the global settings, and I was the only one working on this Automise instance this morning.

Thanks for looking into this.

This behaviour is as designed. Automise loads it’s options on startup and does not react to external changes (ie editing by hand or another instance). We have never supported this scenario and it’s fraught with danger.

I had a look at the source code, the Automise IDE always saves it’s options when it exits, ATCMD does not. This suggests to me that your scheduled task is using the IDE rather than ATCMD?

I’m not sure that saving when exiting is strictly necessary as it does save when you edit the options in the options dialog. That said, I’m not about to change that without some serious thought/investigation into when/why that was added.

I will test this scenario today and see what happens with atcmd.

I can confirm that ATCMD does not update the global options on exit. Still investigating why the IDE does.

So for the IDE saving the options, it’s been there since before 2013 (when we switched version control systems) - I can’t look at commits before then as the old system is no longer around.

There is actually a comment in the code

 //Why are we doing this?? To upgrade options perhaps?

which lead me to look at what happens on the first run (ie the very first time a user runs this major version)

if TIDEConfigData.IsUserFirstRun then

So the always save thing is totally redundant and will be removed for the next update.

So there is a situation where saving is needed when shutting down, and that is where options have been changed by script at runtime (not many users would do this). So the change we made today is to check for modification when deciding whether to save the options on shutdown.

This build should behave better with respect to this


1 Like