1. Have `MigrateToGhostUser` be a service rather than a mixed-in module, to keep
things explicit. Specs testing the behavior of this class are moved into a
separate service spec file.
2. Add a `user.reported_abuse_reports` association to make the
`migrate_abuse_reports` method more consistent with the other `migrate_`
methods.
Introduction
------------
1. The foreign key was not explicitly specified on the association.
2. The `AbuseReport` model contains two references to user - `reporter_id` and
`user_id`
3. `user.abuse_report` is supposed to return the single abuse report where
`user_id` refers to the given user.
Bug Description
---------------
1. `user.abuse_report` would return an abuse report where `reporter_id` referred
to the current user, if such an abuse report was present.
2. This implies a slightly more serious bug as well:
- Assume User A filed an abuse report against User B
- We have an abuse report where `reporter_id` is User A and `user_id` is User B
- If User A is updated (`user_a.block`, for example), the abuse report would
also be updated, such that both `reporter_id` _and_ `user_id` point to User A.
Fix
---
Explicitly declare the foreign key `user_id` in the `has_one` declaration
Rather than using a separate `ghost` state. This lets us have the benefits of
both ghost and blocked users (ghost: true, state: blocked) without having to
rewrite a number of queries to include cases for `state: ghost`.
1. Create a `Uniquify` class, which generalizes the process of generating unique
strings, by accepting a function that defines what "uniqueness" means in a
given context.
2. WIP: Make sure tests for `Namespace` pass, add more if necessary.
3. WIP: Add tests for `Uniquify`
- "Associated" issues are issues the user has created + issues that the
user is assigned to.
- Issues that a user owns are transferred to a "Ghost User" (just a
regular user with `state = 'ghost'` that is created when
`User.ghost` is called).
- Issues that a user is assigned to are moved to the "Unassigned" state.
- Fix a spec failure in `profile_spec` — a spec was asserting that when a user
is deleted, `User.count` decreases by 1. After this change, deleting a user
creates (potentially) a ghost user, causing `User.count` not to change. The
spec has been updated to look for the relevant user in the assertion.