Decreased the 'phase' values where variable(s) allow(s) #1941
Conversation
There was a problem hiding this comment.
I have looked through all the changes in this PR by hand and I have not found a problem.
It looks like all the changes are valid and we do not lose anything by shifting to phase:1 in these situations. This looks very good.
I did not check the remaining phase:2 rules so I can not tell whether some of them could still be moved to phase:1, but I presume this is not the case.
I've collected the variables by a script, and checked the variables and the phases where they waked. The "target" phase became the highest value - except the collection variables, like The untouched rules are in right phases I guess. |
|
I am positive this is the case, not the least because you did work by script. Where I am a bit weary is skipAfter happening in the wrong phase now. But I checked all the rule-exclusion packages and they are correct in this regard. So I think we are OK. |
|
Did an additional review also, and haven't found a problem. This is a very good PR! |
|
Thank you, @fzipi. We're ready to merge, but since this is a significant change, we'll keep it on the agenda for tonight. There are also other questions around the underlying issue. And we should discuss those. |
|
Meeting decision (#1944 (comment)): This will be merged once the new conflict is resolved. |
|
Conflict had resolved. |
|
Thank you for your quick reaction and the patch. Merging now. |
Decreased the
phasevalues where variable activated the previous phase - eg.REQUEST_FILENAMEavailable inphase:1, not necessary to wait to 2nd phase (body processing). All changes are fromphase:2tophase:1, except in case of rule 950100, which is a response rule - there the old phase value is 4, now it's 3.