Root > Integral parts > Options > Report sending page > Jira/BitBucket

Jira/BitBucket

Previous pageReturn to chapter overviewNext page   

This is setup options for Jira send method (wsmJira). They are located at Sending tab.

 

This article refers to Jira bug tracker, which was initially known as "just Jira". Later it was renamed to "Jira Software". This article does not reference "Jira Core", "Jira Service Management", "Jira Service Desk", "Jira Align", "Jira Work Management" or any other product from Atlassian Jira family. Jira bug tracker can be integrated with BitBucket. If you are looking for a way to submit bug reports to Jira Service Desk instead ("Jira Service Management") - you can use Jira issue collectors.

 

This article describes options for accessing Jira via API. Alternatively, you may use HTTP send method to post bugs to Jira issue collector.

 

 

Jira send method options

Notes:

 

 

1. "URL" (.SendJIRAURL) option specifies target URL for your Jira installation. Do not add here "http://" or ":80" parts here. Specify only domain name (or IP) and path. Example: www.example.com/jira/

 

Warning: be sure to setup adequate maximum upload file limits in your web-server/ira configuration. Otherwise sending may fail on large bug reports.

 

 

2. "Port" (.SendJIRAPort) option specifies HTTP port on web server. It's 80 by default. Other common value is 8080. For SSL/TLS it's usually 443. Port will be set automatically to 80/443 by default.

 

 

3. "SSL / TLS" (.SendJIRASSL) option enabled secure mode (HTTPS protocol). Port will be set automatically to 80/443 by default. Don't forget to adjust port number, if you are using an alternative port number.

 

 

4. "Login" (.SendJIRALogin) and "API Token" (.SendJIRAPassword) options specify your account on Jira server. This account will be used to submit bug reports.

 

Notes:

You can use your account's password in older versions of Jira, or if you are using Jira Server installation. Latest versions of Jira and Jira Cloud require you to use API Token as password. Please, refer to Jira Documentation for more details. You must use e-mail address as login when using API Tokens;
When using passwords (not API Tokens): do not specify e-mail or full user name as login, use only username. You can find your username in your Jira profile.

 

Warning: your real account's data will be stored inside application. Even if it's encrypted - it's still stored inside .exe, so it can be stolen. DO NOT use Jira admin account here. Create a new special account for bug reporting via this method. Limit its rights to submitting only. See also: Jira setup, Security Considerations.

 

Note: it is a good idea to disable e-mail notifications for this account.

 

 

5. "Proxy" (.SendJIRAProxyHost, .SendJIRAProxyPort, .SendJIRAProxyLogin, .SendJIRAProxyPassword) options specify proxy details. You can leave them blank to use system-provided settings. Or you can fill these values to set custom proxy.

 

 

6. "Connect" button will try to connect to your Jira server using the specified URL/port/credentials. If you made a mistake in your configuration - an error message will be displayed. In case of success - field below will be populated from configuration of your bug tracker.

 

 

 

7. "Project" (.SendJIRAProject) options specifies project name to store bug reports. It's mandatory. Project name is case-insensitive, do not specify project key as name.

 

 

8. "Issue type" (.SendJIRAIssueType) option specifies issue type to create. Mandatory. Default is "Bug".

 

 

9. "Assign to" (.SendJIRAOwner) option specifies owner account name. If this option is empty, all submitted bug reports will be assigned to default account (configured in Jira options). If you enter here any account name - all submitted bug reports will be assigned to this account. Do not specify full user name as login, use only username.

 

Note: this option is ignored, if submitted bug report already exists (submitting known issue).

 

 

10. "Component" (.SendJIRAComponent) option specifies component for submitted reports. It's optional.

 

 

11. ""Count" field name" (.SendJIRACountFieldName) option specifies name of custom field, which EurekaLog will use for bug report counting. By default, Jira doesn't have any "occurrences" or "count" fields, so you can't know how many times bug has occurred. To workaround this problem, you can create a custom field in Jira configuration, which you will use for this purpose. You can enter name of this field here - and EurekaLog will use it to count bugs.

 

Important: custom field must be present on issue creation page. Otherwise EurekaLog will not be able to fill it. See Jira configuration guide.

 

See also: issues workflow.

 

 

12. ""E-mail" field name" (.SendJIRAEMailFieldName) option specifies name of custom field, which EurekaLog will use to store e-mail of user who sent (original) report. By default, Jira doesn't have such field. You can either create a custom field in Jira configuration, which you will use for this purpose; or you can simply extract e-mail from bug report (file attach).

 

Important: custom field must be present on issue creation page. Otherwise EurekaLog will not be able to fill it. See Jira configuration guide.

 

 

13. ""BugID" field name" (.SendJIRABugIDFieldName) option specifies name of custom field, which EurekaLog will use to store BugID. By default, Jira doesn't have such field. You can create a custom field in Jira configuration, which you will use for this purpose. When field is specified - it will be used by EurekaLog to search/merge reports. Otherwise title (summary) is used for merging.

 

Note: we highly recommend to create and use this field.

 

Important: custom field must be present on issue creation page. Otherwise EurekaLog will not be able to fill it. See Jira configuration guide.

 

 

14. "Opened statuses" (.SendJIRAOpenedStatuses) option specifies which statuses indicate that issue is NEW. The list can contain one of more values. Separate individual values with semicolon (";"). This option is case insensitive.

 

See also: issues workflow.

 

 

15. "Closed statuses" (.SendJIRAClosedStatuses) option specifies which statuses indicate that issue is CLOSED. The list can contain one of more values. Separate individual values with semicolon (";"). This option is case insensitive.

 

