Follow-up of https://github.com/odoo/odoo/pull/203142 PR above made several style improvements, one of which is to make the "mark as read" button on messaging menu item look more like a button: it looks like an icon, now this outline and squared like other buttons. To have a similar size as the counter, it had the `.badge` classname. The `.badge` classname has to do some shenanigans to have constant width for 1-digit values, one of which is to set a minimum width of `2.7ch`. When the "m

Follow-up of https://github.com/odoo/odoo/pull/203142

PR above made several style improvements, one of which is to make the "mark as read" button on messaging menu item look more like a button: it looks like an icon, now this outline and squared like other buttons.

To have a similar size as the counter, it had the `.badge` classname. The `.badge` classname has to do some shenanigans to have constant width for 1-digit values, one of which is to set a minimum width of `2.7ch`.

When the "mark as read" button was changed, this become a button but the `.badge` classname was mistakenly kept. As a result, it kept `min-width: 2.7ch`, which made the width too large on this button. `min-width: 2.7ch` should not be used on the same node as `.fa`, as the width of font-awesome glyph is bigger than badge numbers.

This commit fixes by removing the `.badge` classname altogether, so the button is sized properly. Another fix could have been to put the `.fa.fa-check` in child-node, but that results in the same visual so removing `.badge` results in simpler template. As the "mark as read" is a button with outline, there's also no longer need to have exact width as a badge.

Task-4770926

Before
<img width="478" alt="Screenshot 2025-05-05 at 16 55 22" src="https://github.com/user-attachments/assets/dc5ca989-be1d-436e-84e4-57b450f66908" />

After
<img width="476" alt="Screenshot 2025-05-05 at 16 54 32" src="https://github.com/user-attachments/assets/06f99cb0-4ab4-4090-80ea-48e71970e80a" />

Forward-Port-Of: odoo/odoo#208462

Since tax fields might filter on domestic taxes (product taxes), we must ensure that a domestic fp is properly set in all l10ns. l10n_fr did not have a domestic fiscal position because the domestic fp applied to the country group France and Monaco. To resolve this, the domestic fiscal position is split into 2 (one for France and one for Monaco) and all taxes are assigned to both fiscal positions. To avoid this scenario in new localisations, a check is added to the all_l10n standalone test.

Since tax fields might filter on domestic taxes (product taxes), we must ensure that a domestic fp is properly set in all l10ns.
l10n_fr did not have a domestic fiscal position because the domestic fp applied to the country group France and Monaco.
To resolve this, the domestic fiscal position is split into 2 (one for France and one for Monaco) and all taxes are assigned to both fiscal positions.

To avoid this scenario in new localisations, a check is added to the all_l10n standalone test.

Forward-Port-Of: odoo/odoo#208810

