Open mailchecktool-admin opened 1 month ago
I checked the same behavior today and found that OWA is almost unable to retrieve images in the body text with getAttachmentsAsync. Even when they could be retrieved, it is only when sending from some drafts. We provide sample add-ins and manifests, so please follow the above method to verify.
I wondered if the “release-related settings” might have something to do with this issue. There seems to be a difference in behavior between users who have “targeted releases to specific users” from the M365 admin center and those who do not. Users with a targeted release are not able to get any inline images as attachment items (as far as we have confirmed today). Users who do not have a targeted release may or may not be able to retrieve them.
Did you add a fix in an early release program update that prevents getAttachmentsAsync from retrieving images within the body of the email? Or did you make any changes to the method in the standard release update?
Thank you for reporting the issue. This is something that falls under the product limitation currently and we are aware about it. We will inform about the planned actions on them.
@patilganesh-msft Thank you.
You mentioned, "We will inform about the planned actions on them." Could you let us know when and where we will be informed?
Since this also affects users, could you share any information available about the planned specifications?
(As confirmed in the early release, will the specification be such that inline images are not included in the return value of getAttachmentsAsync?)
We do have plans for stabilizing and minimizing some of the parity with classic Outlook for attachments.
@patilganesh-msft Why did you close the ticket unilaterally? I don’t fully understand your explanation.
If there are going to be changes to the specifications, I’d like to request that the details be shared somewhere. Otherwise, both users and developers offering add-ins will be confused.
Let me ask once again: Will what is currently being rolled out to early release users also be expanded to the standard release? And will this become the new standard going forward?
Hi @mailchecktool-admin,
Apologies for lack of clarity. Re-opening the issue till we work on the issue as per planning of attachments improvement work for next couple of months. While we are not sure about the exact timeline for the issue. Internal tracking ID: 5085905
@mailchecktool-admin Have you tried calling saveAsync() on the message item before getAttachmentsAsync()? Just tried a bit, on my side this gives matching file name with image tag's cid in Windows Outlook client.
@chi-mf Are you saying that calling saveAsync() also retrieved the images in the body of the email? I've tried that but it doesn't work. Can you tell me exactly how to do this?
I mean call saveAsync, then call getAttachmentsCallback, i.e.
Office.context.mailbox.item.saveAsync
(
...,
function ()
{
Office.context.mailbox.item.getAttachmentsAsync
(
...,
function (asyncResult)
{
// here you can see inline attachments in asyncResult.value[i] named like image001.png
Office.context.mailbox.item.body.getAsync
(
...,
function (asyncResult2)
{
// here you can see asyncResult.value contains <img src="cid:image001.png@...
}
)
}
)
}
)
@chi-mf I described it as you sent it, but could not get an inline image. You mentioned that you tried with a Windows Outlook client, can you get the same with OWA or the newer Outlook?
Provide required information needed to triage your issue
Your Environment
Summary
The value of attachments that can be retrieved with getAttachmentsAsync in OWA, desktop version of Outlook, and the new Outlook is unstable. When inserting an image in the body of a mail and retrieving attachment information with Office.context.mailbox.item.getAttachmentsAsync(), the attachment information may or may not be retrieved as a value. This occurs when composing a new email, sending an email from a draft, or replying/forwarding an email, and is reproduced in Outlookontheweb, new Outlook and Outlook clients.
In addition, the value of mail body information that can be obtained with getAsync is unstable. If you insert an image into the body of a mail and use Office.context.mailbox.item.body.getAsync() to retrieve the mail body information, the value retrieved for an inline image is <img id=“image_0” originalsrc=“cid:f271504e-98a8-4efd-b419-XXXXXX” size=” 145823“ contenttype=”image/png“ style=”max-width: 835px;">and <img src= “https://attachments.office.net/owa/XXXXXXXXanimation=true” id="image_0” originalsrc=“cid:2eae5236-1101-4cf8-bb28-XXXXXX” size=“145823” contenttype="image/ png“ style=”max-width: 402px; max-height: 297px;"> and the src may or may not be retrieved. Specifically, this occurs when creating a new email, sending an email from a draft, even when replying/forwarding, and is reproduced in Outlookontheweb and in the new Outlook.
We have also confirmed that there are differences between users.
In addition, the Outlook client can use the The attachment name in the value that can be retrieved with Office.context.mailbox.item.getAttachmentsAsync() has changed. When composing a new mail or a mail from a draft, inserting an image in the body of the mail and checking it, the attached file name is changed to “image001.png” or “Outlook-0000.png”.
Have these problems been reported? I'm having trouble separating the cases when inline images are inserted in the body text, because the movement is unstable.
Steps to reproduce
The console displays the attachment information obtained by getAttachmentsAsync and the body information obtained by getAsync(). Confirm that the image information in the body of the e-mail is not output in the attachment information displayed in the console. Also check that the information of images inserted in the body of the mail (mail body information) is also unstable.
Link to live example(s)
I am storing the sample add-in.