**Current behavior:**
There are several related bugs when operating in a multi-company
environment with the barcode app:

*Given:* we have three companies in the selector (A, B, C) where
company A is the first/default/primary of the three.

***Case 1: (CompanyB and CompanyC are checked, either can be focused)***
1) Scanning the barcode for CompanyC's manufacturing operation and
then, within the barcode view, scanning a product which belongs
exclusively to CompanyB will make it impossible to use the back
button (despite the product correctly not being added as a line
in the operation).

2) Repeating the setup with a different operation type (e.g.,
receipt) *will* add the product to the picking but it will not
be possible to validate/take out of draft from either the
barcode app nor from the backend.


***Case 2: (only CompanyC checked and focused)***
1) Scanning the barcode for CompanyC's manufacturing operation type
will open the barcode operation view for CompanyA's manufacture
operation. Products available to CompanyC can be added. Trying
to validate the order will cause an access error, however the MO
is still created in the backend.

2) Scanning the barcode for either CompanyB or CompanyA's
non-manufacturing operations will show an access error dialog,
but an (empty) transfer will still be created in the backend for
the respective company.

---

**Expected behavior:**
In case 1, scanning a product which is not available to the
current company should not trap the user in the barcode
operation view. It should also not add these inaccessible
products to a picking thereby making them unable to be
validated.

In case 2, we should respect the company defined on a
manufacturing operation type which corresponds to a scanned
barcode. Additionally, it should not be possible to create empty
transfers for companies which are not currently checked/active.

---

**Cause of the issue:**
Problem 1: production records (unlike pickings) cannot be
created until a product is added in the barcode view. Because of
this different flow, they are created with less context than
other operation types and there was no mechanism by which their
`company_id` could be inferred.

This caused them to use the default value as defined in the
`MrpProduction` model (`self.env.company`)- which is problematic
in the barcode app, as this field does not actually correspond
to the focused/active company.

Problem 2: when scanning a picking type from the main menu of
the barcode app, the company of the picking type was not getting
respected which would cause a new picking record to be created
even when the current user/environment did not have permission.

---

**Fix:**
1. Create production records using a default `company_id` value
informed by their `picking_type_id` rather than the environment

2. In the main_menu barcode scan route, use the current user's
allowed company ids (from their cookies) to restrict searchable
records

3. When scanning products in a barcode operation view, use the
company_id of the opened operation type to restrict the domain
of searchable records.

opw-3999622