When do you thing the “never error messages” will be a reached status?
Tryton version 99.0 ? (I’m joking because it’s impossible in software world)
Enhanced dialog proposal:
An error 123 occurred.
Click here to see and report technical details.
We achieve something similar to what you propose with the sentry-tryton module and without losing the full traceback for the developer:
- The user sees a nice user message in case of error
- We recieve an alert with all the information in order to reproduce and fix the issue.
1 Like
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.
Please report them so they will be removed.
If you do not take time to report them, it is not by hiding them more that they will be solved.
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 is due to a bad installation or database initialization.
So it is not a bug in Tryton and hiding it will not help fixing it.
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)
It is to translate user error.
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.
There are two types of errors in Tryton:
- 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.
1 Like
An error 123 occurred.
Click here to see and report technical details.
(here: enlarges dialog with backtrace log and/or prepares a complete report with OS, Python & PostgreSQL version, etc.)
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.
1 Like
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.
I love it.
If we’re able to explain that to the customer in those terms I think our “weakness” turns out strength to reach the goal of gain another friend (customer) for Tryton.
1 Like
I deliberately created an bug and looked a bit at the dialog. I think making a small change is a good compromise.
- Make the traceback default collapsed
- Change the
report buglink to a button and put it near theclosebutton - Eventually add the word ‘BUG’ somewhere in the popup, so the user know that trying again don’t make any difference.
I don’t think adding error codes makes any sense. Also the
Fault message is self-explanatory. And when such message pops up at a demo, as the demonstrator you directly blame the developers that they messed things up and you can’t show the situation now.
2 Likes
One thing that I like about Tryton (and I boast it in front of my users and clients) is the highly level of quality that is maintained by the Tryton team. So when @ced points out the importance of testing and maintaining the same high levels of quality, I share the enthusiasm.
On the other hand, it sometimes becomes tough to handle the situation when a client is trying to evaluate and decide that why should he hire the team and use Tryton over other systems when an error message with Traceback appears.
The solution given by @edbo (Hide Python messages) looks good to me and explains the actual need that is required with respect to this topic, in a more diagrammatic way.
1 Like
I can only agree with @pokoli : use Sentry.
There is available the python module he pointed and also very recently this integration https://discuss.tryton.org/t/sentry-sdk-integration has made its way to the master sentry_sdk branch and has been released to PyPI.
Sadly, neither capture client exceptions, only server’s.
If you don’t like this particular ticketing system, you can develop handlers for any other one in a similar fashion.