[#8103] Filters with no conditions
Summary Filters with no conditions
Queue Ingo
Queue Version 1.2.1
Type Bug
State Resolved
Priority 1. Low
Owners Jan Schneider <jan (at) horde (dot) org>
Requester almarin (at) um (dot) es
Created 03/20/2009 (1522 days ago)
Due
Updated 01/13/2010 (1223 days ago)
Assigned 03/23/2009 (1519 days ago)
Resolved 03/30/2009 (1512 days ago)
Attachments maildrop.php[1].patch Download
Milestone
Patch Yes

History
03/30/2009 01:56:27 PM Jan Schneider State ⇒ Resolved
 
03/23/2009 09:39:01 PM Jan Schneider Comment #11
Assigned to Jan Schneider		 Reply to this comment
Committed, thanks.



If you have a chance, can you take a look at the other open bugs of 
the maildrop driver?
03/23/2009 09:32:38 PM Jan Schneider Deleted Attachment: maildrop.php.patch
 
03/23/2009 09:03:27 PM almarin (at) um (dot) es Comment #9
New Attachment: maildrop.php[1].patch Download		 Reply to this comment
I'm so sorry Jan.



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.


03/23/2009 04:29:14 PM Jan Schneider Comment #8 Reply to this comment
Did you actually test the patch? This is how maildrop scripts look like now:



430: ##### Horde Bugs #####

431: if( \

432:    /^From:\s*bugs@horde\.org$/:h \

433: if( \

434: exception {

435:    to INBOX.horde.bugs

436: }


03/23/2009 04:28:03 PM Jan Schneider Deleted Attachment: rule.php.patch
 
03/23/2009 03:18:05 PM almarin (at) um (dot) es Comment #7 Reply to this comment
I don't think so.



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?
03/23/2009 01:36:42 PM Jan Schneider Comment #6 Reply to this comment
This breaks all rules *with* conditions.
03/23/2009 12:31:04 PM almarin (at) um (dot) es Comment #5
New Attachment: maildrop.php.patch		 Reply to this comment


You are right, an unconditional rule should be valid. Let me try 
another patch for maildrop driver




03/23/2009 11:30:40 AM Jan Schneider Comment #4 Reply to this comment
It is perfectly valid having no conditions. The rule should be 
executed unconditionally then. If this doesn't work in maildrop, then 
the maildrop driver has to fixed instead.
03/23/2009 11:14:49 AM almarin (at) um (dot) es Comment #3 Reply to this comment
Not exactly. Update made in #5641 ensures that a defined condition is 
not empty, but doesn't ensures that the rule has at least one condition.






03/23/2009 11:07:01 AM Jan Schneider Comment #2
State ⇒ Feedback		 Reply to this comment
Hasn't this been fixed with bug #5641 already?
03/20/2009 11:47:29 AM almarin (at) um (dot) es Comment #1
State ⇒ Unconfirmed
New Attachment: rule.php.patch
Patch ⇒ Yes
Milestone ⇒
Queue ⇒ Ingo
Summary ⇒ Filters with no conditions
Type ⇒ Bug
Priority ⇒ 1. Low		 Reply to this comment
Hi,



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.