Before this commit, when accessing a shared chatter from a portal user that has edit access, chatter messages could not be loaded when a partner added at least one emoji reaction on a message.

Steps to reproduce:
- Share a project with Joel Willis with edit access
- Create a task with Joel Willis on this project
- Post a message as Joel Willis on the new task
- Let Mitchell Admin add a reaction on the new message

=> Joel Willis cannot load messages:

```
An error occurred while fetching messages.
```

This happens because the custom mail message formatter of portal chatter messages was crafting the reaction data of the messages to return. When providing people that have reacted to the message, Access to reacted partners was denied due to ACL.

This commit fixes the issue by sudo() the partners of message reaction to retrieve their data to the portal user. This is ok because the portal has access to the message, therefore access to the reaction and related data are fine. Note that data of partner that have reacted is very limited: only the name is returned.

opw-4454427

When we implemented shared accounts, a design decision was that all the branches of a root company should have the same code for an account. However, updating the code for a company doesn't update it for the other companies with the same root.

#### Steps to reproduce:
- Create a company and a branch.
- With both companies active, try to modify the code of an account.
- Notice the ValidationError that pops up.

#### Analysis:
When writing on `code`, `_inverse_code` writes on `code_store`, which is a dependency of `code`. However, because `code` is protected at that point, it isn't invalidated + recomputed for the other companies. As a result, the old, incorrect value persists in cache.

#### Solution:
I don't think there is a nice neat solution to this. Ideally, we would like to remove the cache values for all the companies other than the active company. However, there isn't a cache function for doing that on context-dependent fields. We try to simulate that by first invalidating, then eagerly recomputing the code again just for the active company.

task-none

## General Issue:

Cross-dock rules cannot function as the main rule without disrupting unrelated flows (e.g., regular purchases). They also fail as exceptions, as they are not triggered in such cases.

## Cause:

Push and pull rules have been refactored in saas-17.2 (see commit 11e69870db1c49d9a6af79ffd263e4e162b34b6b). Previously, most flows relied solely on pull rules, generating the entire picking chain at inventory need confirmation. With the refactoring, push rules are now prioritized, generating pickings step-by-step upon validation. While this increases route flexibility, it introduces issues for flows expected to be entirely triggered by sales order (SO) validations, such as cross-docking.

In version 18.0, cross-dock rules were refactored to rely only on push rules (see commit af5479dfdbed0959c02bd862c8184fe141b51788), but this created significant issues.

### Steps to Reproduce:

- In the settings, Enable multi-step routes.
- Configure the warehouse for 2-step receipt and delivery
> automatically unarchives the cross-dock route and updates its rules:
    - Push rule: Input → Output
    - Buy rule: → Partner/Customer

#### Scenario 1: Cross-dock set on the product

#### Issue: Cannot receipt in 2 steps → cross dock can not be the rule.

- Create an inventory-tracked product with the buy and cross-dock routes.
- Create and confirm a purchase order for 1 unit of the product.
- Validate the receipt from Vendor → Input.

Result: 

Instead of generating a picking Input → Stock, the cross-dock push rule triggers, generating a picking Input → Output.

### Cause:

Rules are prioritized by product-specific rules, followed by warehouse rules:
https://github.com/odoo/odoo/blob/e3d54695862f73d9be6c35121def57ed641a1a45/addons/stock/models/stock_rule.py#L535-L539 The cross-dock push rule therefore overrides regular 2-step receipt rules, even though cross-dock routes only make sense for flows initiated by an SO.

#### Scenario 2: Cross-dock not set on the product

#### Issue: Cannot trigger cross-docking by any means → cross dock can not be the exception.

- Create an inventory-tracked product with only the buy route.
- Create an SO for 1 unit of the product and set the cross-dock route on the Sales Order Line (SOL). Confirm the SO.
> A purchase order (PO) is created.
- Confirm the PO.
> A regular receipt is generated.
- Confirm the receipt.

Result: 

The flow proceeds as a regular 2-step delivery; the cross-dock route is not applied.

### Cause:

The SO uses the cross-dock route only for the buy rule to generate a PO. Once the PO is generated is role in this world is done. There is no way to provide a route on the PO, it will just generate a regular receipt: https://github.com/odoo/odoo/blob/e3d54695862f73d9be6c35121def57ed641a1a45/addons/purchase_stock/models/purchase_order_line.py#L343-L350 Once it is confirmed, the flow defaults to regular 2-step delivery rules, as the cross-dock route is neither a default nor set on the product.

### Fix:

We add the possibility of transmitting the route_id from the pol. As such, we make it possible to use the crossdock route by setting it on the sol, to generate a PO that will pursue with the crossdock route. Furthermore, we discourage to use the crossdock route on products/product categories by setting the default setable values to False.

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

### Description of the issue/feature this PR addresses:

If the customer sets their last fiscal day and month to February 29th, a ValueError may be raised when creating a placeholder name for account.move records if their dates are not in a leap year.

