Outlook mail send with attachments

[bacca87]

Hi all, is it possible to send an email with attachments using the CLI?

Thank you

[martinlingstuyl]

Hi @bacca87, unfortunately that is not supported. If you'd like you could contribute to the CLI by adding the command 🤗

[milanholemans]

I'm willing to see if we can add this. My suggestion is to add the following option:

Option	Description
--attachments [attachments]	Comma separated list of file paths. These files will be added to the email.

However if we use a comma as separator, file names containing a comma will break everything. Is there a better solution for this?

[martinlingstuyl]

Yea, that might be problematic. But maybe it's okay to just accept that risk.

[bacca87]

paths with comma can be escaped just surrounding it with double quotes:

--attachments "/test/name,1.txt", "/test/name,2.txt"

[milanholemans]

paths with comma can be escaped just surrounding it with double quotes:

--attachments "/test/name,1.txt", "/test/name,2.txt"

As you can see in the 2nd example https://pnp.github.io/cli-microsoft365/cmd/outlook/mail/mail-send/#examples, comma separated lists should be surrounded by quotes, so your example won't work because it will be seen as 2 different arguments.

[martinlingstuyl]

Let's just add a note to the docs. This sounds like an edge case to me.

[waldekmastykarz]

@milanholemans would it make sense to use ; as a separator instead which I believe isn't allowed in the file name?

[milanholemans]

@milanholemans would it make sense to use ; as a separator instead which I believe isn't allowed in the file name?

Unfortunately ; is a valid character in a file name. Besides that, if I'm not mistaken, Linux OS only has one illegal file name character being /.

[milanholemans]

Noticed that --bodyContents option is required, while in code this is declared as nullable.

Here it's declared as nullable https://github.com/pnp/cli-microsoft365/blob/6fb46e09a6d394148d1c2a9b6802b5749ad39b1e/src/m365/outlook/commands/mail/mail-send.ts#L17

It is included in the telemetry https://github.com/pnp/cli-microsoft365/blob/6fb46e09a6d394148d1c2a9b6802b5749ad39b1e/src/m365/outlook/commands/mail/mail-send.ts#L37

Since it's not nullable, this cast is not needed anymore https://github.com/pnp/cli-microsoft365/blob/6fb46e09a6d394148d1c2a9b6802b5749ad39b1e/src/m365/outlook/commands/mail/mail-send.ts#L44

Is this something I can fix right away with this issue, or should I create a new issue for this one?

[martinlingstuyl]

That's fine by me. 👍 Do change it. It's a small detail.

[waldekmastykarz]

Seems like ; is allowed in Windows too. Another way that seems supported by minimist (the package that we use to parse args), is to use the same option multiple times, eg.:

m365 outlook mail send --attachment file1 --attachment file2

That way we don't need to file with reinventing separating multiple values. We'd only need to verify that our code properly supports array. If this works, then I'd propose, that we use this pattern throughout the CLI for consistency. We can take it in a separate issue.

[milanholemans]

Seems like ; is allowed in Windows too. Another way that seems supported by minimist (the package that we use to parse args), is to use the same option multiple times, eg.:

m365 outlook mail send --attachment file1 --attachment file2

That way we don't need to file with reinventing separating multiple values. We'd only need to verify that our code properly supports array. If this works, then I'd propose, that we use this pattern throughout the CLI for consistency. We can take it in a separate issue.

That would be a nice solution!

[waldekmastykarz]

Let's test it and see if it works as intended. Want to give it a try @milanholemans?

[milanholemans]

Let's test it and see if it works as intended. Want to give it a try @milanholemans?

Sure!

[martinlingstuyl]

Another way that seems supported by minimist (the package that we use to parse args), is to use the same option multiple times, eg.:

That looks nice! I think we'll have to update the completion functionality as well though. This will probably not autocomplete the argument when it's already in use.

[waldekmastykarz]

Completion functionality is a part of the shell so there's nothing we can do about it, unfortunately.

[milanholemans]

Seems like ; is allowed in Windows too. Another way that seems supported by minimist (the package that we use to parse args), is to use the same option multiple times, eg.:

m365 outlook mail send --attachment file1 --attachment file2

That way we don't need to file with reinventing separating multiple values. We'd only need to verify that our code properly supports array. If this works, then I'd propose, that we use this pattern throughout the CLI for consistency. We can take it in a separate issue.

This thing seems to work. When I define multiple options, they are combined as an array. So seems perfect for this command.

I am working on implementing the logic right now to send mails with attachments. I'm currently running into some problems with attachments above 3MB. I think I will have to do some more R&D & trial and error for this to work. Is it ok if I currently provide attachments up to 3MB in this PR? Then we can expand this even further to larger files when I get it to work.

[martinlingstuyl]

That would be OK, @milanholemans, we can expand on existing functionality if people request it. Also: sending attachments in emails is always subject to size limitations, so it's okay if it's the same for the CLI.

It would be nice if you'd find the precise byte limit so it can be linked to in the docs though.