We need the ability to specify dates back in time. While it's nice to have the predefined options for reports, there are times we need to know the data for specific time periods. The data should be there- it's just a matter of having reports being much more customizable than what's provided out of the box.

Reporting capabilities are critical to the proper functioning of a healthy service desk. Reporting generally needs to be bolstered to make it more clear on trends, post-problem analysis, and leveraging the investment of the Atlassian ecosystem.

Having just moved from Jira Cloud (where this capability is available) to Jira server (where it is not) we are now having to amend our internal processes to accommodate this lack of functionality. This needs to be resolved ASAP, if it works in Cloud it is possible

I think I have an idea about why Atlassian does not provide custom Start&End dates (yet).

It turns out JSD tries to include all non-complete issues in SLA reports. We realized this while developing "Service Desk Reporter" plugin. If an SLA timer is not complete yet but the goal time is already breached, then JSD will coutn the issue as a breach and will show on the last day of SLA report graph. I guess in order to preserve this behavior, Atlassian only gives date options that always includes the current moment but goes back n days to the past. As you may have realized, this "n days" means "n x 24 hrs" which results in a report start date that is in the middle of the day, n days before. Very frustrating. The report output is always unstable. You cannot get the same report twice.

Actually this is not a technical limitation but rather a design decision that Atlassian made. Our current implementation in "Service Desk Reporter" allows the user to use create date, update date, resolution date and SLA Stop Date for date filters and define custom start&end dates for whichever one you choose. Atlassian JSD report implementation always uses "SLA Stop Date" as referance date and without custom start&end dates. There does not seem to be any Technical reason why Atlassian coud not do this. If we could, so can they. After all it is all about selecting which issues to include in the report, the rest is the same.

Actually, filtering the issues based on SLA Stop Date was the hardest part of the implementation, which JSD already does. Other options are far easier. Just simple JQL.

By the way, we recently released a new version of Service Desk Reporter which includes bugfixes and optimizations as well as a REST API for integrations, aside from already present Excel export option.

We are also in need of custom filter.  One year make no sense now that servicedesk is available since a lot more then that.

The data also is in the database.

Given that your preconfigured dropdown list is only an abstraction that ultimately selects a START and END date for the SQL query, why not allows us to choose our own dates for reporting? Seems a bit silly that we even have to ask for this. But here goes....pretty please, oh great Withholder of Standard Features?

Our need is we want to see year over year reports so we can justify headcount and see trends

The lack of this feature is ruining an otherwise great reporting tool.

We send our customers SLA reports every month but we can only export 30 days worth of data. The ability to filter the reports by month or define custom date criteria is a needed feature.

I can't imagine this being too hard to put in place and I would have expected it to be a basic reporting feature.

Customer:

"I would happy this feature will be available also for the Jira Software".

Is there any update on this? It appears things are starting to move in the right direction, but it's getting pretty frustrating to have to export data to excel in order to get proper reporting if I miss running this by a day (for monthly) or by a month for running quarterly reports. It seems like this should have been implemented from the beginning.

This is another instance of functionality that seems pretty basic being completely missing. (The other is being able to replicate service desks.) How can a system that considers itself to be best-in-class be missing such basics? I'm not impressed.