On delete behaviour for tables

[sueszli]

By default Supabase, foreign keys have either RESTRICT or NO ACTION as on delete behaviour. This obviously doesn't work for most of our tables, but there is not way to change this except by dropping and reapplying these FK constraints manually.

Currently I have implemented the following:

• cascade users -> profiles
• cascade profiles -> event_registrations
• cascade events -> event_registrations
• set null storage.objects (header_images) -> events

We will have to do the following:

• cascade profiles -> votes
• cascade profiles -> event_user_pairs
• cascade event_user_pairs -> votes

What should happen when the organizer of an event deletes their account? Do we just set the organizer null and cancel the event? Do we delete the event and try notifying the users? If we do not delete the event, do we delete parts that may include sensitive information about the organizer like the description?

Note that some tables' rows cannot be deleted by users at this point, but we should probably already start thinking about the expected behaviour, because it will making testing easier.

[sueszli]

This is an interesting one.

I think we should add a button that enables the organizer to delete their event - then there wouldn't be a difference between cancelling and deleting the event.

After the deletion of an event the users just get notified that their event got cancelled and the mail contains the events title, description, address so they remember what it was.

[sueszli]

After an event host deletes their account, all their thrown events get deleted aswell (but from the participants perspective the events were "cancelled")

[sueszli]

This is because being notified about someone deleting their account makes it more likely that you delete yours aswell