Null variables should be ignored

[greyhat64]

I've begun to use the folder level variables in action profiles (which is GREAT, by the way!) and I noticed something.
I have an action profile set to send an email to %fvar_tech1% and %fvar_tech2%. The issue comes into play when a folder only has a %fvar_tech1% defined.

In that case the To/Recipient field in the subsequent email looks like this

Joe Q Techie, <%fvar_tech2%>

In this case it is a minor annoyance and could be ignored, but null variables may pose a greater issue in other applications, especially if interpreted as a literal as in this case. Shouldn't a null variable be ignored and not passed to the action handler (SMTP in this case)?

P.S. And while I appreciate the folder level variables, in my opinion it's still not a substitute for user/group management (via user profiles or, preferably Active Directory/LDAP) as described in an earlier post.
I'm hoping this is also being considered in v8.

[KS-Soft]

"Null variable" is variable that represents empty string.
"Non existing" variable is different matter...

Auditing tool should warn you when you are using non existing/invalid variable.
I think HostMonitor works correctly.

Regards
Alex

[greyhat64]

Then explain the literal interpretation of <%fvar_tech2%> in the recipient field of the alert email.
Whether you call it a null variable or, more correctly, a non-existing variable this is not an expected response, wouldn't you agree?

[KS-Soft]

Then explain the literal interpretation of <%fvar_tech2%> in the recipient field of the alert email

According to SMTP protocol specifications recepient address may (or probably "should") be concluded into angle brakets.
http://www.ietf.org/rfc/rfc0821.txt

Whether you call it a null variable or, more correctly, a non-existing variable this is not an expected response, wouldn't you agree?

Actually I do not agree. In this case HostMonitor's behavior looks fine to me. HostMonitor keeps non-existing variables so you may easily find and fix the problem. If you forgot to define some variable, you see this right away so you may fix problem quickly.

Regards
Alex

[greyhat64]

In my opinion undefined variables should be revealed with the auditing tool, not as a byproduct of (also my opinion) poor variable handling. I would even prefer that it merely pass the 'blank' value, as opposed to the current behaviour, which you consider a troubleshooting tool.

If this were working as I interpret it should, then I would define a separate variable for each recipient and use one alert profile regardless of the number of recipients (as defined by the alert profile). Of course it works as I currently have it set up, with the aforementioned byproduct in the recipient field. It's just an ugly solution.

So far I've only concerned myself with folder variables in the context of email alerts. I haven't yet, but I'm concerned that I could find a situation where this behavior would be not only undesirable, but misleading or outright detrimental.

I know what you're thinking - of course I could concat the multiple recipients as the value of one variable, but that is not nearly as descrete and can be equally difficult to maintain across a large set of folders where I'm trying desperately to maintain as few folder 'templates' as possible.

Which is why I have asked for Improved folder variable inheritance and have long been asking for the use of User Profile fields as well as Active Directory/LDAP integration.

Anyway, you've always done a great job of hearing me out, so thanks for listening - again.