3
votes

We are using The Graph api to set the content type of a SharePoint document. Without changing any code, we are getting Access denied errors, starting from August 23.

We are executing a "PATCH" to the address "https://graph.microsoft.com/v1.0/sites/[companyName].sharepoint.com,[siteCollectionID],[siteId]/lists/[listId]/items/[itemId]/fields" With the requestdata "{"ContentTypeId": "0x[ContentTypeID]"}"

On one SharePoint Online environment this still works, but on another SharePoint Online environment we receive the following error: Code: "accessDenied" Message: "Field 'ContentTypeId' is read-only"

Because this happens without any code change we're wondering if Microsoft changed something in a SharePoint Online update, or is there any setting on the failing SharePoint environment that could cause this exception??

Thank you for any help or suggestions

Update

Unfortunately, things got worse over the weekend. A update to our situation: We have 2 SharePoint Online environments that we administer our selves and and 1 SP Online that we don’t control. On Friday 1 of my environments still worked correctly and 2 started failing. Now on Monday, all 3 environments fail. I’m 100% sure we didn’t change the code and of 2 SP environments I’m 100% sure we didn’t change any settings.

I'm trying to look into the updates of SharePoint Online, by using the Office Roadmap (https://products.office.com/nl-NL/business/office-365-roadmap?filters=%26freeformsearch=SharePoint) or are there any more helpful places that I could use?

3

3 Answers

4
votes

To change the content type of a list item using the graph API you actually want to modify the ContentType facet on the item itself, not the ContentType or ContentTypeID fields. Here's an example:

PATCH 

https://graph.microsoft.com/v1.0/sites/YOURTENANT.sharepoint.com:/sites/SITENAME:/lists/LISTNAME/items/1/

{
    "contentType": { "id": "0x0100D3426610C727AC42B5238A1FA52864F6" }
}

In that case that's the Id of my basic item type. I'm not sure why patching to the ContentTypeId field would ever have worked as it doesn't appear to be an addressable field in our underlying code. I'm going to keep digging to see if there was a change made recently but as best I can tell right now it really shouldn't have worked previously as ContentType is a complex type that includes both a name and an Id so patching the field directly isn't correct.

1
votes

I assume there is some change rolled out for Graph. Tested the calls in Postman and i can confirm the Graph call has stopped working on several environments starting August 23th. As far as i can tell it has nothing to do with any setting on the SharePoint environment.

As a workaround it still seems possible to change the content type using the SharePoint REST Api.

PATCH {siteurl}/_api/web/lists(guid'{libraryId}')/items({id})
If-Match: {eTag}
X-HTTP-Method: Merge

{"ContentTypeId": "0x0101009E44B70FDF6D5D418E3B608C7DB4E8DB0100F24E9188A7EE514197DF449302E7D11C"}

It is a bit annoying to have to fall back to the SharePoint API for something that used to work with Graph.

0
votes

After some digging, i don't see any official posts from Microsoft stating any updates related to Sharepoint online yet. But it could just be delay or something they've forgot.

From your error code. "accessDenied" Message: "Field 'ContentTypeId' is read-only". Seems the permissions have been changed.

I would suggest that you check your Field element which defines a site column. Or compare your two SharePoint online environment to see if the permissions are changed as intended.

ReadOnly="TRUE" | "FALSE"
ReadOnlyEnforced="TRUE" | "FALSE"

Maybe site admin was considering locking the column but forget to lift it. Sometimes when a new site column is created, a SharePoint admin will set it as read only or as read only enforced to prevent the user of editing the data stored in the field. This can be done either through PowerShell or CSOM.

Here are some references and field property.