Sp-dev-docs: Documentation and roadmap for GraphHttpClient

[wobba]

Category

• [x] Question

I recently tested the GraphHttpClient, and it works just fine. After decoding the Bearer token I saw the permissions available are

• Group.ReadWrite.All
• Reports.Read.All

But seems to be limits to what you can pull out from an O365 Group - as fetching members gave me a 401.

Are there docs in the plans for exactly what you can query and not, as well as a roadmap for which permissions you are planning to add - or if the route would be bring your own app permissions?

[VesaJuvonen]

Docs in plans and should be getting out latest on early next week.

[jonathanhotono]

@VesaJuvonen is it out yet? Kind of need to use graph api now since graph GQL search api is now deprecated and will be removed by 31 august.

[wobba]

@jonathanhotono Have you tried calling the API on /me/insights? I haven't tried myself, so not sure if it works or not.

[jonathanhotono]

@wobba Yes I did tried it with beta/me/insights/trending and it seems that I might haven't configured something and it got this error message 403 forbidden on GET request: Insufficient privileges to complete the operation.
Is there any additional permissions that I need to setup via azure or something like that to enable the request?
Code:
this.props.context.graphHttpClient.get("beta/me/insights/trending", GraphHttpClient.configurations.v1).then((response: HttpClientResponse) => { return response.json(); }).then(data=>{ debugger; });

@waldekmastykarz have you tried this?

[wobba]

The permissions used are those in my original Q, and those do not include /me/insights. Not sure what perms are needed for that, as I couldn't find it in the docs when mobile browsing.

[jonathanhotono]

I think maybe since this is preview feature those permissions might be restricted to those at the time being.

[waldekmastykarz]

@jonathanhotono @wobba according to the docs you need either Sites.Read.All or Sites.ReadWrite.All to access insights, none of which are currently available through GraphHttpClient. For more info on insights see the docs @ https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/insights.

[wobba]

Thank you @waldekmastykarz, and I see now the scopes are listed on the sub pages per call :)

[ypcode]

Hi there,
Is there any functional reasons or maybe technical limitations why Group and Reports are the only available permissions ? (Maybe it is just not yet available while in preview).

As @VesaJuvonen suggests, I would like to give here my input:
Ideally, to do through the GraphHttpClient everything the users are allowed to would be great !
I have plenty of ideas of applications (Some of them are actually real customer requests I will have to deal with soon):

• Access the user Outlook data (Mail, Calendar, Tasks and Contacts) for a really integrated and engaging UI in a custom application (or customization)
  -- for an overlay on a public calendar in an Intranet Page
  -- full integration with the ecosystem tasks, (not only a SharePoint task list and the involved limitations)
• See and retrieve content from personal OneDrive for engaging UI Implementation in SharePoint (e.g. an integrated personal file explorer)
• Access the Excel and OneNote endpoints to integrate custom actions that perform quick automatic changes on these files

There are tons on things the users would love if we can manipulate the whole users relevant data from a SharePoint page.

I know, anyway, everything could be done using ADAL,JS. But it would be great, if the GraphHttpClient was as easy to use as the Graph Explorer.

What do you think ?

[ollij]

Maybe there could be a tenant specific setting Azure AD for GraphHttpClient. What permissions are allowed in this tenant. The default could be very limited, but the admin could change it and basically allow everything that is available if that is needed.

[BlairMcc]

Are there any further updates?

Currently, we are attempting to do it on a classic page using code like this http://www.vrdmn.com/2017/06/access-microsoft-graph-from-classic.html

However, it seems like the SP.OAuth.Token endpoint used by GraphHttpClient is actually encapsulated within it and the token being passed back does not give us the sufficient Sites.Read/Write.All scopes for the insights/trending endpoint. https://dev.office.com/sharepoint/docs/spfx/call-microsoft-graph-using-graphhttpclient

We have a pretty critical issue as SPO Graph is disappearing on 31 Aug, the me/insights/trending endpoint is only in beta, and the SP.OAuth.Token endpoint is dependent on GraphHttpClient

