I think this is missing some coordination with the overall event status. Since all events must have at least one event date, it seems like there should be validations for all event dates that determine the allowable overall event status. Examples:

• All event dates must be marked as billing pending (or later "finished" statuses like canceled) for the overall event to be marked as billing pending.
• All event dates must be marked as canceled for an event to be marked as canceled. If some eventdates took place but others did not, then the overall status should be billing pending or completed, not canceled.
• There are definitely way more of these if you think through all of the permutations.

I think these validations are especially necessary until the billing system switches to being fully by event date and not by event (later pull).

Theoretically the overall event status could be determined from an expression based on the statuses of the event dates, but that will need some thought into edge cases.

I think a "set all at once" option is necessary for massive events like orientation (this could be in the frontend so that you can make exceptions). This should be a later pull.

I think I would much prefer having cancelled as an eventdate status instead of a checkbox since that mirrors how overall events work. If people billed for an event date, then it took place as far as billing is concerned.

Another thought: there should be a "blank" or null default state for eventdate statuses so that we don't have to edit old events when adding columns to the DB. Also useful for events that don't use the event date statuses.