Summary
You can use the Time in Status configuration file to configure some of the parameters of Time in Status.
Creating a Configuration File
In order to use the configuration file, create a text file named timeinstatus.properties in the Jira Home folder of your Jira server.
When you make changes to the configuration file, you will need to just disable/re-enable Time in Status app for the changes to take effect.
Restarting Jira also works as a disable/enable operation but it is not needed.
If you create a Configuration File but see that it has no effect, you might have placed the file in the wrong folder. In that case, update to the latest Time in Status version, enable DEBUG level logging (follow the steps in How to create detailed Jira logs for OBSS plugins?), and disable/re-enable the app. At that point, the log output will show where Time in Status is looking for the config file and it will also show if the app could find the config file or not.
Disabling Report Types
By default, all reports are available to users. You can use the configuration file to disable one or more of Time in Status Report Types.
When a report type is disabled, that type will not appear in the user interface and Time in Status REST API will reject report requests of that type.
Put the following properties in the file:
timeinstatus.reporttypes.statusduration.enabled = true timeinstatus.reporttypes.durationbetweenstatuses.enabled = true timeinstatus.reporttypes.assigneeduration.enabled = true timeinstatus.reporttypes.statusdurationbyassignee.enabled = true timeinstatus.reporttypes.assigneedurationbystatus.enabled = true timeinstatus.reporttypes.groupduration.enabled = true timeinstatus.reporttypes.groupdurationbystatus.enabled = true timeinstatus.reporttypes.statusdurationbygroup.enabled = true timeinstatus.reporttypes.statuscount.enabled = true timeinstatus.reporttypes.transitioncount.enabled = true timeinstatus.reporttypes.firsttransitionfromstatusdate.enabled = true timeinstatus.reporttypes.lasttransitionfromstatusdate.enabled = true timeinstatus.reporttypes.firsttransitiontostatusdate.enabled = true timeinstatus.reporttypes.lasttransitiontostatusdate.enabled = true timeinstatus.reporttypes.anyfieldduration.enabled = true
Each property entry in the file corresponds to a report type. Change the value of the property to false for the report types that you want to disable.
Gadget Date Range
By default, Time in Status gadgets will allow you to set a date range with a max value of 365 days.
To increase or decrease this limit, put the following line in the properties file and set the new limit value.
Accepts any positive integer.
The default value is 365 so if this key is not defined, a limit of 365 will be enforced.
timeinstatus.gadget.maxdaterange = 365
Export File Expire Duration
By default, Time in Status export files will be removed from the system after 30 days (720 hours)
To increase or decrease this duration, put the following line in the properties file and set the new duration value in hours.
Accepts any positive integer.
The default value is 720 so if this key is not defined, the expiration duration will be 30 days (720 hours)
The system checks for expired files when a new export is triggered and this check runs no more frequently than 1 hour. In other words, the actual file purge happens only when a new export is triggered and your files might be kept on the system for up to 1 hour longer than the configured value.
timeinstatus.export.file-expire-hours = 24
Limits
The keys in this section allow the Jira Admin to set limits on Time in Status functions that might consume relatively high system resources and thus limit the effects of Time in Status on system performance.
Using these keys might cause a decrease in the quality of your users' experience but it will protect your Jira from being overloaded by Time in Status reports.
By default, you should NOT need to set values to these keys. But depending on ...
- The number of issues on your Jira instance.
- Your server capacity.
- The actual number of Time in Status gadgets used on dashboards.
- The number of concurrent Time in Status users
- The number of issues included in Time in Status reports
... you might want to set some of these limits to control the load that your users can create on your instance through the use of Time in Status.
Use these settings with discretion.
Gadget Issue Limit
By default, Time in Status dashboard gadgets will not show reports that need the processing of more than 1000 issues.
To increase or decrease this limit, put the following line in the properties file and set the new limit value.
Accepts any positive integer.
The default value is 1000 so if this key is not defined, a limit of 1000 will be enforced.
timeinstatus.gadget.maxissuenumber = 1000
System-wide export limit
Defines the maximum number of system-wide file export operations that can run concurrently.
Accepts any positive integer.
When the maximum is reached, any user trying to start another export will get an error.
The default value is "infinite" so if this key is not defined, no limit will be enforced.
Consider setting a limit using this key when you discover that different users are getting multiple file exports at the same time and this is having a performance impact on your Jira instance.
timeinstatus.export.maxsystem = 5
Per-user export limit
Defines the maximum number of per-user file export operations that can run concurrently.
Accepts any positive integer.
When the maximum is reached for a user, that user will get an error if tries to start another export.
The default value is 3 so if this key is not defined, a limit of 3 concurrent exports per user will be enforced.
Consider setting a limit using this key when you discover that some users are starting multiple file exports at once and this is having a performance impact on your Jira instance.
timeinstatus.export.maxuser = 1
System-wide aggregation limit
Defines the maximum number of system-wide aggregate calculations (average, sum, etc.) that can run concurrently.
Accepts any positive integer.
When the maximum is reached, any user trying to start another aggregate calculation will get an error.
The default value is "infinite" so if this key is not defined, no limit will be enforced.
Consider setting a limit using this key when you discover that different users are getting multiple aggregate reports at the same time (either via the main reporting screen or maybe they have too many TiS gadgets calculating aggregates on their dashboards) and this is having a performance impact on your Jira instance.
timeinstatus.aggregate.maxsystem = 20
Per-user aggregation limit
Defines the maximum number of per-user aggregate calculations (average, sum, etc.) that can run concurrently.
Accepts any positive integer.
When the maximum is reached for a user, that user will get an error if tries to start another aggregate calculation.
The default value is 10.
Consider setting a limit using this key when you discover that some users are getting multiple aggregate reports at the same time (either via the main reporting screen or maybe they have too many TiS gadgets calculating aggregates on their dashboards) and this is having a performance impact on your Jira instance.
timeinstatus.aggregate.maxuser = 5
Issue count limit
Defines the maximum number of issues that can be processed in a single Time in Status report request.
Accepts any positive integer.
Time in Status will simply reject report requests if the resultset contains more than the defined number of issues.
The default value is "infinite" so if this key is not defined, no limit will be enforced.
Consider setting a limit using this key when you discover that users are getting file exports and/or aggregate reports with high numbers of issues and this is having a performance impact on your Jira instance.
timeinstatus.report.maxissues = 50000
There are two things to emphasize here:
First, while getting an aggregate report (average, sum, etc.), Time in Status (for example) might process 5000 issues and turn them into a 3-row report output. This parameter controls the maximum number of issues that will be processed, not the number of rows in your report output.
Second, while getting on-screen List reports, even if your dataset contains a lot of issues (let's say 100K+), Time in Status will process a single page (10, 20, 50, or 100) of those issues to display on the screen. This parameter controls the maximum number of issues that will be processed for a single report request, not the size of your total source issue set. In other words, if you set your issue count limit to 10,000 and try to get an on-screen List report using a JQL query that returns 100K issues, you might expect Time in Status to reject that report request but it will not, since only a single page of those issues are actually processed for the on-screen List report.
Time limit for single-request REST endpoints
Defines the maximum execution time (in milliseconds) for REST endpoints that return data with a single REST call (Small Export and Aggregation).
Accepts any positive integer.
If the execution exceeds this time, data processing on your Jira for that request will be terminated prematurely and an error response (HTTP 408) will be returned to the client.
The default value is 60000, which corresponds to 60 seconds. (The default HTTP timeout is 60 seconds, so all gateways between a client and your Jira server will probably also return timeout errors for requests that take more than 60 seconds to complete.)
Consider decreasing this limit if you want to limit execution durations to a lower time. Consider increasing this limit if you want to provide REST data with longer execution times (for larger data sets). If set to a value longer than 60 seconds, make sure you also increase the timeout configurations of all gateways en route to your clients.
timeinstatus.report.timelimited.maxdurationmillis = 60000