Description
We need a full audit of the Expression System UI to ensure it only exposes intended and valid interactions between fields, operators, and property accessors.
There is an existing edge case in the Logic tab where a radio field can be paired with property accessors like length or count, and then combined with operators such as equals. In the UI, this can surface as a dropdown-style interaction that appears valid, but the resulting rule does not make sense semantically.
For example:
- Field type:
radio
- Property accessor:
length
- Operator:
equals
- Expected value:
option one
This can produce a rule shape like:
- condition type field
- target ID = radio field
- operator = equals
- expected = radio option
- property accessor = length
The problem is that length is not a meaningful accessor for a radio field, since radio inputs are option-based and do not support length/count-style evaluation in this context. We need to audit the UI and rule builder logic to ensure unsupported combinations like this are prevented, hidden, or clearly blocked before they can be created.
Goals
- Review the Expression System UI for all field/operator/property accessor combinations.
- Identify invalid or nonsensical combinations, especially across Logic tab rule building.
- Ensure the UI only presents valid choices for each field type.
- Prevent rule states that can be generated but are semantically invalid.
Acceptance Criteria
- Invalid field/operator/accessor combinations are not selectable in the UI.
- Radio fields do not expose unsupported property accessors such as
length or count unless explicitly intended.
- The UI prevents or clearly blocks rule configurations that would result in invalid expressions.
- Audit covers other similar edge cases across field types, not just radio fields.
- Document any intentional exceptions or supported special cases.
Notes
This is an audit and cleanup ticket, so the implementation may uncover multiple related fixes or follow-up tickets.
Description
We need a full audit of the Expression System UI to ensure it only exposes intended and valid interactions between fields, operators, and property accessors.
There is an existing edge case in the Logic tab where a
radiofield can be paired with property accessors likelengthorcount, and then combined with operators such asequals. In the UI, this can surface as a dropdown-style interaction that appears valid, but the resulting rule does not make sense semantically.For example:
radiolengthequalsoption oneThis can produce a rule shape like:
The problem is that
lengthis not a meaningful accessor for a radio field, since radio inputs are option-based and do not support length/count-style evaluation in this context. We need to audit the UI and rule builder logic to ensure unsupported combinations like this are prevented, hidden, or clearly blocked before they can be created.Goals
Acceptance Criteria
lengthorcountunless explicitly intended.Notes
This is an audit and cleanup ticket, so the implementation may uncover multiple related fixes or follow-up tickets.