1- The user has created an account. He wants to delete his account. Today it’s not possible, he can only modify it.
Legally a user should be able to delete his account. We have been asked not very friendly by a user once to delete his data from our system, the thing is that today this is not possible without hard delete them in the database.
As images speaks better than long talks, I did a presentation with the step by step desired behaviour : https://docs.google.com/presentation/d/118LsYaX7GbGj9Rlg6r4L0RW9IPXq0SQkeCCTElUTpEk/edit?usp=sharing
2- The user write to us and ask for his data to be deleted from our software / or we have created a fake user for testing purpose and want to delete it from our database
delete his account if he has one so he becomes guest again > we can do that by changing his password, connecting with his account and deleting it (see slide 3 in the document)
mark them “archived” (from users menu as now that all users will be validated I guess they will all be there) and make it impossible to see them: in the “customer” section a hub won’t be able to see the user again if he asked all his data to be delete
I don’t think we need any specific “show unactive users/enterprise” button for admin, if somehow the user made a mistake and call us, I guess we can still go in the database and uncheck the “unactive user” / “unactive enterprise” button ?
@enricostn following our previous discussion I checked the legal requirements and called the data security stuff staff in France, I think this should be ok to start with… officially I think we should destroy all the orders after the legal official conservation time, etc. But let’s see that later, the urgent part for me is enable a user to delete his account… as this is front end stuff, today they see that they can’t delete their account, and we are really illegal there. Let me know if what I proposed with this “archived” thing seems feasible given the spree model.
change the user’s email in the DB to myemail+deleted@gmail.com so he/she can create a new user with his/her email address and make developers really angry
add so called “defensive code” all over the application, like: “Order created by unknown user”
Ok, great to know there is a technical path for that
In order for me to work with @Rachel and @Augustin maybe (if you want to deep jump in the core OFN pool ;-)) and try to break that feature into the relevant multiple github issues (would be great for the French team to do the epic creation process if that case is adapted so that we keep on learning) can you just comment in the slides document if the UX seems ok or add any comment you may have ? @sstead@danielle@Kirsten ? @lin_d_hop@oeoeaio@maikel do you agree with @enricostn technical pat proposal ?
I’d be happy to take care of this but first we should make sure we all agree on what to do.
Is there really a standard way of doing this? Until reading this, I thought the theoretical-maybe-never-done-in-practice standard way of doing this was hard deleting the data.
Are there some reasons for us not wanting/being able to do this? As far as I’m concerned, it would feel like the cleanest way of implementing this.
Otherwise, we’ll have to deal with default_scope: where(deleted_at: nil) which is known to be evil, along with some user.deleted_at ? 'User deleted' : user.name kind of tricks.
This is doable but will bring some pain in perspective.
Also I’m not a lawyer, but I know that the CNIL in France is pretty strict with what we can do with user data, and I think deletion MUST be possible and effective (at least anonymisation, this needs to be checked).
Finally, a quick note on doing myemail+deleted@gmail.com: this would still deliver emails to myemail@gmail.com because of the + email feature.
@Augustin the problem is that if a user placed an order in OFN and wants to leave the platform we’ll have a whole lot of chained relationships tied to that. The order cannot be deleted for instance since other users (e.g. hub admins) will need that historical info. In any case would be impractical to remove everything tied to that user.
At enterprise level would be even worst, so many relationships to take care of.
The “deleted user” pattern I propose is not a painless one, just a practical take on the issue. And it can garantee anonymization (if properly done). As per the email I mistyped, you need some more trick there, but that’s not the point of this discussion.
I cannot see a third option though. Any other idea?
@oeoeaio@maikel it would be great to have your view on that. This is like a core basic thing that makes us illegal today (so would be great to move forward quickly on that…)
I think it’s ok not to delete but just anonymize regarding the CNIL @Augustin (here is the norm that apply to us I think : https://www.cnil.fr/fr/declaration/ns-048-fichiers-clients-prospects-et-vente-en-ligne) they are a bit unprecise about the duration of data conservation, they say data shouldn’t be conserved longer than “the strictly necessary duration of the commercial relationship…” but they also say that it’s ok to anonymise on an irreversible manner the data.
I do like the European privacy laws. And it is also very nice if you can delete unwanted data. Since we have a lot of connected entities here, it would be nice to have a little diagram for that. We probably need to look at it from several perspectives. Some questions that come to my mind:
Which data does the enterprise need to keep and for how long? Orders, invoices, customers, payments…
Which of this data is saved in user records?
Do we want to offer an “undo delete”?
What about database backups?
I guess I would like to delete as much data as possible. For example a user without orders could be deleted without a problem. Orders and transactions get deleted after x years. A replacement transaction keeps track of the user account balance if needed.
Thanks @MyriamBoure I have been looking for some info from the CNIL but had a hard time finding the one that applies in our case.
About the diagram, there are some tools that allow to make them automatically from the source code, I’ll have a look at it there (it will be an opportunity for me to understand the code better anyway).
Regarding entreprise data, I’m not aware yet of how the the whole thing work here, but I know that an invoice MUST never be modified once edited. It means that even if the user is anonymised, his name will still be on the invoice. Because of that, what we did in a former project, was a second app that was only in charge of invoices, and which duplicated the data required by the invoice not to be further edited, independently from the main app. (This would be a step to Microservice architecture).
How are invoices handled at the moment?
I think No is the answer here, otherwise, we simply give the feeling that we allow deletion, but we’re still not CNIL-compliant.
Those ain’t a big deal either: previous data can be stored there, as long as backups are not kept longer than a certain amount of time. So we’ll have to make sure we delete backups after eg. 1 year, but that’s pretty healthy I think.
In general, from my experience, when it comes to legal stuff, the intent is very important. We can read further content on the topic, this won’t make us lawyer (unless we have some with us), so:
Either we try to figure out a decent solution by ourselves keeping in mind that we have good intentions with the user data (but that doesn’t make us illegal I’d say)
Or we’ll have to ask a lawyer for its expertise, but we also have to keep in mind that the law moves fast on this topic (there is a new one coming next spring).
I don’t have a strong preference for either the hard or soft delete options. Both have their advantages and disadvantages.
I think we probably can’t delete orders or payments - that kind of thing probably needs to stick around for as long as tax regulation requires records to be stored (7 years in Australia?).
I just know that incorporated associations have to keep records for 7 years in Australia. But that means we should delete them after 7 years, I think. That’s a time frame we should plan with.
Yeah, I think 7 years would be good. It’s 6 in France but 7 will be ok.
We just need some “process” to norify the hub manager and allow him to download some archive if needed, no ?
And also there are some other cases where we need to delete / anonymize data before, unactive accounts and users data 3 years after the end of commercial relationship. I explain all that in the other discussion.
@enricostn and maybe @lin_d_hop would you be interested to work with me and the consultants on that ? I need at list one tech people if we want to have meaningful advices and know what’s our plan (so that we can then enter that in our backlog and prioritize…)
In terms of skillset complimentarity I think @enricostn and @MyriamBoure would have the skills covered. I wouldn’t add anything to that super team I’m pretty time stretched but if you’d like my input too do let me know.
