You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 4, 2019. It is now read-only.
Supporting attachments in this way would be beneficial because it would allow webworks apps to append attachments to emails without requiring 'Shared File' permissions (currently the invoke card for email requires a path to the shared directory for attachments; private app storage cannot be used).
The text was updated successfully, but these errors were encountered:
Just checking: in the end this just added the ability to specify attachments by path right? I think this was previously supported by blackberry.invoke.card.invokeEmailComposer without the plugin. This original bug was about being able to supply an attachment as a stream of data instead of a path to a file. This would permit attachments to be generated by apps and attached without requiring the access_shared permission to be set.
Weird, for some reason I thought that had been included already. This does allow files to be included from the App's private filesystem, so it does bypass the need to use the shared folder. I'll reopen it though so that we can add the byte array feature.
Thanks Tim. Since it is already using MessageBuilder under the covers, I think it would just be a 30 minute fix to allow a var to be passed containing what would be the contents of a text file or the base64 of an image.
MessageBuilder can also take Attachment(s) that can be constructed from strings (or byte arrays):
https://developer.blackberry.com/native/reference/cascades/bb__pim__message__attachment.html#function-attachment-mimetype-name-textdata
Supporting attachments in this way would be beneficial because it would allow webworks apps to append attachments to emails without requiring 'Shared File' permissions (currently the invoke card for email requires a path to the shared directory for attachments; private app storage cannot be used).
The text was updated successfully, but these errors were encountered: