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)

Issue -->

For company dependant fields of type `boolean`, `integer`, `float`, `monetary`, casting a `null` value leads to a `cannot cast jsonb null to type _` error on postgresql.

For example, consider the following ->
1. Database has two companies : 'a' and 'b'
2. has one res.partner record with no `credit_limit` set.
3. `credit_limit` (float or numeric) is not a required field and does not have a default value

`credit_limit` on the backend looks like `{"a.id": null, "b.id": null}`

Fetching the value for this field leads to method `_field_to_sql` which builds the select query, while also casting the type to each field. In this case, with no fallback default value and a float field, the query is `SELECT ("res_partner"."credit_limit"->'a.id')::double precision FROM res_partner` which resolves to `null(jsonb)::double precision` which unfortunately, is not supported on Postgresql.

Solution -->

Remove the condition for the types `boolean`, `integer`, `float`, `monetary` and use the `field->company_id->>0` logic instead. This works because the `->>` operator returns a text object; the text `null` value can be cast into the types mentioned above.
https://github.com/odoo/odoo/blob/2ed38db47ac3152eef1a0e328c8ff572474d079f/odoo/models.py#L2964-L2967

opw-4313425




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

### Issue:

Since 18.0, the catalog is used in certain actions of the shopfloor However, if you leave the catalog fast enough after your last change (something of the order of ~0.5 sec in localhost), you can trigger a reload of the shopfloor records and call a `web_read` prior to the update of these records.

### Note:

This is easily reproducible by hand in localhost and should worsen if you have server delay.In addition, Also, it makes it impossible to write a proper tour involving the catalog in the shopfloor.

### Steps to reproduce:

- Create a product with a bom and an operation op1
- Create and confirm an MO for 1 unit of that product
- Go to the shopfloor > on the operation > wheel > Add component
- Add a component to be consumed in that operation
- Close the catalog fast (using ESC for instance)

#### > While the componenet was correctly added to the MO and linked to the WO it is not visible on the shopfloor.

### Cause of the issue:

When a product is added from the catalog it triggers an rpc call to update the data's of the MO (notably creating a new raw move): https://github.com/odoo/odoo/blob/193c9a49dfc039ee93fbc8e171819236697b5c50/addons/product/static/src/product_catalog/kanban_record.js#L62-L69 https://github.com/odoo/odoo/blob/193c9a49dfc039ee93fbc8e171819236697b5c50/addons/mrp/models/mrp_production.py#L2898-L2901 On the other hand, closing the product catalog will reload the mrp record that started the action that opened the catalog: https://github.com/odoo/enterprise/blob/c1346dd2279bf3882b47b260b8d03ef9651ffaf1/mrp_workorder/static/src/mrp_display/dialog/mrp_menu_dialog.js#L41-L45 Since this reload is currently not waiting for the update of the record the associated `web_read` might be called prior to the last update of the record and the newly created raw moves might not be displayed.

### Fix:

We use the props option of the action opening the catalog to transfer a callback to reload the records when all the record update promisses are resolved.

Enterprise: https://github.com/odoo/enterprise/pull/72942

opw-4199156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this commit, some things were unclear. The mobile view was not working as expected and expired sign items were displayed in the thank you dialog. Refusing sign request would not cancel them.

Moreover this commit fix the sign tests.
This commit aims to fix an issue with test_archived_requests_dont_send_reminders.

Previously the test was trying to archive a record by performing a direct write command, but since we have a designated action for archiving sign requests, it should be used.

Another issue is that when we archive a sign request, its state is set to 'canceled', and for canceled sign requests we cannont update the validity, however the test was trying to update the validity (as a way of jumping to the future). But this is not the correct way of doing it, since we shouldn't change the validity if state is canceled.

To fix the issue, a mock_datetime_and_now is introduced.

Note: this is the backport of https://github.com/odoo/enterprise/pull/73156

task: 4294860

### Steps to reproduce the issue:

1. Activate Mexican Localization
2. With a Mexican Company, create an Invoice and add a Product with a valid UNSPSC code
3. On the Invoice Line, set Price to 1030.17 and add a 3% Discount
4. Confirm then Send & Print (with CFDI checked)
5. In the generated XML, the following values are off:
    - In node "Comprobante, SubTotal="1030.16" Descuento="30.90"
    - In node "Concepto", ValorUnitario="1030.16" Importe="1030.16" Descuento="30.90"
    - Expected are 1030.17 and 30.91

### Explanation:

During the calculation of the values for the CFDI, `gross_price_subtotal_before_discount` is calculated using `price_subtotal` in every case where `discount` is not 100%. This is due to other values affecting `price_subtotal` (e.g.: taxes with `price_include=True`), in which case calculating a value related to `price_subtotal` with `price_unit` would give the wrong result.
This calculation method causes rounding issues such as above because `price_subtotal` is rounded before calculating `gross_price_subtotal_before_discount`.

### Fix reasoning:

We need to account for any value that could affect `price_subtotal` and make it different from `price_unit * quantity` except for `discount`, which will be included when comparing both values.
The case `discount == 100.0` is covered by this new condition as well, since `discount_factor` would equal to 0 and `price_subtotal` too.

opw-4183556