task-2118794

closes odoo/odoo#42207

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

closes odoo/odoo#42295

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

Purpose of the commit is, the template website.404 is renamed
in commit https://github.com/odoo/odoo/commit/423402f1e50000186924186beba0cbe87e02e774



but still remains use of it at some places which is going to produce
the traceback so replace the template website.404 rendering with NotFound
exception as it will use the template http_routing.404

Task-2145659

closes odoo/odoo#42294

Closes: #40924
X-original-commit: e5af7617
Related: odoo/enterprise#7394
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

The remaining hours on a task are now displayed unless there are no
planned hours defined.

 - Between 0 and 79%: green border
 - Between 80 and 100%: yellow border
 - Above 100%: red border

closes odoo/odoo#41222

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

Writing for the web interface on the scheduled date of a stock move
will failed as the date is send to the python server as a string. Then,
a duration in datetime format is added. This failed as operation on string
and datetime is forbidden.
This commit cast the string date into a datetime object before applying
date logic.

closes odoo/odoo#42287

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

purpose of this commit is to reuse availability widget for
rental products so need to refactor the widget

task- 2081260
closes- #41598

Related: odoo/enterprise#7169
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

Issue

    - Install Email Marketing
    - Create/Edit a template
    - Switch into source mode
    - Add things
    - Save

    Things not saved.

Cause

    The widget override his parent `commitChanges` and don't take
    source mode into account.

Solution

    Take source mode into account like:
    https://github.com/odoo/odoo/commit/e29c08969f6e7ad981e9b7b79027d84dc89fbca2#diff-59db103a74684967379b66a89695cfdeR102-R105



OPW-2151675

closes odoo/odoo#42193

