Specifying your GreenHopper General Configuration

 

Note that this page only applies if you are using the Classic Boards.

 

You must have the 'JIRA Administrators' global permission before you can configure GreenHopper's General Configuration settings.

You can configure a number of GreenHopper settings globally (i.e. across all projects in your JIRA instance). A number of these global settings also exist as project settings. Your project settings will override the equivalent global settings.

To configure GreenHopper's global settings,

1. Log in as a user with the 'JIRA Administrators' global permission.
2. Select JIRA Administration from the top bar, then select Plugins > GreenHopper.
3. Select GreenHopper Configuration.
4. The GreenHopper Configuration screen will appear (see Specifying your GreenHopper General Configuration#screenshot). The following global GreenHopper settings will be available for you to configure:
   Please note: all changes made on the General Configuration page are applied immediately.

On this page:

Screenshot: GreenHopper Configuration

General Configuration

The general setup options for your project are described below:

• 'Scheduling Permission' — Select this check box to override the 'Resolve Issues' permission (i.e. 'Fix for version' permission) with the JIRA 'Schedule Issues' permission. Users will then need to have the 'Schedule Issues' permission in order to drag and drop cards into version boxes on the Planning Board.
• 'Card Creation' — Select this check box to allow the creation of cards via GreenHopper. If you uncheck this checkbox, the creation of cards via GreenHopper will be locked.
• 'Time Aggregation' — Select this check box to enable the aggregation of sub-task time tracking within the parent issue, denoted by a Σ icon.
• 'Auto assign' — Select this check box to automatically assign issues to the current user when transitioning issues on the Task Board.

Non-Working Days

To improve the accuracy and appearance of the charts, you can specify non-working days throughout your project (e.g. Saturday and Sunday), which will simply be withdrawn from the charts. If a Work Log is entered on a non working day, it will be associated with the previous working day and reflected in the charts accordingly.

You can also define non-working days specific to a version. Select 'Non Working Days' from the 'Actions' drop-down menu in the Statistics Column on the Chart Board.

GreenHopper Listeners and Services

GreenHopper ships with a number of useful listeners and services that can help you maintain the integrity of your GreenHopper data.

To enable listeners and services for GreenHopper, select one or more of the following check boxes:

• 'Versions Synchroniser' — The Versions Synchroniser listener ensures that your version hierarchies are respected by detecting and repairing all the issues that are missing some versions based on your version hierarchies.
• 'Components Synchroniser' — The Components Synchroniser listener ensures that your component hierarchies are respected by detecting and repairing all the issues that are missing some components based on your component hierarchies.

Query Result Limit

Some GreenHopper requests, such as cross-project charts, query many thousands of issues. If these requests impair the performance of your JIRA site, you may wish to limit the number of issues queried in any one request. Users will be notified if their request exceeds the issue limit.

To limit the maximum number of issues displayed on the Task Board,

• Select the 'Ask users to filter issues if exceeding' option and specify the maximum number of issues to display on the Task Board in the text box below.

Worklog Cache Limit

GreenHopper makes use of the data in a JIRA issue's History and Work Log entries to calculate Time Spent and Remaining Estimate values for Hour Burndown Charts. This data is also used in the Statistics Column on the right side of the Chart Board and Planning Board. Since these calculations can involve heavy querying of the JIRA database, GreenHopper caches these query results in memory to improve performance.

You can configure the size of this cache by specifying the Cache size. This value (which is 20,000 by default) represents the number of issues whose query results will be cached in memory.

The current cache usage is displayed as a percentage below this field. The cache starts empty and is filled on demand. When the cache is full (at 100%), the oldest entries in the cache will be dropped to make space for new query results.

For maximum performance, keep the cache usage below 100% by increasing the Cache size.
Whenever the size of the cache is changed, the current cache will be destroyed and a new, empty cache will be created.

The cache consumes heap memory and the actual amount of memory consumed can vary largely, depending on how many changes to Work Logs and/or Remaining Estimates were made to individual issues. As an approximation and guideline, caching query result data for 1,000 issues consumes about 1MB of memory.