Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro TicketQuery(summary=APP_BUG_REPORT_FORM_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed

current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

this should be invokable  from help menu, or on internal error

The Bug report form eases communication between users and developers. The form contains:

• A log containing information useful for debugging. This field is read only.
• A custom text field containing user explanation on what happened. This is not a required field.
• A text field for the user's e-mail address.
• A warning that user information such as working path and filenames will be sent.

Behavior:

• The bug report form appears automatically when an expected error occurs (exceptions, etc).
• The bug report form may be forced by the user using "Help->Send an error report"

The goal of this revision is to provide the client side of bug reporting. (I.e. the bug report couldn't be sent automatically, but can be saved as a file).

Task requirements

• Create an extension for the "Send an error report" item for the Help menu.
• Implement invoking the Application bug report form automatically on catching an exceptions.
• Create the bug report form
  • A dialog
  • Titlebar
  • Text fields
    • The content of the e-mail field should be saved in a config file. First time the form is opened, the user enters his/her e-mail address. Next time the field displays the same address.
  • Report button - in next revision
  • Save-as-file button - saves the report as a plain text file (a file dialog is opened and the user selects a path for the file)
  • Cancel button - closes the form without saving or sending the report
• Bug report contents (in this order):
  • Exception's stack trace if the form is invoked automatically on error.
  • Sophie's log file (currently it is not in distrib directory).
  • System properties such as operating system version, version of Java, ...
  • User's e-mail address.
  • User's explanation (which can be empty).
• Titlebar must contain Bug number or exception description.

Task result

Code.

Implementation idea

• This is a draft diagram. For now, the checkbox is obsolete as it is hard to implement and not much useful. Instead, there is a text field for the e-mail address.
  

• Create a handler for unhandled exceptions. Use Thread.setDefaultUncaughtExceptionHandler.

• Save the e-mail address in a config file in distrib directory. In next revisions save it in application's configuration file.

• Get the contents of Java system properties like "os.name", "os.arch", "os.version", etc.

Related

PLATFORM_STANDARDS_MANUAL_TESTS

How to demo

• Open Sophie 2.
• Perform an action that throws an error (if you don't know such, manually invoke the form by the Help menu).
• Enter something in the explanation text field.
• Save the error report in a file.
• Open the file to show the collected information.

Design

Implementation

^{(Implementation results should be described and linked here (from the wiki or the repository))}

Testing

Comments

danvisel: A note on this: I think it's important to get the user's email address in some way. In Sophie 1, 95% of the time, users just clicked "okay", we were sent a bug report, and then couldn't do very much with it because we didn't know anything about the book, what was being done, and we didn't have any way to contact the user about it. I think in the pre-release versions of Sophie 2 we should get the user's email address the first time they start the program; this should be sent with the bug report so we have some way to get more useful information for debugging.