I suggest Structure Plugin should ...

Limit parent-child relationship to specific types of issues

Let JIRA admin specify what issue types could contain what other issue types. For example, a Test Suite may contain Test Cases, which can contain other Test Cases, but not Feature Requests.

76 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AdminIgor Sereda (Admin, ALM Works) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    20 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • AdminIgor Sereda (Admin, ALM Works) commented  ·   ·  Flag as inappropriate

        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

      • Simon Schaffner commented  ·   ·  Flag as inappropriate

        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.

      • Jonathan commented  ·   ·  Flag as inappropriate

        Hello Igor,

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

      • AdminIgor Sereda (Admin, ALM Works) commented  ·   ·  Flag as inappropriate

        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

      • Jonathan commented  ·   ·  Flag as inappropriate

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

      • AdminIgor Sereda (Admin, ALM Works) commented  ·   ·  Flag as inappropriate

        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.

      • Niels Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • Sri kanth commented  ·   ·  Flag as inappropriate

        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

      • AdminIgor Sereda (Admin, ALM Works) commented  ·   ·  Flag as inappropriate

        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

      • Mike commented  ·   ·  Flag as inappropriate

        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).

      • Guy Fraser commented  ·   ·  Flag as inappropriate

        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. :)

      • Guy Fraser commented  ·   ·  Flag as inappropriate

        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 Wickline commented  ·   ·  Flag as inappropriate

        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.

      • AdminIgor Sereda (Admin, ALM Works) commented  ·   ·  Flag as inappropriate

        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.

      • Walter commented  ·   ·  Flag as inappropriate

        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.

      • AdminIgor Sereda (Admin, ALM Works) commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base