Follow up to UX issues with contract signee invitation #11011
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of the problem
Follow up to UX issues noted in #10982 (comment)
Describe your changes
Now we only show the contract sub form if the invited user is a manager. This raises a small issue where you could have Manager selected, then set them to be a contract signee, then change the role to Reader or Member and try to submit. This would do the right thing and result in an error, but I think is confusing UX, so I changed the backend to only honor the
is_signee
field when Manager is the selected role.An alternative would have been to clear the contract signee form in the frontend when switching roles, but I think sanitizing params in the backend was easier in this case.
I didn't realize we were using alpinejs for this form, we might want to consider removing the stimulus controller I added for hiding and using alpinejs for that too.
We now only show the cosigner option when "Contract Signee" is selected. This was implemented by changing
form_hide_field_controller
to take the option we want to show the conditional field on, not the ones we want to hide on.This one I left as is for now as it might be intentional/desired behavior.
@garyhtou can you confirm whether this is fine, or should we consider setting a default option for the regular invite flow? This would make it easier to remove the prompt option in both places we are using this