…_validator (OCA/server-tools#1247)

This addon introduced an integration conflict when tested in a database that had `mail_tracking_mass_mailing` installed, producing this failure:

    Traceback (most recent call last):
    File "/opt/odoo/auto/addons/auth_signup_verify_email/controllers/main.py", line 44, in passwordless_signup
        sudo_users.reset_password(values.get("login"))
    File "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
        self.gen.next()
    File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 419, in savepoint
        self.execute('RELEASE SAVEPOINT "%s"' % name)
    File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 154, in wrapper
        return f(self, *args, **kwargs)
    File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 231, in execute
        res = self._obj.execute(query, params)
    InternalError: no such savepoint

Which in turn produced the following in the next test:

    InternalError: current transaction is aborted, commands ignored until end of transaction block

The problem comes from the fact that one cannot rollback to a nested savepoint if the parent savepoint was released. It became a problem because that's the strategy that both this addon and upstream's `TestCursor` follow.

To avoid that, tests now mock the `send_mail` method. This results also in having a predictable outcome from the test `test_good_email`, so it is more meaningful now.

Besides, previously we were using the `validate_email` package, which is currently a dead project that can silently fail under certain environments, as seen in syrusakbary/validate_email#80.

There's the `email_validator` package, freely available, supported, and it provides a human-readable error message whenever some format from the email fails.

As such, here I'm switching the dependency, while still adding a backwards compatibility layer for preexisting installations.

…e email_validator (OCA/server-tools#1247)

…_validator (OCA#1247)

This addon introduced an integration conflict when tested in a database that had `mail_tracking_mass_mailing` installed, producing this failure:

    Traceback (most recent call last):
    File "/opt/odoo/auto/addons/auth_signup_verify_email/controllers/main.py", line 44, in passwordless_signup
        sudo_users.reset_password(values.get("login"))
    File "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
        self.gen.next()
    File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 419, in savepoint
        self.execute('RELEASE SAVEPOINT "%s"' % name)
    File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 154, in wrapper
        return f(self, *args, **kwargs)
    File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 231, in execute
        res = self._obj.execute(query, params)
    InternalError: no such savepoint

Which in turn produced the following in the next test:

    InternalError: current transaction is aborted, commands ignored until end of transaction block

The problem comes from the fact that one cannot rollback to a nested savepoint if the parent savepoint was released. It became a problem because that's the strategy that both this addon and upstream's `TestCursor` follow.

To avoid that, tests now mock the `send_mail` method. This results also in having a predictable outcome from the test `test_good_email`, so it is more meaningful now.

Besides, previously we were using the `validate_email` package, which is currently a dead project that can silently fail under certain environments, as seen in syrusakbary/validate_email#80.

There's the `email_validator` package, freely available, supported, and it provides a human-readable error message whenever some format from the email fails.

As such, here I'm switching the dependency, while still adding a backwards compatibility layer for preexisting installations.

Syncing from upstream OCA/server-tools (16.0)