-
Notifications
You must be signed in to change notification settings - Fork 510
Implement conditional fields in registration forms #6678
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
ThiefMaster
left a comment
There was a problem hiding this 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!
indico/modules/events/registration/client/js/form_setup/ItemSettingsModal.jsx
Outdated
Show resolved
Hide resolved
ea437df to
9dadacb
Compare
tomasr8
left a comment
There was a problem hiding this 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.
Yes, that should certainly be possible. And I agree that the fields should be shown as "section > field" or similar.
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... |
@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. |
|
@ThiefMaster @tomasr8 alright, ready for review! |
|
In response to @tomasr8 questions/ideas:
Let's keep out out of this PR for now?
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?
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.
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? |
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.
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. |
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'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.. |
|
Added changes to:
|
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.
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! |
368a977 to
0c7af7a
Compare
ThiefMaster
left a comment
There was a problem hiding this 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
indico/modules/events/registration/client/js/form/fields/ShowIfInput.jsx
Outdated
Show resolved
Hide resolved
indico/modules/events/registration/client/js/form/fields/ShowIfInput.jsx
Outdated
Show resolved
Hide resolved
indico/modules/events/registration/client/js/form/fields/ShowIfInput.jsx
Outdated
Show resolved
Hide resolved
|
@ThiefMaster everything addressed! Ready for another round 😄 . |
indico/modules/events/registration/controllers/management/fields.py
Outdated
Show resolved
Hide resolved
indico/modules/events/registration/controllers/management/fields.py
Outdated
Show resolved
Hide resolved
indico/modules/events/registration/controllers/management/fields.py
Outdated
Show resolved
Hide resolved
indico/modules/events/registration/client/js/form/fields/ShowIfInput.jsx
Outdated
Show resolved
Hide resolved
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.
f0ab078 to
25c87a5
Compare
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_idandshow_if_valueto 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