microsoft-graph-toolkit
microsoft-graph-toolkit copied to clipboard
microsoftgraph
Consent Indicator
Consent Indicator
Description
I am looking for an easy way to validate that proper consent is in place when testing a SPFx solution that includes MGT components.
Rationale
I am thinking of a few use cases:
- developer building a SPFx solution that requires Graph access
- Samples for user testing
- Check current tenant consents, for developers who don't have admin access
Preferred Solution
I don't know how to make it work, but for the UI I was thinking it could be a component, with as property either the scope name or the component name. Something like this:
<ConsentIndicator scope="Group.Read.All"/>
or
<ConsentIndicator component="TeamsChannelPicker"/>
Additional Context
Certainly not a big deal, more a nice to have if easy to implement.
Hello PathToSharePoint, thank you for opening an issue with us!
I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌
Thanks for the suggestion @PathToSharePoint. Can you clarify the use case you'd be looking into? I would love to understand deeply this request as it's a hot topic for us! Thanks!
I have listed some use cases, but I can talk more about my own experience. When I include the "magic" MGT controls in my solutions, usually I don't get it right the first time. And because the control doesn't display a specific error message, it's difficult to tell whether I have the code wrong or the consent not implemented correctly. Maybe there are othe ways to test?
For example, recently I tried a Team&Group picker, and only the team level was showing up. Because the control was still displaying some results, it took me some time to realize that the issue was with API permissions, not with the way I set the control.
How would you expect MGT to report back on the missing scopes? What would be the most effective way for you to learn about your missing scopes so you can either add them to your Msal2Provider (more for SPA scenarios) or to your SharePoint package where you identify the required scopes?
Documentation already mentions them but how could we help with the developer experience?
Let me start by acknowledging that the documentation is really well done, with that section dedicated to API permissions. It works pretty well when you have full control on the tenant.
Ideally, I would hope the component itself to report back. I find the message "we couldn't find any matches" a bit misleading, as it kind of implies that the query actually ran. I'd rather see an "unauthorized" message if proper API permissions are not in place. In my Team&Group example above, there is no message at all.
If we want to keep the component itself lightweight - which I could understand - then I could imagine a dedicated API test component. You would put the component on the page with the API name as attribute/property, and at runtime the component would show a green or red indicator. Crazy idea?
Was discussed way back. Something we are looking at providing to help with the overall understanding. #450