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

[Ed Choromanski]

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 ID	Issue Type	Summary	Description	Issue Links	Requirement Path	Hardware Platform	Hardware Version Used	Labels	Updated
[[key]]	[[issuetype]]	[[summary]]	[[Description]]	[[linkedissues]]	[[path]]	[[hardware platform]]	[[hardware version used]]	[[labels]]	[[updated]]

[Bernhard Doleschel (Ease Solutions)]

Hello @Ed Choromanski ,

thanks for highlighting this here. As usual, could you please create a service desk ticket for this issue at https://support.easesolutions.com/
So we can track the progress easier and analyze the problem better.

Form current investigation:

• The default Excel export considers the order in the tree correctly
• The template based Excel export need a rework to allow mixed structures. Currently is starts in a tree node always with folders and then list all parallel sibling issues underneath. 
• For the Excel Addin we are working on a sorting capability based on the tree structure.

Best Regards,

Bernhard from Ease Solutions

[Stephen Ellwood]

We have a similar problem when viewing R4J requirements in Confluence. The requirements are nicely ordered in the R4J view but not at all ordered in the Confluence Jira search.  We would like them to be in the same order when we do a Confluence (or Jira!) search as they are in R4J.  Does Ease Solutions have a solution for this?  It would seem to be simple just to add an Order By parameter to the search?

[Stephen Ellwood]

BTW I tried to fill in a feature request but since I am not a Jira administrator (our company has 21000 employees and a whole IT group who does that) I could not do so.  Here is what I wanted to write:

Currently R4J is in use by our Software teams. We are developing a full requirements flow for our product development process including hardware that uses a mixture of Jira and Confluence. Atomic requirements are created using bespoke Jira Issue types (a kind of extended version of your Product Requirements). We would like to use the ordering feature of R4J but this currently only works in the Jira Requirements tab and not when doing Jira Searches or Confluence Jira access. This leads to double work since we have to add a REQID field that manually orders the requirements and must be kept in step with the R4J folders. This is so bad that it is preventing adoption of R4J by most of the teams. Since R4J is clearly aware of the location of the requirement in the requirement folder structure this request is simply to make that information accessible in a Jira Search e.g. order by "R4J Order". This will help me to get R4J accepted with the Hardware teams as well as the Software teams.

[Bernhard Doleschel (Ease Solutions)]

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

[Stephen Ellwood]

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.