musicbrainz-server
musicbrainz-server copied to clipboard
MBS-9063: Don't try to submit dates for reltypes without them
Fix MBS-9063
Problem
We keep having issues where people will hit an ISE after changing from a relationship type with dates (such as member) to one without (such as founder), because the dates are still stored and submitted with the relationship even though it doesn't make sense.
It's even more confusing with the new editor because the relationship preview will still show the dates, even though the type does not support them, and even though the user has no way to actually change them anymore.
Solution
Since we do not want to lose the dates in a situation where the user ends up selecting a second type that does support them, this stashes and blanks the dates if a type without dates is selected, and restores the dates from the stashed ones if a type with dates is selected again.
Checklist for author
- [ ] If the implementation makes sense, look into flow types
Testing
Tested manually by changing from a performer relationship with dates to a founder one (if submitted, the edit is sent without dates), and by changing from a performer relationship with dates to a founder one and then to conductor (the dates are shown again once conductor is selected and are correctly kept when submitting).
Maybe a dumb question, but is there a reason we need to stash them into a separate variable instead of just ignoring them when
has_dates
is false?
Maybe not. I just thought removing them would be better than remembering to check for date applicability everywhere (on preview and on submission, at least). But that might not be more annoying.