This fix keeps website location simulation working after a change in the third-party GeoIP library. It helps prevent checkout-related automated tests from failing when newer GeoIP versions are used, without changing normal customer-facing behavior.

maxmind decided to remove support for `raw_response` and chhange the API of Country/City to take all the raw_response components by keywords instead
(maxmind/GeoIP2-python@4518919151e1b39bd544df653b41cd155dc2f708). This leads to location mocking not working anymore, which leads to the failure of `:TestWebsiteSaleCart.test_cart_new_fpos_from_geoip` when using geoip2 5.0.

When mocking the request with a country code set, just try the new API then fallback on the old one (note: the commit also removes the `locales` default fallback, so make that explicit).

Reordering items in the map view no longer removes the displayed routes. Routes are kept and recalculated so users can continue seeing the correct path after changing the order.

Before this commit, the map view removed the routes after reordering the items. Now, the routes are kept and the path recalculated.

task-4493063

This fix makes an automated Web Studio test more stable by removing unpredictable behavior that caused occasional false failures. It helps keep development validation reliable without changing how users experience the product.

Current behavior before commit: creating cut-off journal entries for a vendor bill in a previous year using a new sequence reset period in current year will raise an error due to the accrual move date mismatch with the destination move fetched from the move in _get_accounting_date Reason: due to the accrual move date mismatch with the destination move fetched from the move in _get_accounting_date Fix: Added a function to compute a reference move for each get_lock_safe_date call an

Current behavior before commit:

creating cut-off journal entries for a vendor bill in a previous year using a new
sequence reset period in current year will raise an error due to the accrual move
date mismatch with the destination move fetched from the move in _get_accounting_date

Reason:
due to the accrual move
date mismatch with the destination move fetched from the move in _get_accounting_date

Fix:
Added a function to compute a reference move for each get_lock_safe_date call
and compare approrpiate dates for accrual moves.

Steps to reproduce on runbot:

1. ensure the sequence for the Miscellaneous
Operations journal
(l10n_fr for example) resets yearly for the
previous year (ex 2024)

2. create a new journal entry in the
Miscellaneous Operations journal in current year and rename it
to "Name 3000"

3. Create a vendor bill and set the date field to be 12/12/2024 for example
and post it

4. Create cut-off journal entries with a recognition date set as today and the same journal
"Miscellaneous Operations" and observe the traceback.

opw-4507925

Forward-Port-Of: odoo/odoo#196836

Steps to reproduce: - add a payment reference on a vendor bill - confirm - register a payment - see the memo takes the payment reference value - update the payment reference on the invoice, register (no matter if you reset the invoice into draft or not) - register a payment Issue: see the memo takes the same vale as the initial payment reference Cause: We use the `line.name` which is not wrong as when we update the payment reference the it will be updated. But whenever we update th

Steps to reproduce:
- add a payment reference on a vendor bill
- confirm
- register a payment
- see the memo takes the payment reference value
- update the payment reference on the invoice, register (no matter if you reset the invoice into draft or not)
- register a payment

Issue:
see the memo takes the same vale as the initial payment reference

Cause:
We use the `line.name` which is not wrong as when we update the payment reference the it will be updated. But whenever we update the payment reference again, the `line.name` will not be updated https://github.com/odoo/odoo/blob/0bec22df0a34c6bc201d2627cf1123509d272a6d/addons/account/models/account_move_line.py#L482-L483

Solution:
We prioritize the payment reference for the communication as it is the case in 18.0

opw-4405999

Forward-Port-Of: odoo/odoo#198826
Forward-Port-Of: odoo/odoo#196611

In [1] when the web client was rewritten in OWL, the `noContextKeys` parameter behavior was lost (only the `shadow` `settings` was used). In [2] the `_rpc` was overridden, losing the `noContextKeys` parameter. Because of each of these, even though the HTML Editor always fetched a `en_US` version of the page for edition, upon save, the current user's language was being used upon save, leading to the loss of translations. This commit fixes the issue by removing the mentioned keys from the co

In [1] when the web client was rewritten in OWL, the `noContextKeys` parameter behavior was lost (only the `shadow` `settings` was used). In [2] the `_rpc` was overridden, losing the `noContextKeys` parameter.

Because of each of these, even though the HTML Editor always fetched a `en_US` version of the page for edition, upon save, the current user's language was being used upon save, leading to the loss of translations.

This commit fixes the issue by removing the mentioned keys from the context in the `legacyEnv.session.rpc` rather than getting rid of that parameter completely because since [3] the user context is always included in the rpc context - which would restore the language.

Steps to reproduce:
- Set user's language to Dutch.
- Add Dutch as the default language of a website.
- Create a new Dutch page.
- Drop an accordion snippet.
- Switch website preview to English.
- Translate the first title.
- Save.
- Edit the page with the HTML Editor (English version is edited).
- Make some minor change, even adding a space is enough.
- Save.

=> Dutch text was lost and replaced by the last saved version.

