X
Closing this message and/or accessing our website tells us you are happy to receive all cookies on the ClearPeople website.
However, if you would like to, you can change your cookies settings at any time.
Graph API in SharePoint and external users - A Microsoft Approved workaround

Recently I've been working in a project with Modern SharePoint, SPFx Framework, React, Fabric UI, Graph API, and all these cool and modern stuff that Microsoft is pushing SharePoint developers to use. For a "classic" developer like me, this conversion from the "old good times" of the known Feature Framework where you have the control of everything, to this new way of re-doing all is a challenge. Sometimes you enjoy it a lot, and you like the way you can do so many cool things in such an easy way, but other times, having to trust in third APIs, is rather than annoying.


Let me go directly to the point of my frustration. I had the "simple" requirement of retrieving metadata of items from a SharePoint list using Graph API. Among that metadata, there were some managed metadata fields. To do that, I used Graph API. Why Graph API instead of SharePoint Rest API? Please, read this. Exactly, this is the query we're doing:


https://graph.microsoft.com/v1.0/sites/tenant-domain.sharepoint.com,xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/lists/<<ListName>>/items/11484?$expand=fields($select=ID,FileLeafRef,Keywords,Category)


Note that Keywords and Category are MMD fields.


Well, all was working fine until an external user (with owner permissions) claimed that the portal wasn't working for him. For visitor external accounts, all seemed to be working fine. The same for internal accounts, doesn't matter the kind of permissions. So, after digging a bit into the issue, I found that the Graph API queries were returning a no-meaning "409 conflict", with this response body:

 

{
  "error": {
    "code": "nameAlreadyExists",
    "message": "The specified item name already exists.",
    "innerError": {
      "request-id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "date": "2018-07-03T14:43:24"
    }
  }

}

 

The same query, but removing the MMD fields from the "select" worked as expected, so something is wrong in Graph API when retrieving items' taxonomy. But only for owner/editor external accounts?

At that point, I didn't have any better option than raising a support ticket with Microsoft. And after showing the issue, and exchanging some emails, the support guy from Microsoft came back with this kind of workaround:

  1. With the permission for external user set to visitor (read), please open a browser and sign into the SharePoint site with that external user where the list exists.
  2. Open new tab and run the REST API query - https://<yourdomain>.sharepoint.com/sites/<yoursite>/_api/web/lists/getbytitle('List Name')/items directly from the URL box. Please check if the xml output is returned successfully.
  3. Now change the permission level for the external user to non-visitor (editor/owner) and sign in to the SharePoint site with that external user where the list exists.
  4. Open new tab and run the REST API query - https://<yourdomain>.sharepoint.com/sites/<yoursite>/_api/web/lists/getbytitle('List Name')/items directly from the URL box. Please check if the xml output is returned successfully or you’re getting an error that says – “A list, survey, discussion board, or document library with the specified title already exists in this Web site.  Please choose another title.”
  5. If you’re getting the above error, open the SharePoint site with a logged in user that has site collection admin permissions. Now open https://<yourdomain>.sharepoint.com/sites/<yoursite>/Lists/TaxonomyHiddenList/AllItems.aspx . Go to ‘List’ tab in the ribbon and then click on ‘Shared With’ button. Please share the list with the external user.
  6. Now open - https://<yourdomain>.sharepoint.com/sites/<yoursite>/_api/web/lists/getbytitle('List Name')/items (with external user signed in) and see if you are getting the xml output correctly (without any error). If the output is being returned successfully, try running your SharePoint framework app and make the Graph API call using external user to confirm if it fixes the issue.

And that did the fix! Why do we need to share the TaxonomyHiddenList with editor/owner external accounts and not for visitors? No clue. And I am still waiting for a convincing answer for that from the Microsoft support guy. But in the meantime, that "fix" works. In my case, I gave read-access to the "Owners" group of the site into the TaxonomyHiddenList.


And this is the end of my rugged journey using Graph API when retrieving MMD fields of a SharePoint list items. After weeks trying to figure out why the same Graph API was working for visitor external accounts, but not for owners/editor ones, is like a sweet win, if we can make it work at the end. I hope this helps someone out there which is facing the same issue.

Author bio

Cristian Zaragoza
Cristian Zaragoza
SharePoint Developer
As a senior SharePoint developer, I’m involved in the whole development process of SharePoint projects that we deliver, also playing the role of Technical Lead. Outside of work, I enjoy as much sport as I can, learning to cook and reading books - Game of Thrones mostly!

Comments


comments powered by Disqus

Related Articles

Sign up to our Newsletter

Every now and then, we'd like to send you information that delivers, develops and promotes our products and services that are relevant to you. Submitting your details tells us that you're OK with this and you also agree to our Privacy & Cookies policy. You can, of course, opt out of these communications at any time.