View Issue Details

IDProjectCategoryView StatusLast Update
0025514mantisbtapi restpublic2019-03-24 21:13
Reportervboctor Assigned Tocommunity  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
Product Version2.19.0 
Summary0025514: Subprojects returned in GET project doesn't include inherit_parent
Description

Possible fixes:

  • Include inherit_parent in result of GET project for its sub-projects.
  • Implement a separate GET for subprojects of a project that returns all sub-projects and their info.

This was raised as part of: https://github.com/mantisbt/mantisbt/pull/1453

I noticed that in Get Project, the sub-project information doesn't include the inherit_paent field. We should add it there.

This should get its own issue in the tracker and not handled by this PR. From my point of view, Get Project has more issues. Let's say project (1) has three subprojects (2,3,4). For a request GetProject(1) I would expect a response with one project (1) including its subproject list. Actually returned is an array with four projects (1,2,3,4). This is at least not consistent, as for example GetIssue(123) only returns one issue, and not additionally those in relationships.

TagsNo tags attached.

Activities

obmsch

obmsch

2019-02-28 03:29

reporter   ~0061603

@vboctor I would be in favour of a separate GET, which returns a list of the project's (user accessible) subprojects
with their info (id, name, inherit_parent). And use the new command in project GET to obtain the list of subprojects.

And as already touched on in PR#1453, don't return those as 'additional' projects (This should have its own issue in
the tracker. I can do this, but wouldn't be allowed to add a relationship to this one).

If we agree along this lines, I would look to provide a PR.

vboctor

vboctor

2019-03-01 22:32

manager   ~0061612

@obmsch Let's use this issue to implement a GET for subprojects of a project that corresponds the Add/Update/Delete that you implemented earlier.

Please open an issue for the Get Project issue and submit this as a separate PR.

Thanks for your contributions.

obmsch

obmsch

2019-03-04 08:20

reporter   ~0061619

@vboctor I'm working on this, but would like to clarify how to proceed before I go ahead.

  1. Completeness
    The new in ProjectHierarchyGetCommand should return all user accessible subprojects for:

    • get subprojects (only childs, exclude disabled)
    • get subprojects (only childs, include disabled)
    • get subprojects (all descendents, exclude disabled)
    • get subprojects (all descendents, include disabled)
      To implement this, the payload should contain booleans all_descendents and include_disabled
  2. Unclarity
    Simply adding inherit_parent might not be sufficient.
    Let's have a simple project hierarchy:
    p(1,inherit_parent=true)->p(2,inherit_parent=false)->p(3,inherit_parent=true)
    A get subprojects (all descendents) call on p(1) would deliver:
    (('id'=2,'name'='p2',inherit_parent=false),('id'=3,'name'='p3',inherit_parent=true))
    Theinherit_parent property of p3 is decoupled from the calling p1.
    We either don't care, or add parent_id as well.

obmsch

obmsch

2019-03-23 04:39

reporter   ~0061742

PR https://github.com/mantisbt/mantisbt/pull/1487

cproensa

cproensa

2019-03-23 06:42

developer   ~0061744

@obmsch

For all your comments in 0025514:0061619 , i think you should review my proposed PR:
https://github.com/mantisbt/mantisbt/pull/1480
Since I'm trying to clean up the same issues at core level

cproensa

cproensa

2019-03-23 08:32

developer   ~0061746

Completeness
The new in ProjectHierarchyGetCommand should return all user accessible subprojects for:
get subprojects (only childs, exclude disabled)
get subprojects (only childs, include disabled)
get subprojects (all descendents, exclude disabled)
get subprojects (all descendents, include disabled)
To implement this, the payload should contain booleans all_descendents and include_disabled

After working in the hierarchy stuff, i wonder:
Why would you need to retrieve "only direct children"? In my PR i have removed all the code that needs that, except for the soap/rest api (only because it's translating the core functions).
If you need that information, you probably need the real hierarchy, without user visibility, or disabled status, constraints.
My line of thought is that we need to clearly separate "actual hierarchy" and "user visible hierarchy". That may also imply having separate api endpoints.

Unclarity
Simply adding inherit_parent might not be sufficient.
Let's have a simple project hierarchy:
p(1,inherit_parent=true)->p(2,inherit_parent=false)->p(3,inherit_parent=true)

Well, the parent inheritance is a property of the relation, not the node.
A project with two parents, P1 and P2, can be configured to inherit from P1, but not P2. So, if you have a property returned along the child node, this can't be a boolean, and should contain "[P1]", in this case.

A get subprojects (all descendents) call on p(1) would deliver:
(('id'=2,'name'='p2',inherit_parent=false),('id'=3,'name'='p3',inherit_parent=true))
The inherit_parent property of p3 is decoupled from the calling p1.

What do you mean by "decoupled"?
Note that inheritance should point to an actual project, regardless of that project being inside the returned scope of your query. So, P1 should be returned even if it's not included in the results.
Again, i wonder, why would you need the inheritance from a client side, and in such case, whether this request is, or not, the correct one to provide that.

obmsch

obmsch

2019-03-24 20:24

reporter   ~0061766

@cproensa I have seen your PR, and once I figure out how to apply that, I will take a look. For now I am happy to get the git basics right.

I will try to answer/discuss all points in the PR. Just for your question:

What do you mean by "decoupled"?

In the example, the list of subprojects of p1 contains the grandchild p3. My point was, that simply only adding 'inherit_parent` without adding a reference
to the parent project too, might be misleading because p3 doesn't inherit from the requested p1.

cproensa

cproensa

2019-03-24 21:13

developer   ~0061767

In the example, the list of subprojects of p1 contains the grandchild p3. My point was, that simply only adding 'inherit_parent` without adding a reference
to the parent project too, might be misleading because p3 doesn't inherit from the requested p1.

Thanks
As discussed in the pr, and victor said, the best representation is to state directly the target project(s), instead of a boolean.