Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: add ability to recursively load Taxonomy Terms from a termset. #4209

Closed
martinlingstuyl opened this issue Dec 8, 2022 · 7 comments

Comments

@martinlingstuyl
Copy link
Contributor

martinlingstuyl commented Dec 8, 2022

Say I have a termset with a nested list of terms and I execute:

m365 spo term list --termSetName "Some termset" --termGroupName "Some group"

I only get the top-level terms. I'd like to be able to include the child terms as well.

Option Description
--includeChildTerms If specified, child terms are loaded as well.

Remarks

The list of terms retrieved is a nested object, with arrays of child terms in every term object.

  • In text, csv and md output modes, the command output should contain all terms, children as well as parents.
  • In text, csv and md output modes, each term contains the ID of the parent term. If the term doesn't have a parent, the value of the property is empty.
  • In json output mode, the command output should keep the nested structure that the API returns.
@martinlingstuyl martinlingstuyl added enhancement needs peer review Needs second pair of eyes to review the spec or PR labels Dec 8, 2022
@waldekmastykarz
Copy link
Member

How does that affect the shape of data we retrieve and output? How would we present child items in text and csv output modes where we typically don't show nested objects?

@waldekmastykarz waldekmastykarz added needs discussion needs design and removed needs peer review Needs second pair of eyes to review the spec or PR needs discussion labels Dec 10, 2022
@martinlingstuyl
Copy link
Contributor Author

martinlingstuyl commented Dec 11, 2022

Hmmm, good point @waldekmastykarz. I'd say we should just return the api output, which means the child terms are a nested array.
That would also mean the text and csv output modes would not show the child terms, that's true. We could possibly add a child term count property, to show the user there's more. I believe that's included in the api output.

Not ideal though maybe. For text and csv output you'd like a more flat structure.

We could consider ourselves more wise than the SharePoint API, and return a flattened list in all output modes, but that would be unexpected maybe as well, and would add work for the user to check which terms are where in the hierarchy.

What would you think about adding a --flatten option and leave the choice to the user whether he wants the flattened list or the hierarchical list?

@waldekmastykarz
Copy link
Member

A flat list would make sense only if we included the ID of the parent term so that users can decode the hierarchy from the provided output. I'd say that we produce a flat list for all outputs except JSON and in JSON keep the hierarchy.

@martinlingstuyl
Copy link
Contributor Author

Added it to the remarks.

@waldekmastykarz
Copy link
Member

Extended the spec adding that in text, csv and md output (we've got that one now too 😄), we also need to include the ID of the parent term.

@MathijsVerbeeck
Copy link
Contributor

I would love to work on this!

@milanholemans
Copy link
Contributor

Nice to hear @MathijsVerbeeck!
All yours!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants