User should be able to delete the live events which are already completed.
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.
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.
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.
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
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
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 -
validates_uniqueness_of :email, :scope => :deleted_at
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