add a link or button to report a stack trace / error

[tkimnguyen]

On a page that shows a stack trace when an error occurred, add a button/link "Report this Error" to report the error to the site owner. Should include the URL, browser, OS, logged in user name, the stack trace text, and (would be very cool) a screen shot. @plone/ux-team

[fulv]

Aren't Stack traces hidden from non-admin users?

On Wed, Nov 4, 2015, 4:35 AM T. Kim Nguyen notifications@github.com wrote:

On a page that shows a stack trace when an error occurred, add a button/link "Report this Error" to report the error to the site owner. Should include the URL, browser, OS, logged in user name, the stack trace text, and (would be very cool) a screen shot. @plone/ux-team https://github.com/orgs/plone/teams/ux-team

[image: screen shot 2015-11-04 at 6 33 11 am] https://cloud.githubusercontent.com/assets/815418/10938242/2aa06138-82be-11e5-9b9a-b970b6e4141b.jpg

— Reply to this email directly or view it on GitHub https://github.com/plone/Products.CMFPlone/issues/1223.

[tkimnguyen]

@fulv yes, and non-admin users see a "this error with really long ID occurred, please tell your admin" message with no link, no email address, no /contact-info form suggested. When regular people see that they find some other way (if they can) to report the problem, and then we don't know which site it was on, what the actual error ID was, when it was, which URL it was they were visiting, who visited (as what user, or public?), which browser & OS was used, etc, but mostly I suspect they just don't bother reporting it.

[mauritsvanrees]

+1

[hvelarde]

+1

[davisagli]

+1, good idea.

We have to pick between putting the traceback in a hidden form input (potentially leaking info about the system to non-privileged users) or referencing it by id when the form is submitted (hard because the error_log is in RAM per instance and in a load balanced configuration the form may not submit to the same instance that logged the error).

[mauritsvanrees]

Good point! We can use the id. If we come at the same zeoclient, we mail the traceback. If we end up at a different zeoclient, we mail only a link, plus a warning that the error number was not found, with an explanation for the possible reason. Probably safe to include the title of the error in the hidden form and use that as title of the mail. I guess this is the last line of the traceback.

[fulv]

Couldn't the zeoclient grep the current event logs for all other clients for the Id, if we end up at a different zeoclient?

On Thu, Feb 4, 2016, 2:25 AM Maurits van Rees notifications@github.com wrote:

Good point! We can use the id. If we come at the same zeoclient, we mail the traceback. If we end up at a different zeoclient, we mail only a link, plus a warning that the error number was not found, with an explanation for the possible reason. Probably safe to include the title of the error in the hidden form and use that as title of the mail. I guess this is the last line of the traceback.

— Reply to this email directly or view it on GitHub https://github.com/plone/Products.CMFPlone/issues/1223#issuecomment-179756178 .

[djay]

Doesn't work if its a multiple machine cluster. But u could use js to poll until you found the right zeo client. But in all likelyhood production servers aren't the one people would send reports from.

On Thu, 4 Feb 2016 7:04 pm Fulvio Casali notifications@github.com wrote:

Couldn't the zeoclient grep the current event logs for all other clients for the Id, if we end up at a different zeoclient?

On Thu, Feb 4, 2016, 2:25 AM Maurits van Rees notifications@github.com wrote:

Good point! We can use the id. If we come at the same zeoclient, we mail the traceback. If we end up at a different zeoclient, we mail only a link, plus a warning that the error number was not found, with an explanation for the possible reason. Probably safe to include the title of the error in the hidden form and use that as title of the mail. I guess this is the last line of the traceback.

— Reply to this email directly or view it on GitHub < https://github.com/plone/Products.CMFPlone/issues/1223#issuecomment-179756178

.

— Reply to this email directly or view it on GitHub https://github.com/plone/Products.CMFPlone/issues/1223#issuecomment-179790958 .

[tkimnguyen]

@djay not sure what you mean by " in all likelyhood production servers aren't the one people would send reports from". I was thinking of regular users of production systems running into a problem.

What's the next step? Should I create a PLIP from this?

[hvelarde]

@tkimnguyen the problem, as @davisagli pointed out, is the error log entry only lives in the instance that generated it: you have very low probability of falling in the same instance at the time you want to send the message to the administrator of the site.

this kind of scenario probably will be better handled by tools like Sentry which can be configured to send emails also.

[gforcada]

@tkimnguyen @hvelarde one could go around that by sending a header with the server name so that the email can already point to which server to look at.

[idgserpro]

Shouldn't https://github.com/collective/collective.logbook be merged into core instead of this? We prefer an automated approach. Tracebaks are saved on controlpanel, can set an email or a Web Hook for posting the tracebacks.

[tkimnguyen]

...or use Sentry... (logbook isn't what I had in mind)

I still think there should be an obvious way to report a problem to the site owner, with contextual information, and that mechanism should be enabled & visible only if the site owner enables it in Site Setup somewhere.