X-original-commit: 14f55b8d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Issue

    - Install Mail template
    - Enable debug mode (normal or assets)
    - Create or edit a mail template
    - Click in the text editor

    The toolbar is not showing up (it does when we're not in debug mode)

Cause

    We are doing `splice(-1, 0, ['view', ['codeview']])` on toolbar
    which is undefined, the method crashes and the toolbar doesn't
    render.

Solution

    Checking if the toolbar is defined before doing all that logic.

OPW-2151675

X-original-commit: 0e5ca50d

Generate a pricelist report for products and its variants. It's base on selected
pricelist and quantities. It also bring new UI.

closes odoo/odoo#35341

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Co-authored-by: Jigar Patel <jat@openerp.com>

closes odoo/odoo#42174

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

This is usefull for tests invoicing cases.

closes odoo/odoo#42169

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

Before this commit:
When loading a employee form, a write is done due to hr_org_chart

After this commit:
No write should be performed

closes odoo/odoo#42214

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

rev[0] aimed to fix an intercompany reservation issue by allowing the
intercompany moves to be seen, however the new domain was too soft and
also allows the visibility of any moves going to a location without
company, for example now outgoing moves to customer from all companies
are visible.

We strengthen the domain to only allow intercompany moves, ie we add the
transit constraint in the domain.

We also fix the same issue for the move line model (see [1])

Now that this one is fixed, the next move is automatically reserved
during _action_done. This didn't work either, so we carefully sudo and
force_company on the destination move.

[0] 3c4bb080
[1] f9461c7096a65565a05136a4c6c42ddfa6881926
task-2157248

closes odoo/odoo#42270

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

When an attachment is linked to a record (res_id and res_model are set)
we check the access rights and access rules of that record.

The access we check on linked record has changed as follow:

- 15905e78 (2013) => we check `write` access right/rule for `create`
- f5ebc509 (2014) => we check `write` access right for all mode
- 66644e85 (2015) => we check write access right for all but create mode

So currently we check on the linked record for each mode:

- create: write access right / write access rule
- read:   read access right  / read access rule
- write:  write access right / write access rule
- unlink: write access right / unlink access rule

The behavior is not expected for `unlink`, we should check if we have
write access through access rules instead of checking unlink access.

Without the change, the added test failed with a `unlink` access rule
AccessError on the linked record.

opw-2154448
closes #41814

closes odoo/odoo#42264

X-original-commit: 2b3fc2e3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

closes odoo/odoo#42248

X-original-commit: abdc08d8
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: beledouxdenis

Assume F and G are computed by the same method on a missing record R.
During recomputation of F on R, the compute method is called but fails
because R is missing.  Both fields are re-marked to compute (because
computation failed), then F is discarded (because R is missing).  Then
comes G's turn: G is accessed on R and the computation fails.  Both
fields are re-marked to compute (because computation failed), then G is
discarded (because R is missing).  Now F is marked again to compute: the
process never ends.

To avoid this situation, discard all fields to recompute on missing
records.

closes odoo/odoo#42234

X-original-commit: 78bf4dba
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

closes odoo/odoo#39621

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

To reproduce the bug:

1. Install `crm`.
2. Uninstall `iap`.
3. Go to any `res.config.settings` view.

Odoo will crash because the `iap_buy_more_credits` JS widget doesn't
exist (defined in iap).

Moving the widget from `crm` to `crm_iap_lead_enrich`. Since
`crm_iap_lead_enrich` depends on `iap`, this problem will not happen
anymore.

@Tecnativa TT20916

closes odoo/odoo#42258

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

closes odoo/odoo#42253

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

Currently when there is an issue with the google API key, a generic message
is send to the user, with the error details embedded in it in an ugly way.

Now a message is displayed: "Your Google API key is invalid, please update it
into your settings. Settings > Website > Features > API Key". This is done
by parsing the JSON google sends back after request and determining if the
error is linked to the API key.

Task #2082857

closes odoo/odoo#40547

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

This commit moves the finished quiz modal into a dedicated dialog widget.
It will lessen the "slide_course_quiz.js" code length and simplify the dialog template.

Task ID : 2126621
PR : #40801

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

An override of toggle_active was present to ensure that activities
would be removed before archiving records; this commit adapts this
mechanism to take custom active fields into account, since they are
now supported at ORM-level by getting the active field through the
`_active_name` model attribute instead of blindly using the `active`
hard-coded field that was used until now..

closes odoo/odoo#40109

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

Uninstalling an imported module leaves behind an ir.module.module entry
which is entirely useless: it cannot be reinstalled without re-uploading
the module.

A quick solution is provided here by simply cleaning up after the
uninstallation and deleting the ir.module.module records of imported
modules that just got removed.

Another possibility could be to store the uploaded module for good in
an attachment and re-load it from there upon re-installation, but that
would lead to some conflict with Studio, as uninstalling the
studio_customization module usually means you want to get rid of it for
good.

While x_name has long been automatically supported as an equivalent
of name, x_active was not.

This commit adds this behaviour OoB, both in the ORM and the web client.

On the ORM-side, a new `_active_name` attribute is supported on models.
This attribute specifies the field that should behave as an active marker
for records of the model. It is supported the same way `active` has been
until now (filtering by the `active_test` context key and toggled by the
`action_archive`, `action_unarchive` and `toggle_active` methods).
Although no check has been added on the field's type, it is assumed to
be a boolean field (the same way no check is present on the `(x_)name`
field).

On the client-side, the list view and form view now both support
detecting the presence of either `active` or `x_active` on records,
automatically adding an '(Un)Archive' button in the Action menu if such
a field is detected.

Note that the ORM implementation does actually need the field to be named
in any specific way, but since the web client has no mechanism to load
information regarding a model (the lifecycle of an action loading
includes loading the action, view and record(s) but no generic
information about the model itself besides what is included in the
views), we restrict the field's name to `(x_)active` to avoid confusion
as any other name would work at the ORM-level but not in the client.

In the future, the client might be able to more elegantly get
information about models, but this was not the scope of this change and
this solution should cover most cases.

Note that the `active` field will always takes precedence over the
`x_active` field to avoid confusing the polarity, even if both fields
are present on the model.

In the case of a custom field, it might be slightly annoying that the
default value of a Boolean field is `False`, which means that upon
adding the column, all existing records are automatically archived. This
can easily be worked around using an `ir.default` record for that
particular field and an update of existing records (e.g. through the
list view). The goal of this change was not to make it easy to add
support for custom active fields, but to make it possible - we have
therefore kept this implementation which introduces few changes while
adding enough flexibility for developers.
See https://twitter.com/zubair_shafiq/status/1202587553871880192?s=20


for more info regarding supporting any `_active_name` in the web client.

Co-authored-by: Raphael Collet <rco@odoo.com>

Channels uses tags allowing to categorize and filter content. For that
purpose a m2m exists between channels (slide.channel) and tags (slide.channel
.tag). The 2many relationship from tags to channels holds however a wrong
comodel name. It has no impact on code since relationship table is
correctly defined and current code does not use the channel_ids fields
from tags.

closes odoo/odoo#42244

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

Activate a Fiscal position with a defined tax mapping(i.e. 15%). Add to a
product the same tax. Set the tax to be included in price.
In POS Settings add the default fiscal position as the one from before.
Now open POS and add the product.

The total price calculated will be wrong: the tax is added twice, one
from the product line and one from the localization.

Mimic the behavior as in
https://github.com/odoo/odoo/blob/saas-12.3/addons/account/models/account.py#L1512



closes odoo/odoo#42194

X-original-commit: db16d119
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Revision on [1].

Commit above made changes to test helper `nextTick()`, so that it
waits for `window.nextAnimationFrame()` (shorten, 'rAF'). This was
useful to wait for OWL rendering, since OWL renders on next animation
frame.

From a theoretical standpoint, the helper should wait at least as
much time as before, as it adds either no slowdown (rAF is readily
available), or a few milliseconds wait (rAF waits for next available
animation frame).

However, some old tests show non-deterministic behaviours, resulting
to crashes [2]. It suggested, for some reasons, that `nextTick()` did
not wait long enough for re-render... Which is surprising considering
explanation above!

Some of these tests have been fixed, assuming it was caused by un-
guaranteed order of successive `setTimeout(0)` [3]. Unfortunately,
this does not explain why it never crashed before the change on
`nextTick()`...

After investigation, we think that this behaviour comes from rAFs
having their own task queue, which no longer guarantees that queued
tasks happen after queued micro-tasks:

When the requested next animation frame is readily available, the
callback of `requestAnimationFrame()` is immediately called and waits
for `setTimeout(0)`. The `setTimeout(0)` await is resolved before any
other queued async micro-tasks, so that `nextTick()` is resolved
sooner than expected. This would explain how `nextTick()` does not
wait long enough for rendering from the loads of resolved Promises,
even though there is a promise resolution after `setTimeout(0)`.

This commit fixes the issue by moving the await `setTimeout(0)`
before the rAF call, so that it correctly waits render from chain of
resolved promises (since the `setTimeout(0)` is awaited in the same
main task queue).

[1] https://github.com/odoo/odoo/commit/b0941d19a07b08fabc64a284b58e57edc46203dd
[2] http://runbot.odoo.com/runbot/build/771505 and http://runbot.odoo.com/runbot/build/752855
[3] https://github.com/odoo/odoo/commit/6cbfdbce2d0f1b567b6a6d6f637fe2a476980acc



closes odoo/odoo#42123

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

When a manufacturing order was created through a stock rule, the `delay_alert`
feature was broken. Indeed, we should store on the order the `delay_alert` value
similar to what we do with the `propagate_date`, `propagate_date_minimum_delta`
and `propagate_cancel` fields.

We thus add the missing field and add the values in the multiple prepare methods.
We also the missing values for `propagate_date_minimum_delta` and `propagate_date`
in `_get_move_raw_values`.

task-2154781

closes odoo/odoo#42032

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

 `propagate_date` enables the automatic rescheduling which could lead to hard to
 understand behavior if a manufacturing order is planned, i.e. if the work orders do
 have their leaves booked in the workcenter calendar. We thus disable the
 automatic rescheduling in this scenario.

task-2154781

date help: "Move date: scheduled date until move is done, then date of actual move processing")
As this behaviour is also wanted when the onchange mechanism do not work
(ie in a manufacturing order move raw and finished), we move it to write.

