There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
In `account.move` `_stock_account_prepare_anglo_saxon_in_lines_vals`,
the `partner_id` is set two times, following those PR:
- odoo/odoo#75038
- odoo/odoo#84468closesodoo/odoo#86154
X-original-commit: 3db2db30a22b0da968c1c739d53dec40a4cabed8
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Changes made in #78199 would remove the Purchase Security Lead Time from
any orderpoint as long as the 'purchase_stock' module was installed,
whether the orderpoint was related to purchase or not.
Task-2721378
closesodoo/odoo#85594
X-original-commit: 3bd9b7a77a1e0e05ea479945d5cd8085f6981feb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
The aim of this commit is to set partner on anglosaxon
aml in order to help our client in their stock
reconciliation process in case it hasn't been done automatically.
Before this commit:
anglosaxon line were created without partner
After this commit:
A partner is set when anglosaxon line are created
closesodoo/odoo#84547
Ticket: 2692308
Community-pr: https://github.com/odoo/odoo/pull/84468
X-original-commit: abfe37fcea5b20f77799d9331d4d011530880669
Signed-off-by: William André (wan) <wan@odoo.com>
Usecase to reproduce:
- Create product 1 with supplier `Vendor` and a delay of 3 days
- Create product 2 with supplier `Vendor` and a delay of 4 days
- Create two procurements with a need for stock at 01-01-2022 (warehouse
1 step)
- Run procurement for product 1
- Run procurement for product 2
The PO contains the two product but the order date is for 3 days before
and not 4. Also the line for product 2 is planned for the 02-01-2022
It happens because the delivery date is computed base on the purchase
order date and the supplier but the procurement is totaly ignore
X-original-commit: aec7fcdb693729f432ae2341c00ef317b65fbcbc
Part-of: odoo/odoo#83430
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
You are blocked with an access error when you try to replenish a product with `”Buy”` route if you don't have the settings rights,
because the code tries to read a system parameter.
Solution:
To avoid this error, we need to read it as superuser.
opw-2725702
closesodoo/odoo#82814
X-original-commit: dff238959f46708b68cda4b03f8f6981f7245ee7
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
In automated-AVCO configuration, buying a kit at a higher price than its
cost can create inconsistencies in the accounting.
To reproduce the issue:
(Need account_accountant. Use demo data)
1. Create a product category PC:
- Costing Method: AVCO
- Inventory Valuation: Automated
- Set up the Price Difference Account PDA
2. Create 3 products P_kit, P_compo01, P_compo02
- Type: Storable
- Category: PC
- P_compo01:
- Cost: 10
- P_compo02:
- Cost: 20
3. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components:
- 1 x P_compo01
- 1 x P_compo02
4. On P_kit's form, "Compute Price from BoM":
- The cost should be $30
5. Create a purchase order PO with one line:
- Product: P_kit
- Quantity: 1
- Unit Price: 100
6. Confirm PO and process the receipt
7. Create and Post the bill
Error: There is an error in the journal items of the bill: the value for
PDA is $85
When posting the bill, for each account move line, the module computes
the stock valuation of the associated product and the price difference.
To do so, it sums the valuation of all related outgoing stock moves and
divides by the quantity to get the value per unit, then it compares with
the unit price used on the PO's line. Here is the issue: in case of a
kit, there is one outgoing move per component while the PO's line is
linked to the kit itself.
Therefore, in the above case, it uses the outgoing moves of P_compo01
and P_compo02, adds up their value ($10 + $20 = $30) and then divides by
the total quantity (one P_compo01 and one P_compo02, thus $30 / 2 =
$15). This is the reason why it considers that the unit value of P_kit
equals $15. Then, since the unit price on the PO's line is $100, it gets
a price difference value equal to $85.
When comparing the unit value of the kit and its unit price, the unit
value should not be divided by the quantity of components ($30 should
not be divided by 2). Moreover, when buying such a kit at $100, the
surplus ($70) should be distributed among each component. However, it is
difficult to define a rule to correctly weight this distribution.
Therefore, this surplus will be considered as a price difference.
OPW-2566546
closesodoo/odoo#82463
X-original-commit: 20888055d4271bf3cf9e7bc3d42150a1f72e4495
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
The constrains on orderpoint location being related to the warehouse view
location was too restrictive especially in a complex subcontracting flow
with dropship.
This commit change the constrains to only be triggered if the two
location to be compared have both a warehouse.
closesodoo/odoo#79593
X-original-commit: 871cd6ad2d986ee1c28804aeeee63a001156154a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Remove the Purchase Security Lead Time from the computing of the
purchase order's picking deadline to better reflect that the shipment is
actually meant to arrive earlier than date + security lead time.
Also makes sure that receipts and subsequent pickings (multi-step
reception) are planned the earliest possible, not taking the purchase
security lead time into account.
Task-2656397
Part-of: odoo/odoo#79523
Expected behavior : The log note sent when received quantity is updated should take into account the quantity already received.
Current behavior : The log note sent doesn't take into account the quantity already received for a 'stock_moves'. So it always displays `Received Quantity: 0.0 -> quantity in stock` instead of `Received Quantity: quantity already received -> quantity in stock`
Steps to reproduce the error :
- Create a RFQ with few units of a Storable Product (e.g. 5 units)
- Partially validate the receipt and create a backorder (e.g. 3 units)
- Validate the backorder (e.g. 2 units)
Log notes should be :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 3.0 -> 5.0`
But are :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 0.0 -> 5.0`
The value is always equal to 0.0 because `qty_received_method == 'stock_moves'` so `line.qty_received` is overridden by 0.0 in parent `_compute_qty_received` even though its value is already set to 0.0 (default) or to the quantity already received
opw-2600221
opw-2613116
closesodoo/odoo#78858
X-original-commit: 0c8ea86fb8d706af139cd2d412d01487e5899df6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Allow the quantity decrease of Sale Order line of a MTO product.
When increasing de quantities, the related pickings, RFQ / PO are
increased as well, but it wasn't the case if decreasing the quantity.
It should allow the cascade of the decrease in the related pickings as
it would work for the increase. Also modifies a related Purchase Order
if it wasn't yet validated (and thus still a RFQ).
merge_moves was modified so it would allow the merge of negative moves
with positive ones, while trying to "deplete" as much quantity as
possible for each mergeable move.
But negative moves don't always have all required properties to be
compared to the positive ones (some keys might be missing, such as
'created_production_id'). That means we will merge strictly the positive
moves at first as it was done before. But then we try to merge them "less
strictly", using less keys to compare.
Let's say we have those moves (and all other relevant keys matches) :
- move_1 : {qty : 5, created_production_id: 1}
- move_2 : {qty : 3, created_production_id: 2}
- move_3 : {qty : -6, created_production_id: False}
move_1 and move_2 cannot be merged as they don't share the same
created_production_id. But to merge move_3, we'll need to merge it into
move_1 and move_2. It will then deplete move_1 and decrease move_2.
Which will leave us with :
- move_1 : {qty : 0, created_production_id: 1}
- move_2 : {qty : 2, created_production_id: 2}
move_3 will be unliked as its purpose is done.
Task-2513592
Part-of: odoo/odoo#78070
Steps to reproduce the bug:
- Create a BOM kit for “product K” with:
- 2 * “product A”
- 1 * “product B”
- Create a PO for 1 unit of “product K” > confirm
- A receipt delivery with 2 units of “product A” and 1 unit of B will be created
- Modify the ordered Qty to 2 units of “Product K”
Problem:
The receipt delivery will not be updated correctly (4 units of product A and 3 of product B)
because the `"_prepare_stock_moves"` function computed the previous quantity wrong based on the moves quantities
since the moves are for products A and B, not product F.(do not take into account the products in kit)
Solution:
For kit products, do not calculate from the `"stock.move"`, calculate the difference between the quantity before and after the change
opw-2645719
closesodoo/odoo#77838
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Instead of using sort + groupby of itertools (which group only
consecutive), use only the groupby of odoo.tools which
decrease the complexity of the code and avoid unmatched keys
between sort keys and groupby keys
task-2648449
Part-of: odoo/odoo#76761
The combination of a RR and a supplier that has a minimum quantity and a
lead time leads to incorrect results
To reproduce the issue:
1. Create a product P:
- Type: Storable
2. Add a reordering rule for P (min: 10, max: 50)
3. Add a vendor to P
- Quantity: 1
- Price: 1
- Delivery Lead Time: 7
4. Run the scheduler
5. Open the generated PO
Error: The order deadline is <today minus 7 days> instead of today. The
receipt date is today instead of <today plus 7 days>
When computing the quantity to order, the method needs the value of
`qty_forecast` (L254 in [1]) The computation of `qty_forecast` leads to
the computation of `lead_days_date`. To do so, it gets the lead days of
the associated stock rule `_get_lead_days`. In this method, a seller is
selected: [2] However, none of the parameter is defined: [3]
In the above case, the seller has a minimum quantity of 1. Therefore,
since this information is not given in [2], the vendor is not selected
and his lead time is therefore not taken into account. So,
`lead_days_date` will be equal to 0 and won't be recomputed. As a
result, the planned delivery date is today. Then, the quantity to order
is computed (L260 in [1]), so later, the module is able to select the
correct seller. However, this one has a lead time of 7 days -> the
generated PO will have the planned date to today and the order deadline
to <today minus 7 days>
Once an orderpoint has its quantity to order defined, its lead time
should be recomputed because it may be different depending to the
selected seller (and thus we should take this quantity into account when
searching for a seller)
[1]
https://github.com/odoo/odoo/blob/59ac8d891de6e20604494d6cfc6fc357a88d226c/addons/stock/models/stock_orderpoint.py#L254-L260
[2]
https://github.com/odoo/odoo/blob/1b03087524080f1a9751b1561cd8891466e72367/addons/purchase_stock/models/stock_rule.py#L153
[3]
https://github.com/odoo/odoo/blob/045c6ad3353bb0849d3f93d3488d8dcd8b8975b0/addons/product/models/product.py#L602
OPW-2614798
closesodoo/odoo#77110
X-original-commit: f2eb1dca99d16d70613c2f724d4b73f273a49ae7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
The check added in 643e093a4bc9d46973705831697036b56a89b143 was too
strict in case a purchase order was created from an orderpoint
triggering multiple rules. The orderpoint's location could be below
another warehouse that the first rule's location and thus raising the
error.
closesodoo/odoo#77079
X-original-commit: df1f90673fc06f3d535833229d8af3ef6a51dd61
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Because the "Replenishment" can unlink a lot (thousand of
`stock.warehouse.orderpoint`).
and psql needs to check every Many2one `orderpoint_id` constraint
and without index it takes too much time.
opw-2637321
closesodoo/odoo#76116
X-original-commit: 864d90a064f093bd6ba24d8464ee491a443a320e
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Rounding in purchase order is 'UP' which is causing issue when doing
receipt in a different uom than the purchase. Rounding should be
'HALF-UP'
Added test in purchase and sales to ensure this issue is detected in the
future.
closesodoo/odoo#76006
X-original-commit: 9d3d1949d20834c92449c989299ac8e67f26d05d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Divide "Delivery"/"Incoming Shipment" smart button of "Sale"/"Purchase"
order form between normal "Delivery"/"Incoming Shipment" and a
"dropship" picking.
Also clean a little bit technically
task-2486811
Part-of: odoo/odoo#75041
Add a new module to add smart buttons between a subcontracting purchase
order and the ressuply component delivery.
task-2486811
Part-of: odoo/odoo#75041
This allows to solve the following use case:
* we are in March
* a SO created during January shows currently a delivered quantity (timesheet on service or delivered goods on storable products): timesheets/pickings were done in February
* creating the accrued entry for January 31 should display accordingly an amount of 0 by default since everything was done in February
Invoices invoice_dates are also taken into account:
* day 0 : delivered 10
* day 2 : 5 invoiced
* accrued entries for 10 if accrual date = day 1, accrued entries for 5 if accrual date = day 3,
followup of task 2255642
closesodoo/odoo#75886
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Commit 643e093a4bc9d46973705831697036b56a89b143 adds a security on
orderpoints triggering purchase orders. But this new check fails in case
the picking type on the purchase order is not linked to a warehouse (e.g
in a subcontracting flow).
This commit ensure the check is done only if we have a warehouse linked
to the purchase order.
closesodoo/odoo#75619
Opw: 2631979
X-original-commit: 8343ce44d72c77f56937e1694606dc718497fbb8
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps to reproduce the bug:
- create 2 warehouses A & B
- create a new product and add a seller
- Create an Automated replenishment order of the created product for warehouse A
- click on “Automate orders”
- open PO
- in “other information” tab > change the picking type to the “warehouse B” picking type
- confirm order
- click on the receipt
Problem:
The destination location is “Warehouse A” instead of “Warehouse B”
The problem also appears after the duplication.
Solution:
Use the parent_path to check if the location that the user wants to use is below the original warehouse.
opw-2588082
closesodoo/odoo#75501
X-original-commit: bed546486aa667d735df015de8153d42a9af9a41
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Co-authored-by: fmdl <florent.mirieu@gmail.com>
Steps to reproduce the bug:
- Create a storable product, e.g:”Product A”, with a AVCO + Automated category
- Make sure to assign an account in the price difference account field
- Create an RFQ with the “Product A”
- Confirm RFQ and receive the product
- Create the vendor bill and edit to change the unit cost from 55 to 56
- Post the bill
- Check journal items
Problem:
Price difference accounts have no partner_id
opw-2616388
closesodoo/odoo#75085
X-original-commit: 75b45e736bde32e264e7e660b4626142d8f05df2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
And convert the `t-esc` in the template to `t-out` while at it.
So this was a bit of a bummer initially, the PopoverWidgetField gets a
pile of JSON as its value (so from the server), and that pile contains
a template name (optionally) and... the template context,
basically. For leadDaysPopOver the issue was some of that context is
supposed to be rendered HTML to straight inject into the template,
marking that as HTML-safe would be a bit of an issue (having the JSON
specify which parts of the value it returns are HTML-safe being a bit
of a conflict of interest).
However turns out the thing is way over-complicated and
over-engineered: `lead_days_description` necessarily has a very
regular structure owing to being injected as a set of table rows, so
the various overrides to `_get_lead_days` just make their own lives
complicated by formatting the values they want to return into table
rows matching the format of an unrelated template.
Instead we can change the signature of `_get_lead_days` so the
"description" is a list of values to inject in the table (list of
pairs, each pair matching the corresponding columns of the table). The
template can then take care of formatting those values into table rows
the usual way, removing the need for any injection of raw content.
This also makes for better / clearer translation strings.
Before this commit, two POs are merged if their scheduled date is set on
the same day. To relax a little bit this constrain, this commit adds a
system parameter to extend the delta days between two scheduled dates of
POs to be merged.
closesodoo/odoo#73068
Opw: 2557125
X-original-commit: 883112c8db1d3c5cc87715e6b2028e84d09512de
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Infobox to help the user with the replenishment. Allow those actions:
- See the different supplier with their lead time, price and quantity
- Be able to select a supplier and set it on the orderpoint
⁻ See the last delivery by mmonth for the product
- Last purchase date for each supplier
Technicaly it use a wizard and a fields char with JSON used by
a widget to display a static template. Also it creates directly
the wizard in backend instead of just let the view manage the new
object since we need a button on a one2many and if the records do
not have an id, it's not possilbe to use it.
closesodoo/odoo#72039
Task: 2519761
Related: odoo/upgrade#2596
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Resupplying a product with a purchase order ask to choose the suitable
supplier to put on the purchase order. Another search is perform on top
of that to compute de date to order in order to respect the lead days
promise by the supplier. The issue is that the first search is done with
the orderpoint company into account but not the second one.
This commit passes the company to _select_seller when computing the total
lead days required for an order.
opw : 2557125
closesodoo/odoo#72466
X-original-commit: c1bd985ef6a77c8848c4a2a8b92508511d9d8638
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Improve res.patner._compute_on_time_rate performances by calling
mapped('quantity_done') once on all the order_lines.move_ids.
Moving it out of the for loop allows to befinit from the performance
gains of the read_group call in stock.move._quantity_done_compute.
closesodoo/odoo#72422
X-original-commit: 2841525a3a2f1273783874947884b57494def849
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
When purchase order line is removed, related stock moves procure method stays as "Advanced" which doesn't allow reservation from stock
closesodoo/odoo#70708
X-original-commit: 17d0d1bc6294578e035e29a550a7e90ae7ef2f5f
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
1. add packaging to PO lines
2. packaging on PO/SO lines can be propagate to MO
3. add package type to packaging
4. on picking types, we can choose to only reserve full packaging. That
means if you want 1 pallet(100 units) and you have 50 units in stock. It
won't be reserved.
5. suggest suitable packaging for PO/SO/MO line according to the product
qty
Task-2357259
PR #68654
UPG PR odoo/upgrade#2444
When changing the product price precision, this can lead to incorrect
stock valuations.
To reproduce the error:
(Enable debug mode)
1. Go to Settings > Technical > Database Strucutre > Decimal Accuracy
2. Edit Product Price:
- Digits: 4
3. Create a Product Category PC:
- Costing Method: FIFO
4. Create a Product P:
- Product Type: Storable Product
- Product Category: PC
5. Create a RfQ with product P:
- Quantity: 1000
- Unit Price: 0.035
6. Confirm Order, Receive Products, Validate
7. Click on Valuation
Error: The total value is equal to $40 instead of $35. The calculation
was done after rounding the unit price: $0.035 becomes $0.04, then
1000*0.04=$40.
When confirming the RfQ, a stock move is created. To do so, the method
`_get_stock_move_price_unit` is called. When validating the delivery, it
recomputes the unit price thanks to method `_get_price_unit`. In both
situation, and if the line has taxes, the method `compute_all` is called
like this:
```python
price_unit = line.taxes_id.with_context(round=False).compute_all(price_unit,
currency=line.order_id.currency_id, quantity=1.0)['total_void']
```
But here is the problem. In this method, total amount is computed with
this line:
```python
base = currency.round(price_unit * quantity)
```
However, `quantity` is equal to 1 and the multiplication is rounded
using the currency precision. As a result, `base` is equal to $0.04.
Then, all computations will use this value and will be incorrect.
This fix applies the real quantity so `base` will have the correct
value:
```
base = currency.round(price_unit * quantity)
= currency.round(0.035 * 1000)
= 35
```
OPW-2472192
closesodoo/odoo#70269
X-original-commit: 77b7a23c3c759b33e26bf91faf14a10f02449a91
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
To avoid multiple search of the get_warehouse for the same location
and extra SQL request (it happens a lot for complicate flow, e.g.
mrp_mps, replenishment report).
Translate it into a standard compute to use the cache of
the ORM for no-store compute field (`warehouse_id`) and put
some depends to be always correct (even if `warehouse_id` shouldn't
change in the same request).
task-2439019
This reverts commit 170729ee58b199041d7545e7789ac9474e86f998, per
discussion with @thomasdeleval on linked ticket.
opw-2422438
closesodoo/odoo#68293
X-original-commit: 5c2db20a14701f165adfecb391073c3d957081e9
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
To reproduce:
1. set WH receipt in 3 steps
2. create a "receipt in 2 steps" route for product
3. create a PO with product "receipt in 2 steps"
In inventory, we will see this product still follow the "receipt in 3
steps" route.
This is caused when we create move for PO, we prepare the route_ids
according to warehouse's route_ids. After the move has it's own
route_ids, it will not search for route set on product or product
category (which should has higher priority over warehouse route).
To fix it, we remove the route_ids when create the move for PO. A route
will be found when the move being comfirmed.
Task 2448439
PR #65509
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- User in company A,
- Purchase order in company A,
- Product in company B
```
File "/home/odoo/src/odoo/14.0/addons/purchase_stock/models/res_partner.py", line 23, in _compute_on_time_rate
]).filtered(lambda l: l.product_id.product_tmpl_id.type != 'service' and l.order_id.state in ['done', 'purchase'])
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5279, in filtered
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5279, in <listcomp>
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/odoo/14.0/addons/purchase_stock/models/res_partner.py", line 23, in <lambda>
]).filtered(lambda l: l.product_id.product_tmpl_id.type != 'service' and l.order_id.state in ['done', 'purchase'])
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 2483, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 998, in __get__
record._fetch_field(self)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3072, in _fetch_field
self._read(fnames)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3183, in _read
raise self.env['ir.rule']._make_access_error('read', forbidden)
odoo.exceptions.AccessError: Due to security restrictions, you are not allowed to access 'Product' (product.product) records.
```
If you do not share products between companies
(if the multi-company record rule for `product.template` is enabled)
then you are not supposed to use a product from another company in a purchase order.
However, this is possible to land in the case if you enable
the multi-company record rule after you created some purchase orders,
using products from other companies.
Adding `sudo()` just to get the type of product
doesn't cost much to support that case
upg-8277
closesodoo/odoo#66956
X-original-commit: a08ba4be6518dd99ce93a803724165f62cbef032
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Because of the weird behavior of the ORM regarding
related field pointing to computed fields,
`on_time_rate` was taking account of all companies
when asking it through `purchase.order.on_time_rate`
but it was single-company when asked through `res.partner.on_time_rate`.
It was observed during an upgrade request issue analysis,
and in that case the problem was not even the fact
it was miscomputed, but the fact this computed field,
computed as sudo, leaded to fill the cache for
`purchase.order.line.move_ids` with `stock.move` belonging
to other companies than the user one,
and then when attempting to read values from these stock moves
a multi-company access error was raised.
upg-8106
closesodoo/odoo#66882
X-original-commit: 1b729171c5deac4fadebcff013aa061a96860b09
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Gorash