Hi Cathy,

Thanks for your vote. You describe an interesting case, would you mind if I ask you a bit more about what are you trying to achieve with JIRA/Structure, so we can better understand how this feature should work.

This system hasn't got your email - would you please send me a note to sereda@almworks.com ?

Thanks!
Igor

Hi, I'm interested in this feature as it may support true requirements management within JIRA. A system requirement is part of a product baseline. Once it is part of the baseline on a released product, it persists through future releases (unless it is changed). But if you keep them in JIRA, they "go away" with the initiative/sprint/release when it is done.

To our organization, it's silly to maintain all these requirements outside of JIRA (Confluence) and trace them back in for test coverage, feature planning, etc. If they could persist in JIRA indefinitely, in stand alone (not initiative/sprint/release bound) containers, I would stop hating JIRA. :-)

Please alert me when 3.0 is scheduled for release?

Thank you,
Cathy Carlin

Hi Martim, thanks for the feedback. As a rule, we don't promise any dates for upcoming feature releases. At this moment I can say, that the active work on Structure 3.0 has already started, but it is unlikely that the release will happen within next two months. There's a lot of awesomeness to design and code!

Cheers,
Igor

Hi Igor,

good news about this feature being available in Structure 3.0 :)

Any idea of when it will be released?

Thanks, Brian - we have a similar open request already, and I'm going to merge your request and vote there.

And we actually are going to have this feature in Structure 3.0!

We created a container/place-holder Issue type for use in Structure, and then just hid that Issue type from the JIRA projects/screens... Works fine if you are sure you will never need it in JIRA/GH.

In line with Rapid boards, an alternative can be to support some notion of a horizontal swim lane / some other sort of horizontal divider that allows you to segment the Structure to several sections

Any solution to this issue would need to consider what happens when a container issue transitions to a leaf node (and vice versa) (i.e. the parent/child relationship is changed for a particular task). Such use-cases can happen frequently as a structure evolves and more (or less) detail is needed.

I totally agree, for a work around, currently I create a bunch of "category level" issues just to use as folders. put the actual issues inside them, then resolve them.

I've been thinking about the same issue. Container issues can skew issue statistics, especially if they will remain open for long periods of time. So, it would be nice if there were an easy way to make them 'hidden' from JIRA.

I also thought about the separate project idea discussed by Igor in his comment, but that seems pretty cumbersome.

Thanks Bill, we've also thought about this. Having some grouping items that are not issues would be good. This idea needs further thought though - we'll work on it next time we revisit the whole plugin idea.

For now, it may be the best way to create a special Project for the pseudo-issues and create grouping issues there - especially when we'll add the possibility to select Project/Type during inline issue creation.