Versions -------- - 16.0+ Steps (saas-17.4) ----------------- 1. Install `l10n_ar_website_sale`; 2. run `:TestWebsiteSaleProductFilters` test suite. Issue ----- 2 tests fails. Cause ----- The filters search for sale orders from `get_current_website`. Even though the correct website is passed to the `MockRequest`, the result of the call is a website from an Argentinian company with no sales orders. Solution -------- Add `force_website_id` to the `MockRequest` session, so `g

Versions
--------
- 16.0+

Steps (saas-17.4)
-----------------
1. Install `l10n_ar_website_sale`;
2. run `:TestWebsiteSaleProductFilters` test suite.

Issue
-----
2 tests fails.

Cause
-----
The filters search for sale orders from `get_current_website`. Even though the correct website is passed to the `MockRequest`, the result of the call is a website from an Argentinian company with no sales orders.

Solution
--------
Add `force_website_id` to the `MockRequest` session, so `get_current_website` returns the intended website: https://github.com/odoo/odoo/blob/1ea4f285aba925d437a5129cd36143d9987c6e6a/addons/website/models/website.py#L1121

> [!Note]
> Alternatively, we can check for `request.website` being set in `get_current_website`. No idea if there's a reason it doesn't already.

runbot-111554
runbot-111555

Forward-Port-Of: odoo/odoo#208887
Forward-Port-Of: odoo/odoo#201433

Versions -------- - 18.0+ Steps ----- 1. Have a service product that creates a task on confirm; 2. add product to a SO; 3. add description to the line; 4. confirm the order; 5. go to the task. Issue ----- The task only has the SO and service product name as title. This is different from earlier versions, where it would include the first line of the line's description. Cause ----- When creating a task from an order line, it uses the first line of the line name as part of the

Versions
--------
- 18.0+

Steps
-----
1. Have a service product that creates a task on confirm;
2. add product to a SO;
3. add description to the line;
4. confirm the order;
5. go to the task.

Issue
-----
The task only has the SO and service product name as title. This is different from earlier versions, where it would include the first line of the line's description.

Cause
-----
When creating a task from an order line, it uses the first line of the line name as part of the task name, and adds the rest to the description.

Starting from 18.0, the product & description columns are merged in order & invoice views. A side-effect of this, is that the product name will always be present as the first line of the product, and any added description will start from the second line. Consequently, it's no longer possible to add a description to the line that would get used as task name.

Solution
--------
Use the first two lines of the sale line name to form a task title.

opw-4634149
opw-4637902

Forward-Port-Of: odoo/odoo#204112

Sale status was not correctly set when ticket where sold from the POS. Steps to reproduce: ------------------- * Create an event and make sure ticket can be sold in PoS * Open PoS * Add a ticket to the order and complete the order * Add another ticket to the order but go to the backend to save it as draft > Observation: The sale status of the order appears as 'free' when it should be "Sold" and "Not Sold" Why the fix: ------------ We make sure to take the state of the PoS order

Sale status was not correctly set when ticket where sold from the POS.

Steps to reproduce:
-------------------
* Create an event and make sure ticket can be sold in PoS
* Open PoS
* Add a ticket to the order and complete the order
* Add another ticket to the order but go to the backend to save it as
  draft
> Observation: The sale status of the order appears as 'free' when it
should be "Sold" and "Not Sold"

Why the fix:
------------
We make sure to take the state of the PoS order when the ticket has been
sold through the PoS.

opw-4584390

Forward-Port-Of: odoo/odoo#208339
Forward-Port-Of: odoo/odoo#204514

Before this commit, the background color of discuss mobile mailbox selection was `.bg-view`. This is not a problem in white theme, but in dark theme this is too light, which makes it hard to see this is a button group. This commit fixes the issue by removing this `.bg-view`, thus relying on the discuss app background that is already white or dark depending on the chosen web client theme. Forward-Port-Of: odoo/odoo#208612

Before this commit, the background color of discuss mobile mailbox selection was `.bg-view`. This is not a problem in white theme, but in dark theme this is too light, which makes it hard to see this is a button group.

This commit fixes the issue by removing this `.bg-view`, thus relying on the discuss app background that is already white or dark depending on the chosen web client theme.

Forward-Port-Of: odoo/odoo#208612

Before this commit, message author avatars had a size of 38px. This made them so big, to other avatars of 32px, which made them too distracting compared to message content. This commit fixes the issue by reducing them to 32px, matching their size to other avatars, giving a better balance with the message bubbles. Some other related changes were made: - Message and composer sidebar width have been reduced. - Discuss app header avatar has its size matched to the new reduced size of message

Before this commit, message author avatars had a size of 38px. This made them so big, to other avatars of 32px, which made them too distracting compared to message content.

This commit fixes the issue by reducing them to 32px, matching their size to other avatars, giving a better balance with the message bubbles.

Some other related changes were made:
- Message and composer sidebar width have been reduced.
- Discuss app header avatar has its size matched to the new reduced size of message avatar its start padding has been adjusted to align with avatar in conversation
- Avatar size and sidebars have also been slightly reduced in chat window again to give more room for message content

Forward-Port-Of: odoo/odoo#208936
Forward-Port-Of: odoo/odoo#208494

When a user is on leave, the DM chat shows header on top with "Back on X". Before this commit, the alert was far too big and has lots of bottom margin. This commit makes the alert much smaller similarly to the "1 unread mark as read" top banner. Forward-Port-Of: odoo/odoo#208939 Forward-Port-Of: odoo/odoo#208881

When a user is on leave, the DM chat shows header on top with "Back on X".

Before this commit, the alert was far too big and has lots of bottom margin. This commit makes the alert much smaller similarly to the "1 unread mark as read" top banner.

Forward-Port-Of: odoo/odoo#208939
Forward-Port-Of: odoo/odoo#208881

Button was mistakenly too big, due to typo with `.btn-s` instead of `.btn-sm`. Forward-Port-Of: odoo/odoo#208672

Button was mistakenly too big, due to typo with `.btn-s` instead of `.btn-sm`.

Forward-Port-Of: odoo/odoo#208672

Before this commit, the top corner of a message bubble next to author avatar was always non-rounded, including squashed messages. This non-rounded part represent the arrow of the bubble, to show visually that this user has spoken. This is nice for non-squashed messages, i.e. messages next to avatar and header containing info like user name. For squashed messages, however, they are not next to an avatar, because this is the same as the parented oldest message with same author. The non-round

Before this commit, the top corner of a message bubble next to author avatar was always non-rounded, including squashed messages.

This non-rounded part represent the arrow of the bubble, to show visually that this user has spoken.

This is nice for non-squashed messages, i.e. messages next to avatar and header containing info like user name. For squashed messages, however, they are not next to an avatar, because this is the same as the parented oldest message with same author. The non-rounded corner can help for direction between self and others messages, but even there color of bubble is good enough, and since these are squashed messages it's easy to deduce the alignment of message.

This non-rounded corner doesn't look good on squashed messages, so this commit fixes the issue by making squashed messages fully rounded, without this non-rounded corner.

Forward-Port-Of: odoo/odoo#208945
Forward-Port-Of: odoo/odoo#208655

Steps to reproduce: 1. Settings > Navigate to Configure Document Layout 2. Under Layout Background, select Custom and upload an image. Issue: Background image was being cut off at the end. The image was not covering the entire div. Solution: Updated the `.o_report_layout_background` CSS to use `background-size: contain` and remove 300px from `background-position` to ensure the image scales proportionally and stays centered. opw : 4727408 Before FIX : ![image](https://github.co

Steps to reproduce:
1. Settings > Navigate to Configure Document Layout
2. Under Layout Background, select Custom and upload an image.

Issue:
Background image was being cut off at the end. The image was not covering the entire div.

Solution:
Updated the `.o_report_layout_background` CSS to use `background-size: contain`
and remove 300px from `background-position` to ensure the image scales
proportionally and stays centered.

opw : 4727408

Before FIX :
![image](https://github.com/user-attachments/assets/8c3c5cdc-8fad-4e25-8732-2cb2bbf3a44f)
After FIX :
![image](https://github.com/user-attachments/assets/97cc4364-73a4-4913-bda2-89805499bc0a)

Forward-Port-Of: odoo/odoo#207029

Add the Invoice Sending Method field to the partner's list view to enable mass edit. task-no (feedback from WTA) Forward-Port-Of: odoo/odoo#209007

Add the Invoice Sending Method field to the partner's list view to enable mass edit.

task-no (feedback from WTA)

Forward-Port-Of: odoo/odoo#209007

This commit fixes the URL being used in the path argument given to the 'scoped_app' route. Since '/odoo' is already used by the main PWA, we must not use 'odoo' in the actual path of the PWA. Forward-Port-Of: odoo/odoo#208969

This commit fixes the URL being used in the path argument given to the 'scoped_app' route. Since '/odoo' is already used by the main PWA, we must not use 'odoo' in the actual path of the PWA.

Forward-Port-Of: odoo/odoo#208969

Steps to reproduce: - Connect IoT box with scale to DB - Configure PoS with the scale - Configure product to be available in PoS and has to be weighed - Make an order with the product - Scale window pops up for weighing - Close window directly - One unit of product is still added, we expect nothing to be added opw-4643243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208823 Forward-Port-Of: odoo/odoo#208571

Steps to reproduce:
- Connect IoT box with scale to DB
- Configure PoS with the scale
- Configure product to be available in PoS and has to be weighed
- Make an order with the product
- Scale window pops up for weighing
- Close window directly
- One unit of product is still added, we expect nothing to be added

opw-4643243

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

Forward-Port-Of: odoo/odoo#208823
Forward-Port-Of: odoo/odoo#208571

## Issue: A standard IBAN always breaks into two lines on the DIN 5008 report. ## Steps to reproduce: - Install l10n_de; - Change to DE Company; - Navigate to Settings; - Under the Companies section, click `Configure Document Layout`; - Select `DIN 5008` layout; - Check footer display. ## Cause: The commit 3a139b15a5270fb466b608b340013c93214557bb reset the font-size without thinking about the IBAN display. opw-4680515 --- I confirm I have signed the CLA and read the PR guide

## Issue:
A standard IBAN always breaks into two lines on the DIN 5008 report.

## Steps to reproduce:
- Install l10n_de;
- Change to DE Company;
- Navigate to Settings;
- Under the Companies section, click `Configure Document Layout`;
- Select `DIN 5008` layout;
- Check footer display.

## Cause:
The commit 3a139b15a5270fb466b608b340013c93214557bb reset the font-size without thinking about the IBAN display.

opw-4680515

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

Forward-Port-Of: odoo/odoo#204296

This commit, fixes the scroll of the control panel when we opened the search bar. The bug happened because when we scroll we save the last scroll position into `oldScrollTop` variable. But when we "open" the search bar a "new line" (search input) is rendered so the height of the scrolling element is increase (by the height of the search input line). Also, a scroll is triggered so the view remains at the same position. But the `oldScrollTop` is not adapted to reflect the new height of the scroll

This commit, fixes the scroll of the control panel when we opened the search bar.
The bug happened because when we scroll we save the last scroll position into `oldScrollTop` variable. But when we "open" the search bar a "new line" (search input) is rendered so the height of the scrolling element is increase (by the height of the search input line). Also, a scroll is triggered so the view remains at the same position. But the `oldScrollTop` is not adapted to reflect the new height of the scrolling element.
When the new delta was calculated (in the scroll handler) to set the top position of the control panel, a wrong value was set as there was an additional offset of the height of the "search input line".

This commit adds an ResizeObserver to observe the scrolling element and so adapt the `oldScrollTop` variable to adapt the delta of its height.

task-4466063

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

Forward-Port-Of: odoo/odoo#208955
Forward-Port-Of: odoo/odoo#208787

Forward-Port-Of: odoo/odoo#207024

Forward-Port-Of: odoo/odoo#207024

The error in the loop appears during the assertion in the last step. ProductScreen.clickLine("Water", 3) is missing. Before the fix: After creating the new order with 2 waters and 2 cokes, it clicks directly on clickDisplayedProduct("Water"), which creates an new orderline with only 1 water. So there are 4 lines, not 3... => Error After the fix: We wait for the 2 orders to be created and then clickDisplayedProduct("Water"), which adds a water to the existing line. runbot-error-id~190

The error in the loop appears during the assertion in the last step. ProductScreen.clickLine("Water", 3) is missing.

Before the fix:
After creating the new order with 2 waters and 2 cokes, it clicks directly on clickDisplayedProduct("Water"), which creates an new orderline with only 1 water. So there are 4 lines, not 3... => Error

After the fix:
We wait for the 2 orders to be created and then
clickDisplayedProduct("Water"), which adds a water to the existing line.

runbot-error-id~190618

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#208859

Similar fix as what has already be done in this following commit: https://github.com/odoo/odoo/commit/483024d122565523a8f1788201ecce47c6d1dfd0 In multi-company setups, `product.template` records can be shared, but access to `res.company` may be restricted. To avoid access errors when computing `product.template.cost_currency_id`, use `sudo()` when reading `company_id.currency_id`. opw: 4744418 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forw

Similar fix as what has already be done in this following commit: https://github.com/odoo/odoo/commit/483024d122565523a8f1788201ecce47c6d1dfd0 In multi-company setups, `product.template` records can be shared, but access to `res.company` may be restricted. To avoid access errors when computing `product.template.cost_currency_id`, use `sudo()` when reading `company_id.currency_id`.

opw: 4744418


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

Forward-Port-Of: odoo/odoo#208752

Before this commit, we were using the local timezone for comparing orders in self order. This lead to issues because the server is in UTC and the client is in local timezone. This commit changes the behavior to use UTC for the comparison. This means that the orders will be compared in UTC, regardless of the local timezone of the client. Forward-Port-Of: odoo/odoo#208867

Before this commit, we were using the local timezone for comparing orders in self order. This lead to issues because the server is in UTC and the client is in local timezone.

This commit changes the behavior to use UTC for the comparison. This means that the orders will be compared in UTC, regardless of the local timezone of the client.

Forward-Port-Of: odoo/odoo#208867

When creating a record for any model that overrides `utm.source.mixin` and additionally passing default_name in the context, the `utm.source.mixin` model creates a UTM source record and handles duplicates by appending (2), (3). However, the name is removed from the values after source creation in the create method, the `default_get` function retrieves the `default_name` from the context. Since the field is related, it overwrites the source name with the name field of the mixin model, causing

When creating a record for any model that overrides `utm.source.mixin` and additionally passing default_name in the context, the `utm.source.mixin` model creates a UTM source record and handles duplicates by appending (2), (3).

However, the name is removed from the values after source creation in the create method, the `default_get` function retrieves the `default_name` from the context. Since the field is related, it overwrites the source name with the name field of the mixin model, causing a unique constraint violation if the same name already exists.

This PR removes `default_name` from the context.

Task-3901336

Forward-Port-Of: odoo/odoo#208362

When an independent (not linked to an invoice) credit note is submitted to JoFotara, the portal would throw an error because the original invoice number, UUID, and amount are required. This commit restricts the users from sending independent credit notes to JoFotara. It also gives the users the flexibility (in debug mode) to link an invoice to an independent credit note. task-4756603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward

When an independent (not linked to an invoice) credit note is submitted to JoFotara, the portal would throw an error
because the original invoice number, UUID, and amount are required.
This commit restricts the users from sending independent credit notes to JoFotara.
It also gives the users the flexibility (in debug mode) to link an invoice to an independent credit note.

task-4756603




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

Forward-Port-Of: odoo/odoo#208276

The electronic format field should not be displayed in the portal when no option is available for it. Steps to reproduce: ------------------- * (The reported flow was using PoS) * Install the l10n_mx_edi_pos module * Create a PoS and use the self invoicing feature * Make an order and pay for it * On the ticket scan the QR Code and access the invoice portal > Observation: The electronic format field is displayed in the portal but it is empty Why the fix: ------------ We hide the f

The electronic format field should not be displayed in the portal when no option is available for it.

Steps to reproduce:
-------------------
* (The reported flow was using PoS)
* Install the l10n_mx_edi_pos module
* Create a PoS and use the self invoicing feature
* Make an order and pay for it
* On the ticket scan the QR Code and access the invoice portal
> Observation: The electronic format field is displayed in the portal
but it is empty

Why the fix:
------------
We hide the field when no value is available for it.

opw-4628351

Forward-Port-Of: odoo/odoo#208904
Forward-Port-Of: odoo/odoo#208124

This PR refactors `_create_backorder `for better extensibility. Related: https://github.com/OCA/manufacture/pull/1467 @qrtl QT5016 Forward-Port-Of: odoo/odoo#207355 Forward-Port-Of: odoo/odoo#195958

This PR refactors `_create_backorder `for better extensibility.
Related: https://github.com/OCA/manufacture/pull/1467

@qrtl QT5016

Forward-Port-Of: odoo/odoo#207355
Forward-Port-Of: odoo/odoo#195958

In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value. Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field

In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value.

Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field `team_id` is added. This field is a computed-stored field with a callable set as default. Because the default attr is defined, the ORM skips the call to the compute method and calls the default function instead when the team_id param is not given upon creation. That means that for each account.move, `_get_default_team_id` is called. Since the purpose of a compute function is already to give default values to record, removing the default callable allows to benefit from the batching of compute functions.

#### speedup

Test database with account_accountant and sale.
Trying to create batches of account.moves

| Batch size | Before PR | After PR |
|:----------:|:---------:|:--------:|
|     1      |    70ms   |    58ms  |
|     50     |    150ms  |    100ms |
|     100    |    275ms  |    188ms |
|     250    |    660ms  |    450ms |
|     1000   |    2.43s  |    1.75s |
|     3000   |    7.55s  |    5.33s |

Average speedup: 68%.




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

Forward-Port-Of: odoo/odoo#160313
Forward-Port-Of: odoo/odoo#157887

This commit modifies the condition for the Peppol information footnote to be added to the mail to be only when the country of both the company and the partner is one of the following: BE/LU/NL/SE/NO. task-id: 4750146 Forward-Port-Of: odoo/odoo#208836 Forward-Port-Of: odoo/odoo#207270

This commit modifies the condition for the Peppol information footnote to be added to the mail to be only when the country of both the company and the partner is one of the following: BE/LU/NL/SE/NO.

task-id: 4750146

Forward-Port-Of: odoo/odoo#208836
Forward-Port-Of: odoo/odoo#207270

The test test_03_crm_tour_forecast has been deactivated in the recent commit 55cccddeb12a2096730e4fadc84c52fa838b1aec It can be restored with a simple fix, being an explicit call to run "click", which is the expected behavior now, since starting from a recent commit, click is not performed by default, but a check of the element existence is performed instead. Said commit is 84feb3035ff3e829d6602a5d3544d64c673358fb Also, the kanban quick create design has changed in recent commit 566824d0fe

The test test_03_crm_tour_forecast has been deactivated in the recent commit 55cccddeb12a2096730e4fadc84c52fa838b1aec

It can be restored with a simple fix, being an explicit call to run "click", which is the expected behavior now, since starting from a recent commit, click is not performed by default, but a check of the element existence is performed instead. Said commit is 84feb3035ff3e829d6602a5d3544d64c673358fb

Also, the kanban quick create design has changed in recent commit 566824d0fe5764a434bb2b4f899ef864ed6cc56d

Small label / selector changes are applied to make the test succeed now, and to prevent the current column label 'Add add next month'.

Task-4756945

Forward-Port-Of: odoo/odoo#207898

Steps to reproduce: - Go to any form view with a chatter - Make a change in the form view - Open the chatter composer - Click on the "Send" button => The parent record is reloaded, but the changes made in the form view are lost. This happens since 94088d18879a6a634077908e494483cbd0cc1a28, which introduced a `load` call in the `onCloseFullComposerCallback` method without taking into account the fact that the parent record might already be in a dirty state. This commit fixes the issue by

Steps to reproduce:
- Go to any form view with a chatter
- Make a change in the form view
- Open the chatter composer
- Click on the "Send" button => The parent record is reloaded, but the changes made in the form view are lost.

This happens since 94088d18879a6a634077908e494483cbd0cc1a28, which introduced a `load` call in the `onCloseFullComposerCallback` method without taking into account the fact that the parent record might already be in a dirty state.

This commit fixes the issue by saving the record before reloading it.

OPW-4762965

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#208932
Forward-Port-Of: odoo/odoo#208816

Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used [cr.split_for_in_conditions()](https://github.com/odoo/odoo/blob/13133b40eb545c4d4f7427c2145b3d57074fa74b/odoo/sql_db.py#L402-L405) to chunk IDs properly for the `WHERE id IN (...)` clause. However, after the mentioned commit, all IDs are passed at once, especially when `fetchmany()` returns up to 1 lac records. This significantly slows down the update query due to large `IN` cl

Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used [cr.split_for_in_conditions()](https://github.com/odoo/odoo/blob/13133b40eb545c4d4f7427c2145b3d57074fa74b/odoo/sql_db.py#L402-L405) to chunk IDs properly for the `WHERE id IN (...)` clause.

However, after the mentioned commit, all IDs are passed at once, especially when `fetchmany()` returns up to 1 lac records. This significantly slows down the update query due to large `IN` clauses and memory overhead.

To address this, reduce the processing chunk from 1lac to 10k IDs. This reduces update time from over 2 hours to under 10 minutes in practice for recordset shown below:

```sql
apan_2760231=> select count(*) from pos_order;
 count
