•  
      request #5533 Bug not displayed in a report filtered by milestone if in planning is defined as solo item and in tracker hierarchy child of User Story
    Infos
    #5533
    Patricia Carrasco (pcar)
    2017-02-03 11:49
    2013-11-06 14:50
    5663
    Details
    Bug not displayed in a report filtered by milestone if in planning is defined as solo item and in tracker hierarchy child of User Story
    We are currently working with Tuleap 6.6 in which you can plan solo items. Also in 6.6 release we are able to filter by Milestone in a given tracker. In my project in the Tracker Hierarchy, Bugs are children of User Stories. In the Planning definitions, Epics and Bugs can be planned into a Release and User Stories and Bugs can be planned into a Sprint.

    I was able to create a solo bug in the Release Content and then plan it into a Sprint. I was also able to create a bug as a child of a User Story on the Sprint Cardwall. When I filter by Milestone = Sprint 1 in the Bug tracker it only shows the bug that was created as a solo item and not the bug that is a child of a user story. As per confirmation by Martin, I have created this request.
    Trackers
    Empty
    Empty
    • [ ] enhancement
    • [ ] internal improvement
    Emilio Palmiero (empa)
    Stage
    Manuel Vacelet (vaceletm)
    Closed
    2017-02-03
    Attachments
    References
    Referencing request #5533

    Artifact Tracker v5

    rel #5539 6.8

    Git commit

    tuleap/tuleap/dev

    Merge remote-tracking branch 'bender/master' into HEAD 6ebf704fd1
    Merge commit 'refs/changes/43/1443/2' of ssh://gerrit.tuleap.net:29418/tuleap into stable 6224b38603
    Fix request #5533 - Bug not displayed in a report filtered by milestone 7b039dee29

    tuleap/tuleap/stable

    Merge commit 'refs/changes/43/1443/2' of ssh://gerrit.tuleap.net:29418/tuleap into stable 6224b38603
    Fix request #5533 - Bug not displayed in a report filtered by milestone 7b039dee29
    Merge remote-tracking branch 'bender/master' into HEAD 6ebf704fd1

    tuleap/u/hkelf/tuleap/stable

    Merge remote-tracking branch 'bender/master' into HEAD 6ebf704fd1
    Merge commit 'refs/changes/43/1443/2' of ssh://gerrit.tuleap.net:29418/tuleap into stable 6224b38603
    Fix request #5533 - Bug not displayed in a report filtered by milestone 7b039dee29

    tuleap/u/vaceletm/tuleap/dev

    Merge remote-tracking branch 'bender/master' into HEAD 6ebf704fd1
    Merge commit 'refs/changes/43/1443/2' of ssh://gerrit.tuleap.net:29418/tuleap into stable 6224b38603
    Fix request #5533 - Bug not displayed in a report filtered by milestone 7b039dee29
    Referenced by request #5533

    Follow-ups

    User avatar
    • Status changed from Waiting for information to Closed
    • Reported in version cleared values: 6.6
    • Close date changed from 2013-11-22 to 2017-02-03
    User avatar
    By removing the link to the product from the bug it resolved the issue. Now the user get the bugs that belong to the selected milestone. With regards to your above I think we should discuss it our next meeting. This request can be closed.
    User avatar

    Actually the question is more on the global behaviour.

    As long as someone linked the epic and the product, do you think it's "logic" that the bug is listed when you search based on the milestone ?

    • If yes, it means that we should introduce a new "tool" in the web UI to help people to identify the dependencies relationship (as we did in CLI)
    • If no, why (ie. why should't we follow epics connexion) ?
    User avatar
    In the Epic, the Product should not be listed in the linked artifact section. This project is being used my many teams and is quite a big project. It may have been done by someone new. I will try and identify if there are any other artifacts like this and send it back to the group to clean up as it is not my project. I will keep you informed. Thanks
    User avatar
    [root@eselivm2v457l codendi]# /usr/share/codendi/src/utils/php-launcher.sh find-artifact.php 44831 41782
    41782 (bug) is linked by 33555 (story)
    33555(story) is linked by 35814(3FD03-Sprint2)
    35814 is linked by 29777 (releases #29777 - EME 3 FD03)
    29777 is linked by 29778(product #29778 - EME)
    29778 is linked by 76483 (epic #76483 -)
    76483 is linked by 44831 (Release EME3 FD04)

    The Milestone report is being run EME 3 FD04 but the bug beongs to EME 3 FD03. The issue seems to be because the report goes to the product and product is connected to other releases (EME 3 FD04) being one of them.
    User avatar
    I understand that it's just one example but the more interesting question is:
    -> why this bug (41782) should not appears to the result list even though there is a clear (but long) link between them ?
    User avatar
    The output that Michael pasted above is just one of the bugs that should not be displayed in the report as it belong to another release. When we filter by a specific milestone (a release), it returns 433 bugs. So, its difficult to know all the offending bugs.
    User avatar
    Manuel, here is the output:
    [root@eselivm2v457l codendi]# /usr/share/codendi/src/utils/php-launcher.sh find-artifact.php 44831 41782
    41782 is linked by 33555
    33555 is linked by 35814
    35814 is linked by 29777
    29777 is linked by 29778
    29778 is linked by 76483
    76483 is linked by 44831
    User avatar

    I attach a patch to be applied either on top of 6.8 release of 6.7 + 5533_fix_tracker_milestone_filter.patch

    This patch comes with a tool to execute on server like this:

    $> /usr/share/codendi/src/utils/php-launcher.sh find-artifact.php 5768 41609
    41609 is linked by 41579
       41579 is linked by 41483
         41483 is linked by 5769
           5769 is linked by 5768

    Patricia, can you please run it on "offending" artifact ids to find the path between them ?
    Note: the order of parameters matters: it's find-artifact.php <milestone artifact id> <other artifact id>
     


    User avatar
    Ok great!I close the request.

    • Status changed from Under review to Closed
    • Close date set to 2013-11-22
    User avatar
    I have tested the patch on 6.7 and it is working. The following scenario's were tested.

    1. Bugs that children of stories planned in a sprint. Solo bugs planned in a release. When you filter by Milestone = release, bugs that children of stories as well as solo bugs planned in a release are displayed.
    2. Bugs that children of stories planned in a sprint. Solo bugs planned in a sprint. When you filter by Milestone = sprint, bugs that children of stories as well as solo bugs planned in sprint are displayed
    User avatar
    Hi Manuel, yes I can test it on our staging server which contains a copy of the data from production about two weeks ago. We have upgraded to 6.7 on staging. Thanks
    User avatar
    Fix under review with gerrit #1443.

    Patricia, do you have mean to give it a test with your data on staging server if I provide you with a patch ?
    If yes please tell me which version you are running, thx!

    • Status changed from New to Under review
    • Assigned to set to Manuel Vacelet (vaceletm)
    User avatar
    Hi Manuel, I think we need to call for a meeting with Enalean to discuss your solution. I will bring it up at our team meeting this afternoon.
    User avatar

    This is quite tricky to find a clean and efficient solution with so many level of information.

    The only viable solution would be to filter based only on artifact link information:

    Given:
    Release 2.0
    |-- Sprint 14
    |   |-- User story 7
    |       | Bug 8         
    |-- Sprint 2
    |   |-- Bug 6
    |       |-- Bug 3
    |-- Bug 4
    `-- Support Request 4
        `-- Bug 1
    
    Support Request 9
    `-- Bug 10
    
    When I filter on Release 2.0
    Then I get Bug 8, 6, 3, 4 and 1
    
    

    Main change: it no longer uses hierarchy informations at all (so even the bug linked to the support request is displayed).

    Limit cases (maybe others might arise):

    • This will change in the future when we will make use of a artifact-to-artifact parent/child relationship: considering that Support Request 4 is not a child of Release 2.0, in this case, Bug 1 will not appear in the list.
    • If I add a link from "Support Request 9" to Release 2.0, I will not see Bug 10 in the result as the link is not "in the right sense" (the "right sense", from parent to children is only available through the hierarchy)

    In a sense, the purpose of this filter would be:

    "give me the list of Bugs that Release 2.0 references, regartheless on the parent/child definitions"