[wobba]

For short term on SP pages your solution is to register your own O365 app, and use adal to call against it. Maybe not 100%, but that's what we live with when using preview API's for years ;)

[AhmadiRamin]

any improvements ?

[Brentless]

Wondering about an update on this roadmap too. With the graph GQL gone, having this "easy" method directly from SharePoint is a huge must have.

I'd ask priority on the permissions that let you fetch Recent Files, Trending Files, Trending People, and Planner tasks for the current user. Those make the most sense to be featured on intranet home pages. We do this currently (and it is quite messy with adal.js, particular when it comes to token refreshes), but has lots of end user value.

[waldekmastykarz]

@Brentless GQL != MS Graph. Even if we got full access to the MS Graph, you still wouldn't be able to achieve what you could do with GQL. MS Graph contains a few fixed endpoints for specific queries but nothing close to parity with GQL.

I agree it would be very valuable to have the GraphHttpClient do more, but comparing it to GQL is a whole different thing.

[Brentless]

I'm aware they are different, but I could accomplish what I wanted via GQL,
if the GraphHttpClient would return the token that has more permissions, I
could query the Graph (more stable/easier than adal).

I have 4 custom web parts today in a SEWP. One gets recent documents, one
gets trending documents, one gets trending people, and one gets O365 Groups
the user is a part of. 3 of those I could get via GQL (no longer)

Groups I can get via GraphHttpClient token and Graph endpoint.

I can get the token via adal, but it fails allot, especially in token
renewals.

Getting GraphHttpClient token is easy and never fails from my experience

On Sep 8, 2017 12:42 AM, "Waldek Mastykarz" [e-mail]
wrote:

@Brentless https://github.com/brentless GQL != MS Graph. Even if we got
full access to the MS Graph, you still wouldn't be able to achieve what you
could do with GQL. MS Graph contains a few fixed endpoints for specific
queries but nothing close to parity with GQL.

I agree it would be very valuable to have the GraphHttpClient do more, but
comparing it to GQL is a whole different thing.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SharePoint/sp-dev-docs/issues/621#issuecomment-328004415,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABZ1Jm9yFfowpeRAIGfODiPJiUzmcbOVks5sgNOqgaJpZM4NzpM3
.

[waldekmastykarz]

@Brentless any specific issues that you're getting with renewing tokens? GraphHttpClient always works because it obtains its tokens via a different way.
Your scenario is a good use case to submit an entry on User Voice to let the Product Group know that there is need for simplified access to more of the MS Graph capabilities.

[Brentless]

Nothing I can specify, it's just not consistent. I'd say works 80% of the
time, but the remaining 20% users have to refresh a time or two. Which
user voice would this apply to?

On Sep 8, 2017 12:36 PM, "Waldek Mastykarz" [e-mail]
wrote:

@Brentless https://github.com/brentless any specific issues that you're
getting with renewing tokens? GraphHttpClient always works because it
obtains its tokens via a different way.
Your scenario is a good use case to submit an entry on User Voice to let
the Product Group know that there is need for simplified access to more of
the MS Graph capabilities.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SharePoint/sp-dev-docs/issues/621#issuecomment-328167505,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABZ1JnkBHqmb6ALZ6WlcQANA51g2fUdRks5sgXsWgaJpZM4NzpM3
.

[waldekmastykarz]

You can submit your idea here: https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform

[Brentless]

Thanks, I've added the user voice here:
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/31310038-add-additional-permissions-to-graphhttpclient

[VesaJuvonen]

Considering the latest announcements, we should be well covered after Ignite, so closing this one.

• https://www.youtube.com/watch?v=-vbvZj6hopc
• https://docs.microsoft.com/en-us/sharepoint/dev/spfx/overview-graphhttpclient
• https://docs.microsoft.com/en-us/sharepoint/dev/spfx/call-microsoft-graph-using-graphhttpclient

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues