Skip to content

Conversation

@moliholy
Copy link
Contributor

Closes #1227.

Description

This PR allows fields in registration forms to specify both ID and values of sibling fields that control whether the field must be showed or not. Particularly, it adds show_if_id and show_if_value to the payload, and the server stores such information, which later on used in the frontend to either display or hide the field.

Demo

Screen.Recording.2024-12-18.at.01.03.58.mov

TODOs

  • Handle the deletion of fields so that hidden fields are displayed again.
  • Handle more input types (e.g., single-choice).

Copy link
Member

@ThiefMaster ThiefMaster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This already looks very nice!

@moliholy moliholy force-pushed the wip/conditional-fields branch 2 times, most recently from ea437df to 9dadacb Compare December 18, 2024 00:26
Copy link
Member

@tomasr8 tomasr8 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice, I was expecting this to be a much larger change!

Some questions/ideas:

  • Should it be possible to hide entire sections? (probably out of scope for this PR though)
  • Should it be possible to reference fields in different sections? If so, the field selection dropdown should probably also include the section name for cases when you have multiple fields with the same name (currently it's just the field name)
  • What happens when a required field is hidden? Should it be possible to submit anyway? If not, how do we show the error message in that case?
  • It's currently possible to create a cycle (e.g. field A depends on field B and vice versa). This can lead to both fields being hidden with no way to bring them back. I think this can be problematic and probably should not be allowed.

@ThiefMaster
Copy link
Member

Should it be possible to reference fields in different sections? If so, the field selection dropdown should probably also include the section name for cases when you have multiple fields with the same name (currently it's just the field name)

Yes, that should certainly be possible. And I agree that the fields should be shown as "section > field" or similar.

It's currently possible to create a cycle (e.g. field A depends on field B and vice versa). This can lead to both fields being hidden with no way to bring them back. I think this can be problematic and probably should not be allowed.

The management are should never hide fields, but rather just indicate that a field would be hidden. That's also important w/o cycles (which should indeed be disallowed) since you may not immediately know which fields depends on which other fields.


PS: It's easier if you create individual review comments on some dummy line in the diff so there are threads for each point. Otherwise discussions are a mess until GitHub finally adds comment threads not linked to code lines...

@moliholy
Copy link
Contributor Author

The management are should never hide fields, but rather just indicate that a field would be hidden.

@ThiefMaster I changed it so that in the management section the "hidden" field is greyed to indicate it will not be displayed in the user's section.

@github-actions github-actions bot added dependencies Pull requests that update a dependency file javascript Pull requests that update Javascript deps labels Jan 16, 2025
@moliholy
Copy link
Contributor Author

@ThiefMaster @tomasr8 alright, ready for review!

@moliholy moliholy marked this pull request as ready for review January 18, 2025 15:54
@tomasr8 tomasr8 self-requested a review January 18, 2025 17:08
@OmeGak
Copy link
Member

OmeGak commented Jan 20, 2025

In response to @tomasr8 questions/ideas:

  • Should it be possible to hide entire sections? (probably out of scope for this PR though)

Let's keep out out of this PR for now?

  • Should it be possible to reference fields in different sections? If so, the field selection dropdown should probably also include the section name for cases when you have multiple fields with the same name (currently it's just the field name)

In principle, I think that it should be possible to reference fields in other sections. This may come at the expense of clarity, though. On the one hand, we will have very verbose items in the dropdown. On the other hand, it may not be obvious on which field another one is depending on when the registration form is very long. Do you have any ideas on how to mitigate this?

  • What happens when a required field is hidden? Should it be possible to submit anyway? If not, how do we show the error message in that case?

Good question. I believe that marking a field as required really means "required if displayed". If you agree with this, then it's just a matter of making the backend validation not require data if the field was not displayed.

  • It's currently possible to create a cycle (e.g. field A depends on field B and vice versa). This can lead to both fields being hidden with no way to bring them back. I think this can be problematic and probably should not be allowed.

True. I guess that this should be checked when saving field settings and display an error explaining the cycle. Do you have any other idea of how this could be displayed to the event manager?

@ThiefMaster
Copy link
Member

I believe that marking a field as required really means "required if displayed". If you agree with this, then it's just a matter of making the backend validation not require data if the field was not displayed.

Yes, if the field is hidden, then it's no longer required. This also makes sense because depending on what choice you select, you may want to require the user to fill in certain fields.

True. I guess that this should be checked when saving field settings and display an error explaining the cycle. Do you have any other idea of how this could be displayed to the event manager?

I think it's rare enough that it doesn't need to be a super user-friendly message. Something like "Field conditions may not have cycles (a -> b -> c -> a)" would be perfectly fine for me.

@tomasr8
Copy link
Member

tomasr8 commented Jan 22, 2025

In principle, I think that it should be possible to reference fields in other sections. This may come at the expense of clarity, though. On the one hand, we will have very verbose items in the dropdown. On the other hand, it may not be obvious on which field another one is depending on when the registration form is very long. Do you have any ideas on how to mitigate this?

Just an idea, but If we allow referencing fields in other sections we could use two dropdowns - one to select the section and another to select the field.

On the other hand, it may not be obvious on which field another one is depending on when the registration form is very long.

I'm afraid that might happen even if we only allow referencing fields in the same section - people will just create one large section which wouldn't be any more readable. It might also be difficult to 'explain' to the user that only fields in the same section can be referenced..

@moliholy
Copy link
Contributor Author

Added changes to:

  • Avoid selecting the same field as condition.
  • Avoid cycles.
  • Replicate the same condition logic when creating the field, not just when updating.

@OmeGak
Copy link
Member

OmeGak commented Jan 23, 2025

In principle, I think that it should be possible to reference fields in other sections. This may come at the expense of clarity, though. On the one hand, we will have very verbose items in the dropdown. On the other hand, it may not be obvious on which field another one is depending on when the registration form is very long. Do you have any ideas on how to mitigate this?

Just an idea, but If we allow referencing fields in other sections we could use two dropdowns - one to select the section and another to select the field.

I think this would be nicer than prefixing field captions with section title. To improve the UX and avoid managers to always select choices in 2 dropdowns when configuring conditional fields, I would make it so that, by default, the current section of the field is pre-selected.

On the other hand, it may not be obvious on which field another one is depending on when the registration form is very long.

I'm afraid that might happen even if we only allow referencing fields in the same section - people will just create one large section which wouldn't be any more readable. It might also be difficult to 'explain' to the user that only fields in the same section can be referenced..

What do you think about highlighting the depending field when hovering a conditional field? This should happen only in the management view. We could also add an icon on conditional fields that, when clicking on it, displays the caption of the depending field.

@tomasr8
Copy link
Member

tomasr8 commented Feb 17, 2025

What do you think about highlighting the depending field when hovering a conditional field? This should happen only in the management view. We could also add an icon on conditional fields that, when clicking on it, displays the caption of the depending field.

Not sure how much highlighting would help for large forms where you can't fit both fields on the page. Some kind of icon/tooltip sounds good though!

@ThiefMaster ThiefMaster force-pushed the wip/conditional-fields branch 2 times, most recently from 368a977 to 0c7af7a Compare February 28, 2025 15:03
Copy link
Member

@ThiefMaster ThiefMaster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few things I noticed when I started testing this again. Easy ones to fix for now

@moliholy
Copy link
Contributor Author

moliholy commented Mar 2, 2025

@ThiefMaster everything addressed! Ready for another round 😄 .

Yet another case where logic was duplicated... :(
- always pass reg data, even when deleting it
- use ids instead of object (celery wrapper fails if the object is no
  longer in the DB)
Having it generic was too messy, especially w/ the null handling.
This is purely client-side, as we have a server-side sanity check that
ensures the total price of a registration doesn't change.
Make use of final-form functionality, instead of maintaining local state
Do not allow a condition field to be purged before the fields that
depend on it.
@ThiefMaster ThiefMaster force-pushed the wip/conditional-fields branch from f0ab078 to 25c87a5 Compare June 11, 2025 13:44
@ThiefMaster ThiefMaster enabled auto-merge (squash) June 11, 2025 14:50
@ThiefMaster ThiefMaster merged commit e08fd6a into indico:master Jun 11, 2025
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

alembic Contains database changes build-wheel Build a Python wheel for this PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Conditional fields

5 participants