Time Zones in JIRA

JIRA allows every user to specify his own timezone through user profile since version 4.4.

JIRA Time zones

JIRA Time zones

If you look at the above diagram at any time we have to consider 3 different time zone. Theoretically users computer/browser’s time zone may also be different than user’s time zone defined in profile page. In that case JIRA will inform user about this mismatch and request user to fix. If he does not any REStFul API that accepts time zone as milliseconds since 1970 convention will fail. As a best practice web service APIs should accept time related information in textual format. But this also has formatting problems and makes using API a little more difficult but it is better than processing wrong information.

When an action is performed by a user, timestamp is converted to JIRA’s own timezone setting and recorded in the database. Later when needed this timezone is also converted to requesting user’s (possibly a different user than who performed the action) timezone. This cause everyone to see different time for the same event. This is the same for work log entries. Lets see with an example. Following two screenshots are for the same work log entry.
In the first one we see how it is displayed for a user with time zone “(GMT+02:00) Istanbul”:

In the second one we see how it is displayed for a user with time zone “(GMT-11:00) Midway”:

As you can see they see the same work log entry as if it is performed on different days. For the perspective of the user actually it is performed on different days. But the question is, “On which day we should place this work log entry for a timesheet?”
Since timesheets are mostly used for cost or billing calculations the day on which a work is performed is very important. For example some companies may be paying more for works performed on weekends. If a user did not performed the issue on the weekend it should not be reported as performed on weekend just because of time zone of the user requesting the timesheet report is different from time zone of work log author.

In Worklog PRO Timesheet for JIRA we display this work log on the same day work log author reported. Not with the time zone of the user requesting the timesheet or not with the time zone of the server. This is also compliant with how timesheets are reported by another popular JIRA Timesheet tool. But these two plugins are radically different in terms of how work logs are stored in JIRA.
Lets start with the easy one, Worklog PRO Timesheet. It just stores work logs with JIRA’s own convention so its work logs are compliant with JIRA. Later if you decide to uninstall the plugin all work logs will be as if they are entered from JIRA’s own work log entry dialog.
Other timesheet solution stores work log entries normalized with JIRA Server’s time zone. As a result if you look at the same work log with this tools own “work log panel” you will see different date and times than it is displayed by JIRA’s own “work log panel”. Recommended solution is to disable JIRA’s own work log panel. But later if you decide to uninstall the plugin, you will need to re-enable it and it will continue to show incorrect dates forever.

VN:F [1.9.22_1171]
Rating: 9.0/10 (4 votes cast)

Preview Issue Description in JIRA

In start a work day by loggin in JIRA. At the end of the day I usually have 10+ tabs are open in the browser just for JIRA. Most of the times I only look description of the issue, I do not need issue to stay in the browser.
I have developed a free JIRA plugin to solve this problem. Everywhere inside (navigations, dashboard, inside other issues etc.) JIRA, if you hover mouse on an issue link, it displays description of the issue in a popover window. Preview contains all the formatting of JIRA, including images, tables, source code highlights etc. It is lighweight and fast way to browse issues.
You can download the plugin from Atlassian Marketplace.

JIRA Issue Description Preview

JIRA Issue Description Preview

VN:F [1.9.22_1171]
Rating: 9.5/10 (2 votes cast)

Component Versions JIRA Plugin

Component Specific Vesions is a JIRA plugin that allows you to define which versions are valid for which versions, and enforce this during issue operations. For more information please visit http://jiraplugins.com

VN:F [1.9.22_1171]
Rating: 10.0/10 (2 votes cast)

Resolution and Status Colors JIRA Plugin


Resolution Colors Plugin enables issues to be shown with different color depending on their resolution and Status Colors. Why do you need this, aren’t just the Status Colors enough? Unfortunately, no. Because unlike most other issue management systems, a ‘Resolved’ status does not show that the issue is solved. An issue may be resolved because assignee may have decided not to implement it with specifying a “Won’t Fix”, “Cannot Reproduce” or “Incomplete” resolution. So while checking resolved issues, you have to pay special attention to the ‘Resolution’ field.

So what this plugin does is that; this plugin makes it easier to highlight issues according to their resolution type for issue reporters or verifiers. But if you want, you can use this plugin in a way that it only highlights issues based on their status.

Resolution Colors

Initial Configuration

After installing plugin you have to do some initial configuration to activate plugin’s features. The first thing you should do is adding a new custom field of type ‘Resolution Color’. Although the name of this field is ‘Resolution’ it can also highlight issues based on their Status.

  1. From issue administration page, scroll down to ‘Fields’ section and click on ‘Custom Fields’ link. List of your existing custom fields will be displayed. Select ‘Add Custom Field’ from top right of the page.

Resolution Colors

  1. A pop-up dialog box will be opened. Select ‘All’ and write ‘Resolution’ to search field. ‘Resolution with Color’ custom field type will be displayed as shown in the following figure. Select it and click ‘Next’.

Resolution Colors

  1. Enter a name for the new custom field. This name will be displayed as the column name in the issue list. You can enter any description you want, it won’t be displayed to end users. Finally click on ‘Create’ and your custom field will be created.

Resolution Colors

  1. You have to select, on which screens this custom field will be shown. You have to select every screen that contains resolution field, and you want issues to be colored according to their resolution.
    Resolution Colors
  2. Your custom field is now ready to use in issue detail pages. But you have to configure the issue list pages too.
    Resolution Colors
  3. Open the issue list and click on ‘Columns’ on top right of the page. Write ‘Resolution’ to the search field and two Resolution fields should be displayed. ‘Resolution’ is JIRA’s build in ‘Resolution’ field and ‘Resolution with Color’ is our new custom field. De-select ‘Resolution’ and select ‘Resolution with Color’ field and click on ‘Done’. If you change your systems default column layout, every user will start with that layout. But if they have already an active column layout they will need to add ‘Resolution with Color’ field to their column layout as well.

