通过图形设置 contentTypeID 时出现拒绝访问错误（只读）
Access Denied Error (read only) on setting contentTypeID via Graph
我们正在使用 The Graph api 来设置 SharePoint 文档的内容类型。从 8 月 23 日开始，在不更改任何代码的情况下，我们会收到访问被拒绝的错误。
我们正在对地址“https://graph.microsoft.com/v1.0/sites/[companyName].sharepoint.com,[siteCollectionID],[siteId]/lists/[listId]/items/[itemId]/fields”执行"PATCH"
使用请求数据 "{"ContentTypeId": "0x[ContentTypeID]"}"
在一个 SharePoint Online 环境中这仍然有效，但在另一个 SharePoint Online 环境中我们收到以下错误：
代码："accessDenied"
消息："Field 'ContentTypeId' is read-only"
因为这种情况发生时没有任何代码更改，我们想知道 Microsoft 是否更改了 SharePoint Online 更新中的某些内容，或者失败的 SharePoint 环境中是否有任何设置可能导致此异常？
感谢您的任何帮助或建议
更新
不幸的是，周末情况变得更糟。
我们的情况更新：我们有 2 个我们自己管理的 SharePoint Online 环境和 1 个我们无法控制的 SP Online。星期五，我的环境中有 1 个仍然正常工作，有 2 个开始出现故障。现在在星期一，所有 3 个环境都失败了。我 100% 确定我们没有更改代码和 2 个 SP 环境我 100% 确定我们没有更改任何设置。
我正在尝试使用 Office 路线图 (https://products.office.com/nl-NL/business/office-365-roadmap?filters=%26freeformsearch=SharePoint) 查看 SharePoint Online 的更新，或者是否有更多有用的地方可供我使用？
经过一些挖掘，我没有看到任何来自 Microsoft 的官方帖子说明与在线 Sharepoint 相关的任何更新。但这可能只是延迟或他们忘记了什么。
来自您的错误代码。 "accessDenied" 消息："Field 'ContentTypeId' is read-only"。似乎权限已更改。
我建议您检查定义网站栏的 Field 元素。
或者比较您的两个 SharePoint 在线环境以查看权限是否按预期更改。
ReadOnly="TRUE" | "FALSE"
ReadOnlyEnforced="TRUE" | "FALSE"
也许站点管理员正在考虑锁定该列但忘记解除它。有时，在创建新网站栏时，SharePoint 管理员会将其设置为只读或强制只读，以防止用户编辑字段中存储的数据。这可以通过 PowerShell 或 CSOM 完成。
这里有一些 references and field property。
我假设 Graph 推出了一些更改。在 Postman 中测试了调用，我可以确认 Graph 调用已从 8 月 23 日开始在多个环境中停止工作。据我所知，它与 SharePoint 环境中的任何设置无关。
作为解决方法，似乎仍然可以使用 SharePoint REST 更改内容类型 Api。
PATCH {siteurl}/_api/web/lists(guid'{libraryId}')/items({id})
If-Match: {eTag}
X-HTTP-Method: Merge
{"ContentTypeId": "0x0101009E44B70FDF6D5D418E3B608C7DB4E8DB0100F24E9188A7EE514197DF449302E7D11C"}
不得不回退到 SharePoint API 以获取曾经与 Graph 一起使用的东西，这有点烦人。
要使用图表 API 更改列表项的内容类型，您实际上想要修改项目本身的 ContentType 方面，而不是 ContentType 或 ContentTypeID 字段。这是一个例子：
PATCH
https://graph.microsoft.com/v1.0/sites/YOURTENANT.sharepoint.com:/sites/SITENAME:/lists/LISTNAME/items/1/
{
"contentType": { "id": "0x0100D3426610C727AC42B5238A1FA52864F6" }
}
在这种情况下，这是我的基本项目类型的 ID。我不确定为什么修补 ContentTypeId 字段会起作用，因为它在我们的基础代码中似乎不是可寻址的字段。我将继续挖掘以查看最近是否进行了更改，但据我所知，它之前确实不应该工作，因为 ContentType 是一种复杂类型，包括名称和 Id，因此修补该字段直接是不正确的。
我们正在使用 The Graph api 来设置 SharePoint 文档的内容类型。从 8 月 23 日开始，在不更改任何代码的情况下，我们会收到访问被拒绝的错误。
我们正在对地址“https://graph.microsoft.com/v1.0/sites/[companyName].sharepoint.com,[siteCollectionID],[siteId]/lists/[listId]/items/[itemId]/fields”执行"PATCH" 使用请求数据 "{"ContentTypeId": "0x[ContentTypeID]"}"
在一个 SharePoint Online 环境中这仍然有效，但在另一个 SharePoint Online 环境中我们收到以下错误： 代码："accessDenied" 消息："Field 'ContentTypeId' is read-only"
因为这种情况发生时没有任何代码更改，我们想知道 Microsoft 是否更改了 SharePoint Online 更新中的某些内容，或者失败的 SharePoint 环境中是否有任何设置可能导致此异常？
感谢您的任何帮助或建议
更新
不幸的是，周末情况变得更糟。 我们的情况更新：我们有 2 个我们自己管理的 SharePoint Online 环境和 1 个我们无法控制的 SP Online。星期五，我的环境中有 1 个仍然正常工作，有 2 个开始出现故障。现在在星期一，所有 3 个环境都失败了。我 100% 确定我们没有更改代码和 2 个 SP 环境我 100% 确定我们没有更改任何设置。
我正在尝试使用 Office 路线图 (https://products.office.com/nl-NL/business/office-365-roadmap?filters=%26freeformsearch=SharePoint) 查看 SharePoint Online 的更新，或者是否有更多有用的地方可供我使用？
经过一些挖掘，我没有看到任何来自 Microsoft 的官方帖子说明与在线 Sharepoint 相关的任何更新。但这可能只是延迟或他们忘记了什么。
来自您的错误代码。 "accessDenied" 消息："Field 'ContentTypeId' is read-only"。似乎权限已更改。
我建议您检查定义网站栏的 Field 元素。 或者比较您的两个 SharePoint 在线环境以查看权限是否按预期更改。
ReadOnly="TRUE" | "FALSE"
ReadOnlyEnforced="TRUE" | "FALSE"
也许站点管理员正在考虑锁定该列但忘记解除它。有时，在创建新网站栏时，SharePoint 管理员会将其设置为只读或强制只读，以防止用户编辑字段中存储的数据。这可以通过 PowerShell 或 CSOM 完成。
这里有一些 references and field property。
我假设 Graph 推出了一些更改。在 Postman 中测试了调用，我可以确认 Graph 调用已从 8 月 23 日开始在多个环境中停止工作。据我所知，它与 SharePoint 环境中的任何设置无关。
作为解决方法，似乎仍然可以使用 SharePoint REST 更改内容类型 Api。
PATCH {siteurl}/_api/web/lists(guid'{libraryId}')/items({id})
If-Match: {eTag}
X-HTTP-Method: Merge
{"ContentTypeId": "0x0101009E44B70FDF6D5D418E3B608C7DB4E8DB0100F24E9188A7EE514197DF449302E7D11C"}
不得不回退到 SharePoint API 以获取曾经与 Graph 一起使用的东西，这有点烦人。
要使用图表 API 更改列表项的内容类型，您实际上想要修改项目本身的 ContentType 方面，而不是 ContentType 或 ContentTypeID 字段。这是一个例子：
PATCH
https://graph.microsoft.com/v1.0/sites/YOURTENANT.sharepoint.com:/sites/SITENAME:/lists/LISTNAME/items/1/
{
"contentType": { "id": "0x0100D3426610C727AC42B5238A1FA52864F6" }
}
在这种情况下，这是我的基本项目类型的 ID。我不确定为什么修补 ContentTypeId 字段会起作用，因为它在我们的基础代码中似乎不是可寻址的字段。我将继续挖掘以查看最近是否进行了更改，但据我所知，它之前确实不应该工作，因为 ContentType 是一种复杂类型，包括名称和 Id，因此修补该字段直接是不正确的。