--------
 146885
(1 row)

apan_2760231=> select count(*) from pos_order_line;
 count
--------
 378860
(1 row)

apan_2760231=> select count(*) from pos_payment;
 count
--------
 184679
(1 row)
```

Logs:

Before fix (Almost 3 hrs):
```py
2025-04-17 07:06:31,094 31 INFO db_2760231 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids
2025-04-17 10:08:39,397 31 INFO db_2760231 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL
```

After fix (reduces to 10 mins):
```py
2025-04-17 11:29:44,294 23 INFO apan_2760231_18.0 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids
2025-04-17 11:39:58,582 23 INFO apan_2760231_18.0 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL
```

opw-4734894
upg-2760231


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

Forward-Port-Of: odoo/odoo#206558
Forward-Port-Of: odoo/odoo#206467

**Problem:** When clicking the button Purchase Matching, in a Vendor Bill, if the vendor is an individual but has a company, the bill will not appear below the Purchase Orders. If the vendor is an individual without a company, the Purchase Matching button will display everything like it should. **Steps to reproduce:** - Make a Purchase Order, the vendor has to be an individual with a company. - Create a bill for the same product and vendor. - Use the Purchase Matching button on the bi

**Problem:**
When clicking the button Purchase Matching, in a Vendor Bill, if
the vendor is an individual but has a company, the bill will not
appear below the Purchase Orders. If the vendor is an individual
without a company, the Purchase Matching button will display
everything like it should.

**Steps to reproduce:**
- Make a Purchase Order, the vendor has to be an individual with a company.
- Create a bill for the same product and vendor.
- Use the Purchase Matching button on the bill.
- The bill is not displayed, but the Purchase Orders are.

**Cause of the issue:**
https://github.com/odoo/odoo/blob/cc9e7cb92f1a6237a496b9acabd93506a8724a62/addons/purchase/models/account_invoice.py#L143-L144
The partner_id for the Purchase Orders are the current individual
vendor, but we are trying to match it with the partner_id of an
Account Move Line, which is set to be the commercial partner of
the individual, meaning the company, as seen below.
https://github.com/odoo/odoo/blob/9e9e992698946b75212040ca0ff812194200a8bf/addons/account/models/account_move_line.py#L481-L483
On the matching table, we use the partner of the Account Move Line,
and this is the why filtering on the individual doesn't give any
result, if we wanted some we would need to filter on the company.
https://github.com/odoo/odoo/blob/45533a1c6a70a3b86cf744a0f950c92d8a99afcf/addons/purchase/models/purchase_bill_line_match.py#L109

**Fix:**
The domain was updated to take both the individual and the
commercial partner (the company). This ensures that the bill
will be found even in we are dealing with an individual that
is in a company.

opw-4577643

Forward-Port-Of: odoo/odoo#208894
Forward-Port-Of: odoo/odoo#202012

**Problem:** The problem happens when a service is linked to a task but it's not billed on timesheet. If a quotation is created with this service (which creates the task linked to it) and a timesheet is added to the task, this will trigger a recompute of `purchase_price` (the cost column) of the sale order line in the quotation. If the client had written another cost on the sale order line of the quotation than the original one (coming from the `standard_price` of the product) this will

**Problem:**
The problem happens when  a service is linked to a task but it's not billed on timesheet.

If a quotation is created with this service (which creates the task linked to it) and a timesheet is added to the task, this will trigger a recompute of `purchase_price` (the cost column) of the sale order line in the quotation.

If the client had written another cost on the sale order line of the quotation than the original one (coming from the `standard_price` of the product) this will erase it and set the value back to the standard price of the product. 

Because the service is not billed on timesheet we don't want a modification of timesheet to affect the cost set on the quotation.

**Steps to reproduce:**
- In settings, activate the "margins" setting in Sales
- Open Sales/products and create a new product
- Set the product type as "Service"
- Set the "create on order" field as Task
- Set the "project" field to an existing project
- Set a strictly positive value in the cost field
- Set a name and save
- Create a new quotation and add the product you just created
- Confirm the quotation
- In the order lines page, add the cost column
- Change the value of the cost column
- Click on the "Tasks" smart button
- Add a new timesheet in the timesheet page and save
- Come back to the sale order via the smart button

**Current behavior:**
The value of the cost column was reset the the cost of the product

**Expected behavior:**
Mofifying the timesheets shouldn't impact the cost of a service which is not invoiced on timesheets

**Cause of the issue:**
Because the sale_timesheet_margin module is installed the
_compute_purchase_price method is overriden and depends on
analytic_line_ids.amount
https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_timesheet_margin/models/sale_order_line.py#L8
when this method is called in our flow, because
sol.product_id.purchase_price is not null our sale order line
will not get filtered out
https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_timesheet_margin/models/sale_order_line.py#L11
and it will reach the original
_compute_purchase_price method were the value of purchase_price
will be reset to the value of self.product_id.standard_price
https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_margin/models/sale_order_line.py#L30


**Fix:**
We want to filter out the sale.order.lines for which the computation
of purchase_price has been triggered via the analytic_line_ids.amount
dependency and for which we don't want the computation to happen
(when the service_policy is not "timesheet").
We need to do this without filtering out the sales.order.lines for which the
computation of purchase_price has been triggered by a dependency from
the original compute_purchase_price method
https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_margin/models/sale_order_line.py#L20-L21
or another orverride of this method
(for now there are two of those : one in sale_expense_margin
https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_expense_margin/models/sale_order_line.py#L10-L11
and one in sale_stock_margin
https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_stock_margin/models/sale_order_line.py#L10-L11
)

is_expense is defined in the sale module
is_service is defined in the sale_service module
service_policy is defined in the sale_project module
all those field are available when sale_timesheet_margin is installed



opw-4627037

Forward-Port-Of: odoo/odoo#208196
Forward-Port-Of: odoo/odoo#205415

This commit is a hack to work around the module loading order without creating a new bridge module, to fix the issue in stable versions. ### Steps to reproduce: 1. Install both `stock`, `delivery` and `mrp` 2. Create a product with a kit BOM and weight - Set the kit UoM to Unit and the components to Kg - Add a weight to the components too 3. Create SO with the kit product 4. Add shipping (UPS) 5. Delivery product 6. `The unit of measure Unit defined on the order line doesn't bel

This commit is a hack to work around the module loading order without creating a new bridge module, to fix the issue in stable versions.

### Steps to reproduce:
1. Install both `stock`, `delivery` and `mrp`
2. Create a product with a kit BOM and weight
   - Set the kit UoM to Unit and the components to Kg
   - Add a weight to the components too
3. Create SO with the kit product
4. Add shipping (UPS)
5. Delivery product
6. `The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure Kg`

The sale price computed in `stock_delivery` does not take kits into account, which leads to conversion of UoM from different products (and therefore different UoM categories).
However, `sale_mrp` already computes the right value for kits.

It worked in earlier versions, thanks to the module loading order, but `_compute_sale_price` moved from the module `delivery` to `stock_delivery`.

Here is the (simplified) module dependency graph:
```
Odoo 16.0:
sale
`-> sale_management
   `-> delivery
`-> sale_stock
   `-> sale_mrp

Odoo 17.0:
sale
`-> delivery
   `-> stock_delivery
`-> sale_stock
  `-> sale_mrp
```

Odoo sorts modules by depth in the graph, and ordered alphabetically for modules with the same depth.
So in Odoo 16.0, `delivery` was loaded before `sale_mrp`, but starting Odoo 17.0, `stock_delivery` is loaded after `sale_mrp` since they both have the same depth.

opw-4385052

Forward-Port-Of: odoo/odoo#208413
Forward-Port-Of: odoo/odoo#190750

This commit fixes the position and update the color being used in the both SVG and PNG versions of the icon. The main #714B67 color is now used and everything is centered. The shadow has been removed. Forward-Port-Of: odoo/odoo#209004

This commit fixes the position and update the color being used in the both SVG and PNG versions of the icon. The main #714B67 color is now used and everything is centered. The shadow has been removed.

Forward-Port-Of: odoo/odoo#209004

Issue: On a database with large stock pickings (> 100 stock moves per picking), displaying the tree view of stock pickings can be slow, because of the computation of the availability fields, as these fields are computed from the availability of the moves: 80 pickings per page means ~8000 moves to consider. If we are lucky the number of products to consider is lower than that, but on the customer database for which this PR is being done, we still have 3000 products. Displaying the 80 pickings

Issue:

On a database with large stock pickings (> 100 stock moves per picking), displaying the tree view of stock pickings can be slow, because of the computation of the availability fields, as these fields are computed from the availability of the moves: 80 pickings per page means ~8000 moves to consider. If we are lucky the number of products to consider is lower than that, but on the customer database for which this PR is being done, we still have 3000 products. Displaying the 80 pickings on the first page takes 8 to 10s.

One of the issues found when analyzing the issue is that the 3 SQL queries performed on stock_move in the beginning of _get_report_lines are slow:

```
        past_outs = self.env['stock.move'].search(AND([out_domain, past_domain]), order='priority desc, date, id')
        future_outs = self.env['stock.move'].search(AND([out_domain, future_domain]), order='reservation_date, priority desc, date, id')

        outs = past_outs | future_outs

        ins = self.env['stock.move'].search(in_domain, order='priority desc, date, id')
```

Further analysis and testing show that using a domain with a negative condition ('not in') on the `state` column of stock_move prevents PostgreSQL from using the existing index on that column. By changing the condition in the domain to use a positive condition on that column, the execution time of each of the three queries goes from 1000-1500ms to about 100ms, saving about 3s on the total loading time of the page, which is still slow but a bit less.

Without patch:

```
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 151 3.907 4.824
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 155 3.998 5.284
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 167 4.246 5.725
```

