Iteration L2: Storing Support Requests from Our Mailbox

As we mentioned above, the purpose of mailboxes is to allow us to execute code on every email we receive. Because emails come in whenever the sender sends them, we’ll need to store the details of a customer support request somewhere for an administrator to handle later. To that end, we’ll create a new model called SupportRequest that will hold the relevant details of the request, and have the process method of SupportMailbox create an instance for each email we get (in the final section of this chapter we’ll display these in a UI so an admin can respond).

Creating a Model for Support Requests

We want our model to hold the sender’s email, the subject and body of the email, as well as a reference to the customer’s most recent order if there’s one on file. First, let’s create the model using a Rails generator:

This created a migration for us, which is currently empty (remember that migration filenames have a date and time in them, so your filename will be slightly different). Let’s fill that in.

With this in place, we can create this table via bin/rails db:migrate:

We’ll also need to adjust the model itself to optionally reference an order:

Now, we can create instances of SupportRequest from our mailbox.

Creating Support Requests from Our Mailbox

Our mailbox needs to do two things. First, it needs to create an instance of SupportRequest for each email that comes in. But, it also needs to connect that request to the user’s most recent order, if there is one in our database (this will allow our admin to quickly reference the order that might be causing trouble).

As you recall, all orders have an email associated with them. So, to get the most recent order for an email, we can use where to search all orders by email, order to order the results by the create data, and first to grab the most recent one. With that, we can use the methods on mail we saw earlier to create the SupportRequest.

Here’s the code we need in app/mailboxes/support_mailbox.rb (which replaces the calls to puts we added before):

Now, restart your server and navigate to the conductor at http://localhost:3000/rails/conductor/action_mailbox/inbound_emails. Click “Deliver new inbound email” and send another email (remember to send it to [email protected]).

Now, quit your server and start up the Rails console. This will allow us to check that a new SupportRequest was created (remember we have to format this to fit in the book, so your output will be on fewer, longer lines):

You should see the data you entered into the conductor saved in the SupportRequest instance. You can also try this using the email of an order you have in your system, to verify it locates the most recent order. Of course, manually checking our code isn’t ideal. We would like to have an automated test. Fortunately, Rails provides a simple way to test our mailboxes, which we will learn about now.

Testing Our Mailbox

When we used the generator to create our mailbox, you probably noticed the file test/mailboxes/support_mailbox_test.rb get created. This is where we’ll write our test. Since we generally know how to write tests, all we need to know now is how to trigger an email. Action Mailbox provides the method receive_inbound_email_from_mail which we can use in our tests to do just that.

We need two tests to cover the functionality of our mailbox. The first is to send an email from a customer without an order and verify we created a SupportRequest instance. The second is to send an email from a customer who does have orders and verify that the SupportRequest instance is correctly connected to their most recent order.

The first test is most straightforward since we don’t need any test setup, so we’ll create a new test block inside test/mailboxes/support_mailbox_test.rb, like so:

If we run this test now, it should pass:

Great! For the second test, we’ll need to create a few orders before we send the email. You’ll recall from ​Test Fixtures​, that we can use fixtures to set up test data in advance. We have one we can use already, but ideally we’d have a total of two orders for the user sending the email and a third order from another user. That would validate that we’re both searching for the right user and selecting the most recent order.

Let’s add two new fixtures to test/fixtures/orders.yml

Note how we’re using ERB inside our fixture. This code is executed when we request a fixture and we’re using it to force an older creation date for one of our orders. By default, Rails sets created_at on models it creates from fixtures to the current time. When we ask Rails to create that particular fixture with orders(:another_one), it will execute the code inside the <%= and %>, effectively setting the created_at value to the date as of two days ago.

With these fixtures available, we can write our second test, that looks like so:

Next, rerun the test and we should see our new test is passing:

Nice! We can now confidently write code to handle incoming emails and test it with an automated test. Now what do we do with these SupportRequest instances we’re creating? We’d like to allow an administrator to respond to them. We could do that with plain text, but let’s learn about another part of Rails called Action Text that will allow us to author rich text we can use to respond.