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}}.
--
Magnus Holmgren holmgren@???
(No Cc of list mail needed, thanks)
"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans
