[Team Deletions] Migration: add team deletion schedule - #6611
Conversation
Backported from the team-sites-deletions-intervals branch, where the team_deletion_schedules status enum's `:deleted` value was renamed to `:completed` - keeping the partial unique index's WHERE clause in sync.
aerosol
changed the title
| :team_deletion_schedules, | ||
| [:team_id], | ||
| unique: true, | ||
| where: "status NOT IN ('cancelled', 'completed')", |
There was a problem hiding this comment.
How is status: 'completed' different from the row being deleted via cascade from the teams table deletion?
There was a problem hiding this comment.
We don't delete the team, we delete its sites. The team stays and remains still available for upgrade. Does that make sense?
There was a problem hiding this comment.
We have to support the case when the team subscribes for a month and then cancels only to renew next year
There was a problem hiding this comment.
EDIT: Ignore stuff below, I didn't see your reply before posting. I am slightly surprised by that – I was assuming we delete the team. But if that's agreed with @metmarkosaric then all good.
Thinking about the lifecycle after reading https://github.com/plausible/analytics/pull/6615/changes#r3852893234
When a deletion is executed, I'm assuming the team will be deleted and it cascades to this table automatically.
Is there a planned lifecycle state where the team still exists but the deletion schedule is in completed state?
If there is a use-case for this state, the sync_eligible function does not seem to account for that. In case team exists and deletion schedule is completed, it looks like another deletion schedule will be created (or is this intended?)
There was a problem hiding this comment.
@ukutaht we just planned to delete dashboards and stats. accounts and teams we don't touch. it's mostly sites/stats that affect us in terms of data storage/backups and CS while it seems nice for people to keep access to their account, team setup, subscription history etc. it also makes it easier to come back and start again if/when needed
There was a problem hiding this comment.
Hmm but if we only delete sites then won't the churned customer be on a never-ending cycle of deletions?
sync_eligiblefinds a churned customer with no active deletion schedule- Deletion schedule is created
- Email notifications go out
- Sites are deleted
- Deletion schedule status is changed to
completed - GOTO step 1
or am I missing something that prevents this?
There was a problem hiding this comment.
Yeah @ukutaht that's a valid observation. I'll address that
There was a problem hiding this comment.
It's a nice catch overall, I think what we should do is to ensure at least one site exists for a team in order to fulfill the eligibility check. That way already completed deletion sweeps exist as audit entries and don't loop, unless a new site is created (which implies subscription must go through its cycle again). Does that make sense?
3 participants
This isn't final form, but an initial base migration for tracking/audting team deletions life cycle (expired trials, cancelled subscriptions).
Discussion: https://3.basecamp.com/5308029/buckets/44692882/messages/10216872798