See also: issues workflow.

 

 

16. "Max. text field size" (.SendJIRAMaxTextSize) option will cut all text fields (description, summary, comment, etc.) to the specified value. The limit is set in characters. Set this option to 0 to remove limits. This option must match your Jira configuration. If you set this value to be larger than specified in your Jira configuration - then sending report may fail.

 

Note: not all Jira versions have this setting. If your Jira installation do not have such setting (allow unlimited amount of text) - then remove the limit by setting this option to 0.

 

 

17. "Use/fill "Environment" field" (.SendJIRAUseEnvironment) option instructs EurekaLog to use "Environment" field in Jira to store PC and OS information. Disable this option, if you've customized this field and/or use it for other purposes. You can also fill this field manually instead of automatic generation by EurekaLog.

 

 

18. "Use/fill version field" (.SendJIRAUseVersion) option instructs EurekaLog to use "Affect Version" field in Jira. Disable this option, if you've customized this field and/or use it for other purposes. You can also fill this field manually instead of automatic generation by EurekaLog.

 

Notes:

You must enter valid versions into Jira's configuration. You also need to store version information in your executables to fill this field.
A project version will be used during sending. The version is extracted from version information of your project's executable.
Exception's module version is not used for sending (unless exception's module matches project's module).
Obsolete/archieved versions are always excluded from version search.

 

 

19. "Require "Released" status" (.SendJIRARequireReleased) option will perform version search only on released versions. Otherwise non-released versions will also be used in search.

 

Because bug tracker may create versions in an arbitrary format (like "Version 1" or "7.3 hotfix 2"), and application uses 4 numbers format (like "7.3.2.0") - EurekaLog has to perform heuristic search. Therefore, it is a good idea to minimize chances of false-positive matches by utilizing additional information, like released status.

 

We recommend to enable this option for production.

 

Note: obsolete/archieved versions are always excluded from version search.

 

 

20. "Search match up to N numbers" (.SendJIRAMinVersion) option specifies how version search is performed.

 

Because bug tracker may create versions in an arbitrary format (like "Version 1" or "7.3 hotfix 2"), and application uses 4 numbers format (like "7.3.2.0") - EurekaLog has to perform heuristic search:

First, EurekaLog looks up exact match (e.g. "7.3.2.0" = "7.3.2.0");
Second, EurekaLog tries to find version with same numbers (e.g. "7.3.2.0" = "7.3.02.000");
Third, EurekaLog performs partial search (e.g. "7.3.2.0" = "7.3.2", or "7.3.2.0" = "7.3", or "7.3.2.0" = "7.3 Beta"). The search is always performed from longer matches to shorter. E.g. when searching "7.3.2.0": "7.3.2" has higher priority than "7.3".

 

This option indicate when EurekaLog need to stop when searching version:

A value of 4 means "all four numbers must match". This is a strict search.
Value of 3 means that search would fail if there is no match with at least 3 number (e.g. "7.3.2");
Value of 2 means that search would fail if there is no match with at least 2 number (e.g. "7.3");
Value of 1 means that search would fail if there is no match with at least 1 number (e.g. "7").

 

We recommend to use value of 4 for this option, because it greatly reduces possible ambiguity. However, it will mean that you have to enter each build (even very minor one) of your application in your bug tracker's configuration.

 

Value of 1 means using very wide criteria. We do not recommend to use it. If you are still going to use it - be sure not to enter too much sub-versions in your bug tracker, especially with added text.

 

Values of 2 and 3 are a good compromise.

 

 

21. "Upload bug report files for duplicates until bug is closed" (.SendJIRAUploadFilesForDups) option allows you to collect all bug reports. If this option is unchecked (default): only first bug report is uploaded and stored. All other bug reports for the same problem (identified by BugID) will be discarded. Only "count" field will be increased (if it was configured). If this option is checked: bug reports for the same problem will be uploaded to issue.

 

Notes:

if you check this option be sure to name bug report files in unique way to avoid file names duplicates. Also, be sure to have a lot of hard disk space to store all bug reports.
bug reports will not be uploaded, once the issue is closed or resolved.
you can also stop collecting files by changing status to "In progress".

 

See also: issues workflow.

 

 

22. "Append bug report text to additional information" (.SendJIRAAppendText) option allows you to insert bug report's text into "Description" field. It's convenient, if you need to peek bug report without downloading bug report file. You can turn this option off, if you don't need this behaviour.

 

Note: checking this option will not disable bug report file upload. File will still be attached.

 

 

23. "Append only call stack instead of full report" (.SendJIRAUseCallStackAsBugReport) option alters previous option. Disabled: full bug report text will be added (e.g. general section, call stack, modules, processes, CPU/assembler, etc.); Enabled: only call stack will be added (you will still be able to view full bug report by downloading file attach).

 

 

24. "Append bug opening link to "Success" message" (.SendJIRAAllowLinks) option will add a link to view bug report on Jira to message dialog after successful send. So end user (client) will be able to view status of the report on your bug tracker (login is required).

 

This option has no effect if successful message dialog is disabled. Turn this option on for public bug trackers. Turn this option off for private bug trackers.

 

 

"Append bug opening link to "Success" message" option is enabled

 

 

"Append bug opening link to "Success" message" option is disabled

 

Note: active hyper-link will work on Windows Vista or later. It will be displayed as plain text on Windows XP and earlier.

 

 

See also:

Jira send method for general description of this send method



Send feedback... Build date: 2024-09-30
Last edited: 2023-03-07
PRIVACY STATEMENT
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: https://www.eurekalog.com/help/eurekalog/send_options_jira.php