Activity Control - Refactor Condition Check

[SyntaxNode]

Refactor the condition check in preparation to add 3.5 defined clauses.

[SyntaxNode]

Per the spec:

Note that rules can have no conditions, in which case they automatically match and the "allow" value is utilized.

I don't expect to see this actually used, but this requirement simplifies the evaluation logic.

[VeronikaSolovei9]

Ok, but it doesn't really make sense. Should it be a validation error? Should we skip Evaluation to the next rule?
Allow is always true or false which means we will always return without further checking (after first rule without conditions):

for _, rule := range p.rules {
		result := rule.Evaluate(target)
		if result == ActivityDeny || result == ActivityAllow {
			return result
		}
	}

[SyntaxNode]

which means we will always return without further checking (after first rule without conditions)

You're right.

Per the spec, processing will end at the first rule without conditions and that "allow" value will be used. I don't expect any host to actually set a rule without conditions, but if it does happen somehow I'm cool with what the spec defines. I think we can argue either way on that behavior and this way is simpler to code.

[VeronikaSolovei9]

Ok, this works too.

[VeronikaSolovei9]

Looks good to me, just have one question.

[SyntaxNode]

Looks good to me, just have one question.

Let's merge your two open PRs first. I rather ship that functionality first and can update this PR to handle the merge conflicts (due to renaming Allow -> Evaluate).

[SyntaxNode]

Closing. @VeronikaSolovei9 is continuing the work in #2989.