forked from thesuss/shf-project
-
Notifications
You must be signed in to change notification settings - Fork 37
Model destroy actions for associated models
Ashley Engelund edited this page Jan 8, 2018
·
32 revisions
Are we doing the right things with the right models?
From a business point of view, what historical information must we retain? (ex: for audits)
- financial information: who/where is the system of record? (required for financial audits)
- historical information: who applied in the past? what companies exsited in the past.... ?
- what questions has SHF had to answer about past information? What information have they been keeping (e.g. in paper) so that they have been able to answer questions?
- what about the Swedish and and EU privacy laws? and information retention?
Model | Association | Considerations |
---|---|---|
ShfApplication | has_many, dependent: :destroy | |
User | has_many, through: :shf_applications | |
Payment | has_many, dependent: :destroy | Need an overall strategy for payment retention/destroy. (Note that User model does not currently destroy payments.) Retain payment records? (perhaps via dependent: nullify). Or, archive payment records? Or, use HIPS as audit source as needed? (the HIPS record will contain user_id and payment_type, but not company ID) |
BusinessCategory | has_many, through: :shf_applications | |
Address | has_many, dependent: :destroy | |
Picture | has_many, dependent: :destroy |
Model | Association | Considerations |
---|---|---|
User | belongs_to | |
Company | belongs_to, optional |
Model | Association | Considerations |
---|---|---|
User | belongs_to | |
Company | belongs_to, optional | Company is destroyed in after_destroy callback if no remaining applications |
BusinessCategory | has_and_belongs_to_many | |
MemberAppWaitingReason | belongs_to | Should we destroy custom reasons when app is destroyed? |
UploadedFile | has_many | Uploaded files destroyed in before_destroy callback |
Model | Association | Considerations |
---|---|---|
ShfApplication | has_many | A user can delete their own account (via profile edit) but this will result in an error if there are any applications. |
Payment | has_many | A user can delete their own account (via profile edit) but this will result in an error if there are any payments. See also Company treatment of payments upon destroy. |
Photo | has_attached_file | If a User is destroyed, the photo is also destroyed (via before_destroy callback) |