From API Get a portfolio, the parent field value back in json is actually the same gid with the portfolio in query.
The Portfolio object doesn’t have a
AFAIK there’s no way to tell if a portfolio is contained within another portfolio from the
portfolio object itself.
@sasha_f @Jeff_Schneider Can you confirm that this is the case?
Hi @Phil_Seeman , thanks for replying back. Wondering is there anyway could pull out the relationship for the parent portfolio, current I couldn’t find a way to read that in API or any raw data.
The only way I know of is to use the Get portfolio items endpoint on each of your portfolios. Each item will have a
resource_type of either
project or in the case of a sub-portfolio,
Okay, will try that ahead,. Thank you so much!
@Phil_Seeman’s answer may provide an immediate solution. But if not, or if you’re coding for the future, see:
It seems like the API docs are not updated yet, but note in the post the code below “Prototype of the new Membership resource (when a member can be a team or a user)”
Hope that helps,
I think that’s different, @lpb - as I understand it, @Ross_Zhang wants to know if a portfolio is inside of another portfolio.
Portfolio membership returns the users (or teams) who are members of the portfolio.
I guess I misread @sasha_f’s post. I though the column of “Old endpoints” was going away but that’s my mistake because I now see most of them are not changing; only the rows indicated. Maybe “Old” is not the best column header there; “Current” or “Existing” might be more clear because most are not going away.
Thanks for catching that, @Phil_Seeman.
For Upcoming changes that impact getting and setting memberships and access levels, everything in the “Old Endpoints” column will be replaced by the “New Endpoints” in the same row. So all of the
GET endpoints will be replaced by a single
GET /memberships endpoint, and similarly for the mutating calls.
I think the question in this was was about portfolio nesting, and not about the memberships within a portfolio (although the term “memberships” is definitely overloaded – in the context of portfolios, I think of it as only teams or members that have access to a portfolio, not of contained portfolios).
Something for us to think about in improving ergonomics, it can definitely be a little confusing!
Great explanation, @sasha_f. I think I made every wrong interpretation possible there!
“User membership” is clear, but I read “membership” and was thinking more like:
task.memberships[object] Create-only. Array of projects this task is associated with and the section it is in. At task creation time, this array can be used to add the task to specific sections. After task creation, these associations can be modified using the
removeProjectendpoints. Note that over time, more types of memberships may be added to this property.
Yes, overloading “membership,” even when modifying with “user membership” did throw me due to years of non-user meaning of nesting/contained in.
Thanks for clarifying,
To conclude: These won’t help @Ross_Zhang as I had originally hoped.