Skip to content

Tiptap image links 0.30 questionnaires fixes - #7

Open
entantoencuanto wants to merge 12 commits into
tiptap-image-links_0.30from
tiptap-image-links_0.30_questionnaires_fixes
Open

Tiptap image links 0.30 questionnaires fixes#7
entantoencuanto wants to merge 12 commits into
tiptap-image-links_0.30from
tiptap-image-links_0.30_questionnaires_fixes

Conversation

@entantoencuanto

Copy link
Copy Markdown
Member

🎩 What? Why?

Please describe your pull request.

📌 Related Issues

Link your PR to an issue

  • Related to #?
  • Fixes #?

Testing

Describe the best way to test or validate your PR.

📷 Screenshots

Please add screenshots of the changes you are proposing
Description

♥️ Thank you!

entantoencuanto and others added 12 commits July 17, 2026 19:30
When a question is hidden by its display condition, its response was left
in place and questions conditioned on it were not re-evaluated. As a
result, a question further down a chain (e.g. Q0 → Q3 → FINAL in the
test) stayed visible even after an ancestor trigger stopped being
fulfilled.

`hideQuestion()` now clears the hidden question's response (unchecking
radios/checkboxes and clearing text inputs) and fires a `change` event
only on the inputs that actually changed. This lets questions conditioned
on it re-evaluate their own display conditions, so hiding propagates down
the chain and terminates instead of looping over already-cleared inputs.

Add jest specs for display_conditions.component.js covering the direct
condition, the intermediate question, and the cascading hide.
has_many through ignores the foreign_key attribute and a source is
required because association name on the join model can't be
inferred from the association name
`Question#display_conditions_for_other_questions` is keyed on
`decidim_condition_question_id`, but declared `inverse_of: :question`
and the `question` belongs_to on DisplayCondition is keyed on
`decidim_question_id`. Because of this mismatched inverse_of, assigning a
display condition's `condition_question` also re-stamped its owner FK
(`decidim_question_id`) with the trigger question's id.

In Decidim::Forms::Admin::UpdateQuestions the update attributes for each
display condition include `condition_question` but not `question`, and
`update!` persists every dirty attribute — so on every save (even with no
changes) the condition was silently reassigned to its own trigger
question. This corrupted questionnaires as admins added conditions: rules
disappeared from the back-office and questions stopped displaying on the
participant form.
The display-conditions fixes were authored against develop, which renamed
answer_* to response_*. On this 0.30 fork the old naming is still in use, so
the cherry-picks left references that do not exist here and would raise at
runtime / fail specs:

- questionnaire_copier.rb: eager-load :answer_options / :answer_option instead
  of :response_options / :response_option (the associations on this branch).
- update_questions_spec.rb: use "answered", "short_answer", answer_option: and
  question_2_answer_options / decidim_answer_option_id.
- display_conditions.component.test.js: match the real DOM input name
  [answer_option_id].

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This is an alternative to the hiding half of decidim#17321 .

(cherry picked from commit 613c37c)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant