How to send mails for any business scenario without coding

A few weeks ago, the eXpandFramework released registration support as discussed in How to manage users (register a new user, restore a password, etc.) from the logon form. While users could register, the implementation process was still incomplete it was missing email notification. Thus, this post will discuss the new EmailModule which was made available beginning version 13.1.8.2.

The module was designed following the workflow discussed in Declarative data auditing. In this post I will demonstrate how to install the module along with the registration functionality discussed in How to manage users (register a new user, restore a password, etc.) from the logon form in order to create three mail rules (

1) When new user is registered.
2) When the password is forgotten.
3) When a new customer is created.

In addition I will discuss how to restrict the EmailModue to sending emails only when a specific user role is logged in.

1) Installation

To complete installation, drag & drop the EmailModule from the toolbox into the module designer.

2) Enabling Registration

To use the registration process, the XpandSecurityWinModule & XpandSecurityWebModule must be installed just as we did with the EmailModule in step 1. Drag & drop these two modules from the toolbox into the module desinger. In addition, use the XpandLogonParemeters as the LogonParametersType of our authentication as illustrated in the following image.

The final step is to configure the model as shown below.

When the application starts, the logon form will have two extra actions. See below.

When the end user executes the top action, the XpandSecurity module will create a new view from the non-persistent RegisterUserParameters class.

Let’s stop here and configure the rule that will actually send an email..

4) Sending an email when a user is registered

The EmailModule will extend the Application model with an extra node

The first step towards sending an email is to setup the SmtpClient. See below.

Next we need to create an EmailContext that will instruct the EmailModule on how to locate the email template used for this type of notification.

Now it’s time to create the actual EmailTemplate. The EmailModule uses the Razor engine and provides an EmailTemplate persistent object for this. Thus, the code snippet inside a ModuleUpdater bellow can do the job!

And of course, XAF can do its usual magic in terms of the UI, allowing the end user to fully design the template at runtime in both windows and web!

The next stop is to create the rule that will send an email based on the template created when a new user registers. This is illustrated below.

and the mail is send!

5) Sending an email for a forgotten password

As you might have guessed, the process is awfully similar here. We create a different EmailTemplate persistent object for this type of a notification and then create a new model EmailTemplateContent.

Then we form a rule, which instead of using the RegisterUserParameters class will use the RestorePasswordParameter and the “pass forgotten Template” context.

6) Sending an email to all admins when a new customer is created

The procedure is pretty similar to the steps in the previous section. The difference is that in this case we will not set the CurrentObjectEmailMember attribute, since we want to send the email to all the admins and not to the customer. This is why we will need to create an EmailRecipient context as the image below illustrates.

After, we must create the actual rule where we will set the EmailReceipientContext attribute..

7) Sending emails only when a specific user role is logged in

If you already read the Declarative data auditing post you probably know that all modules that use the Logic module can create rules using three different ways.Code Attributes decorating a class, using the Application Model or using permissions as you see bellow.

 

Note that the above layout is inherited from the Logic module using the technique discussed in the Model View inheritance version post.

An alternative approach is to use the Model Application modifications discussed in this post and using the ModelDifference module apply them to a Role Model and assign that model to the roles you want. For more information on this approach, see Changing your web Model at runtime with Model Editor and no IIS reset.

Feel free to explore what I discussed in this post in the eXpand source code under Demos/Modules/Email/EmailTester.sln

As always feel free to use the eXpand forums for your feedback and questions.

Happy XAF’ing to all!