PURPOSE

Make digest email and tips more appealing. The goals of these tips are

  * to encourage the adoption of other apps (Did you know ?);
  * to make Odoo look more fun (Fun tips and tricks, young and dynamic style);
  * to show social proof and increase trust (emphasis on already existing
    projects / customers to);

SPECIFICATIONS

Add a daily digest option, allowing to send digests on a daily basis. It
will be the default settings to help users coming back to odoo.

Add a slowdown heuristics. If not any user targeted by a daily digest logs
himself within 3 days, digest is slowed down to a weekly setting to avoid
spam.

Add a preference section in template, to hold notably links to some
configuration steps sent mainly for admin / CEOs.

Improve access on models.

LINKS

Task ID 2197417
PR odoo/odoo#51619

PURPOSE

Make digest email and tips more appealing. The goals of these tips are

  * to encourage the adoption of other apps (Did you know ?);
  * to make Odoo look more fun (Fun tips and tricks, young and dynamic style);
  * to show social proof and increase trust (emphasis on already existing
    projects / customers to);

SPECIFICATIONS

Improve template according to FP specifications, aka
    Header
    Tip
    KPIs
    Preference text
    Want to customize?
    Mobile Tip
    Footer

LINKS

Task ID 2197417
PR odoo/odoo#51619
Upgrade PR odoo/upgrade#1256

Co-Authored-By: Elisabeth Dickinson <edi@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>

PURPOSE

Make digest email and tips more appealing. The goals of these tips are

  * to encourage the adoption of other apps (Did you know ?);
  * to make Odoo look more fun (Fun tips and tricks, young and dynamic style);
  * to show social proof and increase trust (emphasis on already existing
    projects / customers to);

SPECIFICATIONS

Slightly reorganize code to ease future changes, notably in KPIs computation
that will be made a bit more generic.

LINKS

Task ID 2197417
PR #51619

Currently only digest planned "today" are sent. Which means that digest that
missed a cron tick are not sent anymore. We fix that by making the cron run
on all digest whose scheduled date is in the past or today.

LINKS

Task ID 2197417
PR odoo/odoo#51619

PURPOSE

Make digest email and tips more appealing. The goals of these tips are

  * to encourage the adoption of other apps (Did you know ?);
  * to make Odoo look more fun (Fun tips and tricks, young and dynamic style);
  * to show social proof and increase trust (emphasis on already existing
    projects / customers to);

SPECIFICATIONS

In this commit we simply add a first support of tools to render qweb templates
like rendering jinja. Instead of giving the template to render the xml id of
the view is passed.

This code is meant to be improved in a near future with new use cases that
will soon arise.

LINKS

Task ID 2197417
PR odoo/odoo#51619

Purpose
=======

As the first displayed menuitem is the kiosk mode (if enabled)
We can't easily navigate through the menuitems.

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

Set the check in / check out menu first (as default).

closes odoo/odoo#52148

Taskid: 2237996
X-original-commit: f74042ae3934d014f57a3de1edd54bd1834312af
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Commit bca2926b introduced a fix for
ir.ui.view unlinks during uninstall but forgot to return the result of
the super() call to unlink which broke behaviour downstream.

This commit restores the proper behavior of returning the result of the
call to super.

Closes #52364

closes odoo/odoo#52435

X-original-commit: a3d91cc8
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>

The present PR aims to replace the "time range menu" component in the control panel by a new
component called "comparison menu".
The new component purpose is roughly the same: compare a period of data in a reporting
view with the previous period or the previous year.
Its implementation is a bit simpler: it will only appear if at least one
date filter is selected in the search view, and will suggest to compare
each selected date option with the previous period or the previous year.

Remarks:
1) The date filter options are now ordered a bit differently: the chronological order has been chosen.
For example, we would get May 2019/June 2019/Q1 2019/May 2020/June 2020/Q1 2020 instead of
June 2020/May 2020/Q1 2020/June 2019/May 2019/Q1 2019 (for simplicity no comparison is done
between quarters and months).
2) The key 'timeRanges' in the ir.filters contexts is no more used. We now use the key 'comparison'.

Task ID: 2245719

closes odoo/odoo#51379

Related: odoo/enterprise#10658
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>

Tests have been adapted accross all affected modules to support the new
"comparison" menu component.

Task ID: 2245719

Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>

The control panel test helpers related to the "time range" menu have
been removed and a new helper for the "comparison" menu has been added.

Task ID: 2245719

Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>

The "board" module has been adapted accordingly to the recently
introduced comparison menu.

Task ID: 2245719

Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>

This commit replaces the "time range menu" in the control panel by a new
component: the "comparison menu".

Its purpose is roughly the same: compare a period of data in a reporting
view with the previous period or the previous year.

Its implementation is a bit simpler: it will only appear if at least one
date filter is selected in the search view, and will suggest to compare
each selected date option with the previous period or the previous year.

Task ID: 2245719

Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>

