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>

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>

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

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>

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

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

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

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

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.

Thanks rgo-odoo for the _get_dates method and the removal of the context abuse.