Tickets :: [#11893] Ingo 3 destroys some custom rules.

5.3.0-git

2016-09-24

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 (1379 days ago)
Due
Updated	2013-02-01 (1331 days ago)
Assigned	2013-01-31 (1332 days ago)
Resolved	2013-02-01 (1331 days ago)
Milestone	3.0.3
Patch	No

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	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 State ⇒ Feedback Patch ⇒ No	Reply to this comment
There was no patch attached.

2012-12-15 02:22:21	warp-spam_horde (at) aehallh (dot) com	Comment #1 Type ⇒ Bug State ⇒ Unconfirmed Priority ⇒ 2. Medium Summary ⇒ Ingo 3 destroys some custom rules. Queue ⇒ Ingo Milestone ⇒ Patch ⇒ Yes	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.