Before this ref, the dropdown menu got his icon directly from his props.
This means that any inheriting class had either to define its icon with
the 'default_props' key or to have its parent giving it in the props.

Now, the icon is retrieved from the props via a getter (same as title
and items) and can be overridden to force a fixed icon on the class.

closes odoo/odoo#52456

X-original-commit: 977f1bd2
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>

Issue

	- Go to unsubsribe sms page where the 'sms_code' is the same
	in multiple traces
	- Fill the correct phone number (same one of any traces)
	- Click on 'Unsubscribe me'

	Traceback is raised.

	Also, if empty phone number, still have successfull message.

Cause

	Multiple traces with same "sms_code" but different "sms_number".
	The current behavior does not handle multiple traces.

Solution

	- Filter and retrieve the trace with the correct "sms_number".
	- Add 'required' attribute on phone number input.

opw-2264200

closes odoo/odoo#52452

X-original-commit: 34a8f633
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>

This method has been lost during the forward-port of:
https://github.com/odoo/odoo/commit/161498cf8a75d62f9a8e1a17c6dc62a142b85acc



closes odoo/odoo#52424

X-original-commit: 18d08cc3b48a12c015bd2513cc64ee1166336b5d
Related: odoo/enterprise#10956
Signed-off-by: Josse Colpaert <jco@openerp.com>

- Create a lead and set a language
- Convert to opportunity and choose 'Create a new customer'

The new customer created doesn't have the language of the lead set.

This is more logical to set the same language to the new customer.

opw-2270321

closes odoo/odoo#52376

X-original-commit: 1999c68ff4eb382019c92064d9285411314a39be
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

The event registration form is made up of a public widget that
instantiates an internal normal widget. All public widget are
automatically destroyed when entering in edit mode as well as the widget
it created. Therefore, it's main element is removed from the DOM when
the widget is destroyed. Here, we're detaching the main element from the
internal widget before the widget is destroyed so that we avoid to
destroy his main element from the DOM when entering in edit mode.

task-2210733

closes odoo/odoo#52426

X-original-commit: d515e423
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

The /shop/cart/update was accepting both GET and POST request. Therefore,
we couldn't have csrf on the route meaning any website could change your
cart if the route was known.

task-2263776

closes odoo/odoo#51486

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

Refactoring the tag cloud to make it work with post request.
Disallow multi-tag in get for bot indexation.

task-2250385

It was deleted in 11.0 as it was not used anymore. Now, it is
reintroduce as it is a nice utility function for some external app or
fixes. Here, it is use so that /website/add and /website/add/<path> work
as a controller POST with a CSRF token.

task-2241766

Courtesy of Federico (fza)

closes odoo/odoo#52404

X-original-commit: 7f035f38
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

https://github.com/odoo/enterprise/commit/7d17dad678361f161c259eddd45d9b5186941bd0

 fixed the sign used for cash basis entries in the tax report, but this change had to be reflected on the tax_audit computed on cash basis entries as well.

Before that, cash basis entries never were made on sales journals, and their move lines never had a refund-typed invoice_id. So it means those factors, when present on the original invoice, never influenced the audit string computed for cash basis entries. This was obviously wrong.

closes odoo/odoo#52381

X-original-commit: 1157b3073f409c9fbdffe8f3b3322331f470de02
Related: odoo/enterprise#10927
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

- A custom COA could be passed as parameter.
- Merge the invoice setup to the generic suite like it is in master.

forwart-port of https://github.com/odoo/odoo/commit/161498cf8a75d62f9a8e1a17c6dc62a142b85acc



closes odoo/odoo#52378

X-original-commit: c0acebe2c55f7030df3bd10ad8058da6a070aa72
Related: odoo/enterprise#10921
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

This commit adds the support of nolabel attribute on fields
in list view. This attribute can be used to empty the column header.

Example of use:

<record id="module_example_tree_view" model="ir.ui.view">
  <field name="name">module.example.tree.opportunity</field>
  <field name="model">module.example</field>
  <field name="arch" type="xml">
    <tree>
      <field name="name"/>
      <field name="tag_ids" widget="many2many_tags" nolabel="1"/>
    </tree>
  </field>
</record>

Result:

This will create a tree view with 2 columns.
The second column will have an empty header and won't be sortable.

Name    |
--------+--------------
Record1 | [tag1]
Record2 | [tag1][tag2]
Record3 | [tag2]

closes odoo/odoo#52302

Task: 2269315
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

closes odoo/odoo#52384

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

According to http://cpe.sunat.gob.pe/sites/default/files/inline-files/anexoV-340-2017.pdf


The right tax for the FRE tax should be 9996 and not 9997

closes odoo/odoo#52387

X-original-commit: 5c6e8bb9
Signed-off-by: Josse Colpaert <jco@openerp.com>

Save in l10n_ar_vat field the cleaun up CUIT number (without spacings,
dashes and points.

This way we can use it so sent it properly as a number to AFIP.

closes odoo/odoo#52380

X-original-commit: d0214151
Related: odoo/enterprise#10925
Signed-off-by: Josse Colpaert <jco@openerp.com>

The `get_string` method from the `pyusb` package has changed its
signature after version 1.0.0b1 so we used to force the IoT Box to use
this version to avoid an error. The problem is that version 1.0.0b1
has dependencies that raise DeprecationWarings in Raspbian Buster.
We then want to update the version of pyusb that is installed on the
IoT Box in 14.0.

As the Driver might be loaded to old versions of the IoT Box as well
as new ones, we need to check what version of the package is present
on the IoT Box before calling `get_string`.

This check will be removed in 14.0, as people will have to use the
latest version of the IoT Box.

closes odoo/odoo#52374

X-original-commit: e5475ae8
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>

Remove borders/background-color in columns of the features snippet in
job description.

closes odoo/odoo#51823

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Cause

	When kit BOM line quantity is equal to zero in a sale order, it raise error
	because trying to divide bom_line_data['qty'] / bom_line_data['original_qty']
	when computing kit quantities.

Solution

	As BoMs allow components with 0 qty, a.k.a. optionnal components,
	we simply skip those to avoid a division by zero.

Cherry-pick of #38890

opw-2262540

closes odoo/odoo#52362

X-original-commit: ab780a9d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>

Consider a context-dependent field, and successively access it on a
recordset with different contexts.  On the first context, the field is
correctly computed in batch.  After that, the field is always computed
one by one.

The bug is in the method that determines which records in a given set
have no value in cache.  On the first context, the cache is empty for
the field, so all records are returned.  After that, the method
considers that all records have a value in cache: they do, but for
another context key!  Simply using the context key when looking up the
cache fixes the issue.

closes odoo/odoo#52360

X-original-commit: 35d69589d9b43afe6c6fc9779458323f7180153e
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Co-authored-by: Xavier-Do <xdo@odoo.com>

X-original-commit: 612b900fb99b26daba22eb25409f512a3a0cb2ea

Steps to reproduce the bug:

- Let's consider a customer company partner P
- Let's consider, P1, a child partner of P
- Create a SO for P1
- Archive P1

Bug:

The SO count in the smart button Sales of P was 0 instead of 1

opw:2267828

closes odoo/odoo#52340

X-original-commit: 31ded31d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

Before this commit, a user with attendance administrator rights can see
the attendances of all users of all companies and not only the companies
he is allowed.

Now, the administrator will only see the attendances of the users of the
companies he is allowed.

opw-2263577

closes odoo/odoo#52355

X-original-commit: 0e8f8679
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

'account_id' & 'name' are no longer valid fields to create a statement line since:
https://github.com/odoo/odoo/commit/caeb782841fc5a7ad71a196e2c9ee67644ef9074



closes odoo/odoo#52343

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

Note : Manual forward port recovering from commit ae1e70eb

Purpose
=======

Let's say that the field 'foo' is tracked and defined with a res.group.

When the field is modified, a mail.tracking.value is generated, but the
reference to the field name is a char field.

When displaying the mail.tracking.values on the chatter, a check is done
according to the field group to decide whether we should display it or not
to the user. See: c7aa8c5f#diff-ad8b6db158187579d2208f233d993c3cR43

So if I rename the field, and if the mail.tracking.value is not modified,
the mail.tracking.value magically appears to the users who shouldn't
access it before.

Note: If the migration is correctly handled, this shouldn't be the case.
But manual manipulations on the database could lead to this issue.

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

If the field referenced by the mail_tracking_value doesn't seem to exist,
then display its value to system users only, by security.

closes #39016

closes odoo/odoo#52348

Taskid: 2088634
X-original-commit: 19bc081e4a71042c3f009e4af641da18fc16bdfe
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

When installing sale_margin, the computed fields will be computed on existing
sale.order and sale.order.line in database.  On huge databases, the computation
may take a lot of time, depending on the configuration (multi-company, multi-currency, ...)

The current commit improves the computation of the purchase_price
(recently changed to a computed field), by avoiding unnecessary currency
conversions when possible (one less query to get the conversion rates).

In a multi-currency database where the products have no cost defined
(standard_price field), the sale_margin installation takes up to 50% less time.

closes odoo/odoo#52338

X-original-commit: 3c9841d1aa4fc5b10012c8239a31d6e7f8676fc0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Installing sale_margin module on a db with a lot of sale.order was impossible.

This commit significantly improves performances.
Went from many hours (forecasted) to 15 minutes on a db with 300k orders

For sale.order:
  - Duplicating logic between edit mode and non edit mode
  - Edit mode logic stays the same as before
  - Non edit mode uses read_group to speed up the computation

X-original-commit: 9f1ea7427cdb6984f175f5111e4c9a4c5f013af2

Before this commit, `self.env.user.company_id.id` may represents different company from the current company based on context.

In this commit, we use correct company based on contextual company.

Follow up on b39173a8

closes odoo/odoo#52328

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