More precisely, a ValueError is thrown when creating the starting sequence of the placeholder name, as a new date object is created using the company's last fiscal day and month and the year of the account.move.

This commit adjusts the day of the created date to February 28th if the last fiscal day and month is set to February 29th and if the account.move year is not a leap year. This date was chosen since that's 365 days after February 29th.

### Current behaviour before PR:

If the company's last fiscal day and month is set to February 29th, creating a placeholder name for account.move records whose date is not in a leap year raises a ValueError.

Steps to reproduce:
1. Set the last fiscal day to February 29th.
2. Go to Accounting > Journal Entries (account.move).
3. Trigger the computation of the placeholder name for account.move() (edit journal_id, create record, edit date field...)
4. A ValueError exception is raised.

### Desired behaviour after PR is merged:

The placeholder name for account.move records is successful and less prone to errors.

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

Steps to reproduce:
----------------------------------
   1) Create two companies and two users with employees.
   2) Create a sale order with Company A.
   3) Confirm the sale order.
   4) Remove the company_id from the project.
   5) Select the default company B and remove Company A.
   6) Add a timesheet to the task.
 
Issue:
------------------------
 - When we try to add the timesheet for company 2 an access error will appears

Cause:
------------------
 - Currently, when we remove the company from the project, the project and task become
  accessible to all companies.The sale line item reference is not removed from the task,
  so when creating the timesheet, the sale item reference is passed. The user can access
  the sale order, but the analytic distribution is not accessible, causing an access error.
  If we remove the sale item from the task, there will be no access error. However,
  doing so is not preferable, which is why we applied sudo.

Fix:
-------------------------
 - In this commit to resolved access error by adding `sudo()` to bypass record rules when retrieving `analytic_distribution` from `sale.order.line`.
  
task-4206915

When exporting a SA E-invoice file, the system needs to collect
invoice line without downpayment lines. However, when collecting tax
values, because of an error correction mechanism, the tax amount will
still include the amount of the downpayment tax line

Steps to reproduce (with SA localization installed and SA company):
- Create a SO of 1000$ with 15% tax
- Make a downpayment of 100$ with 15% tax and confirm
- Make the final invoice with downpayment deducted
- Confirm and send e-invoice for validation

Issue: The invoice is validated, but a warning is logged
```
Invoice was Accepted by ZATCA (with Warnings)
The invoice was accepted by ZATCA, but returned warnings. Please, check the response below:

BR-CO-17: VAT category tax amount (BT-117) = VAT category taxable amount (BT-116) x (VAT category rate (BT-119) / 100), rounded to two decimals.
BR-S-09: The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is Standard rated shall equal the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119).
```

As the warning states the is an issue with the tax computation.
When collecting amounts from the final invoice, we should
filter out downpayment amounts, but due to the error correction
mechanism introduced to account for manual modification of the journal
items, the filter is ignored, so we will have the filtered base amount
(1000) and the unfiltered tax amount (135 instead of 150)

A possible solution is to avoid the error correction when we know we
need to filter invoice lines

opw-4380798

Forward-Port-Of: odoo/odoo#192596
Forward-Port-Of: odoo/odoo#191867

**Steps to reproduce:**
- Configure `Analytic Accounting` via `Accounting` module's settings;
- Go to `Analytic Plans` through `Accounting / Configuration / Analytic Accounting`:
    - Select any record and change its name for a really long one;

![Capture d’écran 2025-01-02 à 15 21 40](https://github.com/user-attachments/assets/365a7089-9bb4-4215-8b7d-59ac85abc952)

- Go to `Expenses` app:
    - Select any expense in the list;
    - Open the `Analytic Distribution` widget.

___
**Issue:**
Long `Analytic Plans` names are wrapped and may lead to unreadable texts.

![Capture d’écran 2025-01-02 à 15 22 28](https://github.com/user-attachments/assets/b5ddbd88-1209-4640-a0ce-bf9396871038)

*(from the ticket - Odoo 17)*

![imagem](https://github.com/user-attachments/assets/2f3f0543-b08b-4f16-a4a0-4547369eb478)

___
**Expected:**
A smooth UI should display `Analytic Plans` as when accessed through an invoice line from `Accounting` app.

![Capture d’écran 2025-01-02 à 15 23 16](https://github.com/user-attachments/assets/ef0aa2fd-e8c5-47ba-8c39-ce4538b85380)

___
**Cause:**
The `Analytic Distribution` widget style of the invoice view inherits from the list renderer, forcing a `nowrap` style while the expense view of the same widget does not.

___
**Fix:**
Force a `nowrap` style for that specific widget.

![Capture d’écran 2025-01-02 à 15 22 55](https://github.com/user-attachments/assets/2af26b22-63e2-43fc-b636-f739a0aa094d)

___
opw-4357324

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

Forward-Port-Of: odoo/odoo#194162
Forward-Port-Of: odoo/odoo#192203