I think this has been reported with the sample data

Sorry. Just realised when you said versions you didn't mean a backup. Doh.

What would you suggest as a solution to this? We had something similar with
sample content

Well this was demonstrated with the same content - but the issue remains years down the line with content generated on the site.

When you delete a user - there should be a process that "cleans up" the data - because you are effectively breaking relationships when removing a user.

The quick wins are all bad. The correct way is something like, "when I delete a user, if that user "owns" anything (like created_by, modified_by, checked_out_by) then "re-own" it to some other user if its a required field or null it if its not a required field"... but the selection of which user inherits the object is something hard for erm... a UX team to discuss... :)

Like I say, I dont have all the answers :)

That actually adds a lot more requirements to the delete user function and
would require update queries in every record and table in the db. I think
there must be a better way

Exactly - this is not a quick fix... but at the moment deleting a user can cause data integrity issues like this... which also is not good.

Too bad we don't use proper FK relations, the database could just be told to cascade the changes appropriately.

@mbabker proper FK relations are coming in j4?

If someone wants to "fix" JTable to work with them then sure. Last time I tried it in a project it failed because (at least with MySQL) the table expects a NULL value and JTable sets the column value as '' (empty string).

even that would be bad...

Deleting a user, and having FK delete all my articles... gulp....

Whats needed is "when I delete a user":

• I need all tables that have created_by fields to be checked for my user id - and if found those items need to be assigned to someone else
• I need all tables that have modified_by fields to be checked for my user id - and if found those items need to have their last modified by user changes to something else... thus breaking the concept of modified_by and tracking
• I need all tables that have checked_out_by fields to be checked for my user id - and if found those items need to be checked in, or checked out to someone else
• I need that ALL tables that rely on my user object existing to be checked and have their data manipulated to enforce integrity after my user is gone... see below

Here is another example.

• Create a user
• Create a Contact in the com_contact, select the user as the Linked User
• publish a menu item to that contact (com_contact)
• delete the user
• you get the error in admin when editing the Contact
• on the frontend you get a blank contact

Deleting a user, and having FK delete all my articles... gulp....

I wouldn't cascade delete most of the content, in most cases we should be cascade nulling the column. That also means working through the code to make sure it knows how to deal with a null FK relation instead of assuming it will always be defined.

ok another example (and Im going to raise this as a separate bug)

On my site I have an admin and a Front End Author

The front end author submits 3 articles on the front end - this generates 3 messages in my private inbox in Joomla Admin.

If someone then deletes that "front end author" then I'm now suck with "(3) Messages" in my admin footer but no messages in my com_messages screen

@PhilETaylor dumb idea:

 if (is_array($app->getUser(userId)))
{
//proceed normally
}
else
{
$userId = '';
}

in the user field

@dgt41 yes we can mask and ignore the data integrity issue... but we are better than that. We are, meant to be, professional open source developers ;-)

On 13 Nov 2016 8:59 p.m., "Phil Taylor" notifications@github.com wrote:

@dgt41 yes we can mask and ignore the data integrity issue... but we are
better than that. We are, meant to be, professional open source developers
;-)

That's why I asked if you had any suggestions :)

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or mute the thread.

Depending on the reason for deleting the user if it is discovered during a check for "delete user" that the user in question has created an article/edited an article etc. Would it be plausible to have a "ghost the user" option.

Depending on the required train of thought, remove the ability for a user to log in, removal of user email and any information that's been added. Which would mean any article that's written by/edited by an no-longer in place user would not throw any errors and depending on the sites layout all would operate correctly.

yes I made them here #12881 (comment) but the (relatively) quicker win is @mbabker:

In most cases we should be cascade nulling the column.

That also means working through the code to make sure it knows how to deal with a null FK relation instead of assuming it will always be defined.

Thinking about this earlier I dont think its a good idea at all to change the data because a user has been deleted. That would break the history of the item.

Instead I think that instead of outputting the warning
User: :_load: Unable to load user with ID: %s

