Model destroy actions for associated models
Decisions made subsequent to last edit to this page:
- The SHF website is not the system of record for payments - instead, we will use HIPS.com for the definitive system of record for PAYMENTS.
- For now, we (the SHF organization) have not defined, specifically, what historical information needs to be maintained for regulatory compliance, audit, or other purposes.
- We have made some decisions regarding associated records - see updates in table below.
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) Hips.co
- historical information: who applied in the past? what companies existed 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?
The User model has a couple of severe problems - see below - to be discussed with client.
-
who has been a member in the past? What were their approved skills/credentials?
- how long were they a member?
-
who has applied but was rejected?
What if a person has applied, but then decides they want to delete their application?
| 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). Update - June 2018: When a company is deleted, associated payments records will be deleted (so, no change to this association) |
| 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. Update - June 2018: We now delete the associated application record when a user is deleted. |
| 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. Update - June 2018: This association has been changed to has_many :payments, dependent: :nullify - so that we retain the H-branded payment records for any associated company(s). We cannot then see who paid the fee, but at least the company retains its payment status. Also, we retain the user's membership payments, but, again, cannot see who made those payments. A future refinement could be the removal of the membership payments, or the addition of an attribute to the Payment record with that information. |
| Photo | has_attached_file | If a User is destroyed, the photo is also destroyed (via before_destroy callback). |