task-2154781

Before this patch, writing on the `date_expected` field on the raw moves did not
update the `date_planned_start` (but writing on `date_planned_start` did write on
the raw AND finished moves `date_expected`).

This proved to be wrong: having the same `date_expected` on both raw and finished
moves did not make sense (the manufacturing order is not instantaneous). It also
makes difficult to make the rescheduling work: the rescheduling is done on the stock
moves and thus updates `date_expected` on the raw moves. If this information is not
transmitted to the manufacturing order, we won't be able to continue the rescheduling
on the finished moves (the idea is to update the raw moves which will update the
date_planned_start which will update the date_planned_finished which will update the
finished moves)

To have a more sane system, the `date_planned_start` and `date_planned_finished` are
computed (with an inverse) on the raw and finished moves `date_expected` (similar to
what's done on the picking model). There's a tweak though: as `run_manufacture`
creates first the order with a `date_planned_finished` and then confirm it (which will only
create the finished move at this moment), there's no place to write `date_planned_finished`.
The compute thus defaults on `date_deadline` which is stored and the finished moves
will be created later on with this value.

We implement the same logic `_onchange_date_planned_start` in `write` so that it doesn't
only rely on the onchange mechanism and the rescheduling can work when changing the
`date_expected` on a child mo for example.

task-1970595

- Before this commit file name is Timer.js which create issue in macOS
due to non case-sensitive harddisk partition. So file renamed to timer_mixin.js

closes #42232

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

Fixes a7b89070

opw-2078313

X-Original-Commit: 8ab09cad

Remove the create_edit option when creating a new lost reason to avoid
displaying an unnecessary wizard.

task-2155189

closes odoo/odoo#42120

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

When exporting fields, the reward attempts fields were split from each other. By grouping them, it allows
easier management from user as all rewards fields are now grouped in the export wizard.
Additionaly, they are also grouped in the dropdown for custom filter.

task-2155189

closes odoo/odoo#42103

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

Since the name updates are done in onchanges, the relational values
may be newIds and therefore we have to use their _origin for comparisons.

closes odoo/odoo#42217

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

The `color` attribute allows specifying a field by which the calendar
view will color the event entries in the view.

In views where this attribute is not defined, the event was instead
given the `text-white` class, which rendered the event invisible in the
calendar, save for a slight left-border.

This commit just use the 1st color class by default in such cases,
ensuring all events are visible.

opw-2145652

closes odoo/odoo#42200

X-original-commit: 375b34be
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

Ensure that expression.OR and expression.AND and some other
expression.py methods do not propagate or rely on TRUE_DOMAIN and
FALSE_DOMAIN that may be muted on some instance.

For example, if we did:

  self.search(expression.OR([]))

then in the search method we do something like:

  received_domain.append(('res_field', '=', False))

before this commit, FALSE_DOMAIN would be altered for any succeeding code
that try to use it in `[(0, '=', 1), ('res_field', '=', 'False')]`.

Without the changeset, the added test would fail with:

    [(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
    [(0, '=', 1), ('id', '=', 1)] != [(0, '=', 1)]
    [(0, '=', 1), ('id', '=', 1)] != [(0, '=', 1)]
    [(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
    [(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]

note: another commit referenced in #41968 should make the TRUE_DOMAIN
and FALSE_DOMAIN immutable.

related to work on opw-2154448
closes #42107

closes odoo/odoo#42222

X-original-commit: 303ce32e6ccd7432b96ffae545e4a6eced68ae84
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

* website, website_mass_mailing

Instead of a custom string, use the name of the snippet when displaying
an 'invisible' snippet in the 'invisible elements' section.

This commit also fixes a font-awesome bug introduced with the library
update revert.

Part of https://github.com/odoo/odoo/pull/41789



closes odoo/odoo#41789

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