RFC: Deleting users with associated orders

[aitbw]

After talking with @elia and @jacobherrington about how we should tackle #3126, I think it's better for everybody to have a say on this particular issue. (I think #2221 is also related to this?)

Initially, I plan to submit a PR to hide the delete button for those users that have at least one order associated and then work from there on whatever the community consensus is.

The proposed ideas to completely completely fix the aforementioned issue are the following:

• Create a ghost / fake user, like Github does with @ghost, to inherit the orders of the deleted users
• Keep the users, but remove all the sensitive data (i.e.: email address, billing/shipping addresses) and replace their names with something like Deleted user <some_id>

Take into consideration that this is something that stores administrators must be aware of, it should be GDPR compliant and last but not least, orders can't be deleted whatsoever.

Let me know what you think! 🙌

[stem]

@epicery, we keep the user object and scramble it's data.
Doing so enable us to keep stats about our average lifetime value, average order interval, average order count, etc. Migrating all orders to a "ghost" user will certainly break that.

[jacobherrington]

I agree with deleting as much PII as possible and renaming the user to "Deleted user <some_id>. I'm not sure on how far we can go with scrambling data before we run into other problems.

[kennyadsl]

I agree that we should explore the approach proposed by @stem if that's compliant with GDPR. Are there some rules to respect for not being able to reverse scrambled data with real users data?

[seand7565]

We could use SecureRandom to generate a new email - eg."#{SecureRandom.hex}@deleted.com" - to remove unscrambling as a possibility.

[brchristian]

Hi all, have we reached consensus here? We are getting requests from users to delete their accounts but I can’t tell if there is a Solidus best practice for that. Where has this conversation arrived now that we’re 2 years out? I’m happy to submit PRs if needed.

[kennyadsl]

Hey @brchristian, I think we should go with extracting the current logic that deletes users in a configurable class that contains the logic for that action. In the beginning, it should just be identical to what we have now. After that, we can provide another opt-in class that does something more advanced like scrambling data. I suspect this is not enough because each store can have users' references in other tools (like marketing or OMS integrations) and they will need to add custom logic to remove users from those platforms as well. What do you think?

[brchristian]

Hi @kennyadsl that is a very good suggestion. I would also suggest that we include the logic for whether users are eligible for deletion on the backend, as currently we don’t allow the backend to delete users unless orders.empty?, which will be too restrictive for a lot of stores.

[kennyadsl]

Makes sense, we can even call this action differently than delete if it makes sense. Like anonymize, can make sense for what you are trying to do?

[tvdeyen]

We are running into this a lot lately and I think we should provide a solution to be GDPR compliant. Some thoughts:

1. We should allow to destroy users that have incomplete (not payed) orders. Currently we restrict to delete users with any order in any state. This is wrong imo.
2. Scrambling the data (especially addresses on complete orders) can cause legal issues with accounting. Ie. an order/invoice might not have been accounted yet and the user already deleted their account.
3. I just checked the European GDPR "the right to be forgotten" law and this explicitly excludes technical and legal reasons from that law.

That said, I think we should be able to keep addresses that are attached to orders (for legal and accounting reasons), but should remove the address from the users address book (same with payment sources in users wallet). The user record can be deleted, since Solidus does not need an user_id on the order, an email is good enough.

All of this should be good enough to be GDPR compliant.

Obvious disclaimer: I am not a lawyer

[tvdeyen]

I added a PR that allows to at least change the deletion validation logic. Stores can override the can_be_deleted? method in the user class to allow to delete incomplete users if they like.