文件附件在Microsoft Graph API中显示为消息实体 [英] File attachments showing as message entities in Microsoft Graph API

问题描述

最近，我们注意到Microsoft Graph API已经将文件附件作为从/me/messages端点返回的消息实体返回.

Recently we've noticed that the Microsoft Graph API has been returning file attachments as message entities returned from the /me/messages endpoint.

要重现的场景如下:

• 向您发送包含一个或多个文件附件的电子邮件(或让其他人向您发送电子邮件)
• 在Graph Explorer中运行以下查询: https://graph.microsoft.com/v1.0/me /messages
• 请注意，将有一个对象代表电子邮件本身(这是正确的行为)，还有一个或多个对象代表文件附件.

还值得注意的是，这些附件消息"与原始电子邮件具有相同的主题，正文内容设置为附件的文件内容(如果附件是文档)，则没有发件人或收件人，它们的isRead状态为true，isDraft状态为true.废话！

It's also worth noting that these attachment "messages" have the same subject as the original email, the body content is set to the file content of the attachment (if the attachment is a document), there are no senders or recipients, they have an isRead status of true, and an isDraft status of true. Utter nonsense!

我只能假设这是Graph API中的错误-我看不出有什么理由会在设计上发生这种情况.还值得注意的是，我已经使用Graph API大约9个月了，而且这种行为只是最近才开始发生.

I can only assume this is a bug in the Graph API - I can't see any reason why this would happen by design. It's also worth noting that I've been working with the Graph API for around 9 months and this behaviour has only recently started happening.

Microsoft有人可以尽快对此进行联系吗?这是API中的主要错误，无疑会破坏使用该API的大多数应用程序.同样令人担忧的是，在我们下面更改了据称稳定的v1.0.为什么不为下一版本使用v1.1或v2.0?

Could someone from Microsoft please get in touch regarding this as soon as possible? This is a major bug in the API which will undoubtedly break most applications using it. It's also a great concern that a supposedly stable v1.0 is being changed underneath us. Why not use v1.1 or v2.0 for the next release?

推荐答案

感谢您的举报！如果通过/me/messages端点检索消息，我也会看到这种行为.如果通过/me/mailfolders/inbox/messages检索，则不会.这实际上是一个重要的线索.

thanks for reporting! I see this behavior as well if I retrieve messages via the /me/messages endpoint. If I retrieve via /me/mailfolders/inbox/messages, I do not. This is actually an important clue.

我查看了消息的parentFolderId.对于正确"的那个，它是收件箱的ID.另一方面，事实并非如此.无论它是什么ID，我都无法通过API检索(得到404).因此，很可能这是一个隐藏的文件夹.

I looked at the parentFolderId of the messages. For the one that is "right", it was the ID of the Inbox. For the other, it was not. Whatever ID it is, I can't retrieve it via the API (I get a 404). So it's likely this is a hidden folder.

使用ID，我能够转换为MAPI ID，并使用 MFCMapi 打开它.原来是文件文件夹.因此，我认为这里的错误是/me/messages返回结果时不应包含 Files 文件夹.我将在我们的开发团队中记录一个错误.

Playing with the IDs, I was able to convert to a MAPI ID and open it with MFCMapi. It turns out it's the Files folder. So I think the bug here is that /me/messages should not include the Files folder when returning results. I'll log a bug with our development team.

这篇关于文件附件在Microsoft Graph API中显示为消息实体的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！