Do not use assert in production#80
Closed
yajo wants to merge 1 commit intosyrusakbary:masterfrom
yajo:patch-1
Closed
Do not use assert in production#80yajo wants to merge 1 commit intosyrusakbary:masterfrom yajo:patch-1
yajo wants to merge 1 commit intosyrusakbary:masterfrom
yajo:patch-1
Conversation
Instead, just do the check and `return False` if it fails.
yajo
added a commit
to Tecnativa/server-tools
that referenced
this pull request
May 17, 2018
…_validator
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
yajo
added a commit
to OCA/server-tools
that referenced
this pull request
Jun 13, 2018
…_validator (#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.
rafaelbn
approved these changes
Jun 13, 2018
yajo
added a commit
to Tecnativa/server-auth
that referenced
this pull request
Jun 19, 2018
…_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.
pedrobaeza
pushed a commit
to OCA/server-auth
that referenced
this pull request
Jun 20, 2018
…_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.
|
@yajo, you can close this as there's no answer and we have switch the library already. |
daramousk
pushed a commit
to daramousk/server-tools
that referenced
this pull request
Jul 16, 2018
…_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.
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
to OCA/server-auth
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.
|
@yajo can be this PR closed? |
|
Ping @syrusakbary |
Author
|
The PR is valid but yes, this project seems dead and we're not using it anymore. Closing. He can merge the patch manually if he wants. |
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.
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.
adhoc-cicd-bot
pushed a commit
to adhoc-cicd/oca-server-auth
that referenced
this pull request
Jan 16, 2025
…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.
adhoc-cicd-bot
pushed a commit
to adhoc-cicd/oca-server-auth
that referenced
this pull request
Jan 18, 2025
…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
Jan 29, 2025
…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, 2025
…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.
F4LC0NN
pushed a commit
to F4LC0NN/server-auth
that referenced
this pull request
Feb 25, 2026
…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.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Instead, just do the check and
return Falseif it fails.Possibly fixes #63
@Tecnativa