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.
... when the user is destroyed.
1. Normally, for a given awardable and award emoji name, a user is only allowed
to create a single award emoji.
2. This validation needs to be removed for ghost users, since:
- User A and User B have created award emoji - with the same name and against
the same awardable
- User A is deleted. Their award emoji is moved to the ghost user
- User B is deleted. Their award emoji needs to be moved to the ghost user.
However, this breaks the uniqueness validation, since the ghost user is
only allowed to have one award emoji of a given name for a given awardable
1. When the user is deleted.
2. Refactor out code relating to "migrating records to the ghost user" into a
`MigrateToGhostUser` concern, which is tested using a shared example.
FFaker can generate data that randomly break our test suite. This
simplifies our factories and use sequences which are more predictive.
Signed-off-by: Rémy Coutable <remy@rymai.me>
Timothy Andrew