- RPI 5 displays detection: `vcgencmd` outdated -> now using `xrandr`, - Odoo now automatically restarts on crash: replaced `init.d/odoo` by `systemd/system/odoo.service`, - Now using Chromium instead of Firefox, - Improved server connection behaviour: - prevent from calling `rename_iot.sh` if new name is same as hostname, - Updated HDMI display UI to improve coherence with IoTBox browser homepage, - Updated DNS configuration (use 1.1.1.1), - Cached `socket.gethostname()` insid

- RPI 5 displays detection: `vcgencmd` outdated -> now using `xrandr`,
- Odoo now automatically restarts on crash: replaced `init.d/odoo` by `systemd/system/odoo.service`,
- Now using Chromium instead of Firefox,
- Improved server connection behaviour:
    - prevent from calling `rename_iot.sh` if new name is same as hostname,       
- Updated HDMI display UI to improve coherence with IoTBox browser homepage,
- Updated DNS configuration (use 1.1.1.1),
- Cached `socket.gethostname()` inside of an `helper` method,
- Added missing packages leading to warnings and errors in logs: `vobject`, `num2words`, ...,
- Added missing `__manifest__.py` in `point_of_sale/` leading to a warning for missing licence.


Task: 3947355

Forward-Port-Of: odoo/odoo#169633

It was reported that on some locales (eg) Japan the snailmail styling was not properly applied. This was due to the selector in snailmail styling which was incorrect for a multi-company setup. Targeting `.o_company_1_layout` will break the selector for any company which is not the first one. task-4099258 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175821

It was reported that on some locales (eg) Japan the snailmail styling
was not properly applied.

This was due to the selector in snailmail styling which was incorrect for a multi-company setup. Targeting `.o_company_1_layout` will break the selector for any company which is not the first one.

task-4099258


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

Forward-Port-Of: odoo/odoo#175821

