How to have sort order be the same as the R4J Tree View?

Question

We are using R4J for requirements management. I have put together an excel export template but the sort order does not match the order of the R4J Tree View.

We are using the Issue Key as the requirement ID since this automatically generated and always unique for the project. The tree structure breaks down the various sub system of the project. The requirements evolve over time so new requirements (issue keys) are added to sub systems. This results in the requirements (issue keys) not being in sequential order.

Is there a way to force the output to match the R4J Tree Structure?  Otherwise it is a painstaking long manual copy / paste exercise.

I also tried using the R4J Excel Addin's "download" and this also outputs and out of order excel spreadsheet!

Appreciate any assistance!

Here is the pretty basice template I am using:

Requirement IDIssue TypeSummaryDescriptionIssue LinksRequirement PathHardware PlatformHardware Version UsedLabelsUpdated[[key]][[issuetype]][[summary]][[Description]][[linkedissues]][[path]][[hardware platform]][[hardware version used]][[labels]][[updated]]

Denis Pregnolato_s4oifh · Answer

Hi Bernard,

any update on having a query to sort the issue in the same way as the tree view?

Stephen Ellwood · Answer

Hello Bernhard,

Thanks for the quick reply. I am not familiar with the inner workings of Jira or how your store your issue ordering. I must admit I didn't consider that issues could be in multiple trees so I guess you keep the order separate to the issue itself. From what you say its not possible to attach a function to the Jira search to provide a search order. I am used to Python where you can pass an iterator into another function and call have it call the NEXT method.

In our custom field we use a block prefix followed by a 3 digit number including leading zeros to order the issues.  The order does not change very often. so we rarely have to go back and renumber everything. Still its a pain to add this 6-8 character field by hand.  Back when I started in 1982 I wrote in Basic and the system then was to use line numbers in 10s.  Then to add a line between lines I typed a number ending in 5 and so-on.  Very occasionally I typed "renumber" and the machine would renumber everything back to multiples of 10. We could do this but its one additional 0 to to type for every issue. I could write a Python program to read the issues and renumber them.

The Gadget idea is a good one but i have another problem with that in that we use Jira Snapshots for Confluence to do our baselining and this uses Jira lives search when you take a snapshot. Having tested the baselining feature of R4J we see it does not do a "proper" baseline.  To us a baseline is a save of the exact data on that day that is preserved forever.  My colleague who tested R4J found that though the issues were tagged, if the data changed after the baseline the baseline reflected the current data not the data held at the time of the baseline. By contrast Jira Snapshots is literally a snapshot of the data which it gathers and stores separately to the Jira issue and so never changes.  Each snapshot stores another copy of the data.  This is the functionality we ultimately need.

PS. As said, I did try to create a feature request and the SEN number is a required field.  I need to be a Jira Administrator to find the SEN number.

Bernhard Doleschel _Ease Solutions_ · Answer

Hello @Stephen Ellwood ,
thanks for your request on having an order field inside Jira issue to be used by a Jira search query. We´ve already thought about this solution, it lead to problems:

* There is no unique number scheme possible to consider also parent-child structure for the correct 'alphabetical' sorting used by the Jira query. We don´t have an influence to the Jira search
* Any update (e.g. drag&drop) of issues or branches with hundred+ issues put load on Jira to update all issues with the new order values
* Any issues could be in different R4J trees, for the sort order you would to specify the right tree to be use (as we do in our Excel Plugin which support meanwhile the structure)

Considering this, an solution would be to use a Jira/Confluence Gadget to show the tree structure (starting with a selectable tree node and fields to be shown). Would this be an solution which could help your use case?

PS: To create a service desk ticket you don´t need to be an Jira admin.

Best Regards,

Bernhard