How about simply outputting the ID in the relevant field (perhaps with an indicator that user is no longer on the system but that might be ugly

Example

I doubt it is hard to do as we already have the ID in a hidden field but this code is beyond my skills

Missing screenshot

Thinking differently which would require quite a bit of work. But we store the username with the id and if the id fails to load a user we then revert to the stored username as plain text, keeping the integrity intact?

Hmm, if the user is deleted then we don't have the username, am I getting this wrong?

I assume Tony means that wherever we store the ID of someone who did
something then we ASLO store their name.

This would resolve the issue reported but it is a huge amount of change to
views, queries, db structure etc

On 16 November 2016 at 09:49, Dimitri Grammatikogianni <
notifications@github.com> wrote:

Hmm, if the user is deleted then we don't have the username, am I getting
this wrong?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#12881 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8bIfnjaIJ12exxrt-M1Q-_pFLAmHks5q-tGvgaJpZM4KwyrY
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

Exactly @brianteeman but would preserve data integrity....

What about a different approach? We adjust the getUser function.

We have a new table for users archive/data referencing which for now, could just store the deleted date, userid, username.

On delete we move the needed data to this table. Then we can set the getUser method to fall back to this table if not found in the first.

My only concern with this method, is the getUser function is then returning a user and someone maybe trying to fetch fields which are not available.

For me its enough to display the ID in the relevant field - we already have
the data - we even use it in the hidden value - we just have to display it

On 16 November 2016 at 09:58, Tony Partridge notifications@github.com
wrote:

What about a different approach? We adjust the getUser function.

We have a new table for users archive/data referencing which for now,
could just store the deleted date, userid, username.

On delete we move the needed data to this table. Then we can set the
getUser method to fall back to this table if not found in the first.

My only concern with this method, is the getUser function is then
returning a user and someone maybe trying to fetch fields which are not
available.

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

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

I agree @brianteeman that will work for the current situation. If anyone needed to find out who it was, they could go into a backup and find the user based of the ID.

However, I suspect we will have the issue with my last reply. People maybe fetching fields so we would need to return the whole object as per a normal user? Just with additional blank fields.

For me its enough to display the ID in the relevant field

I think that would be enough and is simple to do. See #12908.

We have a new table for users archive/data referencing which for now, could just store the deleted date, userid, username.

NO. If we delete a user, the data has to be gone. If you don't want to have deleted data disappear, just disable/block the user instead.
If anything, we could add a trash or archive state for the users, but that may have security implications if added during the life of a product and honestly I don't see the need.

I am going to close this as we have a PR for testing #12908

travelling so cant test but from code review only it doesnt appear that #12908 resolves the error messages displayed as well? can you confirm that?

It does remove the message ;)

It does remove the message

Not for me. I wonder why it does for you. Because the message is generated by JUser itself and there isn't much we could do there (except remove it).

IT was me - I had modified by users.php while checking the original report and had removed the line that issued that message

SORRY for the confusion

But do we need the warning message now anyway?
https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/user/user.php#L861

Personally, I don't have an issue with the message. It shows that something is broken which the admin should take care.
Also, JUser isn't only used in this formfield. So the error message is valid.
The question is if it should enqueue a message or just log. Ideally it would throw an error which could be catched (and discarded) upstream, but that likely is a B/C break.

Ok ignore the message if you want - fact remains that there is no data integrity in the database - larger issue that we are glossing over :-(

By deleting user you are deleting the relationship but not removing the link to the deleted object - thus data integrity is lost

Sent from my iPhone

On 16 Nov 2016, at 14:02, Thomas Hunziker notifications@github.com wrote:

Personally, I don't have an issue with the message. It shows that something is broken which the admin should take care.
Also, JUser isn't only used in this formfield. So the error message is valid.
The question is if it should enqueue a message or just log. Ideally it would throw an error which could be catched (and discarded) upstream, but that likely is a B/C break.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Yep, but as long as there is no relationship in the database, you can't find where the suer may be used. You'd have to check each extension (using a helper or so).