Modify purchase report in order to make it consistent with
sales report.
For the RFQ it will show the Order Date and for the Purchase order
menu it will display the Confirmation Date.

Also rewrite a bit the SQL view in order to compute every purchase
order in the company currency.

Technicaly rewrite the SQL alias in order to have a report more
readable in the future.

Task ID : 1857130.

closes odoo/odoo#28248

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

Purpose
=======

1/ Robustness & security: right now it is not easy to understand and do something
clean in term of security (hr people vs employees, private info vs public). A
HR officer doesn't know if he can write something on the chatter. Currently, a
note will be visible for all the employees who have access to the employee form
view for example.
2/ In term of business, it makes sense to let a hr manages payroll stuff (contract,
employees private information, ... and other employee see public information
(résumé and work information)

Specification
=============

Introduce 2 new models:

- hr.employee.base (AbstractModel): This represents the basic skeleton
model on which the shared fields and methods between the public and
the private employees models.
- hr.employee.public (_auto=False): This is a sql view based on the
employee values, readable for an internal user (i.e. an employee).

The model hr.employee is not readable anymore for an employee.

There are now 3 ways to access the employee data:
1/ From the hr.employee views. HR officer access rights are required
2/ From the public profile. The public data for an employee are accessible
but can't be modified.
3/ From the 'My Profile' menu. A classic employee can access its own
data from there, and can modify them.

TaskID: 1961151

closes odoo/odoo#33725

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Purpose
=======

1/ Robustness & security: right now it is not easy to understand and do something
   clean in term of security (hr people vs employees, private info vs public). A
   HR officer doesn't know if he can write something on the chatter. Currently, a
   note will be visible for all the employees who have access to the employee form
   view for example.
2/ In term of business, it makes sense to let a hr manages payroll stuff (contract,
   employees private information, ... and other employee see public information
   (résumé and work information)

Specification
=============

Introduce 2 new models:

- hr.employee.base (AbstractModel): This represents the basic skeleton
  model on which the shared fields and methods between the public and
  the private employees models.
- hr.employee.public (_auto=False): This is a sql view based on the
  employee values, readable for an internal user (i.e. an employee).

The model hr.employee is not readable anymore for an employee.

There are now 3 ways to access the employee data:
1/ From the hr.employee views. HR officer access rights are required
2/ From the public profile. The public data for an employee are accessible
   but can't be modified.
3/ From the 'My Profile' menu. A classic employee can access its own
   data from there, and can modify them.

This is much better for code readability, and in our coding guidelines

In List View, the Import button is placed after the Create button.

Before this commit, in a list editable in edit mode, the Create button
is hidden and the Save & Discard buttons are displayed.
But as the Create button was placed before the Save button, the Import
button will appear at the first position.

With this commit, the Create button is now placed after the Discard
button. In this way the Import button will be always the last button and
its position will not change when we switch between edit and read modes.

closes odoo/odoo#32613

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

Before this commit, we had two form views for production lot: one more
complete and one simplier.
The complete one was displayed when we come from the prod lot list view,
and the simplier one in any other case.

But actually, we need to display the simplier one only with "Create and
Edit" and display the complete one in any other case, but it's
impossible to do with only two distinguish views.

So, we keep only one view with all elements and we display or hide some
fields or button in function of the context or if the record is new.

Task #1935921

Creation of a js_class: singleton_list.
It's used in the quant list view and its purpose is to avoid duplicate
line in list editable.

When user creates a new record, if the server responses with a ID
corresponding to a record already present in the view, it'll update the
old one instead of create a duplicate line.

Task #1935921

Change the use of Inventory Adjustment, notable changes are:

    - Removed filter field: When user creates a new inventory
    adjustment, he can set one or multiple locations and/or products.
    An inventory adjustment will worry only about defined
    locations/products, but if neither product or location was set,
    it'll manage all stock.

    - Inventory Adjustment Lines have their own view instead of be
    listed on the Inventory Adjustment form view.
    Inventory adjustment lines have new color legend:
        - Red: The quantity is outdated.
        - Blue: There is difference between the on hand quantity and the
        counted quantity.
    New inventory lines created by the user are written in bold.

    - User can't modify already existing inventory lines, except for the
    counted quantity.

    - When an inventory line is outdated, the user has the possibility
    to select and update it, that'll recompute the on hand quantity.

    - When an inventory adjustment is validated, it will take in account
    only the difference between the theoretical quantity ('On Hand
    Quantity') and the counted quantity to adjust the quants.

    - When an inventory adjustment is canceled, it will keep its
    inventory lines and won't regenerate them when re-started.

    - When an Inventory Adjustment generates Account Moves, user can now
    find them in a stat button in the Inventory Adjustment form view.

Also, made some changes in demo data to match new requirement.

Task #1935921

Made some changes in stock.quant model to allow user to modify product
quantity easier.

To allow the edition of quant without opening more permissions on the
model, we switch to sudo in create mode and write if the conditions are
met (special key in context + access rights on the current user + write
on a specific field).
Also, we have two list views for the quant:
    - The old list view who still readonly.
    - A new list view where user can create new quant or edit quantity
    of existing ones

We display the second one if user is a stock manager.
For existing quants, user can modify counted quantity (which will modify
product quantity). User can also create new quant, in this case:
    - The quant is really a new one (ex.: new product/location
    association) so will simply create a new quant.
    - A corresponding quant already exist, so will modify the existing
    quant instead of create a new one.

When an user creates a new quant, the model will check each time a
non-quantity field (product, location, SN/LN, package or owner) is
modified to see if corresponding quant exists. In this case, it'll get
the quant ID and will update reserved and on hand quantities.
If user didn't change the inventory quantity, it'll be updated too.

On product form view, the 'Update quantity' button was removed as user
can now simply modify quant with 'On Hand' stat button.

Task #1935921

Co-authored-by: sle-odoo <sle@odoo.com>

Purpose of this merge is to clean and improve performances of post and
notification mechanism contained in mail application.

In this merge we provide

* centralization of notification code inside mail.thread instead of being
dispatched in mail.thread, mail.message and res.partner;
* simplification of call chain, removal of unnecessary methods;
* better propagation of messages value through the various calls in order
to use given value and avoid browse and cache miss adding queries;
* optimization of attachments management in post;
* cleaning of message_post now limited to records and simplified in its
management of parameter;
* cleaning and simplification of recipients grouping for email notification;
* cleaning of message_notify;
* various code cleaning and tweaking in order to reduce query count;

Performance tests indicate number of queries did fall, especially in
use cases involving management of followers and attachments. See sub
commits for more details. This merge is linked to task ID 1943901.

closes odoo/odoo#32404

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

Since ORM changes, the ids a many2many are new (virtual) ones in a
onchange, so we have to point to origin which are the real records to
check that the many2one is in as it has a real id.

closes odoo/odoo#33763

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

Currently the fact that the changes in the expected dates are propagated
or not is based on :
- the value of the field propagate on the stock.rule
- the general inventory setting setting use_propagation_minimum_delta

That's not easy to understand for users and difficult to configure.

The purpose of this task is to clarify this configuration (everything is configured
at the same place + but we keep the flexibility by setting this config on the stock.rule)

task-1913401

closes odoo/odoo#33719

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

We use a new method to connect the box to a device in the network.

We use the socket to listen a specific port in the box to connect device through the TCP/IP

Task: 1891152

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

closes odoo/odoo#33398

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

This commit improve the display of payments lines and give
a name to last notebook group in /addons/point_of_sale/views/account_statement_view.xml
to be able to override it in enterprise

With this commit it is now possible for the IoT Box
to listen on a specific port of the box to interact
with a device via TCP / IP.

We use the library 'socket' to listen on port 9000
and if a request comes on this port we create an IoT Device

Purpose of this commit is to improve performance of post and notify through
various code improvements.

Containing
  * making of _notify_customize_recipients a mail.thread method;
  * _message_auto_subscribe_followers optimized;
  * renaming and optimisation of _notify_partners;
  * message_post_attachements optization;
  * remove unused mail_post_autofollow_partner_ids context key;
  * minimize message create queries;
  * only check record related access right for thread messages not in pending
    moderation;
  * get attachements from values instead of db;
  * storing lang in ctx from the beginning;
  * don't track on write on attachments;

Related to task 1943901
Linked to PR #32404

Purpose is to make field use more obvious by correctly stating in the
name it should contain an xml id to a qweb layout used for email
notifications. This renaming is propagated through various calls and
addons.

Related to task 1943901
Linked to PR #32404

Purpose of this commit is to clean notification process: calls, methods
API, method name, variable propagation.

Contains notably

  * simplify API of methods used to group recipients when sending notification
    emails;
  * improve and rename methods used in email notification process;
  * move some methods on model itself as non mail thread records could be
    mass-mailed and _notify_email_headers could be called on other records;

Related to task 1943901
Linked to PR #32404

If no email layout is found when trying to render the layout around the
message content, just send body in notification emails instead of
crashing. See notably 89051058 .

Related to task 1943901
Linked to PR #32404

Purpose of this commit is to move notification methods to mail.thread. Indeed
currently they are split among several models: thread, message, partner.
It makes code difficult to understand. Base record has to be propagated in
order to run methods on it. It is therefore simpler to make those methods
on mail.thread and correctly have model methods.

All notification methods are moved into a single section in the mail.thread
file. This implies some more code move inside mail.thread but allow to have
methods classified by their purpose.

Related to task 1943901
Linked to PR #32404

Message post should always be called on a record (ensure_one). That way we
ensure posting a message is always done in a record's context with right
values computed (reply_to, followers, ...)

Message_notify can be called on record or on mail_thread and must have
partner_ids. It is based on the recently modified user_notification mechanism
and allow to notify a partner on a record or just to push him a message
(aka, not linked to a record).

Small performance improvement

  * browse recipients instead of search in _notify_email_recipients;
  * todo in future optimizations: mayybe be improve by searching on ids
    and is_blacklist immediately;

Related to task 1943901
Linked to PR #32404

Purpose of this commit is to clean some bits of code, notably calls to
message_post/log as well as notification methods. It will ease performance
improvement work.

Small optimization: account: read content after extension check

Parameter cleaning

 * use message log with kwargs instead of args;
 * remove message post after hook useless parameters;
 * remove _notify_email_recipients useless message parameter;
 * remove message_notify useless send_after_commit parameters;
 * remove message post params matching default values;

Other improvements

 * remove message_post commands support for partners and channels;
 * only calls message_post with ids list for channels and partners. We
   don't support mix of ids and command anymore to simplify code;
 * remove support of private discussion in mail.thread adding partners
   as recipients, as there is no use anymore;

Related to task 1943901
Linked to PR #32404

It includes notification on inbox / email as well as attachments management.
This latter one adds quite a lot of queries and is not currently tested
for performances. Future commits will improve those counters.

Related to task 1943901
Linked to PR #32404

Currently if a message has a res_id and a res_model it appears in the
matching record's chatter. Its access rights are computed based on this
record. This is the standard behavior of mail.message model.

User notifications are currently built on messages not having model and
res_id in order to avoid appearing on chatter. This has several drawbacks
notably access rights, redirection to the record, systray, finding back
records, ...

This commit solves those issues by adding new message_type 'user_notification'
that should be as a classic mail.message with model and res_id but without
the whole notification mechanism and without being displayed in the chatter.

An user notification is now a classic message pushed to a given partner only
and not displayed in the chatter.

Related to task 1943901
Linked to PR #32404

Implement the propagation minimum delta per rule in mrp.

Add a basic test.

task-1913401

task-1913401