Summary
Two usability refinements for the automation condition builder, both raised in a call with @ditsuke. Not blocking current PR.
Operator choice per check
Current: a group has one operator. Chooseing AND (or OR) once applies it to every check in that group. To mix operators you must add a nested group.
Wanted: the AND/OR is chosen between each pair of checks, independently, and the selector sits between the two checks rather than above them. After the first check, the user should hafve to pick an operator before the next check can be added (no auto-filled default).
Open design question (needs group decision): mixed operators in on flat list make A AND B OR C ambigous. We must pick how it groups, for example, top-to-bottom running combine, standard precedence (AND binds tighter), or keep explicit nesting for brackets. This choice affects how the tree serializes and how a saved rule reloads into the builder, so it should be settled before implementation.
Summary
Two usability refinements for the automation condition builder, both raised in a call with @ditsuke. Not blocking current PR.
Operator choice per check
Current: a group has one operator. Chooseing AND (or OR) once applies it to every check in that group. To mix operators you must add a nested group.
Wanted: the AND/OR is chosen between each pair of checks, independently, and the selector sits between the two checks rather than above them. After the first check, the user should hafve to pick an operator before the next check can be added (no auto-filled default).
Open design question (needs group decision): mixed operators in on flat list make
A AND B OR Cambigous. We must pick how it groups, for example, top-to-bottom running combine, standard precedence (AND binds tighter), or keep explicit nesting for brackets. This choice affects how the tree serializes and how a saved rule reloads into the builder, so it should be settled before implementation.