With patch:

```
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 151 0.619 4.639
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 155 0.643 5.143
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 167 0.862 5.618
```


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

Forward-Port-Of: odoo/odoo#207022

Since odoo/odoo#202366 the editing state of the message is no longer used and the edit mode relies on checking the availability of the message composer. Clicking on a comment button opens a composer on the message. When clicking again on this button if we don't remove that composer from the message, the message is assumed to be in edit mode. Steps to reproduce: - Install a module that uses the comment feature such as elearning - Go to the portal view of a course as admin - In the chatter c

Since odoo/odoo#202366 the editing state of the message is no longer used and the edit mode relies on checking the availability of the message composer. Clicking on a comment button opens a composer on the message. When clicking again on this button if we don't remove that composer from the message, the message is assumed to be in edit mode.

Steps to reproduce:
- Install a module that uses the comment feature such as elearning
- Go to the portal view of a course as admin
- In the chatter click on a comment button below a message
- Without saving or canceling the comment, click on the comment button again
- The comment composer is closed but an edit composer in the message is opened

Forward-Port-Of: odoo/odoo#207717

## Version: 18.0+ ## Issue: Total section on Purchase Order document is misaligned. ## Steps to reproduce: - Go to Purchase: - Open a purchase order record; - Click on Print > Purchase Order. ## Cause: Fix in Sale app changing report styles without considering Purchase app: https://github.com/odoo/odoo/commit/344007299c91d990c851ad9ed6f7fb5f8aa7a273 ## Fix: Full style reverting opw-4771854 Forward-Port-Of: odoo/odoo#209084

## Version:
18.0+

## Issue:
Total section on Purchase Order document is misaligned.

## Steps to reproduce:
- Go to Purchase:
  - Open a purchase order record;
  - Click on Print > Purchase Order.

## Cause:
Fix in Sale app changing report styles without considering Purchase app: https://github.com/odoo/odoo/commit/344007299c91d990c851ad9ed6f7fb5f8aa7a273 

## Fix:
Full style reverting

opw-4771854

Forward-Port-Of: odoo/odoo#209084

When creating a new channel or sub-thread, it decorates the conversation with a welcome text with avatar / icon of conversation. This commit make small tweaks to this part of UI: - discuss app avatars / icons were too big, now reduced slightly - chat window spacing with conversation name was too small, now made as big as in discuss app - avatar was not as rounded as other avatars in discuss Forward-Port-Of: odoo/odoo#208809

When creating a new channel or sub-thread, it decorates the conversation with a welcome text with avatar / icon of conversation.

This commit make small tweaks to this part of UI:
- discuss app avatars / icons were too big, now reduced slightly
- chat window spacing with conversation name was too small, now made as big as in discuss app
- avatar was not as rounded as other avatars in discuss

Forward-Port-Of: odoo/odoo#208809

Add a new chatbot field in the rule's tree view to improve visibility and management of chatbot configurations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209018

Add a new chatbot field in the rule's tree view to improve visibility and management of chatbot configurations.


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

Forward-Port-Of: odoo/odoo#209018

https://github.com/odoo/odoo/commit/29f7475437586363e473955315d74aef7d80028c changed the markdown syntax from `<br>` to `\n` Adapt the compute display name to the new format Forward-Port-Of: odoo/odoo#209010

https://github.com/odoo/odoo/commit/29f7475437586363e473955315d74aef7d80028c changed the markdown syntax from `<br>` to `\n` Adapt the compute display name to the new format

Forward-Port-Of: odoo/odoo#209010

Fix the default taxes on accounts. They should be purchase taxes and not sales taxes. No task (verbal report) Forward-Port-Of: odoo/odoo#209065

Fix the default taxes on accounts. They should be purchase taxes and not sales taxes.

No task (verbal report)

Forward-Port-Of: odoo/odoo#209065

Description ----------- Deleting an expense is slow when the `account_move_line` table is large, as the `Many2one`/`fkey` `expense_id` needs to be set to `NULL` where necessary. If there is no index on the `fkey`, it's `Seq. Scan` on the table `account_move_line`. Benchmark: ---------- On odoo.com, unlinking an expense took: | Before | After | |--------|-------| | 10s | 58ms | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Po

Description
-----------
Deleting an expense is slow when the `account_move_line` table is large, as the `Many2one`/`fkey` `expense_id` needs to be set to `NULL` where necessary. If there is no index on the `fkey`, it's `Seq. Scan` on the table `account_move_line`.

Benchmark:
----------
On odoo.com, unlinking an expense took:

| Before | After |
|--------|-------|
| 10s    | 58ms  |

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

Forward-Port-Of: odoo/odoo#208875

When using multivat, the taxes imported from another l10n should be assigned to fiscal position creating those taxes. Forward-Port-Of: odoo/odoo#208756

When using multivat, the taxes imported from another l10n should be assigned to fiscal position creating those taxes.

Forward-Port-Of: odoo/odoo#208756

Before this commit, several invisible fields were present in the views in `l10n_ch`, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031. This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master.

Before this commit, several invisible fields were present in the views in `l10n_ch`, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed.

The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031.

This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views.

We will removes the unnecessary invisible fields in master.

opw-4629332




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

Forward-Port-Of: odoo/odoo#205501

Before this commit, when connecting to the IoT box access point on some devices (e.g. Android phone), there would be no popup to sign in to the network. Instead, the user would have to manually navigate to any URL, which would then load the IoT box homepage. After this commit, all HTTP requests on the access point will send a 301 redirect to the IoT box homepage. When Android sees that it gets redirected, it interprets this as a login page and triggers the 'sign-in' popup. In this commit w

Before this commit, when connecting to the IoT box access point on some devices (e.g. Android phone), there would be no popup to sign in to the network. Instead, the user would have to manually navigate to any URL, which would then load the IoT box homepage.

After this commit, all HTTP requests on the access point will send a 301 redirect to the IoT box homepage. When Android sees that it gets redirected, it interprets this as a login page and triggers the 'sign-in' popup.

In this commit we are also refactoring the structure of the nginx config files. Previously, we had configuration both in `/etc/nginx/nginx.conf` and `/etc/nginx/sites-enabled/default`. Now, we are using the modern structure of simply adding our config in the `/etc/nginx/conf.d/` folder. In addition, some redundant settings were removed to simplify the config.

task-4724110

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

Forward-Port-Of: odoo/odoo#209104

**Steps to reproduce:** - Create a new product storable product - Open Inventory/Operations/Physical Inventory - Add a new line - Choose your product - Click on History **Current behavior:** An Odoo Client Error window appears **Cause of the issue:** Inside the counted quantity widget's useEffect, When adding the event listener "this.onInput.bind(this)" creates a new function reference https://github.com/odoo/odoo/blob/4775c0ff640c4a092c7430a03f6324659b9bbca4/addons/stock/static/s

**Steps to reproduce:**
- Create a new product storable product
- Open Inventory/Operations/Physical Inventory
- Add a new line
- Choose your product
- Click on History

**Current behavior:**
An Odoo Client Error window appears

**Cause of the issue:**
Inside the counted quantity widget's useEffect,
When adding the event listener "this.onInput.bind(this)" creates a new function reference
https://github.com/odoo/odoo/blob/4775c0ff640c4a092c7430a03f6324659b9bbca4/addons/stock/static/src/widgets/counted_quantity_widget.js#L18
when removing the event listener "this.onInput.bind(this)" creates another function reference
https://github.com/odoo/odoo/blob/4775c0ff640c4a092c7430a03f6324659b9bbca4/addons/stock/static/src/widgets/counted_quantity_widget.js#L22
As a consequence the event listener is not properly removed

**Fix:**
If the new function reference is created before in a variable the same function reference will be passed the two times and it will be properly removed

opw-4711101

Forward-Port-Of: odoo/odoo#206478

**Purpose of this PR:** The ir.http model should be loaded at the start. If more test cases are expected, it's best to define them now for future-proofing. Entering commands such as /who or similar in a chat or channel previously caused a crash. the issue has been resolved by updating the message posting flow to ensure that commands are processed correctly. Enterprise: https://github.com/odoo/enterprise/pull/84418 task-4759888 --- I confirm I have signed the CLA and read the PR gui

**Purpose of this PR:**

The ir.http model should be loaded at the start. If more test cases are expected, it's best to define them now for future-proofing.

Entering commands such as /who or similar in a chat or channel previously caused a crash. the issue has been resolved by updating the message posting flow to ensure that commands are processed correctly.

Enterprise: https://github.com/odoo/enterprise/pull/84418
task-4759888

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

Forward-Port-Of: odoo/odoo#209064

This commit improves behaviour of new message counter, msg separator and unread message banner in discuss conversation. Before this commit, all these conditions were made with special fields `syncUnread` and passing `sync` param to mark_as_read rpc, so that the server acknowledges by providing the new_message_separator value. This solution is very prone to race condition and the code is far too complicated and result to many misses, leading to end-user to manually click on mark as read ver

This commit improves behaviour of new message counter, msg separator and unread message banner in discuss conversation.

Before this commit, all these conditions were made with special fields `syncUnread` and passing `sync` param to mark_as_read rpc, so that the server acknowledges by providing the new_message_separator value.

This solution is very prone to race condition and the code is far too complicated and result to many misses, leading to end-user to manually click on mark as read very often and/or come back to conversation and/or page reload to have proper counters.

This commit improves by making the implementation much simpler by being fully client-side and more imperative. There's no more `sync` param acknowledgement, and instead the UI versions of counter and separator are mostly the same as the server values but soften in JS for UI concerns, i.e. don't increase counter if it becomes immediately decreased, or new message separator is a bit more persistent to not jump between messages all the time.

This implementation also improve behaviour of auto mark as read: before this commit, focus on composer was a hard requirement for this auto-mark as read. Now, soft-focus on thread is good enough, and scrolling to bottom with focus on either composer or thread is enough to mark the conversation as read.

This commit also makes these new improvements on new message separator:
- new message separator was always displayed on opening new conversation with only new messages. Now this is not displayed because all messages are new anyway. It displays a new message separator however when a new message is posted just after conversation is being displayed
- new message separator is shown above 1st message of conversation only when conversation is explicitly marked as unread from this message

Task-4448873

https://github.com/odoo/enterprise/pull/83240

Forward-Port-Of: odoo/odoo#204723

Follow-up of https://github.com/odoo/odoo/pull/204663 PR above add the new feature to quickly mute and deafen through hotkey `shift+m` and `shift+d`. While this works, the discovery of feature is poor, due to ALT not promoting them. This commit fixes the issue by adding the `data-hotkey` on call actions that have these hotkeys, so that they are shown when pressing ALT to display all available hotkey. Forward-Port-Of: odoo/odoo#208913

Follow-up of https://github.com/odoo/odoo/pull/204663

PR above add the new feature to quickly mute and deafen through hotkey `shift+m` and `shift+d`. While this works, the discovery of feature is poor, due to ALT not promoting them.

This commit fixes the issue by adding the `data-hotkey` on call actions that have these hotkeys, so that they are shown when pressing ALT to display all available hotkey.

Forward-Port-Of: odoo/odoo#208913

Clicking on the report channel graph view should redirect to the discuss channels list, not the report one. task-4775828 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#208774

Clicking on the report channel graph view should redirect to the discuss channels list, not the report one.

task-4775828

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#208774

