Before this commit, when posting a message in chat window, the new message being posted had its size flicker momentarily. This happens because when posting a new message, the message list contains a temporary message with the content momentarily and soon replaced by the genuine message from server data. The genuine message shows quick actions like "Add a reaction", which the temporary message has not. Since these quick actions take some horizontal place, the temporary message was bigger on

Before this commit, when posting a message in chat window, the new message being posted had its size flicker momentarily.

This happens because when posting a new message, the message list contains a temporary message with the content momentarily and soon replaced by the genuine message from server data.

The genuine message shows quick actions like "Add a reaction", which the temporary message has not. Since these quick actions take some horizontal place, the temporary message was bigger on width than an actual message, which results to this flickering when the message takes more than 1 line.

This commit fixes the issue by allocating some space when a message has less (or no) available quick actions, so that their size matches with genuine message that have quick actions.

Before / After
![before](https://github.com/user-attachments/assets/73ad5051-153f-4294-95cf-225a1b4d749e) ![after](https://github.com/user-attachments/assets/09ad2eb0-67f4-4813-aade-8883990b525a)

Forward-Port-Of: odoo/odoo#204958

[REF] web: move default dates to a function - getAllDayDates function was added to be able to inherit it in other modules and change default dates if needed. task-4164485 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205778 Forward-Port-Of: odoo/odoo#189917

[REF] web: move default dates to a function
- getAllDayDates function was added to be able to inherit it
  in other modules and change default dates if needed.

task-4164485


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

Forward-Port-Of: odoo/odoo#205778
Forward-Port-Of: odoo/odoo#189917

In this commit we remove checkDelay from codebase because it is no longer used since https://github.com/odoo/odoo/pull/194508 has been merged. 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#205524

In this commit we remove checkDelay from codebase because it is no longer used since https://github.com/odoo/odoo/pull/194508 has been merged.

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

Currently, a 404 error is occurring when the user clicks on the Check the sample button. <b>Steps to reproduce this issue:</b> 1) Install sales without demo data 2) Click on the `Check a sample. Its clean!` button <b>Issue:- </b> A 404 error occurs with a blank page <b>Cause:-</b> This issue is occurring because the link to open the sample quotation was changed in the Odoo documentation. <b>Solution:-</b> Give a valid link to open the sample quotation pdf opw-4708039

Currently, a 404 error is occurring when the user clicks on the Check the sample button.

<b>Steps to reproduce this issue:</b>

1) Install sales without demo data
2) Click on the `Check a sample. Its clean!` button

<b>Issue:- </b>

A 404 error occurs with a blank page

<b>Cause:-</b>
This issue is occurring because the link to open the sample quotation
was changed in the Odoo documentation.

<b>Solution:-</b>

Give a valid link to open the sample quotation pdf

opw-4708039

Forward-Port-Of: odoo/odoo#205520

Steps to reproduce : 1) Install Ecommerce 2) Open a product that has an extra price (take the customizable desk) 3) Change the pricelist to Euro (€) <b>Issue</b>:- The extra price keeps being displayed in $ even if the price is in €. <b>Cause</b>:- We displayed the monetary symbol of the extra price based on the pricelist or company currency. https://github.com/odoo/odoo/blob/99d00987aa0fba0e52a8c416e1a6a3b514b9e99a/addons/website_sale/views/variant_templates.xml#L154-L156

Steps to reproduce :

1) Install Ecommerce
2) Open a product that has an extra price (take the customizable desk) 
3) Change the pricelist to Euro (€)

<b>Issue</b>:-

The extra price keeps being displayed in $ even if the price is in €.

<b>Cause</b>:-

We displayed the monetary symbol of the extra price based on the pricelist or company currency.
https://github.com/odoo/odoo/blob/99d00987aa0fba0e52a8c416e1a6a3b514b9e99a/addons/website_sale/views/variant_templates.xml#L154-L156

We don't get any pricelist value because in the below-mentioned commit, we removed the pricelist from the values that are used in the template. So it keeps displaying the company currency.

https://github.com/odoo/odoo/pull/159746/files#diff-83686977d1607bdb0a3e755e9d22ec4496c1dc4caebfff4bee3902ddd1b3e866L641

<b>Solution</b>:-

Since the value of the pricelist is provided from the website previously, 
So take the value of the pricelist from the website directly in the template.

opw-4712968

Forward-Port-Of: odoo/odoo#205483

Improve coverage of address sync fields. Purpose is to make cases clearer and cover a bit more current code branches * first contact: updates void parent, not parent with address; * child sync / siblings sync: limited to one level; * invoice / delivery / other adresses are never synchronized; * no upstream update of addresses; Task-4708358 Part of Task-4377720 Forward-Port-Of: odoo/odoo#205903

