5.3.0-git
2014-09-20

[#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 2012-12-15 (644 days ago)
Due
Updated 2013-02-01 (596 days ago)
Assigned 2013-01-31 (597 days ago)
Resolved 2013-02-01 (596 days ago)
Milestone 3.0.3
Patch No

History
2013-02-01 13:28:34 Jan Schneider Assigned to Jan Schneider
State ⇒ Resolved
Milestone ⇒ 3.0.3
 
2013-02-01 13:28:27 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
2013-02-01 00:19:36 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.
2013-01-31 10:46:54 Jan Schneider Comment #2
Patch ⇒ No
State ⇒ Feedback
Reply to this comment
There was no patch attached.
2012-12-15 02:22:21 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.