Feature Request:  When "deleting" events, instead of actually deleting from the DB just disable them and retian the information.

I'm currently working with the Events module and I see that, for a deletion operation, the module is actually deleting data rather than (behind the scenes) marking the data as "deleted" or "inactive".  Both the old and new Event modules work this way.

Although DNN has a great enterprise-design foundation through its use of data abstraction, strongly-defined user roles, etc, one point that has been missing from the basic DNN design is the retention of non-transitional data even after the data has been "disposed of".  That is, database deletions really DO delete the data and it's gone forever. That's bad.  Imagine the user that accidentally deletes a major conference event and the long list of attendees that have registered for it over the past 3 months.  The terrified user will ask for that info to be restored -- could you as the admin do it?  Only if you'd backed up your DNN DB recently and are comfortable tromping through tables and copying selected rows from selected tables from the backup copy to the active DB.   If, however, the conference had only been -marked- as deleted it would be easy to "restore" the event and anything associated with it.

Marking data as deleted (but keeping it) provides more opportunity to backtrack (instant audit trail), analyze and generate data/stats/reports well after the fact (in case you discover there is a stat you wished you'd been tracking for the last year) and just to provide an opportunity to rectify accidents (our previous example with the terrified user that deleted the conference).

There is no reason DNN could not adopt the basic design premise that non-transitional data (users, events, forum posts, etc) is retained and simply marked as "deleted" rather than actually being deleted.  Storage space is not a concern:  it is trival to give the admin the option to "clear deleted data" or "always delete immediately", much like the Windows' trash bin.

Are we likely to see such a shift in DNN's handling of data?  I welcome all thoughts, insights and supporting or opposing views...

While generally I'm with favance on this one, keep the primary tables lean....there is a lot to be said for reporting from the DNN data--if it's there!  Kind of hard to hold someone to call or meeting quotas when they delete the records... 

But favance is also right in that this is a more advanced use case.  Perhaps we could add a trigger to the primary table, and another setting to the module instance: "Copy all items to the reporting archive."  Then if chosen for that module instance, the trigger would copy records to a second table for reporting.  The user could not remove any data, but then normal usage doesn't have to scan pas those rows to show current data.