Summary | Filters with no conditions |
Queue | Ingo |
Queue Version | 1.2.1 |
Type | Bug |
State | Resolved |
Priority | 1. Low |
Owners | jan (at) horde (dot) org |
Requester | almarin (at) um (dot) es |
Created | 03/20/2009 (5965 days ago) |
Due | |
Updated | 01/13/2010 (5666 days ago) |
Assigned | 03/23/2009 (5962 days ago) |
Resolved | 03/30/2009 (5955 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | Yes |
Fix maildrop rules without conditions (almarin@um.es,
Bug #8103).http://git.horde.org/diff.php/ingo/docs/CHANGES?rt=horde-git&r1=82c209c8e71b9473af38085588bda376ab370f98&r2=14e76278f3f4a3f9ce9ff2c56f12c899c74386a4
http://git.horde.org/diff.php/ingo/lib/Script/maildrop.php?rt=horde-git&r1=82c209c8e71b9473af38085588bda376ab370f98&r2=14e76278f3f4a3f9ce9ff2c56f12c899c74386a4
Assigned to Jan Schneider
If you have a chance, can you take a look at the other open bugs of
the maildrop driver?
http://cvs.horde.org/diff.php/ingo/docs/CHANGES?rt=horde&r1=1.55.2.119&r2=1.55.2.120&ty=u
http://cvs.horde.org/diff.php/ingo/lib/Script/maildrop.php?rt=horde&r1=1.7.2.13&r2=1.7.2.14&ty=u
New Attachment: maildrop.php[1].patch
I tested the modification in our current version, and later i
generated the patch making modifications in CVS HEAD version, but
actually i did not test the patch because it was very simple. But i
made a stupid mistake.
I attach the correct and tested patch.
430: ##### Horde Bugs #####
431: if( \
432: /^From:\s*bugs@horde\.org$/:h \
433: if( \
434: exception {
435: to INBOX.horde.bugs
436: }
The patch checks if any condition exists:
if (count($this->_conditions) > 0) {
In that case, it add 'if' statments and the conditions.
I don't know if i'm missing something, but the patch is working for me.
In fact, i think that actual condition looks weird:
if (count($this->_conditions > 1)) {
Comparing an array with a number before count?
New Attachment: maildrop.php.patch
You are right, an unconditional rule should be valid. Let me try
another patch for maildrop driver
executed unconditionally then. If this doesn't work in maildrop, then
the maildrop driver has to fixed instead.
#5641ensures that a defined condition isnot empty, but doesn't ensures that the rule has at least one condition.
State ⇒ Feedback
bug #5641already?New Attachment: rule.php.patch
State ⇒ Unconfirmed
Patch ⇒ Yes
Milestone ⇒
Queue ⇒ Ingo
Summary ⇒ Filters with no conditions
Type ⇒ Bug
Priority ⇒ 1. Low
Now it is possible to create filters without any condition. With
maildrop backend, it generates filters like:
##### New Rule #####
if( \
)
exception {
to "${DEFAULT}"
}
And that generates a maildrop error beause of a mailfilter parsing error.
I think it makes sense to deny any rule without conditions. I attach a
patch to do it.