Uploaded image for project: 'Jira Service Management Data Center'
  1. Jira Service Management Data Center
  2. JSDSERVER-147

Ability to define custom start & end date and interval for JSD reports

    • 35
    • 21
    • We collect Jira Service Desk feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding suggestion.

      As of JSD 1.0, Service Desk reports only show graphs on predefined time settings that is selected from a select list below the graph. The user should have the ability to define custom start & end dates for the graph as well as select interval (daily, weekly, monthly, yearly)

        1. 19-01-2016 14-07-26.png
          58 kB
          Roland Behme
        2. JSDSLAGraph.png
          50 kB
          Jacques Verryn

          Form Name

            [JSDSERVER-147] Ability to define custom start & end date and interval for JSD reports

            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.

            Todd Thomas added a comment - 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

            Iain Murphy added a comment - 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.

            Emre Toptancı [OBSS] added a comment - 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.

             

            Martin Poirier added a comment - 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?

            Phil Cooper added a comment - 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?

            SophInfra added a comment -

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

            SophInfra added a comment - 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.

            Deleted Account (Inactive) added a comment - 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".

            Francisco Oselame (Inactive) added a comment - 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.

            Conductor Sysadmins added a comment - 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.

            Deleted Account (Inactive) added a comment - 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.

              399904f8a539 Tripta Kaur
              0fc80be2b556 Emre Toptancı [OBSS]
              Votes:
              121 Vote for this issue
              Watchers:
              85 Start watching this issue

                Created:
                Updated:
                Resolved: