Content
View differences
Updated by Jonas Heinrich (Finn) almost 12 years ago
**Background**
APIv2 restricts parent\_ids according to the result set of the current request. This means if the real parent of an element is not in the result set, but another ancestor is, the parent\_id becomes the id of the closest ancestor (e.g. the grandparent instead of the parent).
Consider the ticket hierarchy below [this ticket](https://openproject-org.qa.finn.de/work_packages/13976)
Ticket 13976 is the root, its child is 3811 and the grandchildren are 3872 and 13959.
The grandchild 3872 and the root (13976) share the same project (test-robin), while 3811 and 13959 are in different projects.
**Reproduction**
Call https://openproject-org.qa.finn.de/api/v2/projects/test-robin/planning\_elements.xml
**Expected**
The parent\_id of 3872 is 13976 because it is the grandparent and the immediate parent is not part of the result set
**Actual**
The parent\_id of 3872 is 3816, which is a root-ticket from a different hierarchy in the same project (test-robin)
**Hint**
The offending method is most probably rewire\_ancestors in app/controllers/api/v2/planning\_elements\_controller.rb
Jens told me that problem might be, that there is no check whether two planning elements come from the same hierarchy (thus a matching node from any hierarchy could be considered for being an ancestor).
### Steps to reproduce:
- Create a hierarchy with 3 tickets in “**Project** 1”
Ticket **A, B** and **C** share the same project - **A** is parent of **B**, and **B** parent of **C**.
- Create another hierarchy
this time ticket **D** and **F** share the same project “**Project 1**”, while ticket **E** is from a different project \*“Project 2\*”
**D** is parent of **E**, **E** parent of **F**
View the XML:
https://openproject-org.qa.finn.de/api/v2/projects/project-1/planning\_elements.xml
please see the screenshot attached
APIv2 restricts parent\_ids according to the result set of the current request. This means if the real parent of an element is not in the result set, but another ancestor is, the parent\_id becomes the id of the closest ancestor (e.g. the grandparent instead of the parent).
Consider the ticket hierarchy below [this ticket](https://openproject-org.qa.finn.de/work_packages/13976)
Ticket 13976 is the root, its child is 3811 and the grandchildren are 3872 and 13959.
The grandchild 3872 and the root (13976) share the same project (test-robin), while 3811 and 13959 are in different projects.
**Reproduction**
Call https://openproject-org.qa.finn.de/api/v2/projects/test-robin/planning\_elements.xml
**Expected**
The parent\_id of 3872 is 13976 because it is the grandparent and the immediate parent is not part of the result set
**Actual**
The parent\_id of 3872 is 3816, which is a root-ticket from a different hierarchy in the same project (test-robin)
**Hint**
The offending method is most probably rewire\_ancestors in app/controllers/api/v2/planning\_elements\_controller.rb
Jens told me that problem might be, that there is no check whether two planning elements come from the same hierarchy (thus a matching node from any hierarchy could be considered for being an ancestor).
### Steps to reproduce:
- Create a hierarchy with 3 tickets in “**Project** 1”
Ticket **A, B** and **C** share the same project - **A** is parent of **B**, and **B** parent of **C**.
- Create another hierarchy
this time ticket **D** and **F** share the same project “**Project 1**”, while ticket **E** is from a different project \*“Project 2\*”
**D** is parent of **E**, **E** parent of **F**
View the XML:
https://openproject-org.qa.finn.de/api/v2/projects/project-1/planning\_elements.xml
please see the screenshot attached