Skip to content

survey_version_question_visibility_rules

Overview

Visibility logic rules: hide specific choices when a condition holds. Corresponds to CS's visibilities.

Table Definition

Logical name Physical name Column Type PK Relation Unique Nullable Default Notes
Visibility rule survey_version_question_visibility_rules id uuid โ—ฏ gen_random_uuid() Re-assigned on every question update
question_id uuid survey_version_questions:id (cascade)
sort_order integer 0 Rule order
logical_operator branch_logical_operator AND / OR
created_at timestamptz now()
updated_at timestamptz now()

Relations

  • question_id โ†’ survey_version_questions.id (onDelete: cascade)
  • Referenced by: survey_version_question_visibility_conditions.visibility_rule_id (cascade)
  • Referenced by: survey_version_question_visibility_targets.visibility_rule_id (cascade)

Indexes

  • Primary key (id)
  • UNIQUE INDEX: survey_version_question_visibility_rules_question_order_idx (question_id, sort_order)

Difference from Branch Rules

Visibility logic is structurally symmetric with branch rules. The only difference is what it produces.

Item Branch rule Visibility rule
Conditions branch_conditions visibility_conditions (identical column layout)
Logical operator branch_logical_operator (shared) branch_logical_operator (shared)
Condition operator branch_operator (shared) branch_operator (shared)
Output Destination question code + message A list of hide targets

Notes

  • The symmetry mirrors the fact that CS keeps logics (branching) and visibilities (visibility logic) as symmetric, separate APIs
  • The enums are reused directly from the branch side, so condition semantics are exactly the same as for branching
  • On the CS side, a visibility's order_index has been observed to be null, suggesting priority matters less there. This system keeps an explicit order