[1]: https://github.com/odoo/odoo/commit/0573acae2306bf5da2005852da9323ddc59e5431#diff-851c304e3f2a64138c1ff0f3de9856184dbfa0114da3fd76af0309eabe72043eR134
[2]: https://github.com/odoo/odoo/commit/55f1680c74d3b64c3319ba114f7ba3e3f7b49be3
[3]: https://github.com/odoo/odoo/commit/2192480ed1262a13db8e6b0dd945ea91dee91aa9

opw-3493355

Forward-Port-Of: odoo/odoo#144693
Forward-Port-Of: odoo/odoo#142894

Reduce the memory footprint and slightly improve the performance of export, especially when we traverse multiple levels of relational fields. We replace the https://github.com/odoo/odoo/pull/22494 solution because it is only works at the top level of the export, to avoid invalidating records that may be used by the next iteration, and because the cache memory footprint of the cache has been reduced in recent years anyway. Instead, we explicitly read the only asked fields recursively. Memo

Reduce the memory footprint and slightly improve the performance of export, especially when we traverse multiple levels of relational fields.

We replace the https://github.com/odoo/odoo/pull/22494 solution because it is only works at the top level of the
export, to avoid invalidating records that may be used by the next iteration, and because the cache memory footprint of the cache has been reduced in recent years anyway. Instead, we explicitly read the only asked fields recursively.

Memory/Performance changes:

For exporting 10K of stock.picking (Transfers) with basic fields of the list view:
```
Before: 25 Mb of memory peak - 31 SQL requests, +- 55 ms of queries, +- 2440 ms of Python
After : 29 Mb of memory peak - 31 SQL requests, +- 45 ms of queries, +- 2402 ms of Python
```


For exporting 10K of stock.picking (Transfers) with their stock moves (30K) and their stock move line (4K):
```
Before: 191 Mb of memory peak - 162 SQL requests, +- 455 ms of queries, +- 7050 ms of Python
After : 140 Mb of memory peak - 129 SQL requests, +- 315 ms of queries, +- 6930 ms of Python
```

Forward-Port-Of: odoo/odoo#200661
Forward-Port-Of: odoo/odoo#199218

The post processing cron has been recently changed to be disabled by default (ecc5711f002180d7ccf37654d5c3ea5b057b3a17) but this change wasn't properly tested on module updates, which did disable the cron regardless of the providers states. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200897

The post processing cron has been recently changed to be disabled by default (ecc5711f002180d7ccf37654d5c3ea5b057b3a17) but this change wasn't properly tested on module updates, which did disable the cron regardless of the providers states.


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

Forward-Port-Of: odoo/odoo#200897