This PR introduces a visual clue and a popover to guide the user to the fullscreen button if there is a video playing in a chat window. Task-4592983 Forward-Port-Of: odoo/odoo#206098

This PR introduces a visual clue and a popover to guide the user to the
fullscreen button if there is a video playing in a chat window.

Task-4592983

Forward-Port-Of: odoo/odoo#206098

**Steps to reproduce:** - Install Accounting - Create a product: * Product Name: XYZ * Internal Reference: 1234 - Create a second product with the same name: * Product Name: XYZ * Internal Reference: 5678 - Go to "Accounting / Vendors / Bills" - Upload a Peppol BIS Billing 3.0 XML containing 2 invoice lines with the created products: `<cbc:Name>XYZ</cbc:Name>` `<cac:SellersItemIdentification><cbc:ID>1234</cbc:ID></cac:SellersItemIdentification>` and `<cbc:Name>XYZ</cbc:Name>`

**Steps to reproduce:**
- Install Accounting
- Create a product:
  * Product Name: XYZ
  * Internal Reference: 1234
- Create a second product with the same name:
  * Product Name: XYZ
  * Internal Reference: 5678
- Go to "Accounting / Vendors / Bills"
- Upload a Peppol BIS Billing 3.0 XML containing 2 invoice lines with the created products:
`<cbc:Name>XYZ</cbc:Name>`
`<cac:SellersItemIdentification><cbc:ID>1234</cbc:ID></cac:SellersItemIdentification>` and
`<cbc:Name>XYZ</cbc:Name>`
`<cac:SellersItemIdentification><cbc:ID>5678</cbc:ID></cac:SellersItemIdentification>`

**Issue:**
The 2 invoice lines of the generated bill have the same exact product, even when 2 different codes are provided for the products.

**Cause:**
In "_retrieve_product" method, a search is made on the name, the code and the barcode, but an "OR" operator is applied.
Not an "AND".
Several products may satisfy the domain but only the first one is returned.

**Solution:**
If several products matches the conditions, instead of directly returning the first one, try to select one based on the following
priority: barcode, code, name.
opw-4466322




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

Forward-Port-Of: odoo/odoo#209048
Forward-Port-Of: odoo/odoo#205739

- Align Time Off Responsible overview rights with his rights in the managment menu views Task: 4752362 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207675

- Align Time Off Responsible overview rights with his rights in the managment menu views

Task: 4752362


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

Forward-Port-Of: odoo/odoo#207675

**Steps to reproduce:** - Install account - Activate a foreign currency (e.g. EUR) - Set at least 2 different currency rates for date1 and date2 - Create an invoice: * Customer: [any] * Invoice Date: date1 * Currency: EUR * Invoice line: [any] - Save the invoice - Check debit and credit amounts in "Journal Items" tab - Change the price of the product and set "Invoice Date" to date2 - Save the invoice - Check debit and credit amounts in "Journal Items" tab **Issue:** The

**Steps to reproduce:**
- Install account
- Activate a foreign currency (e.g. EUR)
- Set at least 2 different currency rates for date1 and date2
- Create an invoice:
  * Customer: [any]
  * Invoice Date: date1
  * Currency: EUR
  * Invoice line: [any]
- Save the invoice
- Check debit and credit amounts in "Journal Items" tab
- Change the price of the product and set "Invoice Date" to date2
- Save the invoice
- Check debit and credit amounts in "Journal Items" tab

**Issue:**
The debit and credit amounts have been recomputed with the new currency rate, but the conversion has been applied on the old price.

**Cause:**
In "_sync_invoice" method, when the currency rate has changed, balance (and subsequently debit/credit) is recomputed from amount_currency.
However, in this case, balance should be recomputed completely because the line subtotal has changed and amount_currency is not up-to-date with it.

**Solution:**
Do not recompute balance based on amount_currency when price_subtotal of a line has changed.
In that case, it will be recomputed anyway.

opw-4658156



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

Forward-Port-Of: odoo/odoo#207905

The account selector is supposed to give priority to certain account type (not internal group) In the dropdown, prioritize expenses and in the search more, add the filters on account type == 'expense' or 'asset_fixed' Task-4752335 Forward-Port-Of: odoo/odoo#207824

The account selector is supposed to give priority to certain account type (not internal group) In the dropdown, prioritize expenses
and in the search more, add the filters on account type == 'expense' or 'asset_fixed'

Task-4752335

Forward-Port-Of: odoo/odoo#207824

Steps: ======= - Define a combo choice for a single non-configurable product. - Set max_qty for the combo item to a value greater than 1. - Try adding the combo to the cart in the self-order flow. A traceback occurs when the combo is added to the cart. Cause: ======= combo choices only considered cases where comboItem_ids.length > 1 and the product is configurable. It did not account for qty_max, which led to empty combo choice data being sent for valid single-product combos with qty_ma

Steps:
=======
- Define a combo choice for a single non-configurable product.
- Set max_qty for the combo item to a value greater than 1.
- Try adding the combo to the cart in the self-order flow. A traceback occurs when the combo is added to the cart.

Cause:
=======
combo choices only considered cases where comboItem_ids.length > 1 and the product is configurable. It did not account for qty_max, which led to empty combo choice data being sent for valid single-product combos with qty_max > 1.

FIX:
======
Extended the condition to include qty_max > 1.

Task-4762775

Forward-Port-Of: odoo/odoo#208358

ISSUE: When you remove the user from an employee all the linked vehicles are removed as `work_contact_id` is written by the new value before updating the fleet model REPRODUCE: - create a vehicle and link it an employee with user - remove the user from the employee - employee and driver is removed from the vehicle As the issue of persistent 'work_contact_id' on employee has been fixed, all the updates are made auto and these extra code interduce the wrong behavior Task: 4680261 -

ISSUE: When you remove the user from an employee
all the linked vehicles are removed as `work_contact_id` is written by the new value before updating the fleet model

REPRODUCE:
- create a vehicle and link it an employee with user
- remove the user from the employee
- employee and driver is removed from the vehicle

As the issue of persistent 'work_contact_id' on employee has been fixed, all the updates are made auto and these extra code interduce the wrong behavior

Task: 4680261

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

Forward-Port-Of: odoo/odoo#209298
Forward-Port-Of: odoo/odoo#206396

Fixes two issue with EMV QR generation: - The regex applied on comments is wrong and actually does nothing. - VietQR allows less character than that general regex, so we filter it more. opw-4671523 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208956

Fixes two issue with EMV QR generation:
- The regex applied on comments is wrong and actually does nothing.
- VietQR allows less character than that general regex, so we filter it more.

opw-4671523

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

Forward-Port-Of: odoo/odoo#208956

The test `@hr/m2x_avatar_employee/many2one in form view` was failing non-deterministically with the following error: ``` 9. [toHaveCount] found 1 element matching ".o-mail-ChatWindow" > Expected: 2 > Received: 1 > Elements: [ <div.o-mail-ChatWindow.fixed-bottom.overflow-hidden.d-flex.flex-column.shadow-sm.bg-100.rounded-4.border.border-dark.mb-2>, ] ``` This happens because it clicks on avatar card button to send a message, which opens a chat window. However the assertion is made

The test `@hr/m2x_avatar_employee/many2one in form view` was failing non-deterministically with the following error:

```
9. [toHaveCount] found 1 element matching ".o-mail-ChatWindow"
> Expected: 2
> Received: 1
> Elements: [
  <div.o-mail-ChatWindow.fixed-bottom.overflow-hidden.d-flex.flex-column.shadow-sm.bg-100.rounded-4.border.border-dark.mb-2>,
]
```

This happens because it clicks on avatar card button to send a message, which opens a chat window. However the assertion is made synchronously after the `await contains().click()`, which is not necessarily enough time to ensure the chat window has been open.

The next assertion is asserting asynchronously presence of new chat window with specific header, therefore this commit fixes the issue by swapping the assertion orders. When the new chat window with header is shown, then asserting synchronously there are 2 chat windows is correct (it opens new chat window, in addition to keeping previous one open).

runbot-163001

Forward-Port-Of: odoo/odoo#209315

This commit will change the name of the Bank fees reco model to remove the parenthesis no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209219

This commit will change the name of the Bank fees reco model to remove the parenthesis

no task id




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

Forward-Port-Of: odoo/odoo#209219

- In the case `_session_token_get_values` returns `False`, before this commit the code crashes as it wasn't expecting to handle something else than an iterable as `field_values`. The bug was introduced by the commit 3fbd74b3bb7af2b9bc9c86fddc78771ec97ce740 Before this commit, falsy values where correctly handled. We introduce the same behavior to fix the issue. - Added a test to check that computing session on non existing user do not crash and correctly expires the session.

- In the case `_session_token_get_values` returns `False`, before this commit the code crashes as it wasn't expecting to handle something else than an iterable as `field_values`.

    The bug was introduced by the commit 3fbd74b3bb7af2b9bc9c86fddc78771ec97ce740 Before this commit, falsy values where correctly handled. We introduce the same behavior to fix the issue.

  - Added a test to check that computing session on non existing user do not crash and correctly expires the session.





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

Forward-Port-Of: odoo/odoo#208635

Description of the issue this commit addresses: When creating the OSS fiscal positions, if the system creates a tax with a name already used by another tax, the entire mapping process stops due to a unique name constraint resulting in only the countries that have already been done to have the OSS fiscal positions. A solution would be to delete the tax but in the eventuality that it has already been used, it is impossible to delete it hence refreshing the oss fiscal positions becoming totally

Description of the issue this commit addresses:

When creating the OSS fiscal positions, if the system creates a tax with a name already used by another tax, the entire mapping process stops due to a unique name constraint resulting in only the countries that have already been done to have the OSS fiscal positions. A solution would be to delete the tax but in the eventuality that it has already been used, it is impossible to delete it hence refreshing the oss fiscal positions becoming totally impossible.

---

Steps to reproduce:

1. Install l10n_eu_oss and any oss member loca (be for example)
2. Use the company of the loca installed
3. Go to Accouting, Settings, click Refresh tax mapping.
4. Go to the fiscal positions and delete any oss fiscal position.
5. Go back to Accoutning, Settings, click Refresh tax mapping.
6. "Tax names must be unique!" error shows up.

---

Desired behavior after this commit is merged:

When creating the oss fiscal positions, a search is performed to gather the tax and its copies that use the desired name. The name of the new tax will be the name of the one with the most " (Copy)" in its name with one more " (Copy)".

---

no-task

---

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

Forward-Port-Of: odoo/odoo#209186
Forward-Port-Of: odoo/odoo#208532

Before this commit, the `_search_has_ancestor_template` took a lot of time because we first fetch the tasks template to build the domain for that search. The issue is because the search to gather the tasks template is not done in sudo and so the ir.rules of the current are included in the search. This commit adds a sudo to that search to not include the ir.rules since all task templates have to be included in the search method. This commit also add an index on is_template when is_templa

Before this commit, the `_search_has_ancestor_template` took a lot of
time because we first fetch the tasks template to build the domain for
that search. The issue is because the search to gather the tasks
template is not done in sudo and so the ir.rules of the current are
included in the search.

This commit adds a sudo to that search to not include the ir.rules since
all task templates have to be included in the search method. This commit
also add an index on is_template when is_template is true on task since
the search will mostly search the tasks flagged as template.