Improve coverage of address sync fields. Purpose is to make cases clearer and cover a bit more current code branches

  * first contact: updates void parent, not parent with address;
  * child sync / siblings sync: limited to one level;
  * invoice / delivery / other adresses are never synchronized;
  * no upstream update of addresses;

Task-4708358
Part of Task-4377720

Forward-Port-Of: odoo/odoo#205903

Before this commit: When scrolling, the Kanban record drop-down menu overlap Kanban header. After this commit: The Kanban record drop-down menu should not overlap with the Kanban header while scrolling. Task-4686607 Forward-Port-Of: odoo/odoo#204666

Before this commit:
When scrolling, the Kanban record drop-down menu overlap Kanban header.

After this commit:
The Kanban record drop-down menu should not overlap with the Kanban header while scrolling.

Task-4686607

Forward-Port-Of: odoo/odoo#204666

Before this commit orders were synchronized between devices even when no table were used. This commit add a check to ensure that orders are only synchronized when a table is set. The behavior will be test after the backport of 205293 Forward-Port-Of: odoo/odoo#205571

Before this commit orders were synchronized between devices even when no table were used.

This commit add a check to ensure that orders are only synchronized when a table is set.

The behavior will be test after the backport of 205293

Forward-Port-Of: odoo/odoo#205571

But also: - not 400/500 should keep the chain index (each sequential number should have a corresponding invoice) - confirmation datetime should stay the same when the invoice was rejected - Before, the response could get complicated where the json was stringified in the json, while here it is all in the json itself. And so the 400 should be treated the same as other errors. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is

But also:
- not 400/500 should keep the chain index (each sequential number should have a corresponding invoice)
- confirmation datetime should stay the same when the invoice was rejected
- Before, the response could get complicated where the json was stringified in the json, while here it is all in the json
 itself. And so the 400 should be treated the same as other errors.

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

There is an issue in the line template, where the 'vals' of the line are reassigned to the 'price_vals' when building the 'cac:Price'. This means that any extension done to add values after the price no longer have access to the line vals but only the price ones. This is unwanted, and the template is adapted to avoid reassigning 'vals'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205827

There is an issue in the line template, where the
'vals' of the line are reassigned to the 'price_vals' when building the 'cac:Price'.

This means that any extension done to add values after the price no longer have access to the line vals but only the price ones.

This is unwanted, and the template is adapted to avoid reassigning 'vals'.

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

Forward-Port-Of: odoo/odoo#205827

### Steps to reproduce: - Install "l10n_hu" and switch to Hungarian company - In Settings set NAV credentials to "demo" - Make sure accounts are set on the company & customer - Create an invoice, confirm, Sent & Print - Create a Credit Note for this invoice, Send & Print - On the Credit Note PDF the account of the customer is displayed under the "Supplier" ### Cause: The account always shows under the supplier `if 'out' in o.move_type` so also for credit notes ('out_refund'). ### So

### Steps to reproduce:
- Install "l10n_hu" and switch to Hungarian company
- In Settings set NAV credentials to "demo"
- Make sure accounts are set on the company & customer
- Create an invoice, confirm, Sent & Print
- Create a Credit Note for this invoice, Send & Print
- On the Credit Note PDF the account of the customer is displayed under the "Supplier"

### Cause:
The account always shows under the supplier `if 'out' in o.move_type` so also for credit notes ('out_refund').

### Solution:
Change the condition of the display and add the bank account in a xpath.

opw-4710449

Forward-Port-Of: odoo/odoo#205724

Reproduce: Give user Inventory User rights > MO > Miscellaneous > Project Solution: Removed the group for Inventory Admin from the field project_id in mrp_production view Description of the issue/feature this PR addresses: The project field in an MO is only visible if you are administrator of Inventory.  If you have admin rights to MRP and/or projects you can't see the field. Current behavior before PR: In MO under Miscellaneous page we can not see project field without Inventory ad

Reproduce:
Give user Inventory User rights > MO > Miscellaneous > Project

Solution:
Removed the group for Inventory Admin from the field project_id in mrp_production view

Description of the issue/feature this PR addresses:
The project field in an MO is only visible if you are administrator of Inventory.  If you have admin rights to MRP and/or projects you can't see the field.

Current behavior before PR:
In MO under Miscellaneous page we can not see project field without Inventory admin group

Desired behavior after PR is merged:
In MO under Miscellaneous page user can see project field with group project admin only.

opw-4708084

Forward-Port-Of: odoo/odoo#205516

