Some suggestions for new and improved reporting features

Thursday, June 17, 2021

After a few months of using Spira actively (and creating a load of reports), here are some suggestions to the great folks at Inflectra for new features that would make life a lot easier. Do what you will with them and feel free to comment or append.

Low hanging fruit:

  •  Allow re-ordering of document sections by moving them up or down. It's driving me nuts to have to use delete and clone just to change the order of things or to insert another section somewhere.
  •  Use a treeview like structure instead of a list for the reports. A single list can get pretty long and you lose overview.
  • Addendum to the last: In the treeview, have a 'Favorites' node where you can put the reports that you use often
  • Allow creation of custom categories (like Requirements Reports, Test Case Reports, etc.)


  • Reports are separate from Project Templates. Why? A custom report can assume certain types or custom fields to be present that are defined within a template. Some reports will not make sense for projects using project templates they are not intended for. Link a set of (custom) reports to a project template to have one consistent whole. 
  • Allow versioning of a report as a single entity. A report is now just a collection of text fields that can be very easily overwritten by mistake, wasting hours of work (yes it happened to me too several times...) Allow storage mechanism similar to Documents, where you can add/upload a new version. In QA driven organizations, it is required for Document templates to have versions also. It should be possible to restore an older template. We are using a separate Git now where we store the SQL and XSLT portions of each report separately which is, frankly, quite ridiculous.
  • Improve the edit view of the SQL and XSLT portions. Preferably full screen (while editing) and syntax aware. We are currently using VS Code or sometimes even Notepad to edit them because the web form is really horrible to use.

Report content:

  • Allow to add custom graphs to a report as a custom section, as an alternative to the current sections.  Graph can be included as a rendered image, based on a defined custom or standard graph in Spira. Its a shame to only be able to see those graphs in the Spira GUI itself.
  • More custom parameters in the SQL query of a custom report. Next to ProjectId and ReleaseId, we would like UserId (the one requesting the report), BranchId, and perhaps even define a custom parameter yourself in the report definition - you'd set a display name (for the GUI), a variable name (for in the SQL query) and a field type (string, number, user, date, etc.) that determines the edit control to enter it when requesting the report. This would make up for the lack of extensive filter options you have in a custom section report as opposed to using only standard sections.

That's all I can come up with. Thanks for making such a great product!



4 Replies
Wednesday, June 23, 2021
re: dl.pie Thursday, June 17, 2021


Thanks for the suggestions. We're actively reviewing and I will post back our thoughts.



Monday, July 12, 2021
re: dl.pie Thursday, June 17, 2021

Yep, I am waiting for these features too.

Friday, July 16, 2021
re: dl.pie Thursday, June 17, 2021

I think, that another easy to implement feature additionally to ${UserID} is to add ${APIKey}.

First of all, it is safe to provide such key for a user, who owns it)

Goal of it is too use API's from custom reports.

Several use-cases:

  • Custom report is designed to get all requirements for the project, but user could be interested to see from custom report some analytics about incidents. Retrieve ALL information about incidents in advance is retrieving too much information that is not used.
  • Another example that custom report may show analytics (that is retrieves in aggregate) through all projects but based on a user click it could be interesting to dive into details.
Tuesday, February 15, 2022
re: dl.pie Thursday, June 17, 2021

I would also like to see Custom Reports tied (and data restricted) to either Templates, Products or Programs. My client typically has 50-100 projects on the go, some of which are quite customised. As such, there are few reports that work for all projects, and some that are very powerful for a few projects and meaningless for others. Today, this means a huge messy list with numerous apparently similar reports - and finding the right one is a pain.


Also, assuming the "tables" used by ESQL are views of some sort, please add to those views a restriction so that users can only see what they could see via the REST API.

Spira Helps You Deliver Quality Software, Faster and With Lower Risk

And if you have any questions, please email or call us at +1 (202) 558-6885


  • Started: Thursday, June 17, 2021
  • Last Reply: Tuesday, February 15, 2022
  • Replies: 4
  • Views: 987