[#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 Schneider <jan (at) horde (dot) org>
Requester warp-spam_horde (at) aehallh (dot) com
Created 12/15/2012 (158 days ago)
Due
Updated 02/01/2013 (110 days ago)
Assigned 01/31/2013 (111 days ago)
Resolved 02/01/2013 (110 days ago)
Attachments ingo.diff Download
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.