Wouldnt an easier fix (and covers more scenario) being to create a batch process to allow changing the user eg select all articles for user a and batch change them to user b

@brianteeman We can do that. But users by default won't know or think of articles that are existing. Instead they just delete users as they just want to do that and don't know/care about anything else as they are focusing on doing a single task.

A prime example, is when a site is built users tend to use an admin account and then just delete it, or at least this is what I have seen. But all content and modules etc are created under that user. Ideally we should have a reassign users items to X user and click to proceed. Maybe with a plugin hook, so other developers can have their data updated too.

But for the developers and thousands of extensions out there that do not have it, it would be good for JUser to show name/email/username as a deleted one. So people then know they need to update it?

Would be a fine Enhancement in Usability as @tonypartridge wrote. Its happened often if starting using Joomla like you wrote above.

Both actually would be good.
The Stack Ideas approach of nominating a user ID for "orphaned" content alongside being able to batch change the author would be a winner as far as I'm concerned.

We did have a discussion about this before - I think maybe @Bakual will remember the link.

to me sounds like quite an easy solvable problem if we finally proper implement foreign keys

How will foreign keys solve it? Forgive my ignorance, but foreign keys could only work on core items and you'd have to write a cleanup script.. because you can't expect developers to adapt their working component to support them globally.

Tony Partridge

On 29 September 2017 at 12:52:28, Nicola Galgano (notifications@github.com)
wrote:

to me sounds like quite an easy solvable problem if we finally proper
implement foreign keys

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18160 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVglpypPTJnPyXeBOUTcw_M2By7SANtks5snNn8gaJpZM4PoWZy
.

@brianteeman I think you mean #12881 (and #12908) where we show the ID for deleted users.

As for creating a different table with the deleted entries - every database table specialist will kill you for that ?
If you delete something, it is gone. If you don't want to delete it, you don't delete it. You change the state to "trashed" like we do for articles (but not for users). However usually when you delete a user, you want to have it gone, not being still present with a trashed state.

As for forgeign keys, that would indeed solve it but can't be done in J3 and likely also not in J4. But we certainly should have that goal in mind.

How will foreign keys solve it? Forgive my ignorance

In Joomla we have for example a catid field in #__content which is a reference to the id field in #__categories. But that reference is only done in PHP, not at the database level. For the database, it's just two unconnected tables.
Now database like MySQL allow to specify relations between tables, thus the name relational database ? . If you do define such a relation, you tell the database that this catid field in #__content is a "foreign key" to the id of the #__categories table.

Now if you delete the category, the database will check that all references of that category are deleted as well. If not, it will throw an error and prevent the delete. This means you first have to change all references before you can delete the category.
There is another mode where it would actually also delete all referenced items, but that's usually not what you want (eg if you delete a user, it would delete all articles from that user as well).

sorry for my brevity @tonypartridge you can find intersting reading http://www.sqlteam.com/article/using-set-null-and-set-default-with-foreign-key-constraints
in this case will be usefull on delete set null

But that’s only really useful for new component adopting it and core
items? Not solving the core problem.

Proposed solution:

We add a plugin hook to allow checking if any items exist under this user
on delete, if some are found we prompt the user whom they want to allocate
them too, allocate them and delete.

For users trying to be loaded whom cannot be found, we load in dummy data
of User Deleted. Please re-assign. For name.

Many thanks

Tony Partridge

On 29 September 2017 at 13:46:59, Nicola Galgano (notifications@github.com)
wrote:

sorry for my brevity @tonypartridge https://github.com/tonypartridge you
can find intersting reading
http://www.sqlteam.com/article/using-set-null-and-set-default-with-foreign-key-constraints
in this case will be usefull on delete set null

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18160 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVglmPpr92o-KZHi5l8uEgT4_7qHYSKks5snObDgaJpZM4PoWZy
.

Imagine a site with a thousand users and ten thousand content items
Now try to delete 900 users
You will have to check all ten thousand content items to see if the user you are deleting was an author of any content.. And then you will have to repeat that 900 times
:)

Yep you would! But it’s kinda a given, you could have multiple assignments
in a single screen.

