------- 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 <holmgren@lysator.liu.se> 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/ ##
You are the QA contact for the bug.
http://bugs.exim.org/show_bug.cgi?id=167
--- Comment #1 from Magnus Holmgren <holmgren@lysator.liu.se> 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/ ##