As an admin unmarking a group as a band, I want to delete Band info as well

[kitsuta]

Although we can unmark groups as bands, doing so doesn't delete the Band object. I would like the system to:

1. Check to see if a group has had its Band object changed or any Band sub-objects added, and warn me before unmarking a group as a band, so I don't accidentally dissociate a group from a 'real' band.
2. Upon confirmation, delete the Band object and cascade-delete all associated objects, so that the band doesn't show up later in. e.g., exports of all bands.

[thaeli]

Can you mark invalid instead of deleting? Deleting data in the system always scares me a little.

[kitsuta]

Sure, I mean, the goal is really to leave out the data from various reports. Now that I'm thinking through it, that would mean we can even let you 'restore' group's bands by simply setting the band to invalid and not setting group.band_id to None. The group would still have a band in the database, we just wouldn't show the data. That way, admins can change their minds.

[EliAndrewC]

I would personally much rather delete than mark invalid UNLESS part of this ticket is to refactor all of the relevant code throughout the plugin to implement utility methods to distinguish between deleted and invalidated records. For example, right now we send out emails to bands, so we'd need to refactor those emails to only be sent out to non-invalidated bands. Admins will see records for all bands, so we'll need to refactor to account for that. Etc.

I'm fine with someone doing all of that work, but until such time as that's done, doing real deletes is far preferable.

[RobRuana]

We've added a rudimentary "Undo Delete" feature to the Feed of Database Changes, so deleting is a little less scary than it used to be.

So, for this issue, we're going with "delete" instead of "mark invalid".