EurekaLog uses BugID to identify exceptions and leaks. BugID is a hash of exception information. Two exceptions with the same BugID are considered to be the same.

EurekaLog uses BugID to determine if the current exception was already reported or not:

•	If BugID of current exception is not found in bug tracker (in other words, current exception is not reported yet) - EurekaLog will create a new issue in bug tracker, set "count" field to 1, attach a bug report;

•	If BugID of current exception is found in bug tracker (in other words, current exception is already reported) - EurekaLog will not create new issue. The exact behavior depends on status of the issue in bug tracker.

EurekaLog supports three stages (statuses) for bugs in a bug tracker:

Supported issue workflow in a bug tracker

Default workflow

•

NEW. This is a default status. New (freshly posted) issues will have this status. The issue is opened. The "count" field will be updated. The bug report file attaches will be added. This state is used to collect information and reports about issue. Typical status names are: "new", "open", "reopened", "feedback", etc.

•

IN PROGRESS. This is the status that may be manually assigned to NEW issue. It indicates that issue is confirmed, reproduced, and developers are working on it. The "count" field is still updated, but new bug reports will be rejected. This state indicate that developer do not need any more information on the issue. This status is used mostly to stop accepting bug reports for popular issues. It is not necessary to put issues to this state, you can simply close / resolve issue instead. Typically, status names can be anything, except statuses for NEW and statuses for CLOSED. Few examples: "in progress", "assigned", "confirmed", "accepted", "review", "blocked", "verified", "acknowledged", etc. FogBugz only: an issue can be put in this state by switching BugzScout issue to "Stop reports".

•

CLOSED. This is the status that must be manually assigned to NEW or IN PROGRESS issue. The issue is closed, e.g. resolved or rejected. The "count" field is not updated. The bug reports will be rejected. This state indicate that developer do not need any more information on the issue, and there is a solution for the issue. Additionally, this status is treated differently when sending report: see "Only "bug closed"-message" option, for example. Finally, this status allows customization via notes (comments) and special tags. Typical status names are: "closed", "resolved", "done", "fixed", "rejected", etc.

Reopening a closed issue

Some bug trackers and send methods support reopening a closed issue:

1.	Your project must have a version information for this feature to work;

2.	Your bug tracker project must have list of released versions for this feature to work;

3.	Your EurekaLog settings must check/enable the "Use versions" option for this feature to work;

4.	You must close/resolve bugs by specifying version of your application in which the bug was fixed (fields like "Fixed In Version", "Fix versions", etc.);

5.	The bug must occur again in the new version of your application.

When the bug is closed and you have marked it as fixed in version N: any application version M (M >= N) will (re)open the bug. Bug status will be changed from CLOSED to NEW, bug report will be attached, count/occurrences will be increased. For example:

1.	If your bug occurred in version 1.0.0.0;

2.	You have fixed it in version 1.5.0.0;

3.	You have closed the bug in the bug tracker, marking it as "fixed in 1.5.0.0";

Then:

a.	Version 1.0.0.0 of your app will do nothing and tell user that the bug is already fixed;

b.	Version 1.5.0.0+ will reopen the bug and upload a bug report.

Customizing the default workflow

If you are not satisfied with the default workflow - you can customize it.

Root > Solving bugs in your code > Managing bug reports in issue tracker > Bug trackers setup > Issue workflow Issue workflow

Issue workflow

Default workflow

Reopening a closed issue

Customizing the default workflow