Added mgt-taxonomy-picker control

[anoopt]

PR Type

Feature

Description of the changes

Closes #634
Add mgt-taxonomy-picker control as #2156 .

Questions

• I want to add stories for this component however, I am not able to get termstore data (TermStore.Read.All scope). I tried using the below in the mgt-get story to get term groups and see a 403 forbidden message. Can you please let me know if any configuration needs to be updated in the storybook?

<mgt-get resource="/termStore/groups" version="beta" scopes="TermStore.Read.All" max-pages="2">
	<template>
		<div class="group" data-for="group in value">
			<h3>{{ group.id }}</h3>
		</div>
	</template>
</mgt-get>

• I want to use the renderTemplate function to customise the rendering of each option that gets rendered in the dropdown. However, I am not able to achieve that with the committed code. Please see line number 300. Any help here would be appreciated.

PR checklist

• Project builds (yarn build) and changes have been tested in at least two supported browsers (Edge + non-Chromium based browser)
• All public APIs (classes, methods, etc) have been documented following the jsdoc syntax
• Stories have been added and existing stories have been tested
• Added appropriate documentation. Docs PR:

• License header has been added to all new source files (yarn setLicense)
• Contains NO breaking changes

[ghost]

Thank you for creating a Pull Request @anoopt.

This is a checklist for the PR reviewer(s) to complete before approving and merging this PR:

• I have verified a documentation PR has been linked and is approved (or not applicable)
• I have ran this PR locally and have tested the fix/feature
• I have verified that stories have been added to storybook (or not applicable)
• I have tested existing stories in storybook to verify no regression has occured
• I have tested the solution in at least two browsers (Edge + 1 non-Chromium based browser)

[musale]

@anoopt thank you for this work on the taxonomy picker component! For Qn1, is your tenant able to show the values for the endpoint in https://aka.ms/ge? The storybook uses the mock endpoint and I have had issues with some endpoints before. Have you tried logging into the storybook with your own tenant?

For Qn 2 do you mean you want to give the ability to either render a custom option template or a default one?

[anoopt]

Thank you @musale .

For Qusetion 1 - Yes, I see results in the Graph Explorer for that endpoint. Sorry, I am not sure how to login to the storybook with my tenant. If I use mgt-login it always uses the mock provider with user as MeganB@M365x214355.onmicrosoft.com. In the storybook, I see that other mgt-components like mgt-file, mgt-people-picker are using ids. Are those ids from an actual tenant? If yes, is it the case of providing relevant permissions in that tenant?

For Question 2 - Yes, if it's possible can provide that ability for users?

[musale]

@anoopt

For Qn1: Yes the IDs are from the tenant used in most of the sandboxes. I'm not sure about the relevant permissions being granted but I assume that is the case. To login with your tenant in the story book, add the &login=true value on the login component URL. So it should look like this http://localhost:6006/?path=/story/components-mgt-login--login&login=true. Then on your top right you will see a sign in button, login in with your tenant account. Incase you need to change it up, just delete all cookies and session values.

For Qn 2: You totally can do that using custom templates. So instead of:

<fluent-option value=${term.id} selected @click=${e => this.handleClick(e, term)}>
  ${this.renderTemplate('term', { term }, term.id) || term.labels[0].name}
</fluent-option>

You do:

${this.renderTemplate('term', { term }, term.id) ||
<fluent-option value=${term.id} selected @click=${e => this.handleClick(e, term)}>
  ${term.labels[0].name}
</fluent-option>

This allows the user to specify their own term template or just render the fluent-option.

If that doesn't work for you, you can use CSS to customize the fluent-option and provide custom CSS properties that can be overridden by the users. Typically for fluent components, we use the part() css selector. It would look like this in scss:

:host {
  fluent-option {
    &::part(content) {
    background: var(--term-option-background-color, var(--neutral-fill-stealth-rest)) // var(--neutral-fill-stealth-rest) is the default background for option
    // other customizable options
    }
  }
}

The fluent-option has 3 parts so you can use those to customize it as you wish:

[gavinbarron]

@anoopt This is awesome work! Thank you so much for this contribution.

Regarding the option to customize the rendering of the item in the combobox list, I'd suggest against it.
This is using a fluent-combo-box with each item rendering in a fluent-option
This control is not very flexible when it comes to customization, we ran into this when builing the mgt-picker and had to abandon our plans for customizing the options as although they would render correctly the selection interactions were super brittle and broke if there was anything by plain text in the default slot of the rendered fluent-option

cc: @musale

[anoopt]

Thank you @gavinbarron . With the current code I faced the exact issue that you mentioned i.e. selection interactions not working as per the expectation.
The only reason I thought it would work is because of the picker preview gif (2nd one) in this link.

Is it ok to leave the code as is for now so that when in future templating is supported for fluent-option it works without a code update?

[anoopt]

@musale - Can we please grant TermStore.Read.All for the relevant application in the sandbox tenant M365x214355.onmicrosoft.com? The reason I ask for this is, we would need this for the storybook in documentaion. I see that all components in the documentation have an example as a storybook.

[gavinbarron]

@anoopt I think that the way it is now is just fine and if in the future we have a better story for templating those items we can address it then. The items in the second list are using Unicode emojis in their text, not any custom rendering, which looks slick but is still just text.

Regarding the scope request, we're working with the team that manages the sandbox tenant to get more scopes consented but it will take a little time to get resolved.

[musale]

@anoopt could you also add documentation for the component in this repo https://github.com/microsoftgraph/microsoft-graph-docs and target the mgt/v3 branch.

[anoopt]

@musale - I have submitted a PR for documentation.

[musale]

LGTM!

[Mnickii]

LGTM!

[sebastienlevert]

@anoopt FYI, the tenant now supports the TermStore.Read.All scope, so it will be way easier to test for our users! All looks good but I have a request. Can I ask you to update storied based on the tenant data? Then we're all good for merging, it works great! Thanks!

We will see if we add data in this tenant to make the stories easier to manage.

Thanks!

[anoopt]

@sebastienlevert - I have updated the stories accordingly.

I will update the docs as well.

[gavinbarron]

This will need to be updated with the current state of next/fluentui in order to pass the CI builds as there was a breaking change in the object definition of MgtTemplatedComponent

[gavinbarron]

@anoopt FYI, this needs an change to MgtTaxonomyPicker as the code cannot compile now due to changes in the target branch:

Error: src/components/mgt-taxonomy-picker/mgt-taxonomy-picker.ts(34,14): error TS2415: Class 'MgtTaxonomyPicker' incorrectly extends base class 'MgtTemplatedComponent'.
  Property 'error' is private in type 'MgtTaxonomyPicker' but not in type 'MgtTemplatedComponent'.

[anoopt]

@gavinbarron - Apologies. I have updated the code. Running yarn build locally was successful.

[sebastienlevert]

LGTM and works great!

[gavinbarron]

Let's ship it! 🚀

[sebastienlevert]

Hey @anoopt!

We are currently reviewing all the components before we go live for the Toolkit and wanted to bring a suggestion. Currently, the control is using mgt-get + fluent components. As we are improving our mgt-picker capabilities, I was wondering if that could be a nice way to build on top of the existing. It would reduce (a lot) the accessibility reviews, bugs and would improve the components as we improve the mgt-picker along the way.

Do you think that makes sense to re-use the mgt-picker instead of the mix of mgt-get + fluent component, as this is basically what the picker is?

Please let us know! We'd love to work with you on that one!

[anoopt]

Hi @sebastienlevert - Yes I agree with this. In fact that was my first plan when I started working on the mgt-taxonomy-picker. However, the only reason why I did not mgt-picker was because I was not able to pass the keyname as labels[0].name because of the nested data (not flat) returned by the taxonomy API for Graph.

[
       {
            "id": "7a1343f9-72ec-4206-8d12-b5ad9f74bec1",
            "createdDateTime": "2022-02-21T14:23:40.247Z",
            "lastModifiedDateTime": "2022-03-21T12:59:15.217Z",
            "labels": [
                {
                    "name": "Bangalore",
                    "isDefault": true,
                    "languageTag": "en-US"
                }
            ],
            "descriptions": []
        },
        {
            "id": "d2f52bf3-99a3-41a0-9206-4643915e39c3",
            "createdDateTime": "2022-02-20T23:59:50.84Z",
            "lastModifiedDateTime": "2022-03-01T00:44:13.88Z",
            "labels": [
                {
                    "name": "Headquarters",
                    "isDefault": true,
                    "languageTag": "en-US"
                }
            ],
            "descriptions": []
        },
        {
            "id": "26d0cb04-7f86-4e2b-aecc-f62bafacfeea",
            "createdDateTime": "2022-03-29T08:31:07.933Z",
            "lastModifiedDateTime": "2022-03-29T08:31:59.827Z",
            "labels": [
                {
                    "name": "Lisbon",
                    "isDefault": true,
                    "languageTag": "en-US"
                }
            ],
            "descriptions": []
        },
        {
            "id": "8765d0db-e56e-45ef-a98c-249c29bd6803",
            "createdDateTime": "2022-02-13T01:29:25.1Z",
            "lastModifiedDateTime": "2022-03-04T16:35:41.28Z",
            "labels": [
                {
                    "name": "London",
                    "isDefault": true,
                    "languageTag": "en-US"
                }
            ],
            "descriptions": []
        }
]

So, if this line in mgt-picker could have an eval then we can pass the keyname as labels[0].name.

Using eval might be helpful in other scenarios too where the data returned is not flat.

[sebastienlevert]

Adding @musale @gavinbarron @Mnickii to this thread. How could we support some sort of "nested" access for the picker? Goal is to re-use as much as possible the existing components instead of rebuilding!

[gavinbarron]

Thanks for the context @anoopt that's very helpful. I'll take a look at the eval option.

[sebastienlevert]

@gavinbarron how should we treat this for accessibiltiy review and v3?

[anoopt]

@sebastienlevert and @gavinbarron - Just for my information, is TaxonomyPicker not part of @microsoft/mgt-react version 3.0.0-rc.3 package yet?

[sebastienlevert]

In this case, we will be looking at it in 3.1 for the eval feature. Feature created here: #2489

[sebastienlevert]

For the availability in React, we created an issue: #2490