======= Deleting Completed Live events =======

===== Requirement =====

User should be able to delete the live events which are already completed. 

===== Impact =====

Deleting a live event also deletes all the related information including who enrolled/purchased it.  We may need this information for some of the analytics.

==== Reason ====

 We soft delete live events but some of the information related to live events is deleted physically from the database. This happens during the callbacks after soft deleting live events. 

==== Fix ==== 

We should let the related information of the live events to be soft deleted. We already use paranoid plugin to handle this. So, adding **acts_as_paranoid** in the model and handle the unique validations cleanly would be the major change. 

In addition to this, we need to test and verify all the places to make sure no bugs are introduced due to this. The dashboard page should also show the information of the deleted live events and enrollments.

=== Mandatory Change ===

The following models should be made to soft delete table entries as this information is already being used in some reports.

**Enrollment**

**ProgressScore**

**Purchase** (Make sure that deleted purchases will not be billed during subscription.)

**Order** (Make sure that deleted orders should not show up in purchase history.)

**BillingAddress**

**Cart**

**Payment**

**PaymentTransaction**

=== Optional Change ===

The following models can also be made to soft delete table entries. This is required based on the information of live event we want to still access after it is deleted.

(Say, In future, if any report wants the number of questions asked on a deleted live event, we also need to soft delete ProductQuestion model's table entries.)

LiveEventAssociation

ProductQuestion

Question

ProductGroup

ProductQuestion

Category

CategoryAssociation

Comment - (This should be handled carefully. This has soft delete implemented using a method 'logical_destroy' but this should use acts_as_paranoid preferably.)

Rating

Activity

Tag

Like

Recommendation

RecommendationUser

ProgressBreakup

=== Important Note ===

When we change tables to be soft deleted we need to watch out for the column which have unique constraint on them.
If the unique constraint is on MYSQL level, make sure to remove it and add it in the model level. 


When it is in the model level, make sure that the uniqness is checked only among the active entries.

We can redefine validates_uniqness_of method lihe this - https://github.com/ooochie/acts_as_paranoid/tree/master/lib/validations

OR 

Call validations on deleted_at scope - 
<code>
validates_uniqueness_of :email, :scope => :deleted_at
</code>


===== List of models which are deleting table entries physically =====

In addition to the above mentioned models, the following models delete entires physically from the database. These models **do not** effect live event deletion any way. So, no change is needed immediately for these. We can decide if any of these need to be soft deleting entries. 

Annotation (Stores all the annotations on a doc/video)

Announcement

Answer

CertificationQuestionnaire

ClientApplication (Used for apis)

Company (We do not delete a company at all from the app)

CompanyEmailDomain

Photo

ContactUs (All the contact us messages)

CouponUsage

CssRule (Used for Site appearance. We never delete this from UI).


DiskUsage (disk space used by a user. We never delete a user from UI at the moment. So, this is also never deleted)

DropBoxAssociation (Stores which courses have a given dropbox item)

Event

**InPersonEvent**
 
**MerchantAccount**

Message (Inbox message)

OauthToken (Used for Apis)

Page

Poll (Used for blog posts)

QuestionPool, QuestionType, Questionnaire, QuestionnaireQuestion, Response, ResponseSet (Quiz content related info)

ScormPackageDetail, ScormSession

User (We never delete a user from UI)

Subscription, UserSubscription