**Current behavior:**
When a user opens a POS with any special product - such as a tip product - assigned to a different company, no products are displayed in the POS interface.

**Expected behavior:**
The user should receive an error message indicating that the assigned special product is reserved for another company. If the default special product is associated with a different company, products should still be listed in the POS.

**Steps to reproduce:**
1. Create a POS for a company C<sub>**1**</sub>.
2. Create a Tip product, reserved for company C<sub>**2**</sub>.
3. Set the Tip product for the POS of company C<sub>**1**</sub>.
4. Open the POS for company C<sub>**1**</sub>.
5. No products are listed in the POS.

**Cause of the issue:**
The `get_special_products()` method returns the default tip product without verifying the company assignment, leading to incorrect behavior. Additional inheriting models add more products to this method, still without checking the company assignment.

**Fix:**
- Modified the `_get_limited_products_loading` function to filter the special products according to the session company.
- Modified the `_get_default_tip_product` function to bypass the company check if the default tip product is assigned to a different company.

opw-4396020

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

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