By doing that, the search_read of one column in kanban view of tasks in
project Help is made in 0.30 seconds instead of 3 seconds.

Forward-Port-Of: odoo/odoo#209006

During this commit: https://github.com/odoo/odoo/commit/2f86fb973a426a4d6c10d41d61dc524955aebb6b we checked the tin1 twice instead of checking the second one task: 4743115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207181

During this commit: https://github.com/odoo/odoo/commit/2f86fb973a426a4d6c10d41d61dc524955aebb6b we checked the tin1 twice instead of checking the second one

task: 4743115




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

Forward-Port-Of: odoo/odoo#207181

When a conversation is unread (and no important messages), the conversation in discuss sidebar has a small dot next to the item. In white theme its visibility is good, with `.opacity-50`. In dark theme however this indicator is hard to see. This commit fixes the issue by keeping 50% opacity in white theme but bumping to 75% in dark theme specifically. Forward-Port-Of: odoo/odoo#209175 Forward-Port-Of: odoo/odoo#208993

When a conversation is unread (and no important messages), the conversation in discuss sidebar has a small dot next to the item.

In white theme its visibility is good, with `.opacity-50`. In dark theme however this indicator is hard to see.

This commit fixes the issue by keeping 50% opacity in white theme but bumping to 75% in dark theme specifically.

Forward-Port-Of: odoo/odoo#209175
Forward-Port-Of: odoo/odoo#208993

Purpose of this commit: Update the sessions empty record action helper task-4775661 Forward-Port-Of: odoo/odoo#208610

Purpose of this commit:
Update the sessions empty record action helper

task-4775661

Forward-Port-Of: odoo/odoo#208610

When a record is pushed directly into db having partial values like missing checkout date will lead to raising validation error. Steps to Reproduce: - In kiosk try to do a login/logout using the same employee having irregular record it raises validation error. Issue: - Unresponsive kiosk system. Reason: - When a validation error is raised from rpc call it directly displays the error dialog and moves and returns thus making the lockScanner reset, thus not allowing next users to us

When a record is pushed directly into db having partial values like missing checkout date will lead to raising validation error.

Steps to Reproduce:
- In kiosk try to do a login/logout using the same employee having irregular record it raises validation error.

Issue:

- Unresponsive kiosk system.

Reason:

- When a validation error is raised from rpc call it directly displays the error dialog and moves and returns thus making the lockScanner reset, thus not allowing next users to use kiosk.

Fix:

- Catching the error and posting it as notification (dialog can also be done) and letting the whole function execute.

task-4760381

Forward-Port-Of: odoo/odoo#209306
Forward-Port-Of: odoo/odoo#207904

An error occurs when trying to send a reversed invoice to ZATCA if it included a downpayment that was also reversed. Steps to reproduce: - Install "Sales" and "Saudi Arabia - E-invoicing" apps. - Create a quotation and confirm it. - Create a downpayment and post it to ZATCA. - Create an invoice **A** including the downpayment and post it. - Reverse the downpayment and post it to ZATCA. - Reverse invoice **A** and try posting it to ZATCA. An error will occur: ```python File ".../l10

An error occurs when trying to send a reversed invoice to ZATCA if it included a downpayment that was also reversed.

Steps to reproduce:
- Install "Sales" and "Saudi Arabia - E-invoicing" apps.
- Create a quotation and confirm it.
- Create a downpayment and post it to ZATCA.
- Create an invoice **A** including the downpayment and post it.
- Reverse the downpayment and post it to ZATCA.
- Reverse invoice **A** and try posting it to ZATCA.

An error will occur:
```python
File ".../l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py", line 356, in _l10n_sa_get_line_prepayment_vals
    'prepayment_id': prepayment_move_id.name,
                     ^^^^^^^^^^^^^^^^^^^^^^^
File ".../odoo/fields.py", line 1154, in __get__
    record.ensure_one()
File ".../odoo/models.py", line 5204, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move(190098, 190096)
```

This fix ensures that only the actual downpayment move is used by filtering on the move type.

opw-4567756

Forward-Port-Of: odoo/odoo#208259
Forward-Port-Of: odoo/odoo#201322

Before this commit, the roundness of message bubble was 6px. Messaging app competitors have rounded bubble at about 7.5px which looks better than Odoo discuss ones. This commit increases the roundness of discuss bubble to 7.5px, thanks to newly introduced `.o-rounded-bubble` classnames. Forward-Port-Of: odoo/odoo#209395 Forward-Port-Of: odoo/odoo#209270

Before this commit, the roundness of message bubble was 6px. Messaging app competitors have rounded bubble at about 7.5px which looks better than Odoo discuss ones.

This commit increases the roundness of discuss bubble to 7.5px, thanks to newly introduced `.o-rounded-bubble` classnames.

Forward-Port-Of: odoo/odoo#209395
Forward-Port-Of: odoo/odoo#209270

This commit adds counters in the mobile discuss app navbar, so that it's much easier to find the right category containing unread and important conversations. - "Mailboxes" category shows the unread counter in inbox - All other categories show the counter of category, similary to the counter when folding a category in desktop discuss sidebar. Livechat tab reconciles for all livechats, as if there's only 1 livechat category - Unread channels do not show a counter, however the navbar item dis

This commit adds counters in the mobile discuss app navbar, so that it's much easier to find the right category containing unread and important conversations.

- "Mailboxes" category shows the unread counter in inbox
- All other categories show the counter of category, similary to the counter when folding a category in desktop discuss sidebar. Livechat tab reconciles for all livechats, as if there's only 1 livechat category
- Unread channels do not show a counter, however the navbar item displays a dot (unread indicator), similarly to chat bubble and next to discuss sidebar item.

Task-4781564

Before
![Screenshot 2025-05-09 at 16 19 00](https://github.com/user-attachments/assets/140a567f-069f-4e69-985d-8c2483b0cb96)
After
![Screenshot 2025-05-09 at 16 18 24](https://github.com/user-attachments/assets/e9eb30ae-e59d-47bc-8ef4-e471186adea1)

Forward-Port-Of: odoo/odoo#209402
Forward-Port-Of: odoo/odoo#209308

Continuing some cleaning in various test classes to lessen setup and/or have it done in as few places as possible. Improve some asserts tools. Task-4224145: [marketing_automation] Improve test coverage Forward-Port-Of: odoo/odoo#209401 Forward-Port-Of: odoo/odoo#208720

Continuing some cleaning in various test classes to lessen setup and/or have it done in as few places as possible.

Improve some asserts tools.

Task-4224145: [marketing_automation] Improve test coverage

Forward-Port-Of: odoo/odoo#209401
Forward-Port-Of: odoo/odoo#208720

Integrate whatsapp into marketing automation test tools and flow. Module marketing_automation_whatsapp has been added but is still not integrated into global marketing automation tests. Cover more activity types and scenarios, notably to spot corner cases currently badly covered. Added tests: whatsapp / sms types, opposite triggers (aka: cancel mail not open when mail is opened), rescheduling, scheduling for new participants / new activities, ... Add long awaited performance tests

Integrate whatsapp into marketing automation test tools and flow.
Module marketing_automation_whatsapp has been added but is still
not integrated into global marketing automation tests.

Cover more activity types and scenarios, notably to spot corner cases
currently badly covered.

Added tests: whatsapp / sms types, opposite triggers (aka: cancel mail
not open when mail is opened), rescheduling, scheduling for new
participants / new activities, ...

Add long awaited performance tests for marketing automation. As it may
be quite a time consuming module by generating participants, traces
for millions of records, better start with some performance tests in
order to prepare work for some optimizations.

Finally, fix various issues in marketing automation detected when writing
tests.

Task-4066243: [marketing_automation] Rescheduling issues
Task-4224145: [marketing_automation] Improve test coverage
Task-4759343: [marketing_automation] Integrate Whatsapp into MA test suite
Prepares Task-4224152: [marketing_automation] Performance / Scalability

Forward-Port-Of: odoo/enterprise#85242
Forward-Port-Of: odoo/enterprise#84848

Task-4781564 Forward-Port-Of: odoo/enterprise#85243 Forward-Port-Of: odoo/enterprise#85149

Task-4781564

Forward-Port-Of: odoo/enterprise#85243
Forward-Port-Of: odoo/enterprise#85149

A previous commit 9b133b2cd03a726d330c87a1227903fc925b0ed5 restricted the view and actions we had on the accounting dashboard for a bank journal from a branch company, if the journal belongs to the parent company. In Odoo 17 the fix made sense, but in Odoo 18, the dashboard data added conflicts with another one, resulting in no data being displayed at all when the journal is connected to an online account. This PR adapts the initial fix to use the existing data (deprecate `show_bank_connec

A previous commit 9b133b2cd03a726d330c87a1227903fc925b0ed5 restricted the view and actions we had on the accounting dashboard for a bank journal from a branch company, if the journal belongs to the parent company.

In Odoo 17 the fix made sense, but in Odoo 18, the dashboard data added conflicts with another one, resulting in no data being displayed at all when the journal is connected to an online account.

This PR adapts the initial fix to use the existing data (deprecate `show_bank_connect` in favor of `display_connect_bank_in_dashboard`) and adds the 'credit' type journal in the condition for `show_sync_action` to be used by the dashboard data.

Forward-Port-Of: odoo/enterprise#84976

In the access rights section, referrals group was labelled "Recruitment". The security group has been renamed to "Referrals". Task: 4771561 Forward-Port-Of: odoo/enterprise#84856

In the access rights section, referrals group was labelled "Recruitment". The security group has been renamed to "Referrals".

Task: 4771561

Forward-Port-Of: odoo/enterprise#84856

This commit will change the current filter to use account type instead of internal_group to avoid including "other income" and "other expense" task: 4749344 Forward-Port-Of: odoo/enterprise#84120

This commit will change the current filter to use account type instead of internal_group to avoid including "other income" and "other expense"

task: 4749344

Forward-Port-Of: odoo/enterprise#84120

The aim of this commit is making sure that we update the reconcileCountPerPartnerId properly. Before this commit, the code was only updating partner id who still have line to reconcile. It was wrong as we want to update a partner who doesn't have a line to reconcile anymore. In the meantime, we're now calling the function who reloads the count when we delete a reconciled line. task-4782264 Forward-Port-Of: odoo/enterprise#85091

The aim of this commit is making sure that we update the reconcileCountPerPartnerId properly.

Before this commit, the code was only updating partner id who still have line to reconcile. It was wrong as we want to update a partner who doesn't have a line to reconcile anymore. In the meantime, we're now calling the function who reloads the count when we delete a reconciled line.

task-4782264

Forward-Port-Of: odoo/enterprise#85091

Forward-Port-Of: odoo/enterprise#83960 Forward-Port-Of: odoo/enterprise#81174

Forward-Port-Of: odoo/enterprise#83960
Forward-Port-Of: odoo/enterprise#81174

In this commit we put back the search view of the reconciled lines that we removed wrongly during this commit: https://github.com/odoo/enterprise/pull/80787/commits/04a304d58a56c7d2eeb70429340eb048fa9f2be6 Upgrade PR: https://github.com/odoo/upgrade/pull/7662 no task id Forward-Port-Of: odoo/enterprise#85093

In this commit we put back the search view of the reconciled lines that we removed wrongly during this commit:
https://github.com/odoo/enterprise/pull/80787/commits/04a304d58a56c7d2eeb70429340eb048fa9f2be6

