See the advice here on how to write an error message
https://design-system.service.gov.uk/components/error-message/

Yes, that's kind of what I was thinking about... And offer the solution directly in place or at least link there if it can't be done in place.

Huh? I don't get the joke ;) A simple "Click here to reset the user to "none" would be enough in this case. There are other error messages that can be improved accordingly... But is it possible to add "actions" there?

Don't worry about the "joke" - it wasnt funny

But is it possible to add "actions" there?

Actionable errors aren't something our system is designed to work with. In each case the action is going to be very reliant on context. The user ID not found error comes from the core JUser class, it's not something that can be made contextually aware (how does JUser::load() know what it needs to reset or if it even needs to reset something?).

In this example I assume it's caused when you delete a user that is the author of an article. In which case maybe perform a check when someone attempts to delete a user. If they are the author of any content, then display a warning, or allow them to set a different author before deleted

yes that is the reason. Cant remember the link but this idea has been discussed before - cant remember the outcome

My Experience on a closed Source CMS you can't delete a User as long as he is linked as Author. Same for deleting an Multimedia-Object (can't delete it if its used in an Article).

This Behaviour was in Beginning annoying, but save, what i wish for Joomla too.

There is a before delete event that can be used for the pre-delete checks. But, that's really the best we can offer since our entire system is lazy loaded and com_users shouldn't have a hardcoded behavior blocking delete if a user owns something in com_content and com_categories (think of folks using other content components as a reason why).

In general hooking the before delete events isn't a bad idea. But without blowing up core with more plugins or coming up with a way to stop lazy loading all the components so that you don't need plugins to turn on a component feature when it isn't the active component of a request, it's not something that is all that practical with our application design and structure.

I guessed there are Reasons for different Behaviour. Thanks for Comment @mbabker.

So the only solution to improve UX here is to extend the error text at least a bit, right? And is there a possibility to improve UX for Joomla 4 regarding that? To give the user the possibility to solve things with a click?

We can definitely improve the message - I don't know about the rest

To give the user the possibility to solve things with a click?

Again, it all depends on context. Where the error is raised is just as important as the text it raises. Like I said, JUser::load() can't know to attach a "click here to update this item" action to an error message; it's a library class that is used heavily and to give that kind of action context means trying to do things that aren't practical.

With the system design of Joomla, "actionable errors" aren't something that can be easily done. And to be honest trying to design errors to be actionable in that way only works if you very explicitly know the context of the error, what causes it, and what can fix it. In the JUser class, we lack the context and the ability to say what fixes it (the cause is pretty easy, the specified ID doesn't exist in the database). In the MVC layer, our error handling lacks depth to address specific error cases because the error handling is designed as a very generalized "catch an error and report it" mechanism.

Also relevant, #20689 (comment) (and every other issue/comment related specifically to the JUser::load() message since it is probably the most commonly displayed error message).

And if we add a context? Yes I understand It's too much work to have every context filled with recommendations, but if we improve the system at least at one place regarding UX it will be a win for the system...

Specifically in this case I have all the time annoying warnings like this. So I need to reasign everything from the user one by one to "None" manually? Should really be possible to add something and somewhere to improve the UX on that.

Another solution could be also a "deleted users list" where you only see anonymous data like the ID and you say what should happen with articles (or other things) this deleted user wrote.

There is always a way to solve things.

Another Error message that can be improved is that the update server is not available, why not directly linking to the "Update Sites" and recommend to rebuild it?

Specifically in this case I have all the time annoying warnings like this. So I need to reasign everything from the user one by one to "None" manually? Should really be possible to add something and somewhere to improve the UX on that.

Yes and no. Yes, this capability should exist in some form. No, it shouldn't be an action set with the error message IMO. This is the type of thing that should be checked and validated before deletion, or in the case of restoring a version checked after restoration (where an actionable error actually makes sense).

Another Error message that can be improved is that the update server is not available, why not directly linking to the "Update Sites" and recommend to rebuild it?

That assumes the error is related to the update site list not being up-to-date. If the remote server is giving a 4xx/5xx response that recommendation doesn't help at all. That's where context comes into play.

There is always a way to solve things.

You're right. I'm just making sure it's clear that there isn't a blanket fix that can be applied to every error case. Every scenario has to be handled in its own way, and in some high level classes this makes it pretty much impossible to implement an actionable error because contextually the error can be triggered through too many code paths for us to reliably manage.

I would be tempted to go down the lines of an audit component which audit checks which can be provided by components.

I.e. check com_content users associations

If it finds some, output we found some articles which users who do not exist, please select the user you wish to re-assign these items too.

Just a thought...

Thats an interesting idea and shouldnt actually be that hard

Exactly :-). Whilst I know it’s a reactive approach, given @mbabkers concerns over how the system is currently structured we could update the messages and point the user to the correct section in the audit component. Then they are fixing it where support rather than 1 article at a time.
On 26 Jun 2018, 21:55 +0100, Brian Teeman notifications@github.com, wrote:

Thats an interesting idea and shouldnt actually be that hard
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

com_healthcheck

+1
On 26 Jun 2018, 21:58 +0100, Brian Teeman notifications@github.com, wrote:

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

Looking forward to testing it next week

That sounds great @tonypartridge how can I be helpful to do it?

We need to see if the core wants to adapt it first? Otherwise it will be part of your newest favourite extension ?
On 27 Jun 2018, 10:17 +0100, Elisa Foltyn notifications@github.com, wrote:

That sounds great @tonypartridge how can I be helpful to do it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@tonypartridge From perspective of person witch helps less expiries users as a moderator Polish Joomla! forum (http://forum.joomla.pl) and on .org forum this will be huge help for me. , So for me this is must have in core.