Root > Basic procedures > Configuring sending report

Configuring sending report

Previous pageReturn to chapter overviewNext page   

This article is a part of basic procedures.


If you're waiting for your clients to tell you about problems in your application - then you see only a tiny fraction of all problems with your application. That's why you need to build an exception and error reporting facility. And EurekaLog is able to help you with that task: it can send a bug report about each problem in your application, deployed on clients' machines. Reports can be send automatically, silently or with client's approval. You have a bunch of send methods available.


You can configure this behaviour at "Sending" section in EurekaLog project's options.


You should select one or more sending methods - by checking check-box on the left:



One sending method is selected


You need also to setup selected method in the right part. Each method has its own unique options. Usually, you just need to fill details about your account (like login / password).


All default build-in methods can be divided into two categories:

1. E-mail based. These methods send bug report inside e-mail message to your e-mail address.
2. Web based. These methods uploads bug report via HTTP or FTP protocols (including bug-trackers with web interface).


Shell, Simple MAPI, MAPI, SMTP Client and SMTP Server are e-mail based send methods.
HTTP upload, FTP upload, BugZilla, FogBugz, Mantis, Jira, Redmine, YouTrack, Exceptionless, GitLab and GitHub are web based send methods.
BugZilla, FogBugz, Mantis, Jira, Redmine, YouTrack, Exceptionless, GitLab and GitHub are bug trackers.


Unfortunately, there is no best sending method - each way have its own advantages and drawbacks. Please, see Selecting send method to pick a method which matches your needs.


Note: you can select more than one send method and change methods order. If first method will fail sending, the second selected method will be used. If second method will fail too, the third method will be used. And so on, until send will success or there will be no send methods left. The sending phase is considered to be "OK", if one method was able to send report. If all methods had failed - then sending phase will be considered as "failed".



Common "gotcha's" for sending bug reports

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 a wrong code page.
Use several send methods for best delivery results. See Selecting send method for more info. It's best to use one method of your choice and back it up with one of few e-mail sending methods. Thus, if one method fails - another one will succeed. If you use web-tracker as your primary method - often you can configure it to parse e-mails too.
Create a new account specifically for sending reports. NEVER use main/personal/administrator account for bug report submission. Create a new e-mail account (if it's possible - limit its rights to send only). Create a new FTP account (limit its rights to upload files to specified folder only). Create new web-tracker account (limit its rights to submitting reports only).
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.
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.



What's next?

After you start receiving bug reports "from the field" - it's time to read them and solve the bugs.



See also:

Send feedback... Build date: 2023-09-11
Last edited: 2023-03-07
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.

Permanent link to this article: