Fix UniqueTogetherValidator validation when condition references a read-only field#9764
Conversation
We can't always expect to find the value of the condition in the serializer if the field is read-only.
|
Looks like, it would fix #9756 |
7528b11 to
9430c49
Compare
|
Hey @auvipy, that was a bit (too) fast, wasn't it? This PR was merged very quickly compared to our usual turnaround and I feel like it didn't give a chance to other maintainers to review it properly. I want us to be really cautious about changing things, espacially around validation where we've caused a few regressions in the not so distant past... I don't mind merging a PR quickly for trivial things (like a typo) but in this case I would have liked us to wait for another approval. PS: I think I'm ok about the code in this specific instance, but that's more about the process |
|
yeah, I was feeling like that, just after merging it. actually I did it after getting, the confirmation from the issue comment. but from the next time I will wait atleast 72 hours or more for sufficient time to get multiple review. sorry for this time and thanks for raising it explicitly. |
|
I'm also OK with the code in this PR, but second the process concerns. I think a 72-hour deadline is no appropriate, given holidays and other things. When requesting a review from other team members, the best course of action would be to wait for an actual review and approval from the team. In my view, we should usually have 4 eyes from the team review before merging. |
UniqueTogetherValidator validation when condition references a read-only field
Description
We can't always expect to find the value of the unique condition in the serializer if the field is read-only.
The proposed solution is to fallback on instance's value.