Wednesday, November 20, 2024
3 changes · saas-17.2
Resolved issues and error corrections
This fixes the customer portal account form so users can see and select available state or province options. It prevents customers from getting stuck when updating address details, improving self-service account management.
Original PR description
Reproduce --- - -i website,portal - open /my/account - select state -> BUG nothing to select from History of changes --- From newest to latest da2c32470c63b8a45ddfb3565c158feece33c924 just reformatted it 14183883432e9d35c6240e1d7dc8c51d04cb93db it also just reformatted it ea27c1b7a341b6f913197a2e8843562c5e71ea52 moved from addons/website_portal/views/website_portal_templates.xml 55d72e1ab4a64f52e040911a8b4b4c8ce9443f65 updated in here c3c0408471763ea90e9379a2d05fd2add820d57e initially introduced it opw-4218359 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an installation issue where Odoo could pick an unsuitable chart of accounts when a company had no country set. The change prevents failed module installations and avoids applying accounting settings that do not match the company’s country.
Original PR description
When new modules with coas are being installed, the matching coa based on country is autoinstalled if possible, but if multiple charts match then we overwrite the autoinstall and use the one from the last module. Here we make sure we do not overwrite the chart if it is not associated with the company's country. Using a chart not associated with any country (except generic_coa) during module installation will result in failure. Problem is reproduced on: 1- CI when any syscohada module is installed 2- start a new db and do not set a country on your company, then try installing any syscohada module --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes issues that could prevent the website logout page from displaying correctly, including errors caused by language handling during early page loading. This improves the sign-out experience for website visitors and avoids unexpected error pages.
Original PR description
The website module overrides `ir.http:_get_default_lang`, which is called by `http_routing`'s override of `ir.http:_match`. In this override, it calls `website:_get_cached('default_lang_id')` which…
The website module overrides `ir.http:_get_default_lang`, which is called by `http_routing`'s override of `ir.http:_match`.
In this override, it calls `website:_get_cached('default_lang_id')` which calls `website:_get_cached_values`.
However, `ir.http:_match` is called at a time when the environment hasn't been completely initialized (it will be properly initialized when `ir.http:_authenticate` is called), and its context language hasn't been checked against activated languages yet.
This means that `website:_get_cached_values` cannot rely on this language. The first of the two bugs fixed by this commit happens when website has translatable fields. When reading data from the website, the ORM does a prefetch and tries to load this other field, but fails because the language of the context is invalid. The fix is to prefetch manually the four fields that are not translatable and that we want to cache.
The second bug happens specifically on the logout page, which is set as `auth='none'` by the web module. The website module already overrides the `/web/login` route to set it as `auth='public'` in order to be able to read the website. We need to do the same with the /web/session/logout route, so that the page renders properly.
This commit targets saas-17.2 as the first branch because it is fixing two bugs that were introduced as follows, as determined by a git bisect.
- in a3a3650 from #112000 (saas-17.1), the call to /web/session/logout fails with a 500 status (IndexError) because rule.endpoint.routing has no 'no_db' key, in '_serve_ir_http'.
- in 584a172 from #112000 too (saas-17.1), that code is removed, and the error is now a 403 status because it is not possible to read website records without a user. This error is fixed by adding user='public' to the logout route.
- since d01302b from #151502 (saas-17.2), the test added in this commit could reproduce the error in _get_cached_values by accessing the logout route.
As the saas-17.1 is already EOL, we target saas-17.2 and forward-port it to master.
[OPW-3721341](https://www.odoo.com/odoo/project.task/3721341)
[OPW-3911437](https://www.odoo.com/odoo/project.task/3911437)