What is our Error rendering strategy?

[carlosthe19916]

This is a question we might need to involve UX, engineering and potential users to understand how deep or not deep our error messages should be.

Either decision will satisfy a group of users and I recognize not everyone will be happy with a decision. Some users will say that they need more detail and technical error messages, others will find it useless. But it is the kind of thing where we need the direction of PM and UX

[gildub]

We already have the Notification component allowing to inform the user of "high" level events, for instance when an item (or a list of items) is created, added, edited or removed.
The Notification component acts as the main "window" of communication to the user.

Of course it doesn't preclude logs to be displayed in the web browser console.log() which can be used when more details are available. Meanwhile the experience has shown because of the console.log limitations (rough, keeps scrolling along a running application), and because we also know in some use cases some details (error/warning) are available to the user, and in such cases to be used for more advanced users, then we tend to display those details (logs, objects, lists, etc) in an adapted window.

So we can get best of both worlds, by notifying events to the user using the the Notification board and have inside the notification detail with links to more information when needed.