5.2.0-git
04/18/2014

[#11893] Ingo 3 destroys some custom rules.
Summary Ingo 3 destroys some custom rules.
Queue Ingo
Queue Version 3.0.1
Type Bug
State Resolved
Priority 2. Medium
Owners jan (at) horde (dot) org
Requester warp-spam_horde (at) aehallh (dot) com
Created 12/15/2012 (489 days ago)
Due
Updated 02/01/2013 (441 days ago)
Assigned 01/31/2013 (442 days ago)
Resolved 02/01/2013 (441 days ago)
Milestone 3.0.3
Patch No

History
02/01/2013 01:28:34 PM Jan Schneider Assigned to Jan Schneider
State ⇒ Resolved
Milestone ⇒ 3.0.3
 
02/01/2013 01:28:27 PM Git Commit Comment #4 Reply to this comment
Changes have been made in Git (master):

commit 13db04f101d1aa08503f26619dcdf99481135c95
Author: Jan Schneider <jan@horde.org>
Date:   Fri Feb 1 14:28:12 2013 +0100

     [jan] Fix multiple user-defined headers in a single rule 
(Zephaniah E. Loss-Cutler-Hull, Bug #11893).

  ingo/docs/CHANGES |    2 ++
  ingo/package.xml  |    2 ++
  ingo/rule.php     |    6 +-----
  3 files changed, 5 insertions(+), 5 deletions(-)

http://git.horde.org/horde-git/-/commit/13db04f101d1aa08503f26619dcdf99481135c95
02/01/2013 12:19:36 AM warp-spam_horde (at) aehallh (dot) com Comment #3
New Attachment: ingo.diff Download
Reply to this comment
... I have no clue how I missed that.

Attached.

Sorry about that.

Zephaniah E. Loss-Cutler-Hull.
01/31/2013 10:46:54 AM Jan Schneider Comment #2
Patch ⇒ No
State ⇒ Feedback
Reply to this comment
There was no patch attached.
12/15/2012 02:22:21 AM warp-spam_horde (at) aehallh (dot) com Comment #1
State ⇒ Unconfirmed
Patch ⇒ Yes
Milestone ⇒
Queue ⇒ Ingo
Summary ⇒ Ingo 3 destroys some custom rules.
Type ⇒ Bug
Priority ⇒ 2. Medium
Reply to this comment
Take the following ingo rule:

Self-Defined Header: 'X-Original-To' IS 'foo1@example.com'
Self-Defined Header: 'Delivered-To' IS 'foo1@example.com'
Self-Defined Header: 'X-Original-To' IS 'foo2@example.com'
Self-Defined Header: 'Delivered-To' IS 'foo2@example.com'

Ingo 3 will cause condition 2 to be '-' and condition 3 to be '', thus 
breaking the rule.

The code seems to have some confusion as to if $vars->userheader is 
supposed to be an array or a straight value.

The attached patch fixes at least this problem by forcing it to always 
be treated as a straight value that is unconditionally set to the user 
header in question.
(For an actual commit, the lines should at the very least be deleted 
and the indendation corrected.)

Regards,
Zephaniah E. Loss-Cutler-Hull.