About the portal email APIs
The body of custom portal email messages can be composed of plain text, HTML, or a field display format. The messages are sent from the portals using server-side layout script containing one of these APIs: SendEmailAsPlainText, SendEmailAsHtml, or SendEmailAsFieldDisplayFormat. The plain text and HTML APIs use hard-coded strings for the email messages. The field display format API creates the email messages using content generated by the portal.
For each API, a subject, list of recipients, carbon-copied recipients, blind-carbon-copied recipients, and attachments can be specified. The sender is the portal email user specified on the Portal Parameters form.
SendEmailAsPlainText API
This method has these signatures:
- void SendEmailAsPlainText(IEnumerable<string> to, string subject, string body, IPFDocumentCollectionI attachments, string from = null)
- void SendEmailAsPlainText(IEnumerable<string> to, IEnumerable<string> cc, IEnumerable<string> bcc, string subject, string body, IPFDocumentCollectionI attachments, string from = null)
The body parameter determines the plain-text message body of the email message. If this string is null or empty, the message has an empty body.
Sample code:
context.SendEmailAsPlainText(New String() {"to@address.com"},
"Subject", "plain-text", Nothing)
SendEmailAsHtml API
This method has these signatures:
- SendEmailAsHTML(IEnumerable<string> to, string subject, string html, IPFDocumentCollectionI attachments, string from = null)
- SendEmailAsHTML(IEnumerable<string> to, IEnumerable<string> cc, IEnumerable<string> bcc, string subject, string html, IPFDocumentCollectionI attachments, string from = null)
The HTML parameter acts exactly like the body parameter in the SendEmailAsPlainText API, except that this string is interpreted as HTML rather than plain text.
There are some differences in how email clients interpret HTML, but all standard elements are supported.
Sample code:
context.SendEmailAsHTML(New String() {"to@address.com"}, "Subject",
"<p>HTML-Content</p>", Nothing, Nothing)
SendEmailAsFieldDisplayFormat API
This method has these signatures:
- SendEmailAsFieldDisplayFormat(IEnumerable<string> to, string subject, string fieldDisplayFormatName, IPFFilterI filter, IPFDocumentCollectionI attachments, string from = null)
- SendEmailAsFieldDisplayFormat(IEnumerable<string> to, IEnumerable<string> cc, IEnumerable<string> bcc, string subject, string fieldDisplayFormatName, IPFFilterI filter, IPFDocumentCollectionI attachments, string from = null)
Instead of requiring a string to use as the body of the message, this method takes the name of a field display format. The FDF is rendered in memory, and the resulting HTML is used as the body of the email message.
If the FieldDisplayFormatName parameter is null, empty, or does not refer to an existing FDF, then this API throws an exception.
Any issue encountered during the rendering of the FDF is treated just as if rendering took place in a browser. For example, diagnostic messages are thrown and IPFDefault is used as a fallback where required. These issues do not cause the API to throw an exception; they simply influence the appearance of the rendered FDF, just as they would in a browser.
These signatures can also be given a filter for use during the rendering of the FDF. If the FDF is collection-based, then this filter is passed to the initial FilterChanged event. Otherwise, the filter is ignored. Also if the filter is null or empty, it is ignored.
Sample code:
context.SendEmailAsFieldDisplayFormat(New String()
{"to@address.com"}, "Subject", "FDF-Name", Nothing, Nothing,
"from@address.com")
SendEmailAsFieldDisplayFormat formatter restrictions
These IPF formatters are not supported or not fully supported by email rendering for the SendEmailAsFieldDisplayFormat API:
- IPFVideo / IPFAudio: Video and audio are not supported in email. Both HTML 5 rendering and third-party plugins, for example, QuickTime and Flash, are not supported in email clients.
- IPFGauge: This formatter is rendered with FusionCharts. Neither rendering mode of Fusion, Flash or JavaScript, is supported by email clients.
- IPFChart: Only charts rendered using Microsoft Chart Controls are supported by email clients. Fusion is not supported.
- IPFDocument / SLDocument / ISMDocument: These formatters can be rendered only if they are set to download mode, rather than upload mode. Resources are not downloaded immediately when clicked. Instead, a browser opens and requires the user to log in. Once logged in, the user is redirected to the resource.
- IPFEmbeddedDoc: This formatter is not supported, as email clients do not support the PDF plugin.
- IPFGoogleMap / IPFWebPage: These formatters are not supported, as many email clients do not support the rendering of iFrames in an email.
- IPFText / IPFDecimal / SLDecimal / ISMDecimal / IPFDate / IPFDropdown: These formatters are only supported when they are not enabled.
- IPFHelp / IPFPrintPage / IPFToggler / IPFToggleAdmin: These formatters are not supported in email, as they require JavaScript to function, and JavaScript is not supported in email clients.
SendEmailAsFieldDisplayFormat style restrictions
Not all IPF styles are supported when rendering to an email using the SendEmailAsFieldDisplayFormat API. This table shows styles that are not supported in certain email clients:
Style | Not supported in |
---|---|
ipf-bullet | Outlook |
ipf-backgroundattachment | Outlook |
ipf-backgroundgradient | Outlook |
ipf-backgroundimage | Outlook |
ipf-backgroundposition | Outlook |
ipf-backgroundrepeat | Outlook |
ipf-backgroundsize | Outlook, Android Mail, Gmail |
ipf-borderbottomleftradius | Outlook, Android Mail |
ipf-borderbottomrightradius | Outlook, Android Mail |
ipf-borderradius | Outlook, Android Mail |
ipf-bordertopleftradius | Outlook, Android Mail |
ipf-bordertoprightradius | Outlook, Android Mail |
ipf-boxshadow | Outlook, Gmail |
ipf-draggable | All known email clients |
ipf-expandcontentwidth | Outlook, Gmail |
ipf-height | Outlook, Android Mail, Gmail |
ipf-horizontalalign-center | Outlook, Gmail |
ipf-horizontalalign-left | Outlook, Gmail |
ipf-horizontalalign-right | Outlook, Gmail |
ipf-horizontalseparator | Outlook, Gmail, iPhone Mail |
ipf-imagefilltype | Outlook |
ipf-opacity | Outlook, Gmail |
ipf-overflow | Outlook, Android Mail, Gmail |
ipf-padding | Outlook |
ipf-paddingbottom | Outlook |
ipf-paddingleft | Outlook |
ipf-paddingright | Outlook |
ipf-paddingtop | Outlook |
ipf-textshadow | Outlook, Gmail |
ipf-required | Outlook, Gmail, iPhone Mail |
ipf-separator | Outlook, Gmail, iPhone Mail |
ipf-transform-rotate | All known email clients |
ipf-transform-scale | All known email clients |
ipf-transform-translate | All known email clients |
ipf-verticalalign-bottom | Outlook, Gmail |
ipf-verticalalign-middle | Outlook, Gmail |
ipf-verticalalign-top | Outlook, Gmail |
ipf-verticalseparator | Outlook, Gmail, iPhone Mail |
ipf-width | Outlook, Android Mail, Gmail |
ipf-wordspacing | Outlook |
SendEmailAsFieldDisplayFormat scripting restrictions
Only server-side events that are processed on the initial rendering of a field display format are run when rendering for an email message. This includes ScriptInitializing, LayoutInitialized, ItemLoaded, and CollectionLoaded.
It is possible to navigate to a web address by clicking a component of an email FDF, but because scripting does not run, you must use the NavigateToURLOnClick API to set the link's location.