Purpose of the task is, we have added the activities on various
listviews, the goal of this task is to update SO/PO/invoice demo data
with activities and also set tags on sales orders.

So in this commit, We added the activity on several SO/PO/Invoices and
also added the some tags one sales order and set the user as False
where the user is set as 'Odoobot'.

closes odoo/odoo#51799

Taskid: 2254708
Closes: #51799
Related: odoo/enterprise#10743
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

PURPOSE
=======

Since V13.3, the product "Taking care of Trees Course" has a Service Invoicing Policy
configured as "Milestones (manually set quantities on order)".
So, it's not possible to create an invoice from a SO.

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

The policy should be Ordered quantities

Taks ID: 2248213

closes odoo/odoo#51583

X-original-commit: 4883a4fa14dea966df2469ce6bc6cbc5cf5ee8c6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

As portal user has access to the "Taking care of trees" demo course, we add
this course to the sale order that already contains the "DIY Furniture".
Since the course is "pay to access", it makes more sense.

LINKS

PR #41972
Task 2045571

PURPOSE

Test frontend and UI tools of eLearning.

SPECIFICATIONS

This commit move commented demo data due to dependency issues (see 9920f20e4c7753bc17bea71dea3a90f7de687196).
Optional products are now installed with the "full elearning setup" module
introduced recently.

LINKS

Task ID 1937768

PURPOSE

Test frontend and UI tools of eLearning.

SPECIFICATIONS

Add some demo data to allow demonstrating various flows: training, lessons,
public, private, quizzes, ...

Also prepare future test tours by improving courses that will be used for
tours, notably the public one.

LINKS

Task ID 1937768

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>

* pos_sale, sale, sale_crm, sale_management, sale_stock, website_sale

Purpose of this commit is replace the confirmation date field with
order date from sale. As order_date and confirmation_date of sale order
are having same value so no need to keep two fields, remove confirmation
field and instead use order date.

cretae_date use as order Date and replace the order_date on confirmation
of the order as confirmation date.

task-2027274
closes: #34571

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

PURPOSE

eLearning should have its own application in manager. Indeed this is becoming
a big application and having it embedded inside Website application is not
enough anymore. It should also hold updated and easy-to-use menus,
navigation, actions and views in backend.

SPECIFICATIONS

Remove "Our Documentation" dummy default existing data. It makes no sense
to have void data. Instead just add a small explanation text in eLearning
front-end telling the user to create its first course if he has rights to
do so.

In order to better show the new backend add some demo data for missing
numbers, notably

  * sales: add confirmed sale orders in order to have revenues value;
  * forum: add some posts and answers;
  * quiz: update slide.slide.partner demo data to hold quiz attempts count;

LINKS

Task 1978729
PR #35061

Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>

The `website_published` field from the website's mixins is basically a readonly
from `is_published` field.
On read, this field will simply read `is_published` and check if the record's
website_id is accessible (only for the multi mixin).
On write, it will always write on `is_published`.

This commit improves a few things:
- A lot of code was writting on website_published which was just then writting
  on is_published. Writting directly on is_published makes more sense.
- Some backend fields would still reference `website_published` instead of
  `is_published` which would just go through the related for no reason.
  Plus, using `is_published` will make the field tooltip more accurate as we
  are not in a website context ('Visible on current website' to 'Is Published')
- Filter and search on tree view were still using the `website_published`
  related field, which is just a readonly when we are not in a frontend
  context.
- Some create and write function would have security check on
  `website_published` value but that was wrong as the user could bypass that by
  simply writting on `is_published`. For the write method, check `is_published`
  is more accurate as it will cover both case since `website_published` will
  then call the write method on `is_published`

image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small  => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
	what was previously the big size)

+ add new intermediate format:
image_512

PR: #34925