Community Discussions and Support
Alias Rules on restart dont work untill edited

Hi All,

I have set up 2 aliases  of the type Filter: where mail addressed to the aliases run a  filer batch file, that copies the message to a temporary file, then  runs a batch file and finally replies to the originator with a text message.

When I re-start Mercury the rules are not being run untill AFTER I select 'Edit General Ruleset attached to the aliases.

They seem to run fine there after.Can anyone suggest why they dont run when Mercury first starts ?

The same message and processing can be sent to the rules  but on fresh start the honouring needs to be kicked started.

The reply email always comes back, it is the temp file creation and running of the batch file that needs to be kick started.

Any clues out there ?

Cheers

 

 

 

 

<p>Hi All,</p><p>I have set up 2 aliases  of the type Filter: where mail addressed to the aliases run a  filer batch file, that copies the message to a temporary file, then  runs a batch file and finally replies to the originator with a text message.</p><p>When I re-start Mercury the rules are not being run untill AFTER I select 'Edit General Ruleset attached to the aliases.</p><p>They seem to run fine there after.Can anyone suggest why they dont run when Mercury first starts ?</p><p>The same message and processing can be sent to the rules  but on fresh start the honouring needs to be kicked started.</p><p>The reply email always comes back, it is the temp file creation and running of the batch file that needs to be kick started. </p><p>Any clues out there ?</p><p>Cheers </p><p> </p><p> </p><p> </p><p> </p>

[Solved]

Turns out it is best to define the drive and path in a batch file being called by rules.

Looks like when you edit a rule set, the path information Mercury uses to open/save the file sticks in the programs environment and subsequent call to the batch file works. After a restart the environment seems a little different and with out a C: and CD \Mercury\somefolder  at the start of the batch file,  the mercury internals have not got good access to to the namespace

After I set the drive and path specs re-starting mercury would read/run the batch file ..

Taking out that info from the .bat caused the symptom to re-appear...

 

<p>[Solved]</p><p>Turns out it is best to define the drive and path in a batch file being called by rules.</p><p>Looks like when you edit a rule set, the path information Mercury uses to open/save the file sticks in the programs environment and subsequent call to the batch file works. After a restart the environment seems a little different and with out a C: and CD \Mercury\somefolder  at the start of the batch file,  the mercury internals have not got good access to to the namespace </p><p>After I set the drive and path specs re-starting mercury would read/run the batch file ..</p><p>Taking out that info from the .bat caused the symptom to re-appear...</p><p> </p>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft