Hide Python messages

[josesalvador (José Salvador)]

@ced

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.

[edbo]

@prak

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.

I deliberately created an bug and looked a bit at the dialog. I think making a small change is a good compromise.

1. Make the traceback default collapsed
2. Change the report bug link to a button and put it near the close button
3. 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.

[prak (Prakhar)]

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.

[Dan]

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.