Upgrade PR: https://github.com/odoo/upgrade/pull/7662

no task id

Forward-Port-Of: odoo/enterprise#85093

Before this commit, when rescheduling call activities, this could lead to the following crash: ``` Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl') at ActivityListPopoverItem.template ``` This error state that the activity has no related persona in order to display its avatar in the popover. The persona data must be returned with activity data, and this is a required field therefore any activity should necessarily have a persona in their data. The reas

Before this commit, when rescheduling call activities, this could lead to the following crash:

```
Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl')
at ActivityListPopoverItem.template
```

This error state that the activity has no related persona in order to display its avatar in the popover.
The persona data must be returned with activity data, and this is a required field therefore any activity should necessarily have a persona in their data.

The reason of crash comes from voip method `_format_call_activities` that returns custom activity data that do not pass `persona`. This commit fixes the issue by passing `persona` data like in the usual `_to_store` of activity.

The crash occurs since https://github.com/odoo/odoo/pull/190161

opw-4586756

Forward-Port-Of: odoo/enterprise#85134
Forward-Port-Of: odoo/enterprise#84970

**Steps to reproduce:** - Install Accounting and l10n_lu_reports - Switch to a Luxembourgish company (e.g. LU Company) - Go to "Accounting / Reporting / Statement Reports / Profit and Loss" - Set custom date from "01/01/2025" to "31/12/2025" - Export XML **Issue:** In the exported XML, for "CA_BILAN" declaration section, the start date is set to "01/12/2025" instead of "01/01/2025". **Cause:** When generating the report values of that section, the options are recomputed with the co

**Steps to reproduce:**
- Install Accounting and l10n_lu_reports
- Switch to a Luxembourgish company (e.g. LU Company)
- Go to "Accounting / Reporting / Statement  Reports / Profit and Loss"
- Set custom date from "01/01/2025" to "31/12/2025"
- Export XML

**Issue:**
In the exported XML, for "CA_BILAN" declaration section, the start date is set to "01/12/2025" instead of "01/01/2025".

**Cause:**
When generating the report values of that section, the options are recomputed with the comparison filter.
This section is based on "Balance Sheet" report and recomputing the options of that report provides a different "from date" coming from "_init_options_date" method.

**Solution:**
Force the "from date" of the original options when using a custom range date.

opw-4737810

Forward-Port-Of: odoo/enterprise#85025
Forward-Port-Of: odoo/enterprise#84672

In some cases, it's not possible for customers to trim the description of an invoice line to the accepted length (e.g. for traceability or completeness). It turns out that Avalara will trim and transform the descriptions on our behalf to make them compatible with the government's API. As part of that process, they translate `\n` characters to ` | ` before sending it to the government. Unfortunately, there seems to be a bug with that process on their side. When a '\n' character is included

In some cases, it's not possible for customers to trim the description of an invoice line to the accepted length (e.g. for traceability or completeness).

It turns out that Avalara will trim and transform the descriptions on our behalf to make them compatible with the government's API. As part of that process, they translate `\n` characters to ` | ` before sending it to the government.

Unfortunately, there seems to be a bug with that process on their side. When a '\n' character is included in the description, they don't trim the description they send to the government sufficiently. Perhaps they trim before the '\n' to ' | ' translation, or perhaps they have some other bug.

We sidestep the issue by doing that same translation on our side and sending them that. It doesn't result in any change on the EDI PDF or XML, and this way we can avoid hardcoding these limits on our side.

task-4726372

Forward-Port-Of: odoo/enterprise#84841
Forward-Port-Of: odoo/enterprise#84700

Task-4448873 https://github.com/odoo/odoo/pull/204723 Forward-Port-Of: odoo/enterprise#83240

Task-4448873

https://github.com/odoo/odoo/pull/204723

Forward-Port-Of: odoo/enterprise#83240

Issue: Syntax error is raised when applying period comparison on partner ledger report. Purpose of this PR: Group queries with the parentheses. Steps to Reproduce in Runbot: - install accounting - add period comparison to Partner Ledger Report - try to apply period comparison opw-4730435 Forward-Port-Of: odoo/enterprise#85074 Forward-Port-Of: odoo/enterprise#83652

Issue:
Syntax error is raised when applying period comparison on partner ledger report.

Purpose of this PR:
Group queries with the parentheses.

Steps to Reproduce in Runbot:
- install accounting
- add period comparison to Partner Ledger Report
- try to apply period comparison

opw-4730435

Forward-Port-Of: odoo/enterprise#85074
Forward-Port-Of: odoo/enterprise#83652

**purpose of this PR:** Entering commands such as "/who" or similar in a chat or channel previously caused a crash. the issue has been resolved by updating the message posting flow to ensure that commands are processed correctly. community: https://github.com/odoo/odoo/pull/209064 task-[4759888](https://www.odoo.com/odoo/project/1519/tasks/4759888) Forward-Port-Of: odoo/enterprise#84418

**purpose of this PR:**

Entering commands such as "/who" or similar in a chat or channel previously caused a crash. the issue has been resolved by updating the message posting flow to ensure that commands are processed correctly.

