Add visibility conditions to forms

[AdrienClairembault]

Checklist before requesting a review

• I have performed a self-review of my code.
• I have added tests that prove my fix is effective or that my feature works.

Video

Description

"Minimum" implementation of the visibility condition editor (still a lot of code was required).

Features

• Pick a visibility for question/section/comments (Always visible, Visible if... or Hidden if).
• When the visibility is Visible if... or Hidden if, the condition editor is displayed.
• The editor allow conditions to be configured using 4 criteria:
  • Logic operator (And or Or, not available on the first condition)
  • Item (for now, only Short answer questions are selectable here but all questions will be in the future, as well as sections and comments)
  • Value operator (the value depends on the selected item, e.g. Is equals to, Is not equals to, Contains and Do not contains for Short answer questions).
  • Value (the displayed input type will change depending on the item + the value operator, e.g. a simple <input type="text"> for Short answer questions).
• Conditions can be deleted using the trashcan icon.

Note that conditions are not yet applied when the form is rendered for an end user.

UI

The condition editor is available using a small dropdown that is only shown when the question is selected.
The name of the dropdown reflect the current visibility strategy, allowing users to quickly see which questions have conditions.

In the editor, inputs are grouped by color to help visualize the conditions:

Technical constraints

The difficult part here is to always display a valid editor when the dropdown is opened.
Indeed, the editor contains references to some forms items like questions, which may be modified or deleted at any time.
New questions may also be added and should be available in the editor.

We can't rely on the server state to display the editor (as the client state may be modified and not yet saved) and we also can't rely on the client to render the content as we don't use vue here.

The simplest way to handle this is to send the state to the server each time the editor is opened, which will return the rendered content that we can then insert into the DOM (kinda a simplified homemade "live component") .
Any action on the editor that impact the rendering (picking an item or deleting a condition) will also trigger the same re-render behavior.

[orthagh]

deprecated ?

[trasher]

See comment

[AdrienClairembault]

I didn't reproduce the error but it should be fixed now.

I've also applied the UI changes you suggested:

[trasher]

LGTM. Please rebase to solve conflicts and see if tests are still ok now.