As a temporary solution I’ll add in the batch author change.

But we need something better. I hate to mention it, but WP handles it
better although slower.

Maybe only run the check on users whom have creation rights?

--
Tony Partridge

On 29 September 2017 at 14:08:24, Brian Teeman (notifications@github.com)
wrote:

Imagine a site with a thousand users and ten thousand content items
Now try to delete 900 users
You will have to check all ten thousand content items to see if the user
you are deleting was an author of any content.. And then you will have to
repeat that 900 times
:)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18160 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVglpVn-_AU0sMSOuDXx80q-bqVSEZEks5snOvHgaJpZM4PoWZy
.

the scenario i described would kill the site

It would kill the site we unable to load user content messages too if they
had created content…

--
Tony Partridge

On 29 September 2017 at 14:19:25, Brian Teeman (notifications@github.com)
wrote:

the scenario i described would kill the site

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18160 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVglgJD8Y8Kv3jDeSMI3yeAS1edFCaOks5snO5VgaJpZM4PoWZy
.

No #12908 should have meant that if the user is not found then the id is displayed - at least that is what happens in the admin i didnt check the frontend

It probably, does now. I’ve just being theoretical which is probably wrong
since that PR.

--
Tony Partridge

On 29 September 2017 at 14:31:42, Brian Teeman (notifications@github.com)
wrote:

No #12908 #12908 should have
meant that if the user is not found then the id is displayed - at least
that is what happens in the admin i didnt check the frontend

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18160 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVgliUJ7koGt_9MUJlq6tg8MdcTGJ45ks5snPE7gaJpZM4PoWZy
.

Just had it on a clients site, the message was still output in the backend
atleast with the users ID in the user box.

--
Tony Partridge

On 29 September 2017 at 14:32:34, Tony Partridge (admin@xws.im) wrote:

It probably, does now. I’ve just being theoretical which is probably wrong
since that PR.

--
Tony Partridge

On 29 September 2017 at 14:31:42, Brian Teeman (notifications@github.com)
wrote:

No #12908 #12908 should have
meant that if the user is not found then the id is displayed - at least
that is what happens in the admin i didnt check the frontend

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18160 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVgliUJ7koGt_9MUJlq6tg8MdcTGJ45ks5snPE7gaJpZM4PoWZy
.

From memory, the warning is generated by JUser itself and can't be supressed in the formfield. It kind of make sense to show the warning anyway. All I did back then was showing the ID instead of an empty field.

Actually a user should be able to delete himself too.
What will happen to the generated content (core and extensions?)
There must not only be a possibility to reassign an author by badge process but also a decision done by the user what will happen with private data. What if there are any orders in a shopcomponent, what if the articles should be deleted by deleting the user, what if they should stay, as well as the name from the original author even if he/she is not an user anymore...
I think this process should be careful planned especially regarding upcoming laws.

This issue is we don't have control over other components. We could add a Delete My Account function to the frontend easy enough.

and suspect we need to add in a hook for on deleting usings that we check all extensions for and provide an updated userid which run's the extensions function as they wish for the content to be updated to assign the content too. Maybe we add in a dummy user i.e. Deleted User which cannot be seen but can be referenced.

Yes, but what happens if a user deletes him self, will his articles be unpublished, assigned to someone else, assigned to "deleted user", will the articles be deleted because it's private content or will they be still there and so on. Will there be a possibility to restore the user within a period of time (like facebook does) etc.

@coolcat-creations I have a guest blog post from a GDPR expert almost ready to be published that will address this question i hope

Please translate "GDPR".

"General Data Protection Regulation" > https://volunteers.joomla.org/teams/gdpr-working-group

And what about quotes of users if a Joomla site has a forum ? Posts will have quotes of the users or if deleted ... posts that make less sense because the reference was removed from the post.

@infograf768
https://www.eugdpr.org/

@brianteeman

I have a guest blog post from a GDPR expert almost ready to be published

Guest blog post where ?
Who is the expert ? What qualifies them as an expert ?

"General Data Protection Regulation" > https://volunteers.joomla.org/teams/gdpr-working-group
should that be
https://volunteers.joomla.org/teams/compliance-team

