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 determinate 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.
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 configuration of your projects.
Common "gotcha's" for using bug tracker software
Here are some points which are worth looking for:
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 determinate 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.
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.