Hi Simon and all supporters of this feature,

There was a ton of great things we wanted to put into Structure 3. Unfortunately it turned out to be impossible to do all of them and still release Structure 3 in reasonable time. We had to postpone a lot of great stuff, including this feature. Structure 3 is still a great upgrade -- even without the features that got postponed, it took us more than 2 years to bring forward automation, various item types, multi-parent relationships and many more improvements. We'll continue building on the platform that we have and we have all this features in scope.

As for specific dates, I cannot provide an estimate for limiting parent-child relationship right away, sorry. It's not planned for the nearest releases. From what I understand, the need for this feature has gone down a bit with the introduction of generators. However, we still consider it important for manually crafted structures.

Please check back in the beginning of 2017 for an update.

Kind regards,
Igor

Are there any updates on this idea? There have been 3 3.x versions out now and I haven't heard of this feature yet.

Hello Igor,

thank you for your response. That sounds great!
Im very excited to see version 3.0.

Hello Jonathan, and everyone waiting for this feature.

We're considering this as a part of our massive remake and extension of Structure, which is going to be version 3.0. There are no estimates yet, but we're actively working on 3.0 features now. Even if this feature does not make it into 3.0, it will be much more feasible by then and we'll likely implement it in a 3.x version.

Igor

Hello,
any new infos about this feature?
I didnt found anything in the documentation oder via google..

Niels, thanks for keeping in touch. No updates so far, sorry - this is one of the big features we have planned, and it's at the top of the list, but it is massive, considering the implications across the whole product. We're getting closer to it by working on other features who will provide the foundation for this improvement.

Any updates when this feature will be part of the product or any ideas how to implement is as an additional feature? We need this too. The ideas of different permission which founded in discussion is not to important, but if we get TestSuites as children of a TestCase it become a stupid structure.

Thank you.

Dear Sri Kanth,

No this feature is not implemented yet. We cannot promise any dates, but this feature is on our current list of things to be definitely done.

Igor

Is this feature implemented at this point of time? We need this feature in our current requirements. If its not implemented yet, any idea when it might be rolled out? Thanks for a well maintained mesg board

Mike, thanks for an excellent feedback! Seems like there are two distinct features:
- one is enforcing a specific structure of... a structure - what issues can be where in the hierarchy, regardless of who does the changes
- the other is hierarchy-based permissions

My use-case is simple requirements management...
The Business Owner creates an Issue with Type="Requirement". This is the top of our requirement hierarchy. (All such requirements for a release are grouped into a structure which noe functions as the view for that product release)
The Product Owner then creates product level requirements (Issue Type also equals "Requirement") that meet the intent of this business requirement and organizes them directly underneath the business level requirements. He should only have "view" access to the Business level requirements.
At this point the top most level = Business requirements.
The next level down = Product requirements.
Implementation Primes create stories, Issue Type = "Story" below each of the Product Owner requirements. Implementation primes can not change or move Issue Type = "Requirement" issues in the structure, but can manipluate the stories they have created.
An individual Designer can create "tasks" as necessary under these the "Story" issue types.

I need a way to enforce permissions at a layer in the structure or issue Type.

Issue Type permissions would ideally allow the creator of an issue to modify its contents (Title, description, etc.) or re-organize it within the structure. The downside is that it limits collaboration and division of work in real-time. The originator must be the one to make all changes.
Different permissions at differnt structure levels would allow certain users access to specific layers of the decomposition. But I am worried that an implementation would bee too complex without limiting the ability of the Business Owner and the Product Owner to use the hierarchy to full effect as this would require the ability to associate a set of permissions and users to each level per Business level requirement (Ick). Essentially to be able to designate on a per requirement decomposition hierarchy key levels in the decomp at which certain groups are now allowed to continue from, but not make changes to the items above that point in the decomp. (Hope that makes sense).

Hey Guy! Good feedback!

Yes, using projects and types in the restriction set is a more complete solution - we'll have it. Different permissions at different structure levels have been also requested, I'm not sure yet if it's a different feature or the same, but it has a jira issue here: http://jira.almworks.com/browse/HJ-434

Cheers!
Igor

If permissions could also be wired in to this, so that specific user groups can only alter certain parts of the structure, I would cream my pants. That is all. :)

I'd like to extend this to optionally restrict what project the child issues can be in.

For example, issue type A in project FOO can only contain children of issue type B in project BAR.

The ability to use a wildcard for project / issue type, or a list of projects / issue types (or any mix of those scenarios) would be utterly awesome!

The reason for this is that we're using JIRA to basically manage our entire business. So, for example, we have a CRM project that lists customers, then a SALES project where we manage sales, LEGAL project for contracts, SLA/SUP projects for support, WORK projects for bespoke projects and so on.

We need to ensure, for example, that a SALES issue can't contain a CRM issue (because that would be sort of backwards in our desired hierarchy). So we'd want to say that CRM tickets can only have child tickets in the SALES project, and then SALES tickets can only have children in the LEGAL/SLA/WORK projects and so on.

In addition, we'd want to have certain types of SALES tickets only able to have children in specific projects and so on.

Martin, thanks for describing your use case!

For our normal issue creation, we have:
Initiative 1 (Epic 1)
+ Feature 1
+ Story 1
+ Story 2
+ Feature 2
+ Story A
+ Story B
+ Bug C
And we have issue link types that are different by issue type. For example:
Feature 1 --(supports initiative)--> Initiative 1
Feature 2 --(supports initiative)--> Initiative 1
Story 1 --(supports feature)--> Feature 1
Story B --(supports feature)--> Feature 2

We'd like to be able to quickly enter the subordinate issue types, where they auto-link to their parent based on the relevant link type for the parent/child issue types.
What I'm seeing in current functionality is that all link types for a given structure get applied to any issue that's created, with current synchronizer.
It leads to incorrect linking of our issue types... not too useful for our purposes.
If structure could be updated in this way (selective synchronizers?) and sub-issues could be easily created with the child issue type (e.g. first sub-issue of a feature is a story or bug; first sub-issue of an Initiative is a Feature, etc) then we might consider purchasing Structure.

Walter, thanks for the comment. We plan to have Project/Type field selectors when you create a new issue in the Structure - this should address the UX.

I guess this feature is more about keeping a strict process, not allowing arbitrary parent-child relationships.

And need this also. Currently we tell the users that the type of the first child issue needs to be changed, from then on he can create sibling issues and the type is copied. It works but UX drops.

Further improvement: enforce configuration of types set up by the user. For example, if it's configured that an issue of type A always has a parent issue of type B, enforce this when a new issue of type A is created.