class PersonController {
- class PersonController {
- |
-
+ mailService.sendMail {
+ from 'admin@mysystem.com'
+ subject 'New user'
+ text 'A new user has been created'
+ }
+ }
+}
+
+
+
+
+The
+
+The DSL provides
+
+
+
+
+
+All methods take one or more String values that are email addresses using the syntax
+of http://www.ietf.org/rfc/rfc822.txt.[RFC822]. Typical address syntax is of the form
+
+You can supply multiple values for
+
+
+
+
+
+If no value is provided for
+
+
+
+3.1. Sender+
+
+The sender address of the email is configured with the
+
+
+
+
+
+The
+
+If no value is provided for
+
+Message content is specified by either the
+
+
+
+
+
+<%@ page contentType="text/html" %>+
+
+3.2. HTML Email+
+
+To send HTML email you can use the
+
+You can either supply a string value: +
+
+
+
+
+
+Or a view to render to form the content: +
+
+
+
+
+
+See the section on using views for more details of the parameters to this version of
+
+3.3. Text Email (plain-text)+
+
+To send plain-text email you can use the
+
+You can either supply a String value: +
+
+
+
+
+
+Or a view to render to form the content: +
+
+
+
+
+
+See the section on using views for more details of the parameters to this version of
+
+3.4. Text and HTML+
+
+It is possible to send a multipart message that contains both plain-text and HTML versions of the message. In this +situation, the email-reading client is responsible for selecting the variant to display to the user. +
+
+To do this, simply use both the
+
+
+
+
+
+3.5. Using Views+
+
+Both the
+
+
+
+The Mail Plugin is capable of adding attachments to messages as independent files and inline resources. +To enable attachment support, you MUST indicate that the message is to be multipart as the first thing you do in +the mail DSL. +
+
+
+
+
+
+3.6. File Attachments+
+
+The term file attachments here, refers to the attachment being received as a file, not necessarily using a file in your +application to form the attachment. +
+
+The following methods are available in the mail DSL to attach files: +
+
+
+
+
+
+There are 3 things that need to be provided when creating a file attachment: +
+
+
+
+The Mail Plugin supports using either a
+
+In the case of the variants that take a
+
+In the case of the variants that take a
+
+
+
+
+ 3.7. Inline Attachments+
+
+It is also possible to attach content as inline resources. This is particularly useful in the case of html email where +you wish to embed images in the message. In this case you specify a content id instead of a file name for the attachment +and then reference this content id in your mail message. +
+
+To attach an image as an inline resource you could do: +
+
+
+
+
+
+Then in your view you reference the inline attachment using the
+
+
+
+
+
+The following methods are available in the mail DSL to inline-attach files: +
+
+
- |
-
-
-
-
- Quick Reference
- (hide)
-
-
- |
-
There are 3 things that need to be provided when creating an inline attachment:
+content id - the identifier of the resource
+content type - what mime type the email client will treat the content as
+content source - the actual content
+The Mail Plugin supports using either a byte[], File, or InputStreamSource as the content source.
In the case of the variants that take a File that do not specify a content id, the name of the file will be used.
In the case of the variants that take a File that do not specify a content type, the content type will be guessed based on the file extension.
Typically, you don’t want to actually send email as part of your automated tests. Besides wrapping all calls to sendMail
+in an environment sensitive guard (which is a very bad idea), you can use one of the following techniques to deal with this.
You can effectively disable email sending globally in your test by setting the following value in your application for +the test environment.
+grails.mail.disabled = trueThis will effectively cause all calls to sendMail() to be a non-operation, with a warning being logged that mail is
+disabled. The advantage of this technique is that it is cheap. The disadvantage is that it makes it impossible to test
+that email would be sent and to inspect any aspects of the sent mail.
You can override any and all recipient email addresses in sendMail() calls to force messages to be delivered to a
+certain mailbox.
grails.mail.overrideAddress = 'test@myorg.com'All to, cc and bcc addresses will be replaced by this value if set. The advantage of this mechanism is that it
+allows you to test using a real SMTP server. The disadvantage is that it requires a real SMTP server and makes it
+difficult to test address determination logic.
The preferred approach is to use the existing Grails Greenmail plugin to run an +in-memory SMTP server inside your application. This allows you to fully exercise your email sending code and to inspect +sent email to assert correct values for recipient addresses etc.
+The advantage of this approach is that it is as close as possible to real world and gives you access to the sent email +in your tests. The disadvantage is that it is another dependency.
+Consult the documentation for the plugin for more information.
+