this is very dangerous and potentially illegal. for example you have to keep financial records for x years. the user does not have the right to remove/anonymise that data

Not sure of the solution. Username and Password replaced with numbers 0.59679000 1523823261. and name is made empty. Deleting the user account surely would be preferable ?

Deleting the user account surely would be preferable ?

It has already been discussed in depth why automatically deleting accounts is a bad idea, even before you get into sites with legal storage requirements that would "disable" GDPR related anonymization rules.

@mbabker
In that case do I mark it as successfully tested because everything else appears to work ?

Shouldn’t this be an account deletion request?!?! To permanently delete someone’s account to assume is quite a risk as the you have the ability to hold on to historical data for legal reasons under GDPR.

OK, required reading before anyone goes forward with any other issues/PRs/whatever on the subject of GDPR:

• https://wordpress.org/news/2018/04/gdpr-compliance-tools-in-wordpress/
• https://github.com/gdpr-compliance/info

Why WordPress owned resources? Because they have had people working on this problem for some time, and have created a targeted approach with proper milestones and actionable items. We still have a bunch of disconnected ideas and proposals coming from everywhere, and 40 days to get it released.

Told you so before Christmas last year but all I got from some people was stick. Perhaps now you see my frustration. #19078 (comment)

I have tested this item ✅ successfully on eeb795e

Details test:
Joomla! 3.9.0-dev Development

Written by: [name user] above an article is also removed. OK
Super User can not be removed. OK

you have to keep financial records for x years. the user does not have the right to remove/anonymise that data

you still can if you do things..., like backup/encription etc....

yes you can - you can also not enable the plugin. just not sure if this should be part of core because of that as its a destructive change that would be enabled without most users understanding the consequences

i suppose that if you publish a self-delete menu item, you should know what you are doing... or not ?

@brianteeman, what about as part of the core that is disabled by default?

On 16 Apr 2018, 19:46 +0100, Brian Teeman notifications@github.com, wrote:

yes you can - you can also not enable the plugin. just not sure if this should be part of core because of that as its a destructive change that would be enabled without most users understanding the consequences
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

it's already like this
if you don't create/publish a user self-delete account menu item.....

Never assume anything about the intelligence of a user. I learned that lesson a long time ago.

right
unable to translate this in english ?
usually in italian we say....utente === u tonto
is a every day lessons that i'm hardly try to understand ... without luck ?

Perhaps the idea is not bad, but there is not sure that it should be in the core. I will explain why

1. If the user clicks "delete account", you must ensure that all of his data will be deleted, if not immediately at least after a certain time. However, with this implementation, the user is not deleted but is blocked with data replacement.

2. You add onUserBeforeDelete & onUserAfterDelete triggers while user record is not deleted, this can cause unpredictable consequences in third-party extensions.

With this implementation, I do not understand why I just do not delete the user? The only explanation is that there should not be a User not found error in the components, but this error will still appear when the administrator deletes the user.

3. With this implementation on a large site will be formed a bunch of "ghosts" and without the ability to restore them or determine what kind of ghosts. To also not very good.

Therefore, to include such an implementation in the core is not a very good idea. If you add such a function, the truer state in com_users will be a more accurate implementation, which is a very laborious process. In addition, you must add core.delete.own access and Enable delete own setting to com_users config.

@alikon Maybe it's just worth making a system plugin?

@Septdir

1. If the user clicks "delete account", you must ensure that all of his data will be deleted, if not immediately at least after a certain time. However, with this implementation, the user is not deleted but is blocked with data replacement.
Already been discussed at length. Deleting user content is not necessary

2. _You add onUserBeforeDelete & onUserAfterDelete triggers while user record is not deleted, this can cause unpredictable consequences in third-party extensions.

With this implementation, I do not understand why I just do not delete the user? The only explanation is that there should not be a User not found error in the components, but this error will still appear when the administrator deletes the user._
That is why the user is not deleted. Admin can completely delete the user and reassign Articles etc.

2.With this implementation on a large site will be formed a bunch of "ghosts" and without the ability to restore them or determine what kind of ghosts. To also not very good.
Again Admin can completely delete the user and reassign Articles etc.

1. If the user clicks "delete account", you must ensure that all of his data will be deleted, if not immediately at least after a certain time. However, with this implementation, the user is not deleted but is blocked with data replacement.
   Already been discussed at length. Deleting user content is not necessary

you may have to - you may not have to - it depends. there is no global answer as it will depend on the site, the data and the context.
And it does not delete the content anyway. It just removes the name from the content. That may or may not be enough to satisfy the requirements.

There is no global answer as it will depend on the site, the data and the context. There can never be a single solution that will satisfy the requirements

@brianteeman

There is no global answer as it will depend on the site, the data and the context. There can never be a single solution that will satisfy the requirements

You are completely right. If you can develop a solution that will be suitable for most sites, it will be very large and difficult to configure

@Webdongle

Already been discussed at length. Deleting user content is not necessary

I can give you an example.
Let's say you have a website with articles where any registered person can add articles. In each article the author is indicated and it is the author's content. When a user clicks to delete an account, the place of his name in the authorship is empty, which means that the author of the article is the site. I'm not sure how much this is legal, but that's what I'm not completely sure about completely.

A little change the example, for example in this article there are contact details of the user. Removing the account from the site personally, I expect that my data will be deleted.

That is why the user is not deleted. Admin can completely delete the user and reassign Articles etc.

If this is the case, then an easier and logical solution would be simply to write a plugin that you can easily customize to your site. Here is an example of a plugin.

In the plugin's settings, select the default user then in the event
onUserAfterDelete execute the query in the database #__content and simply update created_by. The plugin can be user or system.
The plugin easily adapts to the croquet site and various third-party extensions
Unlike the plugin, the proposed solution can cause problems with third-party extensions
You can write this plugin in a couple of hours

the proposed solution can cause problems with third-party extensions

only due to triggering the "onUserBeforeDelete , onUserAfterDelete" , thus triggering these events should be discussed

• "ghosting" the personal data of the account is not problematic ! and it is very much desirable to be able to do

Problematic is the removal of the user record row and then having a missing user record that is referenced by 3rd party code (see discussion here #19023)

This PR tries to solve --only a part-- of the Privacy issues related to GPDR and similar laws

In the plugin's settings, select the default user then in the event
onUserAfterDelete execute the query in the database #__content and simply update created_by. The plugin can be user or system.

you create and use such a plugin regardless of this PR,
this PR is not about having or not having such a plugin

that is why the event triggering is there, although i am not sure if i like triggering:
onUserBeforeDelete , onUserAfterDelete

probably i would say that new events are needed

@Septdir did you read the starting #19023 ?
how you currently deal when an user is deleted from backend ?

this pr doesn't claim to solve all GPDR related issues

@ggppdk do you mean some kind of onUserBeforeGhost, onUserAfterGhost

do you mean some kind of onUserBeforeGhost, onUserAfterGhost

yes

@alikon

did you read the starting #19023 ?

Just read

how you currently deal when an user is deleted from backend ?

now my administrators work according to this scheme
The user writes in support with the request to delete his account. The request specifies whether to delete its content. If the user allows to leave the content, then simply changes created_by id and adds created_by_alias

@alikon I do not consider the idea itself to give the opportunity to delete my account bad, I do not really like the implementation of blocking and replacing data.

In my opinion a much more flexible and reasonable solution would be pressure parameter trashed
This would solve a number of problems.

1. It will be possible to give an opportunity to restore the user's account during any time. For example, within 30 days a user can write to those support and restore his account, this is a very popular and widespread function.

2. If you do not block the user and do not change his data, then if a person login on by the remote user's login, he can display a warning.

3. Do not immediately delete the user will allow people who have suffered from the actions of intruders to restore their account. Personally, with me a couple of times was when the account fell into the wrong hands and tried to remove it.

4. Adding trashed allows you to reduce the risk for administrators who sometimes accidentally delete users #20049

5. Finishing the standard components, for example com_content you can for the author's place display guest, not just emptiness.

Well and still it is a lot of all. Think for me personally such an option is more important than just a button that allows the user to turn himself into a "ghost"

now it trigger 2 new Events

• onUserBeforeGhost
• onUserAfterGhost

@Septdir a trashed state for me is not meaningful in this context and it just add not needed code

@alikon it correct code.

I can enumerate a long time than such an implementation is incorrect and what disastrous negative consequences can be.

But all this can be reduced. This implementation is not New feature is Core Hack

This is my position. Your position is clear to me too. And I respect her, although I do not agree with her at all.

I can enumerate a long time than such an implementation is incorrect and what disastrous negative consequences can be.

But all this can be reduced. This implementation is not New feature is Core Hack

This is my position. Your position is clear to me too. And I respect her, although I do not agree with her at all.

I expressed my arguments, and I will calmly wait for a decision on this PR

this is the main reason why i like open source, cause there are different POV... ?

@alikon you inspired me to make a plugin to make ghost accounts from users who where inactive during a specified period.
The user himself has no influence. The accounts are no longer related to a user after the expiration date / time. In this way I can follow the history.
This in accordance with the new privacy law (GDPR).
It is just a comment.

@alikon

You have used the function microtime() to set the username and the email.

See: rules 152 and 153
components/com_users/models/delete.php

->set($db->quoteName('name') . ' = ' . $db->quote(''))
->set($db->quoteName('username') . ' = ' . $db->quote(microtime()))
->set($db->quoteName('email') . ' = ' . $db->quote(microtime()))

Had that a special reason? Why not e.g. $db->quote('') or $db->quote(time())?

Had that a special reason? Why not e.g. $db->quote('') or $db->quote(time())?

Cannot be '' empty string , as it should be unique
Similar it should not be time() as it is seconds, so in the rare case off 2 ghosting operations executed at about same time you will have duplicate value

A comment for the email value
it is set to an invalid value
but since account gets blocked, most applications will not try to use the email anyway

Thanks @ggppdk

I am working on a plugin to make ghost accounts from expired accounts.
Multiple ghost accounts with duplicate values are created. A test indicates that this works. But is it wise.

closing in favour of joomla-projects/privacy-framework#85