community: https://github.com/odoo/odoo/pull/209064
task-[4759888](https://www.odoo.com/odoo/project/1519/tasks/4759888)

Forward-Port-Of: odoo/enterprise#84418

Steps to reproduce: - Raise Product Price Accuracy to 6 - Set Global Rounding - Fetch latest currency rate for USD from Bank of Mexico - Create a [TEST] Product with: - UNSPSC Category: 12141502 Magnesium Mg - UMT Aduana: kg - Make an Invoice as follows: - Customer: Deco Addict - Currency USD - Product: [TEST] - Price: 3,114.515000 - Qty UMT: 11 - Incoterm: EX WORKS - External Trade: Definitive - Confirm Invoice - Send CFDI Issue: Validation will fail with er

Steps to reproduce:
- Raise Product Price Accuracy to 6
- Set Global Rounding
- Fetch latest currency rate for USD from Bank of Mexico
- Create a [TEST] Product with:
  - UNSPSC Category: 12141502 Magnesium Mg
  - UMT Aduana: kg
- Make an Invoice as follows:
  - Customer: Deco Addict
  - Currency USD
  - Product: [TEST]
  - Price: 3,114.515000
  - Qty UMT: 11
  - Incoterm: EX WORKS
  - External Trade: Definitive
- Confirm Invoice
- Send CFDI

Issue: Validation will fail with error
"""
Code : CCE122
Message : El atributo cce20:ComercioExterior:TotalUSD no coincide con la suma de ValorDolares de las mercancías. """

In the xml, the ValorDolares for the sold item will be 3114.5150 but the attribute TotalUSD will be 3114.52 This occurs because ValorDolares are emitted as unrounded amount, but TotalUSD is rounded to 2 decimals. When working with 3+ digits the amounts might not add up correctly.
Note: Before version 18, ValorDolares (`product_values['total']`) amount was already rounded according to the currency decimals (2) and there was no issue

opw-4662692
opw-4686226

Forward-Port-Of: odoo/enterprise#84027

Added missing tests for the return period filter. Mainly testing the fallback to normal filter in case it is aligned to a normal date filter. Forward-Port-Of: odoo/enterprise#84779

Added missing tests for the return period filter.
Mainly testing the fallback to normal filter in case it is aligned to a normal date filter.

Forward-Port-Of: odoo/enterprise#84779

This commit removes the demo data for portal user as a portal user cannot be assigned to tasks. taskid:3703637 Forward-Port-Of: odoo/enterprise#81826 Forward-Port-Of: odoo/enterprise#56588

This commit removes the demo data for portal user as a portal user cannot be assigned to tasks.

taskid:3703637

Forward-Port-Of: odoo/enterprise#81826
Forward-Port-Of: odoo/enterprise#56588

Description of the issue this commit addresses: Zero balance lines are creating friction when reconciling lines. They will never need a renconciliation but they still impair the user's ability to reconcile other lines together if selected. --- Desired behavior after this commit is merged: When reconciling lines, the zero balance ones are simply ignored and the reconciliation proceeds as if they were not selected. --- task-4723956 Forward-Port-Of: odoo/enterprise#84944 Forward-

Description of the issue this commit addresses:

Zero balance lines are creating friction when reconciling lines. They will never need a renconciliation but they still impair the user's ability to reconcile other lines together if selected.

---

Desired behavior after this commit is merged:

When reconciling lines, the zero balance ones are simply ignored and the reconciliation proceeds as if they were not selected.

---

task-4723956

Forward-Port-Of: odoo/enterprise#84944
Forward-Port-Of: odoo/enterprise#84851

It's possible to have a 0 purchase order line with a negative invoiced qty if there is only a credit note linked to the PO. When the budget report process this order line, it will trigger a traceback. This commit aims to handle this case so the report can be open without issue. opw-4749480 Forward-Port-Of: odoo/enterprise#84812

It's possible to have a 0 purchase order line with a negative invoiced qty if there is only a credit note linked to the PO. When the budget report process this order line, it will trigger a traceback.

This commit aims to handle this case so the report can be open without issue.

opw-4749480

Forward-Port-Of: odoo/enterprise#84812

The incoterm code of a line in the intrastat report is the incoterm code from the move or if there is no incoterm code on the move, the one from the company. When creating the request when unfolding report lines, the incoterm code was always checked on the move and not on the company. This would not return lines without incoterm code. This commit changes the incoterm domain to also check the incoterm code of the move company when no incoterm code is set on the move. Steps to reproduce: - F

The incoterm code of a line in the intrastat report is the incoterm code from the move or if there is no incoterm code on the move, the one from the company.
When creating the request when unfolding report lines, the incoterm code was always checked on the move and not on the company. This would not return lines without incoterm code.
This commit changes the incoterm domain to also check the incoterm code of the move company when no incoterm code is set on the move.

Steps to reproduce:
- From an EU company, create an invoice to a company in another EU country
- Do not set an incoterm on the invoice
- In settings, set a default incoterm on the company
- Display the intrastat report for the time period of the invoice
- Try to unfold the line corresponding to the invoice

opw-4642781

Forward-Port-Of: odoo/enterprise#84922
Forward-Port-Of: odoo/enterprise#84734

Steps to reproduce the issue: - Create a quality check with any parameters - Add a future activity - Click on the activity icon in the top bar - The activity summary shows: - 0 Late, 0 Today, 1 Future - Click on "Late" Issue: No filter is applied and all quality checks are displayed. Solution: Added predefined filters for activity deadlines (Late, Today, Future) in the search view of the quality.check model, to align with other models using mail.activity.mixin. opw-4727840

Steps to reproduce the issue:
- Create a quality check with any parameters
- Add a future activity
- Click on the activity icon in the top bar
- The activity summary shows:
    - 0 Late, 0 Today, 1 Future
- Click on "Late"

Issue:
No filter is applied and all quality checks are displayed.

Solution:
Added predefined filters for activity deadlines (Late, Today, Future) in the search view of the quality.check model, to align with other models using mail.activity.mixin.

opw-4727840

Forward-Port-Of: odoo/enterprise#84523

Prior to this commit, digits in a partner name would be converted to an x, preventing you from searching for digits in a T9 name search. After this commit, the digits remain as they are, so they can be searched for in a T9 name search. Forward-Port-Of: odoo/enterprise#84393

Prior to this commit, digits in a partner name would be converted to an x, preventing you from searching for digits in a T9 name search.

After this commit, the digits remain as they are, so they can be searched for in a T9 name search.

Forward-Port-Of: odoo/enterprise#84393

In the bank reco widget, applicable models are visible for statement lines. We should limit the ones visible to ones that are manual and which have counterparts that can actually work to produce an entry, so with an account (and a label that can be matched). Also filter on the company. task-4749345 Forward-Port-Of: odoo/enterprise#84139

In the bank reco widget, applicable models are visible for statement lines.

We should limit the ones visible to ones that are manual and which have counterparts that can actually work to produce an entry, so with an account (and a label that can be matched).
Also filter on the company.

task-4749345

Forward-Port-Of: odoo/enterprise#84139

How to reproduce: 1. Run the localhost with the `--with-demo` flag. 2. Install the `Social` Module. 3. Now, from the CONFIGURATION > click SETTINGS > check ENABLE DEMO MODE. Issue: - You will see that the demo data is not loaded. Reason: - There is a recent PR (https://github.com/odoo/odoo/pull/206246) which removed the file we are trying to access. Fix: - We update the file path. Task-4765000 Forward-Port-Of: odoo/enterprise#84583

How to reproduce:
1. Run the localhost with the `--with-demo` flag.
2. Install the `Social` Module.
3. Now, from the CONFIGURATION > click SETTINGS > check ENABLE DEMO MODE.

Issue:
- You will see that the demo data is not loaded.

Reason:
- There is a recent PR (https://github.com/odoo/odoo/pull/206246) which removed the file we are trying to access.

Fix:
- We update the file path.

Task-4765000

Forward-Port-Of: odoo/enterprise#84583

The trigram index on res.partner/t9_name is not useful. The "t9 encoding" reduces the set of possible trigrams far too much for the trigram to be effective in discriminating between large amounts of results. In consideration of the above, this commit removes the trigram index. Forward-Port-Of: odoo/enterprise#84864

The trigram index on res.partner/t9_name is not useful. The "t9 encoding" reduces the set of possible trigrams far too much for the trigram to be effective in discriminating between large amounts of results.

In consideration of the above, this commit removes the trigram index.

Forward-Port-Of: odoo/enterprise#84864

**Steps to reproduce:** - Install Accounting - Install a module that adds a button to tax report (e.g. l10n_ar) - Switch to an Argentinian company (e.g. (AR) Responsable Inscripto) - Go to "Accounting / Reporting / Statements Reports / Tax Return" (i.e. Tax Report) - Select "Argentinean VAT Book (AR)" as report - A cog button should appear after the report name with "VAT Book (ZIP)" option - With browser debug feature, switch to a responsive display and reduce the width or - Repeate

**Steps to reproduce:**
- Install Accounting
- Install a module that adds a button to tax report (e.g. l10n_ar)

- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)
- Go to "Accounting / Reporting / Statements Reports / Tax Return" (i.e. Tax Report)
- Select "Argentinean VAT Book (AR)" as report
- A cog button should appear after the report name with "VAT Book (ZIP)" option

- With browser debug feature, switch to a responsive display and reduce the width
or
- Repeatedly increase the zoom to increase the size of the button

**Issue:**
For a certain range of width the cog button is not visible.

**Cause:**
".o_control_panel_breadcrumbs" element that contains the buttons has a min-width of 200px, hiding all elements that are after these 200px when reducing the width.

**Solution:**
Increase the min-width to 350px.
The value is arbitrary but it covers well this use case.
With a lower value, the cog button could still be hidden in the case of the Argentinian Tax Report in Spanish language.

opw-4747697

Forward-Port-Of: odoo/enterprise#84432

Before, the feature was not usable because HMRC would only accept whole pounds for the total payments made and the materials cost. The fix was to round the values on the report to whoule pounds for those two columns. This way, it would become valid for HMRC as the return is based on those report values. opw-4686819 Forward-Port-Of: odoo/enterprise#83829

Before, the feature was not usable because HMRC would only accept whole pounds for the total payments made and the materials cost.

The fix was to round the values on the report to whoule pounds for those two columns. This way, it would become valid for HMRC as the return is based on those report values.

opw-4686819

Forward-Port-Of: odoo/enterprise#83829

This commit will unfold the statement line depending on a context key task: 4749346 Forward-Port-Of: odoo/enterprise#84123

This commit will unfold the statement line depending on a context key

task: 4749346

Forward-Port-Of: odoo/enterprise#84123

Currently, an error occurs when changing the internal note of an order in **POS Restaurant** if all food items are removed before updating the order. **Steps to reproduce:** - Open a POS session for the **Restaurant** shop. - Select a table, add the food (e.g., "Cheese Burger") and place the order. - Add an `Internal Note` to the ordered food item. - Remove the food item and click the `Order` button (it shows '-1 Food'). - Observe the error. **Error:** `KeyError: 'qty'` The issue

Currently, an error occurs when changing the internal note of an order in **POS Restaurant** if all food items are removed before updating the order.

**Steps to reproduce:**
- Open a POS session for the **Restaurant** shop.
- Select a table, add the food (e.g., "Cheese Burger") and place the order.
- Add an `Internal Note` to the ordered food item.
- Remove the food item and click the `Order` button (it shows '-1 Food').
- Observe the error.

**Error:**
`KeyError: 'qty'`

The issue occurs because when all food items are removed, `note_history` does not contain the `qty` key and it attempts to access `qty` from `note` at [1].

This commit resolves the issue by adding an additional check to ensure that 'qty' is in `note` before accessing the `qty` key.

[1] - https://github.com/odoo/enterprise/blob/f1615134029860d32b95ade09738549a7bb1632d/pos_preparation_display/models/pos_order.py#L79-L80

Sentry - 6303446407

Forward-Port-Of: odoo/enterprise#84900
Forward-Port-Of: odoo/enterprise#79685

This commit will add the newly introduce field description in this commit: https://github.com/odoo/odoo/pull/205191/commits/61c0ce904a6b32773b55a2e9e123b5c79c0d42b7 in the set account of the bank rec widget task: 4750045 Forward-Port-Of: odoo/enterprise#84111

This commit will add the newly introduce field description in this commit: https://github.com/odoo/odoo/pull/205191/commits/61c0ce904a6b32773b55a2e9e123b5c79c0d42b7 in the set account of the bank rec widget

task: 4750045

Forward-Port-Of: odoo/enterprise#84111

To reproduce: ============= 1. have a partner with email test@odoo.com in company1 2. allow to Demo only the company2 3. setup helpdesk team for company2 and enable it on website 4. create a ticket from website with email : test@odoo.com 5. check the ticket will be created with the partner from company1 6. try to open the ticket as Demo user, you will get an access error Problem: ========= `find_or_create` method of `res.partner` model is not taking into account the `company_id` whe

To reproduce:
=============
1. have a partner with email test@odoo.com in company1
2. allow to Demo only the company2
3. setup helpdesk team for company2 and enable it on website
4. create a ticket from website with email : test@odoo.com
5. check the ticket will be created with the partner from company1
6. try to open the ticket as Demo user, you will get an access error

Problem:
=========
`find_or_create` method of `res.partner` model is not taking into account
the `company_id` when searching for the partner.

Solution:
=========
uses `_mail_find_partner_from_emails` method of `mail.thread` model
to find/create the partner with extra domain containing `company_id`.

opw-4699518

Forward-Port-Of: odoo/enterprise#84934
Forward-Port-Of: odoo/enterprise#84245

Commit baa934898f184b10ae4c5c51e26fabe4e0178a86 updated the body for ongoing process responses when checking the status of a report submitted through SBR. The variable `error_description` it tries to assign is not defined in that scope of the function, resulting in an error. This PR reverts the value assigned to be the status description, as it was prior to the above commit. opw-4775345 Forward-Port-Of: odoo/enterprise#84749

Commit baa934898f184b10ae4c5c51e26fabe4e0178a86 updated the body for ongoing process responses when checking the status of a report submitted through SBR.

The variable `error_description` it tries to assign is not defined in that scope of the function, resulting in an error.

This PR reverts the value assigned to be the status description, as it was prior to the above commit.

opw-4775345

Forward-Port-Of: odoo/enterprise#84749

Currently a ParseError is arising when the user installs the `pos_settle_due` module after deleting the `Services` in Product Categories/Configuration. Steps to reproduce: --- - Install `Invoicing` application (without demo data). - Invoicing > Configuration > Product Categories > Delete `Services` - Now install `pos_settle_due` module Traceback: --- ``` ValueError: External ID not found in the system: product.product_category_services ParseError: while parsing /home/odoo/src/ent

Currently a ParseError is arising when the user installs the `pos_settle_due` module after deleting the `Services` in Product Categories/Configuration.

Steps to reproduce:
---
- Install `Invoicing` application (without demo data).
- Invoicing > Configuration > Product Categories > Delete `Services`
- Now install `pos_settle_due` module

Traceback:
---
```
ValueError: External ID not found in the system: product.product_category_services

ParseError: while parsing /home/odoo/src/enterprise/saas-18.2/pos_settle_due/data/pos_settle_due_data.xml:4, somewhere inside <record id="product_product_settle" model="product.product">
            <field name="name">Settle Due</field>
            <field name="categ_id" ref="product.product_category_services"/>
            <field name="type">service</field>
            <field name="weight">0.00</field>
            <field name="available_in_pos">False</field>
            <field name="taxes_id" eval="[]"/>
        </record>
```

The error occurs because the user deleted `Services` in Product Categories, and then tried to install the other module.

This commit resolves the error by providing a False value for the field if the product category is missing.

sentry-6377659355

Forward-Port-Of: odoo/enterprise#81741

The system failed to retrieve `company.l10n_ar_afip_ws_key_id.pem_key` because of quick create. Steps to Reproduce: 1. Switch to `(AR) Exento Company`. 2. Navigate to `Settings `> `Invoicing`. 3. Search for `Argentinean Localization`. 4. In `Primary Key`, clear the field, enter any value, and click Create. 5. Click `Generate Renewal Request`. Error: `TypeError: argument should be a bytes-like object or ASCII string, not 'bool'` Solution: Add `no_quick_create : True` for l10n_ar

The system failed to retrieve `company.l10n_ar_afip_ws_key_id.pem_key` because of quick create.

Steps to Reproduce:

1. Switch to `(AR) Exento Company`.
2. Navigate to `Settings `> `Invoicing`.
3. Search for `Argentinean Localization`.
4. In `Primary Key`, clear the field, enter any value, and click Create.
5. Click `Generate Renewal Request`.

Error:
`TypeError: argument should be a bytes-like object or ASCII string, not 'bool'`

Solution:
Add `no_quick_create : True` for l10n_ar_afip_ws_key_id field.

Sentry - 5999498377

Forward-Port-Of: odoo/enterprise#84940
Forward-Port-Of: odoo/enterprise#83233

This is a useful option that is hard to know about unless you read the code or are told it exists. It should be visible in the report options. In the context of: task-4734528 Forward-Port-Of: odoo/enterprise#83556

This is a useful option that is hard to know about unless you read the code or are told it exists.
It should be visible in the report options.

In the context of:
task-4734528

Forward-Port-Of: odoo/enterprise#83556

part of task-4642428 Forward-Port-Of: odoo/enterprise#84538

part of task-4642428

Forward-Port-Of: odoo/enterprise#84538