Versions
--------
- 17.0+

Steps
-----
1. Log in as admin;
2. have a user with access to Sales: Own Documents but not Invoicing;
3. assign them as a salesperson to a sales order;
4. create a draft invoice for the order;
5. assign admin as salesperson on the invoice;
6. log in as user;
7. create invoice for the sales order.

Issue
-----
- No existing draft warning is displayed.
- Trying to create a draft results in an access error.

Cause
-----
The wizards starts out as a `newId`. Consequently, its `sale_order_ids` field is also `newId` with the actual order id as its origin. When trying to read the `invoice_ids` of a pseudo-record, it will ignore any records you don't have access to. This is why you don't see an exisiting draft invoice warning.

Then when creating the invoice, the check is done again, but no longer as pseudo-records. Now it does get an invoice to check, and throws an error because it's assigned to a different user.

Solution
--------
Use `_origin.sudo()` to ensure access to the `state` field of the invoices.

opw-4554639

Forward-Port-Of: odoo/odoo#200722

### Steps to reproduce:
- In the settings enable "Multi-Step Routes" and "Subcontracting"
- Inventory > Configuration > Warehouse Management > Operation Types
- Unarchive "Subcontracting"
- Create a product tracked by SN with:
    - A set vendor
    - A bom of type subcontracting with your vendor set as subcontractor
- Create and confirm a PO for 3 units of your product with your vendor.
- Go to inventory > Subcontracting (operation type) > the related SBC
- Click on "Produce All" (this should pop a batch produce wizard)
#### > It does not and you have validated the MO for 0 units without backorder

### Cause of the issue:

Since Commit 5722286a36838f644bb4e95c305b65b412774d75 (saas-17.1), the `action_mass_produce` used to split a tracked MO and generate the assocated SN:
https://github.com/odoo/odoo/blob/bc5414602920ee712c45397d7992863a0b1ea161/addons/mrp/models/mrp_production.py#L2281-L2292
should be returned by the `pre_button_mark_done` to be performed: https://github.com/odoo/odoo/blob/bc5414602920ee712c45397d7992863a0b1ea161/addons/mrp/models/mrp_production.py#L2128 https://github.com/odoo/odoo/blob/bc5414602920ee712c45397d7992863a0b1ea161/addons/mrp/models/mrp_production.py#L1994-L1997
However, for subcontracted MO, the returned value of the `pre_button_mark_done` is currently always True, skipping the batch production wizard:
https://github.com/odoo/odoo/blob/bc5414602920ee712c45397d7992863a0b1ea161/addons/mrp_subcontracting/models/mrp_production.py#L105-L108

opw-4447631

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

Forward-Port-Of: odoo/odoo#199390
Forward-Port-Of: odoo/odoo#197459

### Issue:

Currently, running a procurment to fulfill a demand in COMP1 linked to a buy rule of COMP2 toaward the inter-company transit will use seller's set in COMP1 and generate a PO in COMP1 rather than COMP2.

### Steps to reproduce:

- In the settings enable Multi-steps routes
- Have two companies: COMP1 and COMP2
- Create a routes without set companies with 3 rules:
  - rule 1 (comp1): - Pull from Virtual Locations/Inter-company transit to WH1/Stock supply method: Trigger an other rule.
  - rule 2 (comp2):  - Pull from  WH2/Stock to Virtual Locations/Inter-company transit, supply method: Trigger an other rule.
  - rule 3 (comp2): - Buy from Partner/vendors to WH2/Stock using a custom operation type towards Virtual Locations/Inter-company transit.
- Create a storable product with both routes set.
- With COMP2: set a vendor on that product.
- In COMP1, your product > Reordering rules create a new rule using the COMP1 route to replenish WH1/Stock.
- With both COMP1 and COMP2 as active order once.
> The PO could not find a vendor as it looked for suppliers in COMP1 and if such a supplier was set in COMP1, the PO would be created in COMP1.

### Cause of the issue:

