Rational: In a demo session, it’s very ugly that, because of simple permissions issue or action inconsistence, the user sees an error popup with only Python code and messages.
Current behaviour makes common users to believe Tryton is that console Linux-like.
Proposal: A friendly (and translatable) popup that includes at most the error code, and with an optional dropdown button to see details (that matrix code for experts).
Implementation: Deploy error strings and being translatable + include a generic one for unexpected errors. Rework Gtk dialog to hide console box.
When did you have a ugly message? Could you paste it’s message.
Normally when a traceback is shown is because there is a programing error and thus we show the full traceback so it’s easier for the developer to fix it.
About “Rational” I want to add the everyday use cases where traceback text is ugly, and would be better to be hidden in same popup message for that error/warning.
A nice and polite dialog could be:
An error 123 occurred.
Click here to see technical details.
(both strings translatable)
First one is generic in this example, but it could be more specific (and translatable anyway) for each error code.
I can understand the idea but I think the best move is to never have such error message. This means removing the bugs.
Also a drawback if we hide too much the traceback will be to have incomplete bug report because user can not find how to get it.
It is not a matter of when but of how. If we do not receive proper report of bugs, bugs will never be fixed.
By the way, where is your bug report about the traceback you got?
From my experience, it will reduce a lot the number of report with proper traceback. Already now with the traceback clearly shown, we will still have bug reports without them.
By the way, where is your bug report about the traceback you got?
This thread is a feature request (not a bug report).
Didn’t you never get a traceback log as the only message text?
I’ve seen dozens, and I’m talking about all of them.
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/tryton/gui/main.py", line 276, in do_activate
common.Login()
File "/usr/lib/python3/dist-packages/tryton/common/common.py", line 1012, in __init__
func(parameters)
File "/usr/lib/python3/dist-packages/tryton/rpc.py", line 88, in login
result = connection.common.db.login(username, parameters, language)
File "/usr/lib/python3.7/xmlrpc/client.py", line 1112, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python3/dist-packages/tryton/jsonrpc.py", line 285, in __request
raise Fault(*response['error'])
tryton.jsonrpc.Fault: <Fault 'relation "ir_module" does not exist\nLINE 1: SELECT "a"."name" FROM "ir_module" AS "a" WHERE ("a"."state"...\n ^\n': 'Traceback (most recent call last):\n File "/trytond/wsgi.py", line 73, in dispatch_request\n return endpoint(request, **request.view_args)\n File "/trytond/protocols/dispatcher.py", line 46, in rpc\n request, database_name, *request.rpc_params)\n File "/trytond/protocols/dispatcher.py", line 63, in login\n database_name, user, parameters, context=context)\n File "/trytond/security.py", line 31, in login\n pool = _get_pool(dbname)\n File "/trytond/security.py", line 18, in _get_pool\n pool.init()\n File "/trytond/pool.py", line 160, in init\n lang=lang, activatedeps=activatedeps)\n File "/trytond/modules/__init__.py", line 433, in load_modules\n _load_modules(update)\n File "/trytond/modules/__init__.py", line 360, in _load_modules\n where=ir_module.state.in_((\'installed\', \'uninstalled\'))))\n File "/trytond/backend/postgresql/database.py", line 65, in execute\n cursor.execute(self, sql, args)\npsycopg2.ProgrammingError: relation "ir_module" does not exist\nLINE 1: SELECT "a"."name" FROM "ir_module" AS "a" WHERE ("a"."state"...\n ^\n\n'>
This thread is not a bug report but a feature request.
I’ve never asked you in this thread to solve issue related to this log example, but you asked so.
Each error log is due to some bad behaviour and, if we need to talk in bug terms, Tryton’s bug could be to not show a message like: “Error: bad installation or database initialization” (+ translatable)
Because example message should be intercepted by Tryton instead of depending on Python dump.
Did you read the “translatable” request?
How do you localize traceback lines?
Do you empathize with common users impression when they see debug logs exposed as error messages? My personal impression is Tryton is not mature as it should, in error management chapter. No error codes, no messages table and no escaped characters applied (\n).
Maintaining this behaviour means simulating an alpha/beta software can be released as LTS versions for production.
This must never happen. So bug must be fixed not hidden.
We do not.
Because it should never exist.
Plainly false. All user error message are stored in ir.message and translated.
I think you are basing your request on wrong experience because your setup/installation is wrong (or you are using bad modules). I even suspect that you never reach an actual user error but only unexpected crash because of this bad installation.
My experience with many installation shows me that unexpected error (with traceback) is very rare. But when it happens, we get the proper information from the user because they have it on hand directly (we do not have to teach how to get the traceback).
What is ir.message table useful for, when there is no error codes management and you say “is should never exist”??
I think you are basing your replies on wrong example while I didn’t provide you more of them (that was the only I had filed this week because of a cite in an e-mail). I’m not trying to solve a setup/installation with this thread, because I’m not a final user. THIS THREAD IS NOT A BUG REPORT.
I’m talking about messages NOT about errors itself or concrete installations.
I understand you don’t like this requested behavior; then this could be an optional parameter to be set on client profile/tryton configuration. Think the world is very big and cultures are diverse to understand when a user reacts to this:
An error 123 occurred.
Click here to see and report technical details.
(even more when some people is choosing to use Tryton or another ERP)
No because unexpected error are by definition unexpected. So on proper code base and setup, they should not happen. But if by chance, one happens, we need all the information.
If you want to talk about user experience , you would better have a correct/working installation first. Than we can talk about it.
No need to shout out.
As I said, expected error are properly display if you have a correct setup/installation.
We are not going to add an extra parameter for that because parameters are the worst answer to a problem.
Maybe but what we want is the traceback to be reported. So the best way is to always display it.
For sure having unexpected error when testing is bad and does not help to be chosen.
But the real problem is the unexpected error not the message.
Exceptions. These are translatable messages which informs the user that they did something wrong like inserting wrong data into different fields. The developer adds these messages in the code to make sure the right data is added.
TraceBacks. These are plain Python error messages which informs the user that the developer messed up things (it’s a bug). This kind of messages should almost be non-existent in production, but sometimes they are. The user then have to inform the developer with this traceback, so the developer can fix his messed up code.
So I’m with @ced here, when a tracebacks pops up, you have to inform the developer with the traceback. You can try to hide the message behind a nice screen like in Windows with a kind of code, but how will the traceback reach the developer so the developer can fix this? Because a traceback means a bug.
What is the point to request the user to click here if he always has to click it. It is better to avoid him an extra click and provide directly the information.
I would like to add in my experience here. In environments like here, the users are mostly Doctors, Nurses, Civil Engineers, Administration and Accountants or may be simply Data Entry Operators (in nutshell, the people who are not technical people. For them, a message that has been handled properly using “raise”, seems clear and direct.
However, if any of my developer has not handled a scenario that is not imagined at the time of coding, and an error comes up later to the user, it showcases the entire Traceback. This traceback is highly important for the developers to debug the issue. Most of the times, a simple look at the traceback is enough to identify the bug.
But the non-technical users sees this screen as if something horrible has happened. And they start complaining left and right. It has happened with me that in some demos, an unseen scenario pops up the traceback and the entire reputation is ruined.
So the request of @narcisgarcia is relatable to me in the environment that I work with. The confidence of the users and the clients withers away if something like a traceback comes up in front of them at the time of usage or when trying to win a client in a demo.
And they are right. Such thing happens because the code was not tested enough. But at least with the complain and the traceback, this can be fixed.
So we agree. And having a report without it is pointless for the developer.
For good reason if the developed code was not tested enough. And hiding the traceback behind a generic error message will not improve the reputation neither because it is not the display of the traceback the problem but the unexpected error.
But hiding problem will not solve them. It is better to have a bad time once but being able to fix the issue, then having silent errors that are never fixed because it is missing information.
For me, the request is similar to requesting silent failure. This is the worst thing to do for stability and robustness.