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

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

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

### 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 a storable product FP tracked by SN with a BOM:
    - 1 Operation: - instruction: Register Production type (per product)
    - 1 x Comp (storable product in stock)
- Create and confirm an MO for one unit of FP.
- Go to the shopfoor app > open the instruction of your operation
- Type a non-existing serial number in the search bar > Create "new_sn"
> This opens a form view of the stock.lot model
- Save and close the new stock.lot
> Invalid operation: You are not allowed to create or edit a lot or serial number for the components with the operation type
> "Manufacturing". To change this, go on the operation type and tick the box "Create New Lots/Serial Numbers for
> Components"

#### Expected behavior:

The invalid operation should not be raised as the "required" option concerns only componenets and not final products.

### Cause of the issue:

Creating a stock lot will first launch a call of the `_check_create`: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/stock/models/stock_lot.py#L150-L153 However, since this check does not verifies that the product for which we create the lot is indeed related to a component of the MO it will raise the invalid operation even for final products: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/mrp/models/stock_lot.py#L11-L17

### Issue 2:

Currently, the `quickCreate` ("Create *sn_name*") option of the lot field of te "register production" dialog calls a `name_create` that will set an error message in the logs as the product_id required field can not be provided neither in the vals or the context of the `name_create`.  You then fall back on the same form dialog than the "Create and edit".  The `quickCreate` option should therefore just be disabled.

Enterprise: https://github.com/odoo/enterprise/pull/77265

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

Forward-Port-Of: odoo/odoo#200538
Forward-Port-Of: odoo/odoo#193965

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

### Steps to reproduce:

- Create a storable product FP tracked by SN with a BOM:
    - 1 Operation: - instruction: Register Production type (per product)
    - 1 x Comp (storable product in stock)
- Create and confirm an MO for one unit of FP.
- Go to the shopfoor app > open the instruction of your operation
- Type a non-existing serial number in the search bar > Create "new_sn"
> This opens a form view of the stock.lot model
- Save and close the new stock.lot
> Invalid operation: You are not allowed to create or edit a lot or serial number for the components with the operation type
> "Manufacturing". To change this, go on the operation type and tick the box "Create New Lots/Serial Numbers for
> Components"

#### Expected behavior:

The invalid operation should not be raised as the "required" option concerns only componenets and not final products.

### Cause of the issue:

Creating a stock lot will first launch a call of the `_check_create`: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/stock/models/stock_lot.py#L150-L153 However, since this check does not verifies that the product for which we create the lot is indeed related to a component of the MO it will raise the invalid operation even for final products: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/mrp/models/stock_lot.py#L11-L17

### Issue 2:

Currently, the `quickCreate` ("Create *sn_name*") option of the lot field of te "register production" dialog calls a `name_create` that will set an error message in the logs as the product_id required field can not be provided neither in the vals or the context of the `name_create`.  You then fall back on the same form dialog than the "Create and edit".  The `quickCreate` option should therefore just be disabled.

Community: https://github.com/odoo/odoo/pull/193965

opw-4452747
---

Forward-Port-Of: odoo/enterprise#80861
Forward-Port-Of: odoo/enterprise#77265

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