This fix adds the missing CRM lead model definition needed by related enterprise test cases. It helps ensure CRM-related automated tests run reliably and supports smoother validation of enterprise CRM functionality.

Purpose of this PR:
Test cases of the `crm_enterprise` require definition of `crm.lead` model.
Defining the model to match the dependency

Part of task:[3818666](https://www.odoo.com/odoo/project/1519/tasks/3818666?cids=2)

Related Enterprise PR: https://github.com/odoo/enterprise/pull/62256

Users can now leave Discuss channels without seeing an error. The system removes the leaving user from the channel before sending the departure notification, preventing the message from being sent back to them.

**Current behavior before PR:**

when leaving discuss channel from discuss it results in error because leave notification is send to the leaving person itself.

**Desired behavior after PR is merged:**

The issue was resolved by replacing the logic. Now, before sending a notification to the channel, we remove the channel member and the channel itself from the thread of the person leaving.

task-3893498

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

The French accounting localization module name was changed from l10n_fr to l10n_fr_account without fixing the module references in the translation files. This commit fixes the module references in the i18n files. The French tax report was not showing the French translation. task-3986901 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

The French accounting localization module name was changed from l10n_fr to l10n_fr_account without fixing the module references in the translation files. This commit fixes the module references in the i18n files.

The French tax report was not showing the French translation.

task-3986901


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

This fixes an unreliable automated test around messaging subscription updates. It helps keep quality checks stable by correctly handling cases where subscriptions are removed, reducing false test failures during development.

Before this PR, the "bus subscription updated when joining locally pinned thread" test was sometimes failing.

Internally, it uses the waitForChannels helper, which was rewritten in [1] to handle subscription updates before the helper is called.

However, the helper only works for channel addition, not deletion. The helper only works in this case due to a race condition.

This PR fixes the helper to properly handle deletion.

runbot-65320

[1]: https://github.com/odoo/odoo/pull/168438

### Current behavior: Auto-trigger reordering rules can be snoozed from the list view. ### Expected behavior: Since the snooze mechanic is here onyl to hide manual reordering rules, a user error should be raised if one tries to snooze an auto-trigger reordering rule. #### + Revert of commit 515a53a opw-3901613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172213 Forward-Port-Of: odoo/odoo#170911

### Current behavior:

Auto-trigger reordering rules can be snoozed from the list view.

### Expected behavior:

Since the snooze mechanic is here onyl to hide manual reordering rules, a user error should be raised if one tries to snooze an auto-trigger reordering rule.

#### + Revert of commit 515a53a

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

Forward-Port-Of: odoo/odoo#172213
Forward-Port-Of: odoo/odoo#170911

This commit will change the invisible condition on the group "group_edi_config" so that the group is not there if empty. task: 4028343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171718

This commit will change the invisible condition on the group "group_edi_config" so that the group is not there if empty.

task: 4028343




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

Forward-Port-Of: odoo/odoo#171718

**Steps to reproduce:** - Install Accounting - In Accounting settings, configure a separate discount account for invoices - Create an invoice: * Customer: [any] * Currency: [a foreign currency] (e.g. EUR) * Invoice Lines: [Price: 100€ - Discount: 50%] - Check the "Journal Items" tab => Amount in currency for the receivable account and the discount account should be 50. Debit and credit should be the corresponding amount in the currency of the company. - Change the currency of the i

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, configure a separate discount account for invoices
- Create an invoice:
  * Customer: [any]
  * Currency: [a foreign currency] (e.g. EUR)
  * Invoice Lines: [Price: 100€ - Discount: 50%]
- Check the "Journal Items" tab => Amount in currency for the receivable account and the discount account should be 50. Debit and credit should be the corresponding amount in the currency of the company.
- Change the currency of the invoice to the currency of the company
- Save the invoice

**Issue:**
When the currency is changed, all the amounts in currency are simply converted to the currency of the company.
Upon save, the "payment_term" line is recomputed to match with the values on the invoice lines, resulting on an amount of $50 for amount in currency, debit and credit. Which is correct.
However, the recomputation doesn't occur for the discount lines, resulting to an incorrect discount amount.

**Solution:**
Recompute the discount lines if the currency rate is changed.

opw-3881661




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

Forward-Port-Of: odoo/odoo#173692

To recreate the bug: 1- Create a loyalty program with a reward of $ per point and a fixed required amount. 2- Test the loyalty program and observe the rewards and points consumed. 3- We see that whenever we have an amount of points exceeding the required amount, they get consumed entirely, and the reward is calculated as total points * ($ per point). The problem here is that when using a loyalty reward with points, it is possible to give partial rewards. This commit prevents partial rewar

To recreate the bug:
1- Create a loyalty program with a reward of $ per point and a fixed required amount.
2- Test the loyalty program and observe the rewards and points consumed.
3- We see that whenever we have an amount of points exceeding the required amount, they get consumed entirely, and the reward is calculated as total points * ($ per point).

The problem here is that when using a loyalty reward with points, it is possible to give partial rewards. This commit
prevents partial rewards.  Example: - Rule: Grant 1 point per product bought; - Reward: 1.5$ per point in exchange of
2 points (3$)  Before this commit, if you buy 3 products, you get 4.5$ by using 3 points. After, you only use 2 points
and get 3$ (no partial reward).

opw-3922835

Forward-Port-Of: odoo/odoo#173354
Forward-Port-Of: odoo/odoo#170129

Steps to reproduce: ------------------- 1. Create a new analytic plan and set it as the default analytic plan in Project settings (it must be different from the 'Projects' plan) 2. Create again a new analytic plan and set its parent to the one you have created in step 1. 3. Create a new analytic account linked to the plan you have just created in step 2. 4. Create a new project and a new task 5. Link the analytic account you have created in step 3. to the task 6. Create a new timesheet li

Steps to reproduce:
-------------------
1. Create a new analytic plan and set it as the default analytic plan in Project settings (it must be different from the 'Projects' plan)
2. Create again a new analytic plan and set its parent to the one you have created in step 1.
3. Create a new analytic account linked to the plan you have just created in step 2.
4. Create a new project and a new task
5. Link the analytic account you have created in step 3. to the task
6. Create a new timesheet linked to the task
7. In Accounting > Analytic Items, the analytic account of the timesheet will not be reported in the plan you created in step 2.

Fix:
-------------------
The 'Projects' plan (the default one) represents the 'account_id' field of analytic.account.line, other plans have names with the following format: 'x_plan{plan.id}_id' (they are fields created on the fly).
When creating a timesheet we were always setting its account.analytic.account to the 'account_id' field by default and ignoring the other plans.
The fix we propose is to look at the top-level plan of the account.analytic.account of the timesheet being created or modified, and link it to the plan it belongs to.
Note that we keep the 'account_id' ('Projects' plan) updated even if the account does not belong to this plan because this field is used in other parts of the code.

Linked PR: https://github.com/odoo/odoo/pull/139225

task-3820916

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

Forward-Port-Of: odoo/odoo#162213

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 Forward-Port-Of: odoo/odoo#173591 Forward-Port-Of: odoo/odoo#173543

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

Forward-Port-Of: odoo/odoo#173591
Forward-Port-Of: odoo/odoo#173543

Steps to reproduce: - Create an employee, leave job position / department empty - Add a contract (top-right of form) - Set job position / department - Set the contract to 'Running' What happens: The employee's job position / department fields stay empty Why is this an issue: The contract autofills with employee information so the same is expected of the opposite interaction. What was done: We should be fine to assume an employee's job is determined by their active contract but to

Steps to reproduce:
- Create an employee, leave job position / department empty
- Add a contract (top-right of form)
- Set job position / department
- Set the contract to 'Running'

What happens:
The employee's job position / department fields stay empty

Why is this an issue:
The contract autofills with employee information so the same is expected of the opposite interaction.

What was done:
We should be fine to assume an employee's job is determined by their active contract but to err of caution this autofill has been set NOT to overwrite the employee's current job if it is already filled in.

opw-4037757

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

Forward-Port-Of: odoo/odoo#173688
Forward-Port-Of: odoo/odoo#172886

Before this commit, rewards associated with archived products were still accessible, leading to errors when attempting to claim them due to the non-existence of the reward product. opw-4055792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173713 Forward-Port-Of: odoo/odoo#173499

Before this commit, rewards associated with archived products were still accessible, leading to errors when attempting to claim them due to the non-existence of the reward product.

opw-4055792

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

Forward-Port-Of: odoo/odoo#173713
Forward-Port-Of: odoo/odoo#173499

We compute the discount amount by calculating the amount before the discount first, and then computing the discount amount from there. If the discount is 100%, we get division by 0 error. If the discount is 100%, we should compute the amount before the discount using price_unit and quantity. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173871

We compute the discount amount by calculating the amount before the discount first, and then computing the discount amount from there. If the discount is 100%, we get division by 0 error.

If the discount is 100%, we should compute the amount before the discount using price_unit and quantity.




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

Forward-Port-Of: odoo/odoo#173871

As observed in https://github.com/odoo/odoo/pull/173442, the commit https://github.com/odoo/odoo/commit/6336366f772b18cd3731cc03f7ff3fc1eeca204a has introduced a bug for search panel filters that are based on many2many that are not groupable. Indeed, the computation of the domain image is done via _search_panel_domain_image that uses read_group and for many2many that are not groupable it is not allowed to use read_group. We fix that bug by computing the domain image via a search_read when the ma

As observed in https://github.com/odoo/odoo/pull/173442, the commit https://github.com/odoo/odoo/commit/6336366f772b18cd3731cc03f7ff3fc1eeca204a has introduced a bug for search panel filters that are based on many2many that are not groupable. Indeed, the computation of the domain image is done via _search_panel_domain_image that uses read_group and for many2many that are not groupable it is not allowed to use read_group. We fix that bug by computing the domain image via a search_read when the many2many is not groupable.

opw-4055494

Forward-Port-Of: odoo/odoo#173898
Forward-Port-Of: odoo/odoo#173538

Fiscal position using 2 taxes including in price are not working in PoS. If you use the fiscal position only the tax should change, not the total price, as both tax are included in price. Steps to reproduce: ------------------- * Create two taxes that are included in price * Create a fiscal position matching those 2 taxes * Create a product using the first tax * Open PoS session, and add the product to the order * Price should be for example 100€ * Now change the fiscal position to the

Fiscal position using 2 taxes including in price are not working in PoS. If you use the fiscal position only the tax should change, not the total price, as both tax are included in price.

Steps to reproduce:
-------------------
* Create two taxes that are included in price
* Create a fiscal position matching those 2 taxes
* Create a product using the first tax
* Open PoS session, and add the product to the order
* Price should be for example 100€
* Now change the fiscal position to the one you created
> Observation: Price of the product changed when it shouldn't have

Why the fix:
------------
When computing the price of the product with a fiscal position, if the previous tax is included in price and the new one is also included in price, the price of the product shouldn't change. So instead of recomputing the price of the product with the new tax based on the previous tax excluded price. We just use the price of the product

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

Forward-Port-Of: odoo/odoo#172487
Forward-Port-Of: odoo/odoo#169223

Current behavior: After settling the payment of an order, the order remains in the orders list Steps to reproduce: - Install "Point of Sale" and "Sales" apps - Start a shop session, select an order and proceed to the payment - Go back to the orders list and see the paid order still there Note: Forward the test of https://github.com/odoo/odoo/pull/171609 opw-4019204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/

Current behavior:
After settling the payment of an order, the order remains in the orders list

Steps to reproduce:
- Install "Point of Sale" and "Sales" apps
- Start a shop session, select an order and proceed to the payment
- Go back to the orders list and see the paid order still there

Note: Forward the test of  https://github.com/odoo/odoo/pull/171609

opw-4019204


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

Forward-Port-Of: odoo/odoo#173501
Forward-Port-Of: odoo/odoo#173103

In some places, `unlink()` and `mapped()` are used on the result. To avoid error, let's return empty recordset. Examples:   --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173454

In some places, `unlink()` and `mapped()` are used on the result. To avoid error, let's return empty recordset.

Examples:

![Selection_3565](https://github.com/user-attachments/assets/86691039-1536-4e54-8d1a-83ef941ef859)

![Selection_3564](https://github.com/user-attachments/assets/049aa4f1-1cc0-4e5f-bcdd-4c64aeb3e52c)



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

Forward-Port-Of: odoo/odoo#173454

Steps: -Go to your /shop page. -Disable the search bar from the editor. -Configure several pricelists as selectable. Issue: When the search bar is disabled and multiple pricelists are selectable,'Sort by' dropdown does not align correctly, causing it to appear in the middle of the page instead of to the left, just after the pricelists. Fix: Applied the me-auto class to the 'Sort by' dropdown, ensuring it aligns correctly to the left within its container. opw-3994784 --- I co

Steps:
-Go to your /shop page.
-Disable the search bar from the editor.
-Configure several pricelists as selectable.

Issue:
When the search bar is disabled and multiple pricelists are selectable,'Sort by'
dropdown does not align correctly, causing it to appear in the middle of the
page instead of to the left, just after the pricelists.

Fix:
Applied the me-auto class to the 'Sort by' dropdown, ensuring it aligns
correctly to the left within its container.

opw-3994784

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

Forward-Port-Of: odoo/odoo#170988

Currently, when using a company with french localization, if you try deleting lines on a draft order in the session, a new line is created to make the correction. Steps to reproduce: ------------------- * Switch to a company with french localisation * Open Pos shop session * Add products to the cart * Go to the backend * Go back to the session * Try deleting a line > Observations: A new line is added with negative quantity to cancel out the line we wanted to delete. Instead of just re

Currently, when using a company with french localization, if you try deleting lines on a draft order in the session, a new line is created to make the correction.

Steps to reproduce:
-------------------
* Switch to a company with french localisation
* Open Pos shop session
* Add products to the cart
* Go to the backend
* Go back to the session
* Try deleting a line
> Observations: A new line is added with negative quantity to cancel out the line we wanted to delete. Instead of just removing the first line.

Why the fix:
------------
The line correction of the POS certification for the French localization is too restrictive. The law says that correction on validated orders should be made on new lines. For the order that are not validated, the lines can be changed normally.

This is a backport of what will be merged in master as it is a compatible change in stable versions.

This should not break the inalterability chain as you only pass through the functions `disallowLineQuantityChange()` and
`can_be_merged_with()` with orders that are not locked (i.e. they have not been paid yet).

Related ongoing task-id: 3874373

opw-3865724

Forward-Port-Of: odoo/odoo#173728
Forward-Port-Of: odoo/odoo#165468

Steps to reproduce the bug: - Create a storable product “P1” - Go to Operation Type > Return > Enable "Create repair from return" - Create a delivery order with one unit of "P1" and validate it - Return the delivered "P1" - Create a repair order from this return - Select "P1" as the product to repair - Save (important step) - Add any product as a part of the repair, e.g., "Part 1” - Save - Go back to the return picking Problem: The product “Part 1” is linked to the return-picking.

Steps to reproduce the bug:
- Create a storable product “P1”
- Go to Operation Type > Return > Enable "Create repair from return"
- Create a delivery order with one unit of "P1" and validate it
- Return the delivered "P1"
- Create a repair order from this return
- Select "P1" as the product to repair
- Save (important step)
- Add any product as a part of the repair, e.g., "Part 1”
- Save
- Go back to the return picking

Problem:
The product “Part 1” is linked to the return-picking.

When the "repair" button is clicked to create the repair order,
the function `action_repair_return` is triggered, adding
`default_picking_id` in the context to link the repair to the picking.
https://github.com/odoo/odoo/blob/bee32f88d42d9b945ec7216e2496e0167d3904b4/addons/repair/models/stock_picking.py#L40

However, this context is not cleared after the creation of the repair,
therefore, when creating the stock move, this picking is added to the
values of the moves due to the `_add_missing_default_values` function.
Despite attempting to set `default_picking_id = False` for these moves,
this will be ignored because the field `picking_id` is not present in
this list view.

**Solution:**
Using `default_picking_id` in the context to create the repair order
does not seem to be a good idea. This is the third issue related to this
problem; two other fixes have already been made to address the
propagation of these default keys. Therefore, it seems more logical to
use the `default_get` function instead to avoid bugs related to this.

https://github.com/odoo/odoo/commit/e822ec35c37237a9c137771d1d7266188a1877e8

https://github.com/odoo/odoo/commit/a32fb7b3e12ddae1ef7ebd78fa4877b2dbdbe6b1

opw-[4029460](https://www.odoo.com/web#id=4029460&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#172786

Issue: ============================ There is a missing synchronization between the stock move line and stock move for manufacturing orders, by-products, and batch transfers. When clicking on the list icon and making changes in quantity in the detailed operation modal, the updates are not properly reflected. Resolution: ============================ For manufacturing and by-products, add a "quantity" field in the 'detailed operation' view so that whenever the save button is clicked, al

Issue:
============================
There is a missing synchronization between the stock move line and stock move
for manufacturing orders, by-products, and batch transfers. When clicking on
the list icon and making changes in quantity in the detailed operation modal,
the updates are not properly reflected.

Resolution:
============================
For manufacturing and by-products, add a "quantity" field in the 'detailed 
operation' view so that whenever the save button is clicked, all fields are 
updated properly. For batch transfers, save '_parentRecord' instead of
'model.root' when the save button is clicked.

Steps to Reproduce:
============================
1. Install the mrp and stock modules.
2. Navigate to the stock module.
3. For manufacturing, go to the manufacturing menu inside operations.
   For by-products, go to the by-products tab inside the manufacturing order
   form view.
   For batch transfers, go to the batch transfer menu inside operations.
4. In the form view of each, open the modal (Detailed Operations) and modify
   the quantity.
5. Notice the lack of synchronization between the stock move line and the
   stock move.

Expected Result:
=============================
After implementing the solution, changes in quantities should be synchronized
between the stock move line and the stock move in manufacturing orders,
by-products, and batch transfers. When clicking on the list icon, the
quantities should be updated accurately, reflecting any changes made.

Task: 3815521

Forward-Port-Of: odoo/odoo#160095

revert of https://github.com/odoo/odoo/commit/95abe082c27525c0a22a07c6457ea408163f339f it's not supposed to reach saas-17.1 and higher Forward-Port-Of: odoo/odoo#173994

revert of https://github.com/odoo/odoo/commit/95abe082c27525c0a22a07c6457ea408163f339f

it's not supposed to reach saas-17.1 and higher

Forward-Port-Of: odoo/odoo#173994

Several payroll, accounting report, and web export areas were updated to use newer CSV handling behind the scenes. This reduces future maintenance risk and improves portability across server environments without changing the day-to-day user experience.

The documents-to-dashboard modal now shows placeholder guidance for choosing a dashboard section. This helps users understand what to select and reduces confusion when adding document content to dashboards.

Added a placeholder for the dashboard section in the modal template to guide users in selecting a section.

Task: 3918035

Vendor bill lines created from OCR imports are now marked as imported so later product changes do not overwrite their captured prices and taxes. This helps preserve invoice data extracted from documents and avoids unexpected recalculations during bill review.

When changing the product on the vendor bill line, the price and taxes are recomputed. The corresponding community PR uses a flag to disable the computation for lines that have been imported. Since the OCR feature writes the lines later, the flag is set explicitly on created lines.

Task-3837975

Adds a clear connection status for IoT boxes using websockets, making it easier to see whether a box is actively connected. This helps teams diagnose report printing issues faster without digging into technical connection details.

Before this PR, there was no easy way to identify if an IoT box was connected with a websocket, potentially making debugging report printing difficult.

This PR adds an `is_websocket_active` field to the IoT box model, which defaults to False but is set to True when it subscribes to the websocket. If the websocket is closed by Odoo, it is set to False again.

Community PR: https://github.com/odoo/odoo/pull/173286
Task ID: 4045291

Payslips can now show year-to-date totals for each payment and deduction, making it easier for employees and payroll teams to understand cumulative earnings and deductions during the year. Payroll administrators can choose when these totals reset and control whether they appear by payroll structure type or individual salary rule.

The "Year to Date" (YTD) field shows the accumulated total of each payment/deduction of the current year in the payslip (in a YTD column).

The reset date of the YTD is customizable.
YTD can be toggled on the structure type scale, and also on each single rule.

task-4001255

The expense app’s “Try Sample Receipt” option is now available regardless of a user’s access rights, making the onboarding experience more consistent. Tour instruction text was also updated to make the guided experience clearer for users.

* `Try Sample Receipt` button is available whatever the access rights.
* Modify some text in tours instructions.

task-3859580

Odoo PR: https://github.com/odoo/odoo/pull/164373

The accounting dashboard no longer shows separate expense-related warnings because the same journal entries are already covered by vendor bill warnings. This reduces duplicate alerts and helps accounting users focus on the most relevant dashboard items.

This commit remove the warnings we have on the accounting dashboard, as the journals entries are already included in the vendor bills warnings.

task:3877069

Salary rules that depend on a payslip input will now be displayed correctly, even when their payment amount is calculated another way. This prevents valid payroll rules from being hidden and helps ensure payslips are computed as expected.

Issue: If you create a salary rule with a condition based on an input but with something else than input for the amount, the rule will not be shown.

Expected: The rule should be shown if the input is present in the payslip and the computation should happen normally.

Fix: When checking if the rule should be shown or not, we were looking at the wrong field that is related to the amount and not the condition.

Fixes an installation error in the Swedish Point of Sale localization caused by an outdated daily sales report reference. Businesses using Swedish POS can install and use the module without being blocked by this report template issue.

### Steps to reproduce:
- Install pos_l10n_se
- the error `Element '<xpath expr="//div[hasclass('page')]">' cannot be located in parent view`

### Investigation:
- the reason for the error is that the `pos_daily_reports.xml` in `pos_l10n_se` refers to the no longer relevant `report_saledetails` template as it has been updated in [b3a6688a711a9229c7bfca60adf9594ad23a952d](https://github.com/odoo/odoo/pull/171383/commits)

A test tour in Website Studio was made more precise so it waits for the right page update before continuing. This reduces false failures in automated checks and helps keep releases stable without changing user-facing behavior.

in tour engine, we listen for mutations in the DOM in order to look for the element pointed to by the "trigger". If it is found, we execute run().
In this tour, the div[name='name_slugified'] element is found even before the textContent modifications have been made. To resolve the problem, simply be more precise in the trigger selector. It should be noted that we can therefore remove the first assertion in run() which amounts to doing exactly the same thing as the trigger.

This update restores the date filter behavior in the Mexican closing reports after a broader reporting change left this module out. Users working with these reports should now see date filtering work consistently with the rest of the accounting reports.

The commit 6fe06c57fa7d4bce9ad9a9df0f773678047b9d06 changed the way the date filter works in the account reports. During the change, it forgot to apply the change to this niche localisation module.

This update corrects several internal filters and default values across multiple Odoo apps so they no longer require unnecessary processing. It should make these screens and automated rules behave more consistently without changing day-to-day workflows.

The Twitter wall features for websites and events have been removed from Odoo Enterprise. Businesses using these event or website Twitter display tools will need to plan an alternative, and an upgrade script is expected to help handle existing installations.

*: website_event_twitter_wall

See community commit for details.

task-4008369

(will need to create an upgrade script)

This update strengthens an internal accounting test so it will catch accidental changes to the signature field name. It helps protect the reliability of the signature-related accounting workflow without changing how users interact with the system.

The aim of this commit is to ensure the test fail in case the sign_signature field gets renammed.

Originally, it was made to avoid a query but it is insignificant.

task: none

This addresses several issues: - on 'register_consumed_materials' & 'register_byproducts' quality checks, the quantity entered and the selected lot were not saved - make this view clearer by separating the product and the other fields - 'print' & 'next' barcode triggers were sometimes capitalized, making them inoperant - fix component remaining quantity when no producing quantity has been set - generate a new pdf for barcodes: add print barcode & new ghostscript version seems t

This addresses several issues:

- on 'register_consumed_materials' & 'register_byproducts' quality checks, the quantity entered and the selected lot were not saved

- make this view clearer by separating the product and the other fields

- 'print' & 'next' barcode triggers were sometimes capitalized, making them inoperant

- fix component remaining quantity when no producing quantity has been set

- generate a new pdf for barcodes: add print barcode & new ghostscript
  version seems to solve some erratic scanning problems

task: 3987346

Forward-Port-Of: odoo/enterprise#66863
Forward-Port-Of: odoo/enterprise#65396

…invoices Steps to Reproduce on Runbot: 1. Set up AvaTax in Accounting settings 2. Make sure that the “Use AvaTax API” field is checked for the fiscal position named “Automatic Tax Mapping (AvaTax)” 3. Go to “Tax Groups” and for the record called “Tax 15%”, add “Test” to the field called “Preceding Subtotal” 4. Go to the Product Category called “All” and choose any selection for the field called “AvaTax Category” 5. Make an invoice and add the fiscal position named “Automatic Tax Mappi

…invoices

Steps to Reproduce on Runbot:

1. Set up AvaTax in Accounting settings
2. Make sure that the “Use AvaTax API” field is checked for the fiscal position named “Automatic Tax Mapping (AvaTax)”
3. Go to “Tax Groups” and for the record called “Tax 15%”, add “Test” to the field called “Preceding Subtotal”
4. Go to the Product Category called “All” and choose any selection for the field called “AvaTax Category”
5. Make an invoice and add the fiscal position named “Automatic Tax Mapping (AvaTax)”
6. Save then print the invoice. Notice on the printed invoice that above the box called “Total”, the box called “Untaxed Amount” shows up with no tax box.
7. Uncheck the “Use AvaTax API” field for the fiscal position named “Automatic Tax Mapping (AvaTax)” (This step is basically the inverse of step 2)
8. Print the invoice again and notice this time that the box will instead be called “Test” (which we set in step 3) and that a box showing the tax amount will show up.

This commit fixes the issue so that the value in "Preceding subtotal" is shown for printed Avatax invoices too.

opw-4027280

Forward-Port-Of: odoo/enterprise#66932

When `industry_fsm` is installed, the form of `project.project` contains a section `Field Service` with only one setting (`is_fsm`). This option is only visible in only visible in debug mode, so the whole section should be displayed only under this conditon. => The group `base.group_no_one` has been added to the section. When `industry_fsm_report` is installed, another setting appears under that section (`worksheet_template_id`), so the section should be displayed. => The group that is adde

When `industry_fsm` is installed, the form of `project.project` contains a section `Field Service` with only one setting (`is_fsm`). This option is only visible in only visible in debug mode, so the whole section should be displayed only under this conditon. => The group `base.group_no_one` has been added to the section.

When `industry_fsm_report` is installed, another setting appears under that section (`worksheet_template_id`),
so the section should be displayed.
=> The group that is added in `industry_fsm` is removed then.

task-3916982

Forward-Port-Of: odoo/enterprise#62270

How to reproduce (on 17.0 onwards): - Helpdesk -> new ticket form - set the name of the ticket (do not save the record) - then, set a partner to a existing partner - The display_name on the top displays 'name - #False' Expeceted behavior: - instead of displaying 'name - #False', it should display 'name' if the ticket_ref is not defined yet. After this commit, the display_name only displays the ticket_ref (#ID) if it exists. Test have been added for this purpose. Task: 3893076 Forw

How to reproduce (on 17.0 onwards):
- Helpdesk -> new ticket form
- set the name of the ticket (do not save the record)
- then, set a partner to a existing partner
- The display_name on the top displays 'name - #False'

Expeceted behavior:
- instead of displaying 'name - #False', it should display 'name' if the ticket_ref is not defined yet.

After this commit, the display_name only displays the ticket_ref (#ID) if it exists. Test have been added for this purpose.

Task: 3893076

Forward-Port-Of: odoo/enterprise#66471

Problem --- When a stock picking is clicked from the barcode view, its responsible is always automatically assigned to the current user. Fix --- assign current user only if they change anything (validate, edit a line, etc) but not if they just look. opw-3878484 Forward-Port-Of: odoo/enterprise#66897 Forward-Port-Of: odoo/enterprise#61456

Problem
---
When a stock picking is clicked from the barcode view,
its responsible is always automatically assigned to the current user.

Fix
---
assign current user only if they change anything (validate, edit a line,
etc) but not if they just look.

opw-3878484

Forward-Port-Of: odoo/enterprise#66897
Forward-Port-Of: odoo/enterprise#61456

To reproduce: Create a branch for your company On this branch, create an overdue invoice for a partner. Change company for the parent company. Go to Follow-up Reports Go on this partner. You see the invoice appearing in the list Click on Follow-up and print => The pdf does not contain the invoice from the branch The issue is that we check on company and not on the company and branches. opw-3988003 Forward-Port-Of: odoo/enterprise#66896

To reproduce:
Create a branch for your company
On this branch, create an overdue invoice for a partner. 
Change company for the parent company.
Go to Follow-up Reports
Go on this partner.
You see the invoice appearing in the list
Click on Follow-up and print
=> The pdf does not contain the invoice from the branch

The issue is that we check on company and not on the company and branches.

opw-3988003

Forward-Port-Of: odoo/enterprise#66896

With task-3336242, the control panel's dropdown button's display condition was changed from <= xl display to <= md display. Hence, this PR changes the display condition of buttons in the planning gantt view to align with this new behavior. The bootstrap classes that were used to attain this effect are now removed, replaced by a t-if="env.isSmall". This allows us to have only one of the two implementation present in the dom, and to change the display condition to <= md. task-4005521 Forwar

With task-3336242, the control panel's dropdown button's display condition was changed from <= xl display to <= md display. Hence, this PR changes the display condition of buttons in the planning gantt view to align with this new behavior.

The bootstrap classes that were used to attain this effect are now removed, replaced by a t-if="env.isSmall". This allows us to have only one of the two implementation present in the dom, and to change the display condition to <= md.

task-4005521

Forward-Port-Of: odoo/enterprise#65301

The settle due accounts was not always shown on the partner screen. Now it's always shown, and when the user doesn't have any amount due the text changes to "Deposit Money" instead of "Settle Due Accounts" Steps to reproduce: ------------------- * Install pos_settle_due module * Open PoS session * Open partner list * Click on details for any partner with no due > Observation: The "Settle Due Accounts" button is missing Why the fix: ------------ We always show the button, but change

The settle due accounts was not always shown on the partner screen. Now it's always shown, and when the user doesn't have any amount due the text changes to "Deposit Money" instead of "Settle Due Accounts"

Steps to reproduce:
-------------------
* Install pos_settle_due module
* Open PoS session
* Open partner list
* Click on details for any partner with no due
> Observation: The "Settle Due Accounts" button is missing

Why the fix:
------------
We always show the button, but change the text to better match the behavior. If there is no amount due the text says "Deposit Money" and when the user has some amount due it says "Settle Due Accounts"

opw-3925397

Forward-Port-Of: odoo/enterprise#66768
Forward-Port-Of: odoo/enterprise#65762

Community: https://github.com/odoo/odoo/pull/173324 Design Themes: https://github.com/odoo/design-themes/pull/831 Forward-Port-Of: odoo/enterprise#66743

Community: https://github.com/odoo/odoo/pull/173324
Design Themes: https://github.com/odoo/design-themes/pull/831

Forward-Port-Of: odoo/enterprise#66743

Context: On an upgraded database we detected that the resource calendar inherited views where disabled, because they were not able to find parent element. The full timeline is as below: - 2021-01-01: commit odoo/enterprise@1d9fdd624497 introduced `hr_payroll.resource_calendar_view_tree` view - 2021-02-05: commit odoo/enterprise@0506d4e6fa18 introduced `hr_contract.resource_calendar_view_tree` view (with `contracts_count` field) - 2024-07-02: commit odoo/enterprise@1f03fb675922 updated

Context:

On an upgraded database we detected that the resource calendar inherited views where disabled, because they were not able to find parent element.

The full timeline is as below:

- 2021-01-01: commit odoo/enterprise@1d9fdd624497 introduced `hr_payroll.resource_calendar_view_tree` view
- 2021-02-05: commit odoo/enterprise@0506d4e6fa18 introduced `hr_contract.resource_calendar_view_tree` view (with `contracts_count` field)
- 2024-07-02: commit odoo/enterprise@1f03fb675922 updated `hr_payroll.resource_calendar_view_tree` view to add a field after `contracts_count` field.

For databases that were update with each individual changes (at specified date), the `hr_payroll` inherited view will have a lower id than the `hr_contract` one and as such will be applied before (considering the standard view order).

  And following commit odoo/enterprise@1f03fb675922 this will raise a ValidationErorr:

`Element '<field name="contracts_count">' cannot be located in parent view`

This commit update `hr_payroll.resource_calendar_view_tree` view to inherit from the view that really add the `contracts_count` field.

Forward-Port-Of: odoo/enterprise#66913

Steps to Reproduce: ----------- Install the helpdesk_account and helpdesk_sale_timesheet module. Go to the ticket form view. Perform a refund or reverse action. Click on the 'Credit Notes' stat button. Observe that the list view of credit notes is empty. Cause: ---------- When the helpdesk_sale_timesheet module is installed, the action_view_invoices method gets overridden. Fix: --------- We have renamed the actions in the helpdesk_account module to avoid conflicts

Steps to Reproduce:
-----------

  Install the helpdesk_account and helpdesk_sale_timesheet module.
  Go to the ticket form view.
  Perform a refund or reverse action.
  Click on the 'Credit Notes' stat button.
  Observe that the list view of credit notes is empty.

Cause:
----------
  When the helpdesk_sale_timesheet module is installed, the action_view_invoices method gets overridden.

Fix:
---------
  We have renamed the actions in the helpdesk_account module to avoid conflicts.

task-3972344

Forward-Port-Of: odoo/enterprise#65859

Steps to reproduce: - Open planning app - Create a shift for user who has leave during the slot. - You will get an warning in the form view. Issue: - Warning is not aligned vertically Cause; - This is not issue of alignment but due to a empty div created for conflict slot warning. Solution: - A constraint to stop the empty div which causes alignment issues task-3888018 Forward-Port-Of: odoo/enterprise#62645

Steps to reproduce:

- Open planning app
- Create a shift for user who has leave during the slot.
- You will get an warning in the form view.

Issue:

- Warning is not aligned vertically

Cause;

- This is not issue of alignment but due to a empty div created for conflict slot warning.

Solution:

- A constraint to stop the empty div which causes alignment issues

task-3888018

Forward-Port-Of: odoo/enterprise#62645

Before this commit, in about 8% of the time for some test tours, some edition of the report was triggered before the OdooEditor had a chance to start, so the concerned step failed. After this commit, there is no such race condition, as we add OdooEditor's specific class to the step selectors. runbot-error-29949 (and all linked error) Forward-Port-Of: odoo/enterprise#66886 Forward-Port-Of: odoo/enterprise#66815

Before this commit, in about 8% of the time for some test tours, some edition of the report was triggered before the OdooEditor had a chance to start, so the concerned step failed.

After this commit, there is no such race condition, as we add OdooEditor's specific class to the step selectors.

runbot-error-29949 (and all linked error)

Forward-Port-Of: odoo/enterprise#66886
Forward-Port-Of: odoo/enterprise#66815

This commit adds the missing neutralization necessary for the l10n_fr_reports module introduced in 06f32096749a8df29b248f29698226cf996e9106 The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of th

This commit adds the missing neutralization necessary for the l10n_fr_reports module introduced in
06f32096749a8df29b248f29698226cf996e9106

The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database.

This is mainly useful to allow safe support investigation on database duplicates.

opw-3928199

Forward-Port-Of: odoo/enterprise#66838

This fix resolves a system crash that occurred when restaurant staff added an empty internal note to a product order in the Point of Sale system. The issue caused the order processing to fail with a technical error. With this fix, empty internal notes are now handled correctly, allowing orders to process smoothly without interruption.

When a customer adds an empty internal note and tries to order the product,
a traceback will appear.

Steps to reproduce the error:
- Open PoS restaurant session
- Add any product > Order
- Add same product again > Add an empty internal note
- Order

Traceback:
```
KeyError: (3, 'pou', '[]')
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/saas-17.2/pos_restaurant_preparation_display/models/preparation_display_order.py", line 33, in process_order
    res = super().process_order(order_id, cancelled, note_history)
  File "home/odoo/src/enterprise/saas-17.2/pos_preparation_display/models/preparation_display_order.py", line 28, in process_order
    data = order._process_preparation_changes(cancelled, note_history)
  File "home/odoo/src/enterprise/saas-17.2/pos_preparation_display/models/pos_order.py", line 95, in _process_preparation_changes
    quantity_data[key_new]["display"] += old_quantity["display"]
```

https://github.com/odoo/enterprise/blob/4077a5e39fba7197d32d5db05171ad9c8f98c392/pos_preparation_display/models/pos_order.py#L95
Here when customer adds an empty internal note, ```quantity_data``` will become empty,
So, it will lead to the above traceback.

sentry-5494183916

This fix resolves critical issues with the barcode app when managing inventory across multiple companies. Previously, scanning barcodes would sometimes open operations from the wrong company, create unauthorized records, or trap users in the interface. The fix ensures that barcode operations respect the currently active company and prevents creation of records the user doesn't have permission to access.

**Current behavior:**
There are several related bugs when operating in a multi-company
environment with the barcode app:

*Given:* we have three companies in the selector (A, B, C) where
company A is the first/default/primary of the three.

***Case 1: (CompanyB and CompanyC are checked, either can be focused)***
1) Scanning the barcode for CompanyC's manufacturing operation and
then, within the barcode view, scanning a product which belongs
exclusively to CompanyB will make it impossible to use the back
button (despite the product correctly not being added as a line
in the operation).

2) Repeating the setup with a different operation type (e.g.,
receipt) *will* add the product to the picking but it will not
be possible to validate/take out of draft from either the
barcode app nor from the backend.


***Case 2: (only CompanyC checked and focused)***
1) Scanning the barcode for CompanyC's manufacturing operation type
will open the barcode operation view for CompanyA's manufacture
operation. Products available to CompanyC can be added. Trying
to validate the order will cause an access error, however the MO
is still created in the backend.

2) Scanning the barcode for either CompanyB or CompanyA's
non-manufacturing operations will show an access error dialog,
but an (empty) transfer will still be created in the backend for
the respective company.

---

**Expected behavior:**
In case 1, scanning a product which is not available to the
current company should not trap the user in the barcode
operation view. It should also not add these inaccessible
products to a picking thereby making them unable to be
validated.

In case 2, we should respect the company defined on a
manufacturing operation type which corresponds to a scanned
barcode. Additionally, it should not be possible to create empty
transfers for companies which are not currently checked/active.

---

**Cause of the issue:**
Problem 1: production records (unlike pickings) cannot be
created until a product is added in the barcode view. Because of
this different flow, they are created with less context than
other operation types and there was no mechanism by which their
`company_id` could be inferred.

This caused them to use the default value as defined in the
`MrpProduction` model (`self.env.company`)- which is problematic
in the barcode app, as this field does not actually correspond
to the focused/active company.

Problem 2: when scanning a picking type from the main menu of
the barcode app, the company of the picking type was not getting
respected which would cause a new picking record to be created
even when the current user/environment did not have permission.

---

**Fix:**
1. Create production records using a default `company_id` value
informed by their `picking_type_id` rather than the environment

2. In the main_menu barcode scan route, use the current user's
allowed company ids (from their cookies) to restrict searchable
records

3. When scanning products in a barcode operation view, use the
company_id of the opened operation type to restrict the domain
of searchable records.

opw-3999622

Fixed an issue where the shopfloor display was showing all workcenters instead of only the one selected when opening from a specific workcenter, workorder, or production order. This improvement helps users focus on their relevant work area and reduces confusion when managing multiple production lines.

When opening the shopfloor from a specific workcenter, workorder or production order, only the concerned workcenter should be shown.

task-4060857

Fixed an issue where only the first 25 WhatsApp message templates were being synced when users attempted to sync all templates from their WhatsApp Business Account. The system now properly fetches all available templates by requesting up to 200 per page and automatically retrieving additional pages as needed, ensuring users have access to their complete template library.

Only a few templates are fetched when the user tries to sync all the templates from the `WhatsApp Business Account` form view.

Problem:

The API request used to fetch all templates incorporates pagination. In the current scenario, the next URL to the subsequent page is included in the response, but we are not using it. Also, the limit parameter is not utilized in our API request to restrict the number of templates on a single page. Consequently, by default, 25 templates are received on the first page. As a result, only templates received on the first page are being created or updated(i.e. 25).

Solution:

The limit to fetch 200 templates on a single page is added to obtain 200 templates in the first request. However, if there are more than 200 templates, the remaining ones will be fetched from the next page. This process will continue in a loop until all templates are received.

Task-3903321

The technical information for IoT devices has been reorganized into a dedicated "Technical Information" tab for better clarity and organization. This change improves the user interface by separating technical details from other device information, making it easier for users to find what they need.

Moved iot.box view technical information to "Technical Information" tab.

Task: 4033301

The system now stores all IoT device configurations (database URL, enterprise code, authentication tokens, etc.) in a single JSON file instead of multiple separate text files. This change makes configuration management simpler and more efficient for the IoT hardware driver system.

We currently save all configurations (db url, enterprise code, token, ...) in different text files. Now we store them all in a simple json file (config.json), easy to write and load from python.

Task: 2093535

Community PR: [https://github.com/odoo/odoo/pull/173866](https://github.com/odoo/odoo/pull/173866)