我已经使用来自SharePoint Online的Microsoft Graph设置了一个使用数据的React Web应用程序,效果很好。我可以读写SP列表,但是找不到任何有关如何构造数据以写入“人员/组”字段的文档。
使用这些字段查询列表将产生"ManagerLookupId": "12"
,其中Manager
是人员选择器字段名称。我可以使用扩展查询字符串来解析"12"
。我无法弄清楚如何使用Microsoft Graph的/v1.0
或/beta
端点对其进行写操作
将此对象发布到相关端点有效(用于单行文本,选择等)。
{
"fields": {
"Title": "a",
"Category": "b",
"Description": "c"
}
}
但是,如果要在“人员”选择器字段中添加,我将不知道如何构造该数据。我尝试了电子邮件地址和GUID,但两者均无法正常工作。查看SP的本机工作方式,看来是在提交人员选择器字段时提交了此值(已替换了真实值)-
{
"Key": "i:0#.f|membership|EMAIL",
"DisplayText": "NAME",
"IsResolved": true,
"Description": "EMAIL",
"EntityType": "User",
"EntityData": {
"IsAltSecIdPresent": "False",
"Title": "POSITION",
"Email": "EMAIL",
"MobilePhone": "",
"ObjectId": "GUID",
"Department": ""
},
"MultipleMatches": [],
"ProviderName": "Tenant",
"ProviderDisplayName": "Tenant"
}
复制此内容也无法更新列表中的“人员”字段。
我无法在MS Graph API网站上找到任何文档,也无法在其Github上找到类似的先前问题,因此我们将不胜感激!
答案 0 :(得分:2)
您可以在FieldValueSet
的文档中找到关于此的一些信息:
默认情况下,不返回查找字段(如上面的
Author
)。相反,服务器返回一个“ LookupId”字段(如上面的AuthorLookupId
),该字段引用查找中的目标listItem
。 “ LookupId”字段的名称是原始字段名称,后跟LookupId。
在幕后,这是SharePoint跟踪用户的方式的副作用。作为历史的人工产物,SharePoint维护它自己的用户数据库。虽然在某个时间点上,SP管理员对这些用户有很多了解,但今天它是一个完全自动化的过程。它仅在第一次看到经过身份验证的AAD用户时创建一个新的SPUser
记录。这些用户记录具有自己的id
属性。这是常见的INT
而不是GUID
(在您的示例中,其id
是12
)。
更新ListItem
时,需要使用SharePoint的id
。您可以将其作为单个值或作为数组传递:
{
"fields": {
"ManagerLookupId": 12
}
}
{
"fields": {
"ManagerLookupId": [10,11,12]
}
}
这很麻烦,无法从Microsoft Graph获取此SharePoint用户id
。显然,这使得创建/更新ListItem
确实具有挑战性。要解决此问题,您可以使用旧的SharePoint REST API's ensureUser
端点:
http://<sitecollection>/<site>/_api/web/ensureUser(logonName)
请记住,您还需要用于SharePoint的令牌来调用此API。如果您使用的是AAD v1端点,通常只需要使用此调用的SharePoint资源(https://{tenant}.sharepoint.com
)刷新令牌,然后刷新回Graph资源(https://graph.microsoft.com
)即可。你的其他电话。
答案 1 :(得分:0)
我的测试演示,“用户为人”字段允许多个用户。
{
"fields": {
"Title": "test",
"UserLookupId@odata.type": "Collection(Edm.Int32)",
"UserLookupId":[10,23]
}
}
一个用户。
{
"fields": {
"Title": "test",
"UserLookupId@odata.type": "Edm.Int32",
"UserLookupId":23
}
}