Resolution Colors

Note that, you can even add this column to your issue lists in dashboards to make them colored.

List Views

For issue list to be colored you have to add ‘Resolution Color’ custom field to the column list. Without it, there won’t be any coloring in issue list view. You may add this field to default list view columns so that it becomes active for all users by default.

Issue List View

You can also colorize issues in dashboard widgets by adding the same ‘Resolution with Color’ field to columns shown in the dashboard.
Coloring in Dashboard

Issue Detail View

Depending on plugin’s settings different parts of the issue details view are highlighted. Please see ‘Plugin Settings’ section.

Issue Details View

Plugin Settings

You can use the plugin without adjusting any settings. It comes with reasonable defaults. But if you want further customization, or your JIRA Status and Resolution fields are highly customized you may want to tune Plugin’s Settings. There are two settings page, one for ‘Resolution Colors’ and the other for ‘Status Colors’.

Resolution Colors

Plugin assigns its default colors to JIRA’s built in ‘Resolution’ options. If you have custom ‘Resolution’ options you may also assign colors to them. You can also change predefined colors for build in ‘Resolution’ options. Be careful while selecting a resolution color, each device (Projector, Printer, Screen) may display colors differently and this may cause issue details to be unreadable if you select a color that is close to black (normal text color), or blue (link color). So in general, avoid dark colors. For example if you want to use red try to select a very light red.

In addition to the color, you can also select which part of the issue detail view to be highlighted.

  • Header : All issue details fields are colored.
  • Resolution : Only the resolution field is colored.
  • None : Coloring is turned off.

Plugins Settings:Resolution Colors

Status Colors

If you need to differentiate issues based on their status you have to configure Status Colors too. The key is that Resolution Colors have priority over Status Colors. For resolved issues their Resolution Color is used. This is why there is no color setting for “Resolved” status in ‘Status Colors’ configuration page. There is a special case however, the plugin allows you to use ‘Status Color’ of Closed status instead of ‘Resolution Color’ if you set it from ‘Closed Status Coloring’ configuration option.

Closed Status Coloring

  • Use Status Color : For closed issues their Status Color is used instead of Resolution Color.
  • Resolution Color : For closed issues their Resolution Color is used.

Plugin Settings:StatusColors

If you want to use this plugin to highlight issues based only on their status field, you can. You have to specify the same color to every Resolution option and assign different colors to Status options.


VN:F [1.9.22_1171]
Rating: 10.0/10 (2 votes cast)

Similar Issues JIRA Plugin


Similar Issues Finder Plugin targets to minimize number of duplicate issues within JIRA. Each duplicate issue takes precious time of its reporter, assignee, management and QA teams without any significant benefit to the end product. For a 500 employee organization saving 1 minute of each person a day will save nearly 3 months each year. Even a single duplicate issue may easily cause an hours work.

Similar Issues Plugin

Similar Issues Overlay

Similar Issues Plugin performs a real-time background search on the JIRA to find out similar issues as soon as you start to write summary field of an issue. Found similar/duplicate issues are displayed below the summary field. It also highlights matching terms within the result list so that it is easier to see why two issues are similar. Similarity search is also performed in the summary and description of issues. Best matches are displayed on the top. In addition to summary of the issue, issue type and issue key are also displayed. If issue is resolved it’s key is displayed with strikethrough style.

Similar Issues Overlay

As you can see from the above screenshot, issue keys are a link to actual issues and you can open them directly in the new browser tab.

Similar Issues Tab

While working on an existing issue, we sometimes need quick access to similar issues and Similar Issues Plugin could also be a help here. Plugin adds a “Similar Issues” tab to issue’s tab list and when you click on it, issues similar to currently viewed issues are displayed. Similar issues list is not loaded until you open the relevant tab, so plugin does not cause any delay in loading the page.

Similar Issues Tab

Similar Issues Settings

Actually this plugin is an ‘install and forget’ type of plugin; you can start using it immediately after its installation without a single configuration. But if you need to tweak how the plugin works and how overlays are displayed, you can access plugin’s setting panel from plugin administration menu of JIRA.

Plugin Settings

Configuration Option Description
Similarity Mode There are two alternatives. Loose and Strict. Strict mode requires all search terms to exist in similar issues, so it returns much less result than Loose mode. Loose performs more loose similarity check. Loose mode is set as default.
Theme Currently there are two alternatives, light and dark. Light is the default and matches the color schema of JIRA. Similar results overlay takes more attention with the dark mode due to the contrast with JIRA’s look and feel. Light mode is set as default.
Display Mode There are two modes, overlay and inline. In overlay mode similar issues are displayed in a popup just below the summary field but on top of following fields. In inline mode, similar issues are displayed between summary and fields following it. All fields are pushed down to show similar issue list. When you finish editing summary fields similar issue list is hidden in both mode. Overlay mode is set as default.
Number of Issues to Display Default value is 5. This value could be between 3 and 10. It shows how many issues will be listed in the similar issues list.

If you have any problem while using the plugin, you can always enter a support request on http://jira.denizoguz.com/browse/SIFJ or contact me on Atlassian Answers.

You can also download this manual as PDF.


VN:F [1.9.22_1171]
Rating: 10.0/10 (2 votes cast)