OK, thanks for the help Manuel. We figured out our issue, but aren't entirely sure what the problem was. We changed the children that could be in the releases and generally reorganized and got everything working again. We were in over our head, but we have RTFM now.

You should still look into the code that handles the PATCH request /api/v1/milestones/3/content, because it returns 200 OK even if it is not successful.

Actually, I was talking about the export of agile dashboard structure (in the GUI, Agile Dashboard -> Admin).

The documentation you point if for the export of projects structure + data but it only support 1 tracker yet (hence the TRACKER_V5_ID that corresponds to the sole tracker ID you'd like to export).

In paralle, what happens if you got to the milestone artifact (in trackers) and manually link the artifact id of the story with your milestone ?

 

Manuel, are these the steps to follow? http://tuleap-documentation.readthedocs.io/en/latest/administration-guide/project-export-import.html#project-export

Also, where can I find the reference to this var the script needs “TRACKER_V5_ID"?

If we can't reproduce the problem after export/import, should we just use the new project and forget about this until it happens again or are there other debugging techniques we could use?

We would need a export of your agile dashboard configuration + a precise scenario to reproduce the bug (you can test the scenario on your side with a dummy project where you import the configuration)

Following up to see if any more details might be needed for the situation that we are experiencing with the bug that is blocking our Development work stream. Can someone take a look at this for us by chance?

This bug concerns the drag and drop interface for prioritizing the user story backlog and adding stories into release milestones. This is affecting our self hosted Tuleap, version 8.15.99.75. It is only happening in one of our projects, the others are fine.

When dropping a story into a milestone, a PATCH request is sent to /api/v1/milestones/3/content with a payload like {"add":[{"id":21}]}, which responds 200 OK.

At this point, if you refresh the page, you can see that the story was not actually added to the milestone.

If you drop two in a row, you will get a 409 Conflict error response on the second request to /api/v1/milestones/3/content with a payload like {"order":{"ids":[14],"direction":"after","compared_to":21},"add":[{"id":14}]}. The response payload is {"error":{"code":409,"message":"Conflict: Submitted id 21 is not part of the set to order"}} indicating that it is trying to set the order of stories in the milestone but they aren't actually added.

It seems that the code for adding stories to release milestones is incorrectly swallowing an exception, perhaps from a DB restriction that has somehow been triggered by actions we've taken in this project (since it isn't affecting other projects).