Hi,
Like pretty much every designer out there, I have a database which sends e-mails to specified people. The problem is that if the e-mail recipient is out of the office, the person who clicked the button to submit (or whatever) the document, and who therefore sent the e-mail, does not get the OOO notification.
I’ve set the “From” and “Principal” fields to be the person clicking the button that ends up sending the e-mail, but still no joy.
Anyone else had this? More importantly, anyone else solved it?
Cheers from Down Under,
Marion.
Subject: OOO & e-mails from custom databases
Mails sent by LotusScript have an additional control field called $AssistMail with a value of “1” that tells the OOO to ignore the mail – the object being to prevent a potential infinite loop of OOO messages if the recipient and apparent sender are both away (as may happen if an agent sends to someone who is away on behalf of someone else who is away). As far as I know, this item is added when the Send method is called, so I don’t think there’s a way around it.
Subject: RE: OOO & e-mails from custom databases
im a notes noob, but could this be solved with an agent running in the mail file of the recipient, which looks for OOO status and if true, detects a specific string in your email, matches the email address, and sends said OOO reply on the recipients behalf. It would be adaptation of OOO itself, and so you might be able to re-use the inbuilt OOO code to do this.Just a thought. (If you have multiple recipients or don’t facy that idea because it doesn’t scale well, you could write the agent in the application and query for the recipient’s OOO status before/after sending, and provide feedback to the user on the webpage/email)
Now I have no idea how to query for OOO status, but I’m sure there’s a way, even if it’s nasty, cheap and dirty.
Subject: RE: OOO & e-mails from custom databases
Do you have any idea how dangerous that would be? There is a reason why $AssistMail is there. Without it, you really do stand a significant risk of infinite reply loops, and that will both consume the server’s processing power AND quickly blow both mail databases past the file size limit.