Feature/async email support

[bzhr]

This PR follows the guides from #11
Adds ASYNC_EMAIL_TASK setting to settings.

In mixins.py first, if ASYNC_EMAIL_TASK setting is defined and it's a string, will be imported in top.
Then before sending each email, first it's checked if the async function is defined and if it is, call the function with the email send function and it's arguments, else just send the email.

This is done for:

1. Send activation email
2. Resend Activation Email
3. Password reset
4. Secondary email activation

Right now when I run tests, there's no test case for async functions, so either a test case needs to be provided, or we need to add async email support in the example app.

@PedroBern please review and let me know what you think.

[PedroBern]

@PedroBern please review and let me know what you think.

It's all perfect!

Right now when I run tests, there's no test case for async functions, so either a test case needs to be provided, or we need to add async email support in the example app.

As it's actually a pseudo async support, we don't need to write an async test case. However, the testing will be not so trivial, we need to:

• Create a new file tests/pseudo_async_email_support.py with a regular function to be imported as the async function;
• Create tests/settings_c.py, just like the settings_b.py, but only with the new setting, importing the function created early;
• Edit tox.ini file, just copy and paste the py.test --ds=tests.settings_b ..., but for settings_c;
• Create one test for each of the supported functions, inside each respective file, these tests must mock the pseudo function, and check if it was called. If possible, check if it was called with the right arguments;
• Mark these new tests with the @mark.settings_c decorator;

Feel free to do what you judge the best, these steps were just what came into my mind about creating these tests.

It will simply test if the function was called. I guess we need only this, the async implementation can be handled outside of the package.

[PedroBern]

I've changed the base branch to merge this, I can create the tests :) I'm merging now

[PedroBern]

but I found some problems:

• In RegisterMixin, SendSecondaryEmailActivationMixin if the email is in use, it will still send a successful response.
• In ResendActivationEmailMixin if the user is already verified, it will still send a successful response.

The only way to fix it is by moving the logic of the exception out of the model, bringing it to the mixins. It will give a lot more work than expected. Not planning to work on this soon, because of it, I'm closing.

[PedroBern]

@bzhr this was released on v0.3.10 today :)

[bzhr]

@PedroBern Thanks for notifying me. I thought that you're cancelling the PR, but you were just cancelling the tests for now?

[PedroBern]

Yes, I made some changes (used a tuple as the second argument in all function calls and some adjustments on SendPasswordResetEmailMixin). Made the tests in the testproject, live testing.

The reason is that this pattern of many setting files is annoying me, I would like to use a @override_settings decorator to handle this but some months ago I wasn't successful (if you can please tell me how, something in the testing looks like making it not work), then I created the settings_b. I will see if I get back to it and try to make it work, lettings only the settings_b because it uses a different user model. However, if I can't, I will add tests as I said, with a settings_c.

[bzhr]

Awesome! I agree that creating multiple settings files isn't very efficient way to handle the settings/testing. This is ok for simple use cases, we can discuss how to further improve it.

[PedroBern]

Exactly. Thanks for your openness, any ideas feel free to tell me! I will have a look at this in the future when I have more time.