While the rule of COMP2 is found and used to run the procurment here: https://github.com/odoo/odoo/blob/2cd3d6a76db6bedba8bbb3233690b0cd72f87876/addons/stock/models/stock_rule.py#L484 the procurement was created and is linked to the company owning the move creating the demand (that is COMP1):
https://github.com/odoo/odoo/blob/2cd3d6a76db6bedba8bbb3233690b0cd72f87876/addons/stock/models/stock_move.py#L1494-L1498 However, the `company_id` used in the `_run_buy` notably for the data's of the PO will be the company linked to the procurement rather than the company linked to the buy rule. Since the buy rule should generate a purchase order in company it uses, this is incorrect.

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

Forward-Port-Of: odoo/odoo#199807

Steps to Reproduce:

- Create two companies: A and B.
- In Company A, create a sale order for Company B with product P1.
- Confirm the sale order and navigate to the associated picking.
- Add a new product P2 and confirm the picking.

Issue:
No sale order line is created for the newly added move in the picking.

Technical Reason:

Before v17.2, intercompany transfers used the "Partner/Customers" location (type: "customer") as the destination. The logic for creating a sale order line checked move.location_dest_id.usage != 'customer', which correctly allowed the sale order line to be created. In v17.2, intercompany transfers now use "Virtual Locations/Inter-company transit" (type: "transit") as the destination. Since 'transit' != 'customer', the condition incorrectly bypasses sale order line creation. Fix:

Modify the condition to check if the destination location is either 'customer' or 'transit'. This ensures that sale order lines are correctly generated for intercompany transfers.

Task-4455830

Forward-Port-Of: odoo/odoo#200720
Forward-Port-Of: odoo/odoo#197245

To reproduce:
- on a record of a model that inherits mail.activity.mixin, create a new Activity of a 'meeting' type
- open calendar
- create 2 meetings on the calendar
- only the second one is attached to the resource record's chatter

Problem:
When the calendar view is opened, the mail.activity record has already been created, and creating the calendar.event record writes to its calendar_event_id field with the id of the newly created calendar.event. Creating a second calendar.event record in the same view does not create a second mail.activity record, instead it overwrites the calendar_event_id field of the original mail.activity record, overwriting the original calendar.event. This also causes the first calendar.event record to no longer have any associated mail.activity record in its activity_ids field.

Solution:
In the calender.event create() method, modify the condition of whether a new mail.activity record should get created so that it makes a new mail.activity record if the linked mail.activity record already has a calender_event_id

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

Forward-Port-Of: odoo/odoo#199086
Forward-Port-Of: odoo/odoo#196719

date_category can be None, we should check before adding values to the dict.
And also return empty string instead "none" in _compute_kanban_dashboard_graph

error from upgrade mock viewer.
```
  File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 256, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 269, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 429, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 531, in mock_view_kanban
    self.mock_web_search_read(model, view, [domain], fields_list)
   File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 590, in mock_web_search_read
    data = model.search_read(domain=domain, fields=fields_list, limit=80)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6074, in search_read
    return records._read_format(fnames=fields, **read_kwargs)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4016, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6983, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1287, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1469, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5222, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 109, in determine
    return needle(*args)
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_picking.py", line 376, in _compute_kanban_dashboard_graph
    summaries[picking_type_id]['total_' + date_category] += 1
 KeyError: 'total_none'
```

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

### Issue:
- When we user-defined defaults based on company_id set on documents, they always trigger based on the user's default company instead of the current company.

### Steps to reproduce:
- In a multi-company environment say we have companies A(id: 1) and B(id: 2), and the user default company is A. (he has access to both).
- Create 2 user-defined defaults for the field : `documents.document.company_id`, setting value to 1 for company A and 2 for company B.
- Create a document using company B, the document's `company_id` will be set to company B which is wrong.

### Solution:
- in controllers `request.env.company` always returns the user's default company, so whenever we upload a document (call the `documents_upload` controller), `documents.document` create assumes that the current company is the user's default company.
- To fix this, we add the `allowed_company_ids` to the upload request params in the JS `DocumentService` and  we intercept in the python controller and set the `allowed_company_ids` context on the request to make sure create will use the current company instead.

OPW-4507424

Forward-Port-Of: odoo/enterprise#80060