[REF] auth_signup_verify_email: Skip mail send in tests and use email_validator #29
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…_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.
|
Travis is red |
pedrobaeza
approved these changes
Jun 20, 2018
SalahAdDin
pushed a commit
to SalahAdDin/server-auth
that referenced
this pull request
Jan 10, 2019
…_validator (OCA#29) 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.
Tardo
pushed a commit
to Tecnativa/server-auth
that referenced
this pull request
Jun 4, 2019
…_validator (OCA#29) 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.
OCA-git-bot
pushed a commit
that referenced
this pull request
Jul 8, 2019
…_validator (#29) 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.
Tardo
pushed a commit
to Tecnativa/server-auth
that referenced
this pull request
Aug 14, 2019
…_validator (OCA#29) 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.
pedrobaeza
pushed a commit
to Tecnativa/server-auth
that referenced
this pull request
Aug 21, 2019
…ts and use email_validator (OCA#29) 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.
em230418
pushed a commit
to em230418/server-auth
that referenced
this pull request
May 15, 2020
…ts and use email_validator (OCA#29) 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.
em230418
pushed a commit
to em230418/server-auth
that referenced
this pull request
May 15, 2020
…ts and use email_validator (OCA#29) 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.
em230418
pushed a commit
to em230418/server-auth
that referenced
this pull request
Apr 29, 2021
…ts and use email_validator (OCA#29) 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.
em230418
pushed a commit
to em230418/server-auth
that referenced
this pull request
Oct 6, 2021
…ts and use email_validator (OCA#29) 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.
pedrobaeza
pushed a commit
to em230418/server-auth
that referenced
this pull request
Jan 21, 2022
…ts and use email_validator (OCA#29) 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.
em230418
pushed a commit
to em230418/server-auth
that referenced
this pull request
Mar 30, 2022
…ts and use email_validator (OCA#29) 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.
nicomacr
pushed a commit
to adhoc-dev/server-auth
that referenced
this pull request
Oct 5, 2022
…ts and use email_validator (OCA#29) 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.
nicomacr
pushed a commit
to adhoc-dev/server-auth
that referenced
this pull request
Nov 3, 2022
…ts and use email_validator (OCA#29) 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.
nicomacr
pushed a commit
to adhoc-dev/server-auth
that referenced
this pull request
Nov 3, 2022
…ts and use email_validator (OCA#29) 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.
bruno-zanotti
pushed a commit
to adhoc-dev/server-auth
that referenced
this pull request
Nov 25, 2022
…ts and use email_validator (OCA#29) 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.
bruno-zanotti
pushed a commit
to adhoc-dev/server-auth
that referenced
this pull request
Nov 29, 2022
…ts and use email_validator (OCA#29) 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.
bruno-zanotti
pushed a commit
to adhoc-dev/server-auth
that referenced
this pull request
Mar 28, 2023
…ts and use email_validator (OCA#29) 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.
bruno-zanotti
pushed a commit
to adhoc-dev/server-auth
that referenced
this pull request
Jun 13, 2023
…ts and use email_validator (OCA#29) 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.
augusto-weiss
pushed a commit
to adhoc-dev/server-auth
that referenced
this pull request
Dec 18, 2023
…ts and use email_validator (OCA#29) 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.
pedrobaeza
pushed a commit
to Tecnativa/server-auth
that referenced
this pull request
Aug 23, 2024
…ts and use email_validator (OCA#29) 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.
JrAdhoc
pushed a commit
to adhoc-dev/server-auth
that referenced
this pull request
Nov 14, 2024
…ts and use email_validator (OCA#29) 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.
SiesslPhillip
pushed a commit
to grueneerde/OCA-server-auth
that referenced
this pull request
Nov 20, 2024
Syncing from upstream OCA/server-auth (12.0)
anikeenko-viktor
pushed a commit
to avoinsystems/server-auth
that referenced
this pull request
Dec 16, 2024
…ts and use email_validator (OCA#29) 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Forward-port of OCA/server-tools#1247.
This addon introduced an integration conflict when tested in a database that had
mail_tracking_mass_mailinginstalled, producing this failure:Which in turn produced the following in the next test:
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
TestCursorfollow.To avoid that, tests now mock the
send_mailmethod. This results also in having a predictable outcome from the testtest_good_email, so it is more meaningful now.Besides, previously we were using the
validate_emailpackage, which is currently a dead project that can silently fail under certain environments, as seen in syrusakbary/validate_email#80.There's the
email_validatorpackage, 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.
@Tecnativa