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

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

Current behavior before PR:

- When pressing Enter, the styles applied to the text were not carried over to the
newly created line.

- When a nested inline element was removed during the editor's cleaning process,
its parent inline element (if also empty) was not removed. This caused the that
inline element to become inaccessible.

- When pressing `shift+enter` within an inline element with a subsequent sibling
`<br>`, a new line break `<br>` is inserted within the inline element. However, the
cursor appears outside the inline element.

Desired behavior after PR is merged:

- Now, when Enter is pressed, if styles are applied to the text, those styles will
be carried over to the newly created line.

- Now, during the editor cleaning process, if an empty inline element is removed,
all of its empty ancestor inline elements are also removed.

- Now, when pressing `shift+enter` inside the inline element with a next sibling
`<br>`, a new line break `<br>` is inserted inside the inline element. Additionally,
a feff character is inserted after the `<br>` tag to ensure that the cursor
remains inside the inline element.

task-2822187

Forward-Port-Of: odoo/odoo#179255

**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:**
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- Go to "Settings / Technical / Database Structure / Decimal Accuracy"
- Set 4 digits for "Product Price"
- Create a product with a lower price than 0.01 (e.g. 0.0045)
- Create an invoice:
  * Customer: [a Peruvian customer] (e.g. Comercial Constructora los Patitos S.A.)
  * Product: [the created product]
  * Quantity: 100
- Confirm the invoice
- Process the invoice by the E-invoicing service

**Issue:**
An error is triggered because "PriceTypeCode" is set to "02", which is the code used to declare that it is free.
But in this case, it is not free.

**Cause:**
"PriceTypeCode" is computed by using "is_zero" method of the currency on the unit price.
As the decimal accuracy of the currency is set to 2 and the unit price is 0.0045, "is_zero" is returning True.

**Solution:**
Compute "PriceTypeCode" from the line subtotal instead of the unit price.
This is not perfect as it can also be lower than 0.01, but it's less probable.

opw-4608671

Forward-Port-Of: odoo/enterprise#83401
Forward-Port-Of: odoo/enterprise#82019

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

Currently, when settling customer's account using the mexican localization, the session crashes after selecting the payment method.

Steps to reproduce:
-------------------
* Install the mexican localization and switch to one of the company
* Create a new contact of type "Company"
* Create an invoice for that contact so that he has a due amount set
* Open session
* Select the customer and settle due amount
* Select any payment method
> Observation: Blank screen

Why the fix:
------------
Same issue addressed here but at a different place: https://github.com/odoo/enterprise/commit/e1e1abdd23cead2bcd7b8170da28161c3f5b2e15

Cause by the fact that when a customer of type "company" is selected we automatically invoice orders.
https://github.com/odoo/odoo/commit/270779c8250272920d759fbe7b6cfc889e2f5969

Instead of going in the same direction of the first fix, we never set `to_invoice` to true when we are settling customer accounts. It's pointless to set invoice to true when settling accounts as it's impossible to create an invoice without any product. This should also benefit localizations that invoice by default every order by bypassing the invoice in that case.

opw-4685842

Forward-Port-Of: odoo/enterprise#83067
Forward-Port-Of: odoo/enterprise#82785

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