refactor: use new meeting.Registration model #8902
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## feat/regapi #8902 +/- ##
==============================================
Coverage ? 88.90%
==============================================
Files ? 314
Lines ? 41466
Branches ? 0
==============================================
Hits ? 36865
Misses ? 4601
Partials ? 0 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
The final state is on_delete=PROTECT. I had briefly changed to SET_NULL but reverted that change. |
Ah, I must have confused myself by looking at individual commits. |
There was a problem hiding this comment.
Is there anything in the models enforcing attendance_type to be not-None? Perhaps it should raise an exception instead of returning None in the "no tickets" case. Unless places that use the property check for None, it's likely to cause a strange exception, so it might be better to raise one that points at "Registration has no tickets" or some other helpful message.
There is not a restriction in the models but there is in the business logic. Any new registration has a registration type (attendance type). If after a registration cancellation, there are no tickets, the Registration object is deleted. There is an edge case, you could have a Registration with only an Onsite Hackathon ticket for example and this property would return None. It's only use right now is in the proceedings view which already filters on 'onsite', 'remote' types. So it's very speculative, if a new use is added that encounters this edge should it print "None" or fail with an exception? Whichever is preferred. |
Sounds like |
Migrate everything that uses stats.MeetingRegistration to meeting.Registration