------- You are receiving this mail because: ------- You are the QA contact for the bug.
http://bugs.exim.org/show_bug.cgi?id=167 --- Comment #1 from Magnus Holmgren <[EMAIL PROTECTED]> 2007-08-01 20:19:22 --- On Wednesday 01 August 2007 20:34, Brian Blood wrote: > On Aug 1, 2007, at 12:46 PM, Dean Brooks wrote: > > Certain condition= statements in ACL will accept values such as "true" > > or "1" to indicate a positive value, but that is only after regular > > string expansions have been performed on the value of the condition > > statement. > > I'll second my vote for the wishlist item mentioned by John. I' had trouble seeing the benefit of adding "true" and "false" as trivial conditions, taking no arguments. If what was originally asked for is for subconditions of and/or to be expanded, yielding "true", "false", or possibly an entirely new condition, it makes more sense. The way things work now is that conditions appear certain places where a condition is expected and nothing else, while expansion items and variables are signalled by a '$'. But it shouldn't be too hard to check if the first character is a '$' and, in that case, perform a string expansion and evaluate the result as a boolean instead. That won't be possible directly in an ${if}, though, so you can have ${if and{{${lookup mysql{SELECT 1 FROM users WHERE name = '$local_part'}}{$acl_m1}}}, but not simply ${if ${lookup mysql{SELECT enabled FROM users WHERE name = '$local_part'}} {foo}{bar}}. -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