@Webdongle That is up to the Forum Extension Developer to implement into his "user is deleted" logic.

@coolcat-creations
Yep agreed ... if a webmaster has a forum (or comment system) and that extension also deletes the posts fine. But if the extension doesn't or the user is quoted in other posts then allowing Joomla user self deletion would leave that users footprint. Therefore that would be problematic.

That's why imho if Joomla core allows for users to self remove that it should be an optional setting (No as default). That way the webmaster can remove all references on request rather than the user just deleting the account with the website.

On a side note ... deletion request could be clearly stated in the sites T&C. And the T&C box/link could be an option (for the webmaster) on the Registration form instead of the user plugin.

The delete method can be hooked into by plugins already if I remember correctly so extension devs could trigger deleting on their point.

I still think my argument stands of having a hidden single deleted user user, if you load a user that doesn’t exist it should return a false user of ‘User no longer exists’.

On 8 Dec 2017, 10:23 +0000, Kevin Griffiths notifications@github.com, wrote:

@coolcat-creations
Yep agreed ... if a webmaster has a forum (or comment system) and that extension also deletes the posts fine. But if the extension doesn't or the user is quoted in other posts then allowing Joomla user self deletion would leave that users footprint. Therefore that would be problematic.
That's why imho if Joomla core allows for users to self remove that it should be an optional setting (No as default). That way the webmaster can remove all references on request rather than the user just deleting the account with the website.
On a side note ... deletion request could be clearly stated in the sites T&C. And the T&C box/link could be an option (for the webmaster) on the Registration form instead of the user plugin.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

with #19023 i've tried to manage user deletion, instead of creating ghost users, with the help of the onUserBeforeDelete event, we can halt the delete process if the user have some "contents", in this way the webmasters can apply their wokflows to handle this situation

@alikon,

The problem with that is you cannot account for knowing where it is used and if the developer has used it.

The solution to create a ghost user to me is better with a re-assign content for core components on deletion

in my view you can with onUserBeforeDelete any developer can implement they desired workflow

I agree with Tony on this

#18160 (comment)

Why do you need a ghost user for this? You can as well just mark it as ghost if the user is not found. Because it's exactly that.
If your concern is the message, I'm sure we could look into changing JUser or if we can catch the message.

@thomas that’s my point if User is not found we can mark as a ghost User with username = notfound and name = User not found or a translation people approve off.

On 10 Dec 2017, 12:31 +0000, Thomas Hunziker notifications@github.com, wrote:

Why do you need a ghost user for this? You can as well just mark it as ghost if the user is not found. Because it's exactly that.
If your concern is the message, I'm sure we could look into changing JUser or if we can catch the message.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Would it be possible / best to choose rather than 'notfound' something that links more to the upcoming GDPR and an internationally known choice, such as 'Redacted User' whereby any of these listings, could also be linked to / have a link to an explanation of what this means in real terms, to other site visitors?

The Merriam-Webster Online dictionary gives a third sense of redact:

3: to obscure or remove (text) from a document prior to publication or release

So, nothing since the turn of 2018 on any of the above, how do things stand with this whole matter please anybody?

@tonypartridge

that’s my point if User is not found we can mark as a ghost User with username = notfound and name = User not found or a translation people approve off.

Would it be possible / best to choose rather than 'notfound' something that links more to the upcoming GDPR and an internationally known choice, such as 'Redacted User' whereby any of these listings

If a user record is not found in the database this does not mean that the account is redacted as it relates to removal via privacy regulated requests (i.e. GDPR), so no, the name shouldn't default that way. The only way to do that would be to retain the user database record after sterilizing it of all PII (and I get the feeling somebody is going to argue the database PK is PII and needs to be sterilized now...).

Stackideas do something that might work here. They have a setting for "orphaned items" that allows you to select a user to assign them to on deletion of the author. Not sure this is a good solution but thought it worth mentioning.

and I repost ... time to turn off computer!

Patch created https://issues.joomla.org/tracker/joomla-cms/19023

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/18160

closed as having Pull Request #19023