Odoo Changelog — 2024-05-08

Wednesday, May 8, 2024

2 changes · 17.0

Improvements(2)

Enhancements to existing features

[IMP] base, mail, tests: set no_reset_password=true by default in tests

Core17.0basemailaccountauth_signupcalendargamificationhr_recruitmentmass_mailingmrp_landed_costsmrp_subcontractingportalprojectpurchase_requisitionwebsitewebsite_crm_partner_assign

Odoo’s automated test environment now suppresses password reset emails by default unless a test explicitly needs them. This reduces noisy test logs and avoids unnecessary email-preparation work, making test runs cleaner with minimal impact on real users.

Original PR description

There is a lot of reset password mails sent in our testing suite which are not needed and not wanted, ~1000. The goal is to force the already existing context key `no_reset_password` to `True` by…

There is a lot of reset password mails sent in our testing suite which
are not needed and not wanted, ~1000.

The goal is to force the already existing context key
`no_reset_password` to `True` by default when inside the testing suite.

Note that maybe some other context keys could be nice to have by
default, but this one is quite obvious and chosen as the first way to
go.

Also note that the gain time on runbot is probably very tiny if any, but
it's still the way to go: let's avoid entering the email sending code
stack even if the mails are not really sent in test mode, there is still
some processing time when preparing the mail.

Here are some stats, note that the "after" columns is considering the
next few small fix commits.
You can grep in the test logs with `Password reset email sent for user`

**Community**

| build | before | after |
| - | - | - |
| All at_install | 287 | 9 |
| post_install from account to auth_signup | 2 | 0 |
| post_install from auth_totp to microsoft_outlook | 66 | 0 |
| post_install from mrp to resource | 35 | 4 |
| post_install from sale to stock_account | 14 | 0 |
| post_install from stock_delivery to test_mail_sms | 33 | 0 |
| post_install from test_main_flows to web_unsplash | 7 | 0 |
| post_install from website to website | 5 | 4 |
| post_install from website_blog to website_twitter | 27 | 0 |


**Enterprise** (see related branch in enterprise)

| build | before | after |
| - | - | - |
| All at_install | 550 | 9 |
| post_install from account to auth_signup | 6 | 0 |
| post_install from auth_totp to microsoft_outlook | 129 | 4 |
| post_install from mrp to room | 120 | 0 |
| post_install from sale to stock_barcode_mrp | 39 | 0 |
| post_install from stock_barcode_mrp_subcontracting to test_mail_sms | 37 | 0 |
| post_install from test_main_flows to web_unsplash | 8 | 4 |
| post_install from website to website | 5 | 2 |
| post_install from website_appointment to worksheet | 34 | 0 |

#testing#password reset#email noise#automation

[IMP] *: don't set no_reset_password in tests, it's already set

PR #56685

Enterprise17.0appointmentappointment_hrhr_payroll_holidaysl10n_be_reports_post_wizardl10n_mx_edi_landingproject_forecastproject_sale_subscriptionsale_project_forecastsale_subscriptionsale_subscription_stocktest_mail_enterpriseweb_studio

This update removes redundant test settings because the system now applies the password-reset restriction automatically during tests. It also corrects how test context is handled in several areas, helping keep automated checks reliable without changing customer-facing behavior.

Original PR description

See community counterpart, it's already set now in test mode by default.

There is a lot of reset password mails sent in our testing suite which are not needed and not wanted, ~1000. The goal is to force the already existing context key `no_reset_password` to `True` by default when inside the testing suite. Note that maybe some other context keys could be nice to have by default, but this one is quite obvious and chosen as the first way to go. Also note that the gain time on runbot is probably very tiny if any, but it's still the way to go: let's avoid entering the email sending code stack even if the mails are not really sent in test mode, there is still some processing time when preparing the mail. Here are some stats, note that the "after" columns is considering the next few small fix commits. You can grep in the test logs with `Password reset email sent for user` **Community** | build | before | after | | - | - | - | | All at_install | 287 | 9 | | post_install from account to auth_signup | 2 | 0 | | post_install from auth_totp to microsoft_outlook | 66 | 0 | | post_install from mrp to resource | 35 | 4 | | post_install from sale to stock_account | 14 | 0 | | post_install from stock_delivery to test_mail_sms | 33 | 0 | | post_install from test_main_flows to web_unsplash | 7 | 0 | | post_install from website to website | 5 | 4 | | post_install from website_blog to website_twitter | 27 | 0 | **Enterprise** (see related branch in enterprise) | build | before | after | | - | - | - | | All at_install | 550 | 9 | | post_install from account to auth_signup | 6 | 0 | | post_install from auth_totp to microsoft_outlook | 129 | 4 | | post_install from mrp to room | 120 | 0 | | post_install from sale to stock_barcode_mrp | 39 | 0 | | post_install from stock_barcode_mrp_subcontracting to test_mail_sms | 37 | 0 | | post_install from test_main_flows to web_unsplash | 8 | 4 | | post_install from website to website | 5 | 2 | | post_install from website_appointment to worksheet | 34 | 0 |