Common use case includes the following actions:

1. You need to create "project" in your bug tracker software. One "project" for each of your products or component, which you want to track individually. Optionally you need to assign category and/or other classification to "project" (it depends on your bug tracker software).

2. You need to create "submitter" (reporter) account, which will be used to submit reports. Limit its rights as much as possible. Typically submitter account needs rights to create new bug reports, list and view existing reports (to determine if issue was already closed) and update/comment existing issue (to change "number of occurrences"/"count" and similar information in existing report). Exact rights depends on your bug tracker software. We recommend to setup account with minimum rights and test send. Increase account's rights in case of insufficient privileges. Test sending again. Repeat until you'll get successful work. See also: Security Considerations.

Notes:

•	Be sure to test 3 kind of sending:

o	send new report (previously unknown issue);

o	send same report twice (reporting known problem);

o	send report, when issue was closed (to test "bug closed" case).

•	You need to do this action only once. However, optionally you can create one submitter account for each "project" (see below). But this is optional.

It is also a good idea to block changes into this account (i.e. disable possibility for the account to alter its password, delete itself, etc.). That is because your EurekaLog-enabled executable will store account details in order to be able to submit reports, which means account details can be stolen and used for malicious actions. See also: Security Considerations.

3. Assign "submitter" account to each of your "projects".

Note: it's highly recommended to create standalone category and/or "projects" for automatic submissions. Create another "project" to manage manually created issues. You can move issues between two "projects". This will help to isolate manual and automatic submissions. This is especially useful, if you give many rights to "submitter" account. Separating into two "projects" will ensure that "submitter" account can't mess with your important information. It has access only to "projects" for automatic submissions. However, this is optional action. See also: Security Considerations.

4. Create custom informational fields and assign them to your "projects". Exact details depends on your bug tracker software. For example, you can create "count" field for Mantis, BugZilla, Jira, Redmine, and YouTrack (FogBugz, Exceptionsless and GitLab already has such field; while GitHub does not support custom fields). Another useful field is e-mail contact. You need to do this action only once.

5. Setup e-mail notifications, if needed.

6. Enter bug tracker details into EurekaLog settings of your projects.

Common "gotcha's" for using bug tracker software

Here are some points which are worth looking for:

•

Try to avoid non-ASCII characters (those which code is above 128) in host/URLs, account names, passwords, etc. While most recent environments offer full support for localized names and characters, older platforms may limit EurekaLog capability to use them. For example, using Cyrillic account name in Delphi 7 will break sending on Italian Windows - because ANSI string will be treated in wrong code page.

•	Create a new account specifically for sending reports. NEVER use main/personal/administrator account for bug report submission. See also: Security Considerations.

•	Create a new "project" or account for each of your products. Do not mix several products with one account. For example, create different "projects" in bug-tracker software for each of your software products. See also: Security Considerations.

•	Test sending before deploying. Test it with both exceptions and leaks. Test it for new and closed reports. Be sure that sending process meets your expectations.

•

Before upgrading/changing your end of bug report submission (HTTP upload script, FTP configuration, bug tracker software, etc) - be sure to test this new environment. Ensure that new configuration allows old versions of your application to report bugs (if you still need these bug reports). For this reason be extra careful to use "hosted" solution - because you may not control server software changes.

•	There are events for customizing sending: such as OnAttachedFilesRequest, OnZippedFilesRequest, and OnCustomWebFieldRequest.

Sending algorithm

When you deploy EurekaLog-enabled application to your clients - your application will send you bug reports about each found problem "from the field". Application will try to log in to your bug tracker server, then it search for current bug (to see if this is known issue or not). If issue wasn't found - application creates a new issue and assign it to specified account. If issue was found (reporting known bug) - application will read report to determine its status (closed or not). If issue isn't closed - application will edit it to update "count" field, upload bug report (optional) and do similar actions (can be set in options - see options for bug tracker sending). If issue is already closed - application will do nothing.

If you've enabled corresponding options - application will display a success/error/"this bug is fixed" message. See also: Customizing Feedback.

Working with bug reports

Common bug resolving path is as following: first, application reports about found bug. You'll see new issue/ticket in your bug tracker software (either you visit it regularly or receive e-mail notifications about new problems). Now you can start to study problem, bug report, search for solution. While you're working on the issue, your application will continue to reporting about this problem. Basic reporting includes updating "count" field, but you can also enable gathering additional bug reports, if you like.

Notes:

•

Alternatively, when you're in tight time conditions, you can let bug reports to be collected. As the time pass, you'll see which bugs occur most often. So, you can start working on 1-2 "top-bugs". Typically, solving small percentage of your bugs (from your "top" list) solve over 50% of users' problems. Thus, you can save your time (by delaying solving rare bugs) and still have great user's satisfaction.

•	Report submission for specific issue will continue until this issue is closed.

Eventually, you'll fix bug (or find it to be "unfixable"/"no action required" in some cases). When this happens, you need to release an update to your software and publish it, say, on your web-site. Then you "close" bug in your bug tracker. When your (old) application encounter this bug again and attempt to submit a bug report - it will discover that this problem is already solved and will tell user to get an update, so he'll no longer get this problem.

Basic messages includes common generic phrases, but you can create a custom feedback messages.

Root > Solving bugs in your code > Managing bug reports in issue tracker Managing bug reports in issue tracker

Managing bug reports in issue tracker

Common "gotcha's" for using bug tracker software

Sending algorithm

Working with bug reports