Steps to reproduce:
1. Have 2 companies, and select the one w/ the highest ID
2. Create a new product tracked by lot + expiration date
3. Receive product
4. Set the received lot's expiration and alert dates in the past
5. Inventory > Operations > Run scheduler

Before this commit:
An activity is created on the lot for OdooBot,
despite the product's responsible set to the current user.
It happens because the default value for `responsible_id` is the current
user, but the value is only set for the current company. When the
scheduler runs, it doesn't set the company; therefore, it takes the
product's responsible user for the company with the lowest ID, which is
not set.

After this commit:
The activity is created for the product's responsible user using
the lot's company.

opw-3489340

closes odoo/odoo#135361

Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>

To Reporduce
=============
- Install inventory, purchase and product_expiry
- Create a new storable product that is tracked by lots or serial numbers and expiration date and set expiration days to a value
- Go to inventory > configuration > Warehouse Management > Operations Types
- In “San Francisco: Receipts” > Enable "Create New Lots/Serial Numbers"
- Create a new RFQ > select the created product > Confirm the order
- Click on “Receipt”
- Click on the icon with 3 bars (last thing on line) to open Detailed Operations view
- add a line and set a `lot/serial Number`
- from the same view open the `lot/serial number` wizard and edit the expiration the date
- save/confirm

Problem
=======
The expiration date on Detailed Operations doesn't change

Solution
=========
to solve the issue a condition in compute method was corrected

opw-2937438

closes odoo/odoo#97898

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

On a receipt, when defining the expiration date of a lot, the SML keeps
<today> as expiration date

To reproduce the issue:
1. Edit the operation type "Receipts":
    - Show Detailed Operations: True
    - Use Existing Lots/Serial Numbers: True
2. Create a product P:
    - Type: Storable
    - Tracking: By Lots
    - Expiration Date: Enabled
3. Create a planned receipt R with 1 x P
4. Mark R as Todo
5. Add a detailed operations:
    - 1 x P with new lot L
6. Edit the lot:
    - Expiration Date: <today + 7days>

Error: When saving the picking (with the lot updated), the expiration
date is incorrect (set to <today>).

OPW-2785256

closes odoo/odoo#87699

Signed-off-by: Steve Van Essche <svs@odoo.com>

Steps to reproduce:

- Install stock, stock_barcode, product_expiry
- Create a product tracked by lots or unique SN
- Activate expiration date on the product
- Create a lot for the product
- Set an old expiration date for the lot so it expires
- Go Barcode/Operations
- Choose whatever operation, for ex: Delivery
- Add the product you created
- Set the qty and choose the expired lot you created

Current behavior before PR:

- JS traceback as the view confirm_expiry_view is undefined

Traceback:
TypeError: Cannot read properties of undefined (reading 'slice')
at Class._loadViews (https://runbot.odoo.com/web/content/30387-19ad92a/web.assets_backend.js:460:228)
at Class._executeWindowAction [as _super] (https://runbot.odoo.com/web/content/30387-19ad92a/web.assets_backend.js:453:435)
at Class._executeWindowAction (https://runbot.odoo.com/web/content/140-9ec14c8/web_studio.assets.js:6:20)
at Class._executeWindowAction (https://runbot.odoo.com/web/content/30181-63e2b20/web.assets_common.js:4648:371)
at Class._handleAction (https://runbot.odoo.com/web/content/30387-19ad92a/web.assets_backend.js:459:109)
at Class.<anonymous> (https://runbot.odoo.com/web/content/30181-63e2b20/web.assets_common.js:4648:371)
at Class._handleAction (https://runbot.odoo.com/web/content/30387-19ad92a/web.assets_backend.js:479:20)
at Class.<anonymous> (https://runbot.odoo.com/web/content/30181-63e2b20/web.assets_common.js:4648:371)
at Class._handleAction (https://runbot.odoo.com/web/content/30387-19ad92a/web.assets_backend.js:7157:20)
at Class._handleAction (https://runbot.odoo.com/web/content/30181-63e2b20/web.assets_common.js:4648:371

)

Desired behavior after PR is merged:

- Open the confirmation view confirm_expiry_view which warns the customer that one of the lots is expired.

opw-2659939
opw-2729865
opw-2712550

closes odoo/odoo#83053

closes odoo/odoo#83075

Signed-off-by: Arnold Moyaux <arm@odoo.com>

Steps to reproduce the bug:
- Install product_expiry and inventory
- Go to inventory settings and enable “Expiration date”
- Create a product with tracking by lots and an expiration date
- Set on the product category: Force Removal Strategy = FEFO
- Create a PO for the product > Receive product and set expiration date to “30/10” for LOT1
- Create another PO for LOT 2 with an expiration date set to “29/10”
- Create a sales order for this product > Go to delivery

Problem:
Lot1 will be chosen on the delivery linked to the SO while lot2 must be selected
because it has an expiration date before the lot 1

The lot is chosen based on the date defined in the removal_date field,
so this field should always be calculated when an expiration date is defined

Solution:
Set the fields ("use_date", "removal_date", "alert_date") when an expiration date is defined

opw-2613711

closes odoo/odoo#77261

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

This commit adresses to two issues:

Since 0c83542a93dde8dcaead04fadb7db95cf627a8b4, the move line's `expiration_date`
set by the user is always overrided at the creation of the move which
means the user has to modify it after the move was created.

To fix that, the compute doesn't override the `expiration_date` if there
is already one set.
Therefore, the onchange on the product who was removed is re-added to
force to recompute the `expiration_date` if the move line's product is
changed and it has already an `expiration_date` set.

closes odoo/odoo#76847

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

How to reproduce:
  - Create a product tracked by lot;
  - Create two receipts for this product;
  - Use the same lot name in the two receipts;
  - Try to validate the two receipts in the same time
    => `ValidationError` will trigger in the `_check_unique_lot`
        constrain of the production lot.

task-2646107

Part-of: odoo/odoo#76847

Steps to reproduce the bug:
- Install inventory, purchase and product_expiry
- Create a new storable product that is tracked by lots or serial numbers and expiration date
- Go to inventory > configuration > Warehouse Management > Operations Types
- In “San Francisco: Receipts” > Enable "Create New Lots/Serial Numbers", “Pre-fill Detailed Operations”, and "Show Detailed Operations"
- Create a new RFQ > select the created product > Confirm the order
- Click on “Receipt”

Problem:
In the created “stock_move_line” the expiration date field is not set

Solution:
When we add a new "stock_move_line" and choose a product, an onchange is triggered in order to set
the expiration_date field even if we do not choose a "lot /serial number name".
So we can replace the onchange with a compute function to do the same thing in the creation.

opw-2634583

closes odoo/odoo#75806

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

This commit adds the option to have lot/serial number expiration
dates be included in a delivery report (via settings). This is only
applicable for stock.picking where 'State=Done', when 1 or more
lot/serial numbers are used, and 1 or more lot/serial number expiration
dates exist.

This completes subsection 4 of overall Improve delivery slip task.

Task: 2039720

1) removal_date in inventory report should be readonly if
product tracking is none or use_expiration_date of product
is false.

2) removal_date should be editable in inventory mode.

Fixes-2273732

closes odoo/odoo#52827

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

Before this commit, when the user tries to create a new quant, even if
the product doesn't use an expiration date, he/she will not be able to
create the quant.
The issue was as `removal_date` field is added by `product_expiry` in
the quant list view, the field is on the values used to create a new
quant but not in the list of accepted field for quant creation.
So, it raises an UserError.

task-2260085

closes odoo/odoo#51482

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

=======
PURPOSE
=======

Improve duplicated serial number message to show more information.

=======
SPEC
=======

In this commit, we show full information about all invalide product name
and lot/sn number when the user enters duplicated ones.

- Change the sql constraint for checking duplicate sn/lot to python
constraint to support customised error message.
- Create lot in batch to show all invalide ones in error message.

=======
LINKS
=======

task 2083605
pr #44366

Related: odoo/upgrade#954
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

- move all the constrains at the same place, make sure they are private
- move all the onchanges at the same place, make sure they are private
- move `_get_similar_move_lines` helper at the bottom of the file with
  the other helpers

Before this commit, the default `expiration_date` wasn't set when the
move line was created with the help of multiple assign serial numbers
button or when user wrote/copy-pasted a list of SN/LN.

task-2166230

closes odoo/odoo#42809

X-original-commit: ff6126e8077031fb20eada5f3f9d8fd8a4a4c56a
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

Before this commit, in the move line view, the  field `expiration_date`
was readonly even when it must be editable. It was because the condition
who defines if the field is readonly or not was wrong.
Also, removed the field `expiration_date_readonly` as it mainly referred
to `picking_type_use_existing_lots`, and use this latter instead.

task-2166230

X-original-commit: f1b8426919dc049df447d50ed3ac365eec2897c3

Purpose of the task is be able to cancel an order if the products have
been delivered or if an invoice has already been confirmed

-the remaining pickings (back orders) should be cancelled.
-the draft invoices should be cancelled too.

[IMP] product_expiry: compute method should iterate on self

task-1919761
Closes #29920

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Co-authored-by: Hiral Bhavsar <hbh@odoo.com>

How to reproduce:
    - Create a tracked product using expiration dates and don't set the
      `expiration_time` field;
    - Create a receipt for this product (using "Create New Lots/Serial
      Numbers") and confirm it;
    - Create a move line for this product and define an expiration date;
    - Valid the picking -> Traceback.

The issue was as `expiration_time` isn't set on product, the production
lot created on the receipt's validation don't have an `expiration_date`.
So, if the `expiration_date` is set on the receipt move line, the
production lot will try to get a time delta with its unset
`expiration_date`, causing the traceback.

task-2119330

closes odoo/odoo#39795

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

When user goes on product's quants, hides the "Removal Date" field if
the product doesn't use expiration dates.
Also, set it as optional to be hide if the user wants.

closes odoo/odoo#39425

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

The production lot expiry alert was based on the field `alert_date`.
Now, it will be based on the field `life_date` since if user set only
one field, there is more chance this field will be filled but the field
`alert_date` will not.

Task #1938656

When user tries to validate a picking with expired production lot,
displays a wizard for the confirmation popup. This wizard shows which
lots are expired.

Task #1938656

User can now define the lot's field `expiration_date` when he/she
receipts a tracked product using the expiration dates.

Task #1938656

Computes production_lot date fields when the user manually changes the
`life_date` field.

Task #1938656

Changes the label and tooltip of expiration date related fields.

Task #1938656

Adds new product field, `use_expiration_date`, to know if user wants to
use expiration date on product. Only accessible when product is tracked.

Also, changes fields' name:
    - product.template:     life_time becomes expiration_time
    - stock.production.lot: life_date becomes expiration_date

Task #1938656

This branch is the combination of several optimizations in the ORM:

* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;

* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;

* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);

* make method `modified` take advantage of inverse fields to inverse
dependencies;

* filter records by evaluating a domain on records in Python;

* a computed field with `readonly=False` behaves like a normal field
with an onchange method;

* computed fields are computed in superuser mode by default.

Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.

closes odoo/odoo#35659

Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>

This commit improves the performance of product expiry activities generation.
It also removes direct refs to activity types to ensure code stability in case of user deletion of system data.
The xml refs to activity types should only be used through mail methods to ensure fallback strategies can be managed in the mail module only.

closes odoo/odoo#33300

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

- when responsible field is empty on the product then next activity should be assigned to the system admin.

Task ID : 1891230

This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.

All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.

Courtesy of e2f translators

- Create a product tracked by lot with some date values != 0
- Create a MO for this product, click on 'Produce'
- Create a new lot.

The various dates are not registered on the lot.

The product ID is located in the context in this case, not in the
values.

opw-803790

Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.

All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.

Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.

Also removed some dead code or improved the API to remove unnecessary
conversions.

The main idea of this new implementation is that stock.quant is now a
cache of the quantity per location/lot/pack/owner key. We removed every
identity per record, such as `history_ids` or `inventory_value` so that
we can now avoid the linear creation of stock.quant records and are able
to work with only one record per key.

The algorithms to retrieve the quantity per key are made to work with
multiple records, this way we can implement strategies to workaround
postgres locks if concurrent transactions try to work on the same quant
row.

Quants will not be linked to moves anymore, this is in order to be able
to edit stock moves more easily/freely. We removed the links with this
commit and wipe out the `action_assign` on stock move. This will be
implemented in a followup commit, once the relations between stock.move,
stock.pack.operation and stock.quant are clarified.

This commit seems to have unecessary diff, but it was done in order to
run tests on the new implementation.

We adapt the views by removing the fields not present anymore in the
model. This include the complete removal of the inventory valuation
view, as the implementation of stock valuation will be refactored and
moved on stock.move in a following revision.

We wipe out `action_cancel`, `recalculate_move_state`,
`move_quants_by_lot_v10` and `quants_unreserve`.

* `get_removal_strategy` moved from `stock.move` to `stock.quant`

Stock quant model:
  * qty renamed to quantity
  * history_ids: because the quants are not moved
  * inventory_value: implementation moved to stock.move
  * packaging_type_id: doesn't seem to be used (in filters?)
  * propagated_from_id: because we do not split forced quants
  * reservation_id: because the reservation are not linked to
    the stock.move.line

We remove the `lot_ids` computed field, as it depended on the link
between stock moves and quants and could be replaced by a related
to the move lines once the new relation between stock.move,
stock.pack.operation and stock.quant is clarified in a further commit.
Furthermore, the field was not displayed to the user.

PURPOSE
=======

confusing tooltip on "Alert Date".

SPECIFICATION
=============

Replace the tooltip on alert date by : "Date used to determined what are the expired lots and serial numbers using the filter "Expiration Alerts".

In Python 3:

* various builtins and dict methods were changed to return
  view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
  removed altogether

This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).

Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.

issue #8530

* LDAP import: python-ldap is not python3-compatible, pyldap is

  Warning: only supported from debian Stretch (current testing)?
  https://packages.debian.org/search?searchon=names&keywords=pyldap

* implicitly relative imports
* imports of moved or removed stdlib modules

issue #8530

When setting life_date, use_date, removal_date or alert_date, if one of these
fields are already set, it must be kept.

opw:704962

- Hide life_time, use_time, removal_time and alert_time if tracking = no tracking
- Change the tooltip of these fields(life_time, use_time, removal_time, alert_time)
- Add filter 'Expiration Alert' on the Lot/Serial Number list view based on the lot/sn alert date
- Add a tag 'Expiration alert' when the alert_date is reached.

General remarks concerning cleaning commits preparing the stock migration
=========================================================================

Small update / cleaning before moving and migrating. This commit contains
the cleaning of stock_picking_type and stock_picking models.

The first cleaning performed is to clean methods having a browse record or
a list of records replacing ids parameter. Those are converted into classic
old API methods using cr, uid, ids. This eases the migration as they are
then migrated into multi methods.

Another cleaning concerns naming things. Some methods are renamed to ease
the code readability. Some parameters are also renamed as well as some
variables. This kind of change is performed only when the readability
is improved. Otherwise the code is kept as it is to avoid rewriting too
much of the code.

Finally unnecessary stuff is also removed. This concerns dead code (methods
not used in community nor in enterprise) and unnecessary code splitting
(tools methods called once without real added value are directly put into
their called method).

- stock.move: no specific changes; note that a method called only in mrp
  has been moved to mrp.
- product: no specific changes
- config settings: no specific changes
- wizards: no specific changes

stock.quant main changes
========================

 - ``apply_removal_strategy`` method updated to return only the removal
   strategy instead of having a mix of several things (overrides updated)
 - ``quants_get_**`` methods renamed to ease code understanding
 - quants_unreserve from stock.quant to stock.move model because its primary
   record is a move, not quants

stock.inventory and stock.inventory.line main changes
=====================================================

 - stock.inventory: ``move_ids_exist`` field remove. Unused.

stock.picking and stock.picking.type main changes
=================================================

 - stock.picking: ``move_lines_related`` is removed. Indeed it is used only
   to display a slightly different view of moves contained inside a picking.
   However this field causes a lot of issues when migrated into the new API.
   The view is updated to keep the same look and feel while avoiding an
   unnecessary field.
 - stock.picking.type: complete_name field is removed. Using display_name is
   sufficient for the existing use cases.

stock.warehouse and stock.orderpoint main changes
=================================================

 - stock.warehouse: removed ``resupply_from_wh``, unused field

stock.pack.operation main changes
=================================

 - stock.pack.operation: ``processed_boolean`` fields renamed to ``is_done``
   to match its use in the code.

stock.location main changes
===========================

Note that in this commit a strange override in create has been replaced by a
cleaner override in default_get in order to have something more understandable

procurement main changes
========================

 - in this commit some code located in procurement has been moved to the
   orderpoint model. Indeed those methods take an orderpoint as main
   argument, making it more orderpoint methods than procurement methods
 - ``_prepare_orderpoint_procurement`` method has been merged with its
   strange override in stock_calendar to have something a bit more modular