I have tested this item ✅ successfully on 0984a87

I have tested this successfully. From a functional point of view, the PR does what you say.

I wonder though, if it will be confusing for users that in the Created By field after the user is deleted, the username of the deleted user is still in that field... (wouldn't it make more sense to say deleted user) - I guess the maintainers will have to decide if a change is needed or it can be included as is.

A simple solution to a problem we have with orphan articles and anything created by a user.

However there are things to take into consideration.
For instance, we do have a privacy extension where users can opt out of the site. When this is requested, we are required to remove the user no matter what.
Therefore I would suggest all data of the user be removed and just keep the user id and the minimum required for the system to work properly. Maybe have a generic name for deleted users with the user id in the name, so that we can still distinguish which articles were written by whom... A name could be like: deleted_166.

There may be instances were you would like to find all articles created by deleted_166. So we have to make sure filtering by user is still possible.

why do this for ALL users. surely it is only needed for users who have created or modified any type of content

Thanks @exlemor, @obuisard and @brianteeman for your reply.
@brianteeman how can I check first if this user is owner of any component, what if another component/content is added in the future, this deletion method will need to be adjusted, I think it's preferable to be generic. This is my point of view from my contribution, if there is something that make it easier that I don't know to apply this logic, I'd appreaciate it.

@obuisard Thanks for the suggestion, your idea also makes me think that resetting the data, would make it possible to have the username and email reused.

Maybe have a generic name for deleted users with the user id in the name, so that we can still distinguish which articles were written by whom... A name could be like: deleted_166.

Except that would by design fail the privacy rules for completely anonymising the data wouldnt it?

Except that would by design fail the privacy rules for completely anonymising the data wouldnt it?

Indeed. I looked for some more info about the subject and it looks like anonymization the way I was suggesting (data masking) may not be enough to comply with laws like GDPR and would not be transparent to the user (thinking data would be completely deleted while only personal data would).

In forums these users are shown as "ghost", no reset is possible.

Thanks for your discussions.
I can conclude that users shouldn't be anonymized because it anonymizes personal data only, so make soft deleting the user in a way to change state, but all data is kept, also user won't be able to log in

For GDPR, I suggest adding a filter for deleted(soft-deleted) users to be hard deleted.

What do you think, all?

@reem-atalah Please have look at my user profil. You see i'm a non-developer so it makes no sense to request a review by me.

Apologizes @fgsw

@reem-atalah we like this as it brings more consistency to the UI for "objects/items", We think it needs a little more fleshing out so we can meet GDPR requirements while still benefiting from this change. We also wondered how this would work for batch delete? We'll push this to a maintainers meeting to discuss the concept further and get back to you.

Sorry but this is completely wrong.

1. No consideration to privacy regulations.
2. No consideration to how this impacts the front end display of user data

Quick example.
Set an article to display the author name and you will see something like

Before this PR if you delete the user then the author block will not display because of the conditions in the layout and you will see something like

After this PR the author is still displayed

@reem-atalah I am sorry, but suggested changes does not solve #45026.
Instead, it is introducing even more issues. As already noted in previous comments.

I suggest to close the PR.

I'm confused how @Bodge-IT can even consider this a suitable approach (even as a starting point)

@reem-atalah I am sorry, but suggested changes does not solve #45026. Instead, it is introducing even more issues. As already noted in previous comments.

I suggest to close the PR.

hadnt even spotted that this was supposed to be a fix for #45026 which is a much simpler problem to solve

Hi @brianteeman, I like it because it does offer a starting point for the conversation. That's why I've pushed it to maintainers to chew over.

It's starting at the wrong place.

It's starting at the wrong place.

If a site has 10,000 user of which 10 are content authors then this approach impacts all 10,000 users when you are only concerned with deleting the 10 authors.

Instead of the current message that "the author is not found" you intercept that with "the author is not found please assign a new author" AND

You address the concern in the actual issue #45026 with the ability to batch change from deleted author to new author.

then you are not impacting the hundreds of different places by "soft deleting" users and introducing a massive backwards compatibility break that will impact every site even those where you never delete an author.

This was discussed at the maintainers meeting today. We've looked at it from different angles and all the solutions don't really solve the problem or create new problems. To do it perfectly would be a lot of work for this "minor" problem. The final decision is not to work on this problem directly, but we will add a batch job to the CMS that allows to assign another user.

I am closing this PR, thanks for the work/discussion. At least we are now clear on how to proceed.