Oversight from task-3637983 (https://github.com/odoo/odoo/pull/161265) task-4104583 Forward-Port-Of: odoo/odoo#176147

Oversight from task-3637983 (https://github.com/odoo/odoo/pull/161265)

task-4104583

Forward-Port-Of: odoo/odoo#176147

When scrapping a kit, it leads to incorrect behaviours **Case 01:** 1. Create a storable kit with one storable component 2. Validate a scrap order with that kit 3. Open the product moves Error: we moved the kit instead of its component We first create a draft SM with its SML: https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models/stock_scrap.py#L145 https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models

When scrapping a kit, it leads to incorrect behaviours

**Case 01:**
1. Create a storable kit with one storable component
2. Validate a scrap order with that kit
3. Open the product moves

Error: we moved the kit instead of its component

We first create a draft SM with its SML:
https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models/stock_scrap.py#L145
https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models/stock_scrap.py#L112

During the SML creation, we check if we should recompute the state
of the SM:
https://github.com/odoo/odoo/blob/dc0917d2a55a12e5c30d413a46e2c16190fd8a08/addons/stock/models/stock_move_line.py#L344-L355
`reservation` is `True`, the SML has a quantity -> we recompute the
state of the SM -> it is now assigned
Back to the scrap, we now `_action_done` the kit SM
https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models/stock_scrap.py#L147
which leads to
https://github.com/odoo/odoo/blob/6ed0d0ca2f90fef8cd020380b194498a9363267c/addons/stock/models/stock_move.py#L1827-L1830
Here is the problem: the SM has a demand, its state is not draft
-> we don't confirm it
-> we don't explode it
Hence the error. This is the reason why the commit stops providing
the scrap SM with an initial demand. That way, we will explode the
SM and everything will work as expected

**Case 02:**
1. Create a consumable kit with one storable component
2. Validate a scrap order with that kit

Error: a server error is raised "Missing record [...]"

This time, `reservation` is `False` (the diff comes from the kit
type, consu vs stor, c.f. `_should_bypass_reservation`). Therefore,
we explode it. Since we are in scrap mode, we generate SM with a
zero demand:
https://github.com/odoo/odoo/blob/68f981d2a690addf0b70ddab498b556986752e49/addons/mrp/models/stock_move.py#L464-L466
https://github.com/odoo/odoo/blob/68f981d2a690addf0b70ddab498b556986752e49/addons/mrp/models/stock_move.py#L527
Back to `_action_done`, we create the extra moves if needed:
https://github.com/odoo/odoo/blob/6ed0d0ca2f90fef8cd020380b194498a9363267c/addons/stock/models/stock_move.py#L1847-L1853
Here, our component SM has a done qty greater than its demand
(reminder: it demand is zero), so we will create the extra move,
confirm it and merge it with the initial one:
https://github.com/odoo/odoo/blob/6ed0d0ca2f90fef8cd020380b194498a9363267c/addons/stock/models/stock_move.py#L1799-L1802
Buuuuut... Step 2 in the use case, we validate the scrap order.
Since we don't have such product on hand, we trigger a wizard with
some default values:
https://github.com/odoo/odoo/blob/72c4a2352c1184f5e8c1f238d29eb94e37d01115/addons/stock/models/stock_scrap.py#L204-L219
And... Now you see where I'm going: when we create the extra move,
we still have these default values in the context -> the extra move
has a demand and(!) a done qty to 1. We merge it with the initial
move: we are now scrapping a component with a demand equal to one
and a done qty equal to 2. It will later lead to other
inconsistencies (among them, the server error raised)

opw-4090951

Forward-Port-Of: odoo/odoo#176186

### Issue: Changing the reservation method of a picking type on a large DB might result in a memory error invalidating the requested change. ### Cause of the issue: The dependency `picking_type_id.reservation_method` was introduced on the `_compute_reservation_date` method of stock moves by commit c4023d7. This dependency was introduced to remove the reservation date on all moves whose picking type reservation method is no more "date". Because of this new dependency, if one change the `

### Issue:

Changing the reservation method of a picking type on a large DB might result in a memory error invalidating the requested change.

### Cause of the issue:

The dependency `picking_type_id.reservation_method` was introduced on the `_compute_reservation_date` method of stock moves by commit c4023d7. This dependency was introduced to remove the reservation date on all moves whose picking type reservation method is no more "date". Because of this new dependency, if one change the `reservation_method` of a picking type say manufacturing, it will fetch and "recompute" the `reservation_date` of all stock.moves whose picking type is manufacting. The ORM will handle these records 1000 by 1000 but if you happen to have a million records of that picking type (which is the case of the customer) all of these records will be added to the cache during the `_fetch_query`. This will lead to a Memory error since the cache is not cleared after a certain amount of computed records during the `_compute_reservation_date`.

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

Forward-Port-Of: odoo/odoo#175873

### Steps to reproduce: - Install Timesheet and Time-off modules - Let the time-off validation creates a timesheet - Create a time off for an employee and validate it - Archive this employee ### Current behavior before PR: After archiving an employee you will still have the timesheets related to his upcoming leaves even when you are closing all of his activities. This is happening because when archiving an employee we are just updating the state of his hr.leave to refuse without unl

### Steps to reproduce:
	- Install Timesheet and Time-off modules
	- Let the time-off validation creates a timesheet
	- Create a time off for an employee and validate it
	- Archive this employee

### Current behavior before PR:
After archiving an employee you will still have the timesheets related to his upcoming leaves even when you are closing all of his activities.
This is happening because when archiving an employee we are just updating the state of his hr.leave to refuse without unlinking the timesheets https://github.com/odoo/odoo/blob/15.0/addons/hr_holidays/wizard/hr_departure_wizard.py#L23

### Desired behavior after PR is merged:
While archiving an employee we are calling the 'action_refuse' method where it will update the state of the employee's leaves and also will unlink the timesheet related to those leaves.

opw-4070684

Forward-Port-Of: odoo/odoo#176334
Forward-Port-Of: odoo/odoo#175725

**Steps to reproduce the bug:** - Create two storable products: “P1” and “P2.” - Create a picking: - Product: “P1” - Quantity: 10 - Create a second picking: - Product: “P2” - Quantity: 10 - Confirm both pickings. - Set both moves to picked. - Add them to a wave. - Go to the wave and set the quantity of P1 to 0 while keeping `picked=True`. - Validate the wave. **Problem:** The picking of P1 is detached from the wave, but the move remains picked. As a result, `_compute_show_check_avail

**Steps to reproduce the bug:**
- Create two storable products: “P1” and “P2.”
- Create a picking: - Product: “P1” - Quantity: 10
- Create a second picking: - Product: “P2” - Quantity: 10
- Confirm both pickings.
- Set both moves to picked.
- Add them to a wave.
- Go to the wave and set the quantity of P1 to 0 while keeping `picked=True`.
- Validate the wave.

**Problem:**
The picking of P1 is detached from the wave, but the move remains picked. As a result, `_compute_show_check_availability` returns `False`, causing the check availability button to stay invisible.

opw-4016209

Forward-Port-Of: odoo/odoo#176375

### Steps to reproduce: - Install eCommerce module - Go to Website > Cart - Click on Edit > Customize > Extra Info - Go to Website settings and Check 'Extra Step During Checkout' ### Current behavior before PR: The 'Extra Step During checkout' setting is not synchronized when turning on and off from website editor or from website settings. This actually leads sometimes that you might turn it on from website settings and it won't be visible in the checkout process. This is happening b

### Steps to reproduce:
	- Install eCommerce module
	- Go to Website > Cart
	- Click on Edit > Customize > Extra Info
	- Go to Website settings and Check 'Extra Step During Checkout'

### Current behavior before PR:
The 'Extra Step During checkout' setting is not synchronized when turning on and off from website editor or from website settings. This actually leads sometimes that you might turn it on from website settings and it won't be visible in the checkout process. This is happening because in the 'res.config.settings' we are dealing with 'ir.ui.view' that is not linked to any website but in the website editor we are dealing with 'ir.ui.view' that is linked to the website you are editing.
https://github.com/odoo/odoo/blob/17.0/addons/website_sale/models/res_config_settings.py#L68 https://github.com/odoo/odoo/blob/17.0/addons/website_sale/models/website.py#L588

### Desired behavior after PR is merged:
When turning on/off the setting from the website settings now we are dealing with the 'ir.ui.view' that is linked to a website. So the setting is now website dependant.

opw-3992571

Forward-Port-Of: odoo/odoo#175929
Forward-Port-Of: odoo/odoo#170639

### Steps to reproduce: - Create 2 storable product - Update the on hand quantity to 100 only for the first one - Create an confirm an SO 75 units of each - Set the done qty to 50 on both moves and create a backorder - Print delivery slip for the original picking #### > The Ordered quantity is wrong on the product with no stock on hand (50 instead of 75). ### Cause of the issue: If there's no on hand qty the backorder move will not be associated to any `move_line` so that the `qty_

### Steps to reproduce:

- Create 2 storable product
- Update the on hand quantity to 100 only for the first one
- Create an confirm an SO 75 units of each
- Set the done qty to 50 on both moves and create a backorder
- Print delivery slip for the original picking
#### > The Ordered quantity is wrong on the product with no stock on hand (50 instead of 75).

### Cause of the issue:

If there's no on hand qty the backorder move will not be associated to any `move_line` so that the `qty_ordered` will not be updated by these lines:
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L785-L791 Furthermore, since they are not cancelled, they are filtered out here and hence do not update the `qty_ordered` by these lines either: https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L813-L816 https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L831

### Fix:

We modify the filter meant for empty move lines so that moves that are not confirmed and are not associated to any `move_line` contribute to the `qty_ordered` via these:
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L831 However, since we do not want a move that is fully backordered to appear on the delivery slip we need to filter out all the line keys that will be created, because they pass our new filtering condition (but didn't pass the old one), here:
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L819-L821

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

Forward-Port-Of: odoo/odoo#176196
Forward-Port-Of: odoo/odoo#175113

If you were to refresh on a skipped question, the next_page_or_question would not be populated therefore causing any reference to this fail. There should not be a case where there is no next_page_or_question in _prepare_survey_data as the _get_next_page_or_question is only expecting an empty question in survey_submit. Adding a fallback to look for the next skipped question or page for when the next_skipped_page in the post parameter is lost in the http request through refreshing will allow th

If you were to refresh on a skipped question, the next_page_or_question would not be populated therefore causing any reference to this fail. There should not be a case where there is no next_page_or_question in _prepare_survey_data as the _get_next_page_or_question is only expecting an empty question in survey_submit.

Adding a fallback to look for the next skipped question or page for when the next_skipped_page in the post parameter is lost in the http request through refreshing will allow this to work as expected.

opw-4088129

Forward-Port-Of: odoo/odoo#175933

before this commit, on opening general ledger report shows traceback for the user  introduced in this commit: https://github.com/odoo/enterprise/commit/402ed134269db6b82679c32d21eb1122bbda7cfe after this commit, the report will be opened without any issues Forward-Port-Of: odoo/enterprise#68287

before this commit, on opening general ledger report shows traceback for the user

![Screenshot from 2024-08-12 10-55-39](https://github.com/user-attachments/assets/a2f78ccf-ab2c-4435-b011-583035b68814)


introduced in this commit: https://github.com/odoo/enterprise/commit/402ed134269db6b82679c32d21eb1122bbda7cfe

after this commit, the report will be opened without any issues

Forward-Port-Of: odoo/enterprise#68287

Before this commit: Steps 1) Install l10n_es_reports 2) Switch to ES company 3) Create a EU vendor (any except SPAIN) + add TIN 4) Create a bill with last month date 5) Reverse that bill with current month date 6) Go to Tax reports 7) Switch to Tax Report (Mod 349) (ES) 8) Choose date range: This Month 9) Generate BOE => It shows an error with a traceback `/l10n_es_reports/models/aeat_tax_reports.py", line 1257, in _write_type2_refund_records previous_report_amoun

Before this commit:
Steps
	1) Install l10n_es_reports
	2) Switch to ES company
	3) Create a EU vendor (any except SPAIN) + add TIN
	4) Create a bill with last month date
	5) Reverse that bill with current month date
	6) Go to Tax reports
	7) Switch to Tax Report (Mod 349) (ES)
	8) Choose date range: This Month
        9) Generate BOE
=> It shows an error with a traceback `/l10n_es_reports/models/aeat_tax_reports.py", line 1257, in _write_type2_refund_records
    previous_report_amount = invoice_line_data['columns'][0]['no_format']
    TypeError: 'NoneType' object is not subscriptable`

After this commit:
BOE in mod349 is generated properly without errors

opw-4055702

Forward-Port-Of: odoo/enterprise#68096

Issue ---- When clicking an account report cell with the cash basis filter on, `account_reports_cash_basis.account_report.action_audit_cell` adds a domain to filter out `account.move.line`s that don't belong to the cash basis criteria. However, the model is not always an `account.move.line`. If an analytic account column is added with the "Analytic Group By" option, the model is `account.analytic.line`, which results in a field not found error. Steps ---- - Go to Accounting -> Report

Issue
----

When clicking an account report cell with the cash basis filter on, `account_reports_cash_basis.account_report.action_audit_cell` adds a domain to filter out `account.move.line`s that don't belong to the cash basis criteria. However, the model is not always an `account.move.line`. If an analytic account column is added with the "Analytic Group By" option, the model is `account.analytic.line`, which results in a field not found error.

Steps
----

 - Go to Accounting -> Reporting -> Profit and Loss.
 - From the Options button above, select "Cash Basis Method".
 - From the Analytic Group By button, add an analytic account in the "Accounts" filter.
 - Click on a cell under the analytic account's column.
 - An error is thrown.

Cause
----

Domain is applied on the wrong model.

opw-4034786

Forward-Port-Of: odoo/enterprise#66890

Problem: The quality_score field is not received in the response while syncing all the templates. As a result, the default 'none' quality will be applied to all the templates. And the same goes while syncing a single template. It will only be updated when Meta posts a request on the webhook to update the template quality. Solution: The quality_score field can only be received if we explicitly ask for the quality_score field in an API request, But the problem is that only the quality_sco

Problem:

The quality_score field is not received in the response while syncing all the templates. As a result, the default 'none' quality will be applied to all the templates. And the same goes while syncing a single template. It will only be updated when Meta posts a request on the webhook to update the template quality.

Solution:

The quality_score field can only be received if we explicitly ask for the quality_score field in an API request, But the problem is that only the quality_score field will be received here. Due to this, the API request to sync a single template and multiple templates are modified, and all the basic fields like name, components, language, status, category, and ID are included along with the quality_score field so we receive all basic fields and quality_score field.

Task-3908894

Forward-Port-Of: odoo/enterprise#61150

Issue ----- When adding formating to an appointment button linked to a specific type of appointment, the button will lead to all appointments instead of just the specific type. Change ----- Since buttons can have custom formatting, this will add HTML elements inside the button element. Therefore, we need to take into account that the target of the event may not be the button itself. opw-4080512 Forward-Port-Of: odoo/enterprise#68037

Issue
-----
When adding formating to an appointment button linked to a specific type of appointment, the button will lead to all appointments instead of just the specific type.

Change
-----
Since buttons can have custom formatting, this will add HTML elements inside the button element. Therefore, we need to take into account that the target of the event may not be the button itself.

opw-4080512

Forward-Port-Of: odoo/enterprise#68037

## Issue: - A user with sufficient access rights to timesheet, ('User: all timesheets' or 'User: own timesheets only') cannot create an invoice for a sales order within a specific timesheet period, receiving the error: 'Timesheets before [PERIOD] are validated and cannot be modified.' ## Steps To Reproduce: - Edit `Create on Order` of the `Service on Timesheets` product to be `Project & Task`. - in settings: - enable the `Lock Timesheets` option. - set the invoicing polic

## Issue:
- A user with sufficient access rights to timesheet, ('User: all timesheets' or 'User: own timesheets only') cannot create an invoice for a sales order within a specific timesheet period, receiving the error: 'Timesheets before [PERIOD] are validated and cannot be modified.'

## Steps To Reproduce:
- Edit `Create on Order` of the `Service on Timesheets` product to be `Project & Task`.
- in settings:
        - enable the `Lock Timesheets` option.
        - set the invoicing policy for Timesheets to `validated timesheets only` .
        - set the invoicing policy for Sales to 'invoice what is delivered'.
- ​Update the timesheet access for `Marc Demo` and set it as 'User: all timesheets'.
- Create a SO with `Service on Timesheets` as a product.
- On the related Task create a timesheet for period 01 May to 31 May and validate it.
- With Marc Demo click on Create an Invoice on the SO, for the same period notice The Access Error.

## Solution:
- in `check_if_allowed` I modified the condition to check if the current user is not a superuser.

opw-3965532

Forward-Port-Of: odoo/enterprise#66607
Forward-Port-Of: odoo/enterprise#65435

The BelastingDienst returns an error if the format for the 'ProfessionalAssociationForTaxServiceProvidersName' tag is not respected. The string value in that tag should not exceed 20 characters.µ opw-4075462 Forward-Port-Of: odoo/enterprise#67635

The BelastingDienst returns an error if the format for the 'ProfessionalAssociationForTaxServiceProvidersName' tag is not respected. The string value in that tag should not exceed 20 characters.µ

opw-4075462

Forward-Port-Of: odoo/enterprise#67635

Before this commit, when scaning a GS1 barcode containing a packaging for a tracked product and a lot, it doesn't work. This commit fixes two issues: 1. Get back packaging data (product and quantity) when a GS1 barcode is scanned; 2. Be able to find the lot/serial number when a GS1 barcode with no product but a packaging is scanned. Forward-Port-Of: odoo/enterprise#68056 Forward-Port-Of: odoo/enterprise#67727

Before this commit, when scaning a GS1 barcode containing a packaging for a tracked product and a lot, it doesn't work.

This commit fixes two issues:
1. Get back packaging data (product and quantity) when a GS1 barcode is scanned;
2. Be able to find the lot/serial number when a GS1 barcode with no product but a packaging is scanned.

Forward-Port-Of: odoo/enterprise#68056
Forward-Port-Of: odoo/enterprise#67727

before this commit [test_availability_in_clients_tz](https://runbot.odoo.com/runbot/build/66644573) was breaking when not having demo data. Was first introduced in https://github.com/odoo/enterprise/pull/61047 Now we fix the issue where test test_availability_in_clients_tz without demo data as user does not have tz specified by specifying it in the test itself. Forward-Port-Of: odoo/enterprise#68155

before this commit [test_availability_in_clients_tz](https://runbot.odoo.com/runbot/build/66644573) was breaking when not having demo data. Was first introduced in https://github.com/odoo/enterprise/pull/61047

Now we fix the issue where test test_availability_in_clients_tz without demo data as user does not have tz specified by specifying it in the test itself.

Forward-Port-Of: odoo/enterprise#68155

Before this commit: Sendcloud request adds a phone number instead of a mobile number first during the check.  For many carriers, Sendcloud requires real mobile numbers instead of (landline) phone number. After this commit: Mobile number is checked before the phone number and added to the request if available. opw-4005520 Forward-Port-Of: odoo/enterprise#66480

Before this commit:

Sendcloud request adds a phone number instead of a mobile number first during the check.  For many carriers, Sendcloud requires real mobile numbers instead of (landline) phone number.

After this commit:

Mobile number is checked before the phone number and added to the request if available.

opw-4005520

Forward-Port-Of: odoo/enterprise#66480