__Current behavior before commit:__ The Cloudflare Turnstile token expires every 300 seconds (see [Cloudflare doc][1]) which makes the widget reload. There was currently no callback handling this event. If the check had already succeeded, the spinner of the button would have been removed. Thus the second time `turnstileSuccess` would be called, `spinner` would be `null` and it would throw an error when reading `spinner.parentElement`. __Description of the fix:__ Hid the spinner in `

__Current behavior before commit:__
The Cloudflare Turnstile token expires every 300 seconds (see
[Cloudflare doc][1]) which makes the widget reload.
There was currently no callback handling this event.

If the check had already succeeded, the spinner of the button would have
been removed. Thus the second time `turnstileSuccess` would be called,
`spinner` would be `null` and it would throw an error when reading
`spinner.parentElement`.

__Description of the fix:__
Hid the spinner in `turnstileSuccess` instead of removing it.
Added an `expired-callback` to show the spinner back on the button.

__Steps to reproduce the issue on runbot:__
1. Enable and configure Cloudflare Turnstile
2. Go to the `/contactus` page
3. Check the box, wait 5 minutes and check the box again

[1]: https://developers.cloudflare.com/turnstile/get-started/client-side-rendering/#:~:text=the%20next%20300%20seconds

opw-4629962
opw-4681945
opw-4620019
opw-4615863
opw-4640032

Forward-Port-Of: odoo/odoo#202893

**Current behavior:** Using auto valuation and anglo saxon accounting, when a project has some profitability report items for auto valued product, the COGS invoice lines will appear under the revenue section rather than the cost section of the project's profitability report. **Expected behavior:** COGS lines are shown as costs. **Steps to reproduce:** 1. Create a service product that generates a project on sale, on the project template set a specific analytic account 2. Create anothe

**Current behavior:**
Using auto valuation and anglo saxon accounting, when a project has some profitability report items for auto valued product, the COGS invoice lines will appear under the revenue section rather than the cost section of the project's profitability report.

**Expected behavior:**
COGS lines are shown as costs.

**Steps to reproduce:**
1. Create a service product that generates a project on sale, on the project template set a specific analytic account

2. Create another product with real time valuation and assign the COGS account on the product category's expense account

3. Sell some of the service product and the auto val product in the same order, deliver it -> generate invoice & post it

4. In the project's settings, open the profitability report observe that the invoice line for the cost of goods sold account entry is displayed as a negative revenue, rather than a cost

**Cause of the issue:**
In `sale_project` there is no logic to separate the COGS AMLs from the rest of an invoice's line ids.

**Fix:**
Transform the loop in `_get_revenues_items_from_invoices` https://github.com/odoo/odoo/blob/bb6a4fbb92b1a1a1e13e32b27c4c9f2813570fda/addons/sale_project/models/project.py#L656 into two loops such that the existing one iterates twice.

First iteration collects the `revenues` items data (exactly as it currently does)

Second iteration collects the `costs` items (cogs lines)

And the method will now return a dict of data for both `revenues` report items and `costs` report items (and should be renamed/refactored in master)

opw-4652472

Forward-Port-Of: odoo/odoo#205777
Forward-Port-Of: odoo/odoo#203936

Steps to reproduce: 1) Install sales, l10n_din5008_sale and enable pricelist from settings 2) Change the document layout to `DIN 5008` from settings 3) Open the pricelist from sales and print the pricelist report with a product Issue:- Pricelist report gets printed with "Invoice" title Cause:- This is because in the `DIN 5008` report, we print the invoice title by default if there are no `docs` or `object` values. https://github.com/odoo/odoo/blob/c80db0e6ff96ed4d8a00f018176

Steps to reproduce:

1) Install sales, l10n_din5008_sale and enable pricelist from settings 
2) Change the document layout to `DIN 5008` from settings
3) Open the pricelist from sales and print the pricelist report with a product

Issue:-

Pricelist report gets printed with "Invoice" title

Cause:-

This is because in the `DIN 5008` report, we print the invoice title by default if there are no `docs` or `object` values.

https://github.com/odoo/odoo/blob/c80db0e6ff96ed4d8a00f01817694a4edcca6c64/addons/l10n_din5008/report/din5008_report.xml#L93

Solution:
Provide the docs value to the pricelist report values.

opw-4680444

Forward-Port-Of: odoo/odoo#205147

Steps to Reproduce (Calendar View): 1. Open the Calendar view on the monthly scale. 2. Create a planning slot by clicking on a date to plan. 3. Notice that the default hours are set to 7 AM to 7 PM. Steps to Reproduce (Gantt View): 1. Open the Gantt view on the weekly scale. 2. Create a planning slot by clicking on a grid cell. 3. Observe that the default hours are set to 8 AM to 5 PM. - In the Calendar view on the monthly scale, creating a planning slot defaults to 7 AM to 7 PM.

Steps to Reproduce (Calendar View):
1. Open the Calendar view on the monthly scale.
2. Create a planning slot by clicking on a date to plan.
3. Notice that the default hours are set to 7 AM to 7 PM.

Steps to Reproduce (Gantt View):
1. Open the Gantt view on the weekly scale.
2. Create a planning slot by clicking on a grid cell.
3. Observe that the default hours are set to 8 AM to 5 PM.

- In the Calendar view on the monthly scale, creating a planning slot
  defaults to 7 AM to 7 PM.
- In the Gantt view on the weekly scale, creating a planning slot defaults
  to 8 AM to 5 PM.
- These default hours do not align with the working calendar, leading to
  inconsistencies.

- This fix adjusts the default hour settings in both views to ensure they align
  with the working calendar and account for unavailability.

task-4164485

Forward-Port-Of: odoo/enterprise#83330
Forward-Port-Of: odoo/enterprise#69888

Commits fc49984a and 2644a63b introduced changes to: - Prevent rejections for invoices older than 72 hours (error 301). - Use the correct partner/branch timezone when generating the CFDI. However, these changes also cause each re-stamping attempt to use the current timestamp, resulting in duplicates on the SAT if the first attempt times out or is lost (e.g., due to a disconnection). The PAC sees each request as a distinct CFDI if there is even a slight difference in the timestamp. This f

Commits fc49984a and 2644a63b introduced changes to:
- Prevent rejections for invoices older than 72 hours (error 301).
- Use the correct partner/branch timezone when generating the CFDI.

However, these changes also cause each re-stamping attempt to use the current timestamp, resulting in duplicates on the SAT if the first attempt times out or is lost (e.g., due to a disconnection). The PAC sees each request as a distinct CFDI if there is even a slight difference in the timestamp.

This fix ensures that the same emission timestamp (stored in `l10n_mx_edi_post_time`) is reused for subsequent stamping attempts, producing an identical XML and preventing duplicates on the SAT.

Steps to reproduce the original issue:
1. Create and confirm an invoice.
2. Stamp the invoice.
3. Manually set the EDI status to “to_send”: ```python record.edi_document_ids.write({"state": "to_send"}) ```
4. Stamp again without persisting the emission timestamp => a new CFDI is generated.

Expected result after the fix:
- The system reuses the same emission timestamp (l10n_mx_edi_post_time) for each attempt, preventing duplicate CFDIs on the SAT.

According to the [SAT
documentation](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf)
the attribute `Fecha` must be the expedition date.

Forward-Port-Of: odoo/enterprise#83319
Forward-Port-Of: odoo/enterprise#81882

In this commit we remove checkDelay from codebase because it is no longer used since https://github.com/odoo/odoo/pull/194508 has been merged. Forward-Port-Of: odoo/enterprise#83217

In this commit we remove checkDelay from codebase because it is no longer used since https://github.com/odoo/odoo/pull/194508 has been merged.

Forward-Port-Of: odoo/enterprise#83217

When a company partner is selected for an order, the commit https://github.com/odoo/odoo/commit/270779c8250272920d759fbe7b6cfc889e2f5969 automatically sets the order to invoice. This causes the order to miss required localization fields, leading to an error during payment. opw-4670131 Forward-Port-Of: odoo/enterprise#82061

When a company partner is selected for an order, the commit https://github.com/odoo/odoo/commit/270779c8250272920d759fbe7b6cfc889e2f5969 automatically sets the order to invoice. This causes the order to miss required localization fields, leading to an error during payment.

opw-4670131

Forward-Port-Of: odoo/enterprise#82061

At the moment, if a cancellation has been requested, the 'Update SAT' button isn't always visible on the invoice. Analysis: The condition for the 'Update SAT' button being visible is that at least one of the EDI documents falls under one of the domains in `_get_update_sat_status_domains`. In particular, the 'Update SAT' status is visible if there is an EDI document with the 'invoice_sent' status and whose SAT status is not 'cancelled' or 'skip'. If the user requests the cancellation of th

At the moment, if a cancellation has been requested, the 'Update SAT' button isn't always visible on the invoice.

Analysis:
The condition for the 'Update SAT' button being visible is that at least one of the EDI documents falls under one of the domains in `_get_update_sat_status_domains`. In particular, the 'Update SAT' status is visible if there is an EDI document with the 'invoice_sent' status and whose SAT status is not 'cancelled' or 'skip'.

If the user requests the cancellation of the CFDI before the SAT status is fetched for the first EDI document (which represents the sending of the invoice), its SAT status will be set to 'skip'.

As a result, the 'Update SAT' button will no longer be visible, meaning that the user can not update the invoice's state from fetching the SAT status.

![image](https://github.com/user-attachments/assets/8a62a056-f91e-4a58-acdf-3286de6cb159)

Fix:
The Update SAT button should also be visible if there is a document in 'invoice_cancel_requested' whose SAT state is valid.

opw-4375788

Forward-Port-Of: odoo/enterprise#83289