**Issue:** - When selecting the `DIN 5008 (external_layout_din5008)` layout in the report layout and printing the report, the footer font size appears too small.  **Solution:** - After the PR [#100723](https://github.com/odoo/odoo/pull/100723), the table layout was stabilized, but it introduced a very small `font-size (0.7em)`. A subsequent change by `malb` applied a font-size to the `.co

**Issue:**

-  When selecting the `DIN 5008 (external_layout_din5008)` layout in the report layout and printing the report, the footer font size appears too small.

![before_fix](https://github.com/user-attachments/assets/603725a6-065b-43bf-948c-009476833a3b)


**Solution:**

- After the PR [#100723](https://github.com/odoo/odoo/pull/100723), the table layout was stabilized, but it introduced a very small `font-size (0.7em)`. A subsequent change by `malb` applied a font-size to the `.company_details` class, but this is no longer sufficient due to the presence of `<p>` tags in the footer.

To resolve this - 
- remove the general font-size directive
- add a new one in li
- add a limited line-height to the `<p>` tag to reduce the vertical size of the footer, given we are boosting the font size.


![after_fix](https://github.com/user-attachments/assets/b7c033f3-7c84-488a-b8c9-bb6198be59dd)

opw-4506533

Forward-Port-Of: odoo/odoo#198117

Before this commit, when the user creates a custom filter in SO model to select the SO in which there is at least one task linked to a specific project, he got an error saying the domain is invalid. This commit fixes the issue by improving the search method implementing for the `task_ids` field to make sure the search view supports a query contained inside `value` parameter. Steps to reproduce the issue: ---------------------------- 0. Install `sale_timesheet` module with demo data

Before this commit, when the user creates a custom filter in SO model to
select the SO in which there is at least one task linked to a specific
project, he got an error saying the domain is invalid.

This commit fixes the issue by improving the search method implementing
for the `task_ids` field to make sure the search view supports a query
contained inside `value` parameter.

Steps to reproduce the issue:
----------------------------

0. Install `sale_timesheet` module with demo data
1. Go to Sales app
2. Creates a custom filter and select `Tasks associated to this sale >
   Project` as left part, `=` as operator (second field in the custom
   filter) and `After sales-service` as project (right part, last field
   in the custom filter).
3. Apply the custom filter

Expected behavior:
-----------------

The custom filter should be applied without any issue.

Current behavior:
----------------

The user has an error saying the domain is invalid when he tries to
save/apply his custom filter.

Forward-Port-Of: odoo/odoo#200130

Description of the issue/feature this PR addresses: Spurious log entries Current behavior before PR: Odoo [logs](https://github.com/odoo/odoo/blob/17.0/odoo/modules/registry.py#L653-L654) indexes created by [_sync_plan_column](https://github.com/odoo/odoo/blob/17.0/addons/analytic/models/analytic_plan.py#L281) as unexpected Desired behavior after PR is merged: No log entry for expected index Steps to reproduce: - create a new analytic plan, ie 'Test plan' - go to technical/database

Description of the issue/feature this PR addresses: Spurious log entries

Current behavior before PR: Odoo [logs](https://github.com/odoo/odoo/blob/17.0/odoo/modules/registry.py#L653-L654) indexes created by [_sync_plan_column](https://github.com/odoo/odoo/blob/17.0/addons/analytic/models/analytic_plan.py#L281) as unexpected

Desired behavior after PR is merged: No log entry for expected index

Steps to reproduce:

- create a new analytic plan, ie 'Test plan'
- go to technical/database structure/fields, search for the custom field created on model account.analytic.line, named `x_plan{the id of the plan you created in step 1}_id`
- observe the field is not marked as indexed, even though the code creates an index
- update the analytic module, observe there will be an entry of the form `Keep unexpected index account_analytic_line__x_plan{the id of the plan you created in step 1}_id_index on table account_analytic_line`

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

Forward-Port-Of: odoo/odoo#189240

…ot used and give warning on the log Description of the issue/feature this PR addresses: it not an issue but unnecessary overridden 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 Forward-Port-Of: odoo/odoo#200060

…ot used and give warning on the log

Description of the issue/feature this PR addresses:
it not an issue but unnecessary overridden
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

Forward-Port-Of: odoo/odoo#200060

Fix error in .pot and .po files that led to wrong translations. opw-4621039 Forward-Port-Of: odoo/odoo#200708

Fix error in .pot and .po files that led to
wrong translations.

opw-4621039

Forward-Port-Of: odoo/odoo#200708

This PR backports some commits to add the tool functions to check structured reference/communication. It also add a new function for Netherlands and finally apply a check during the qr code values generation to make sure that we don't pass unstructured communication as structured one. See all the commit messages. Doc for NL case: - https://www.betaalvereniging.nl/betalingsverkeer/giraal-betalingsverkeer/betalingskenmerken/ - https://nl.wikipedia.org/wiki/Elfproef opw-4575004 ---

This PR backports some commits to add the tool functions to check structured reference/communication.
It also add a new function for Netherlands and finally apply a check during the qr code values generation to make sure that we don't pass unstructured communication as structured one.

See all the commit messages.

Doc for NL case:
- https://www.betaalvereniging.nl/betalingsverkeer/giraal-betalingsverkeer/betalingskenmerken/
- https://nl.wikipedia.org/wiki/Elfproef

opw-4575004


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

Forward-Port-Of: odoo/odoo#200699
Forward-Port-Of: odoo/odoo#199735

Adding a condition for Avatax not being enabled on the taxes column in portal view of sales orders. task: 4423974 Forward-Port-Of: odoo/enterprise#77683

Adding a condition for Avatax not being enabled on the taxes column in portal view of sales orders.
task: 4423974

Forward-Port-Of: odoo/enterprise#77683

This commit upgrades the image upload endpoint to the one available in the v2 API. This is done because X is deprecating the old upload API endpoint. We also needed to update how the media id was fetched from the response as it changed between versions. task-4606722 Forward-Port-Of: odoo/enterprise#80232

This commit upgrades the image upload endpoint to the one available in the v2 API. This is done because X is deprecating the old upload API endpoint.

We also needed to update how the media id was fetched from the response as it changed between versions.

task-4606722

Forward-Port-Of: odoo/enterprise#80232

Problem ---------- - Demo data payslips doesn't contains NHIF or SHIF amount, it makes the SHIF report wizard add the payslip with an amount of 0. Objective ---------- - check if the SHIF/NHIF amount == 0 before add it in report entries. - Don't allow the user to add a line. Solution ---------- - add a condition on the SHIF/NHIF amount to add the payslip task-4463586 Forward-Port-Of: odoo/enterprise#80453

Problem
----------
- Demo data payslips doesn't contains NHIF or SHIF amount, it makes the SHIF report wizard add the payslip with an amount of 0.

Objective
----------
- check if the SHIF/NHIF amount == 0 before add it in report entries.
- Don't allow the user to add a line.

Solution
----------
- add a condition on the SHIF/NHIF amount to add the payslip

task-4463586

Forward-Port-Of: odoo/enterprise#80453

In the external and internal layouts, some default variables are set conditionally (`o` in particular) This commit evaluates the content of the t-if expression to imitate what the real qweb does. Otherwise, the variable risks of being erased from the context of the node, which is necessary to add field on the right variable with the right type. opw-4592446 Forward-Port-Of: odoo/enterprise#80019

In the external and internal layouts, some default variables are set conditionally (`o` in particular) This commit evaluates the content of the t-if expression to imitate what the real qweb does. Otherwise, the variable risks of being erased from the context of the node, which is necessary to add field on the right variable with the right type.

opw-4592446

Forward-Port-Of: odoo/enterprise#80019