PURPOSE :

A quiz after a course content is a good way to check if the user gets the previous lesson.
Despite, the user/student may not understand why his answer was wrong/correct.
In this task we'll allow the teacher to add a comment next to the asnwer of a quiz.

SPECIFICATION :

The quiz creator will now be able to comment the answers to inform the frontend user why
his answer is wrong/correct. He will be able to add the comments both in backend and frontend.

Task ID : 2072566
PR : #41188

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

SPECIFICATIONS

Fixes following issue: when a lead is marked as lost, the probability is
correctly set to 0 but not the automatic one. If one clicks on the "Set to
automatic", the probability is updated, which un-archives it without really
restoring it, meaning we get in a very strange state outside the expected flow
(no Won/Lost buttons, ...).

With this commit the automated probability is set to 0 when setting as lost.
Moreover restoring a lead recomputes its probabilities.

LINKS

Task ID 2092799
Manual backport of PR odoo/odoo#42015 done in master
PR odoo/odoo#42045

closes odoo/odoo#42057

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

Before this commit, we can't use the Generate and Assign Serial Numbers
on already existing move line. It always creates new one, even if the
picking type use "Pre-fill Detailed Operations".
Now, it will edit existing lines, except if we ask to generate more SN
than we have unassigned move lines, or if the picking don't use the
"Pre-fill Detailed Operations" option, in which cases it will still
create new move line with the generated SN.

Also, before this commit, paste a list of serial numbers to assign them
on multiple move lines in once work only with creation of a new move
line for each serial number.
Now, it's also work with existing move lines.

Finally, some code shared the same logic in `stock.move` in the move
line onchange method and in the `_generate_serial_numbers` method.
Moves this code in a new method, `_generate_serial_move_line_commands`,
and call it in the two previous methods.

task-2150561

closes odoo/odoo#42316

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

glibc's malloc() uses arenas [1] in order to efficiently handle memory
allocation of multi-threaded applications. This allows better memory
allocation handling in case of multiple threads that would be using
malloc() concurrently [2].

Due to the python's GIL, this optimization have no effect on
multithreaded python programs. Unfortunately, a downside of creating one
arena per cpu core is the increase of virtual memory which Odoo is based
upon in order to limit the memory usage for threaded workers.

On 32bit systems the default size of an arena is 512K while on 64bit
systems it's 64M [3], hence a threaded worker will quickly reach it's
default memory soft limit upon concurrent requests. We therefore set the
maximum arenas allowed to 2 unless the MALLOC_ARENA_MAX env variable is
set.

This commit also brings the following changes:
- allow to disable the memory hard limit for all servers if the provided
  value is 0 (instead of crashing)
- increase the log level for threaded server in case of limits reached

Note: Setting MALLOC_ARENA_MAX=0 allow to explicitely set the default
      glibs's malloc() behaviour.

[1] https://sourceware.org/glibc/wiki/MallocInternals#Arenas_and_Heaps
[2] https://www.gnu.org/software/libc/manual/html_node/The-GNU-Allocator.html
[3] https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=00ce48c;hb=0a8262a#l862



closes odoo/odoo#42323

X-original-commit: 85fe2c6e
Signed-off-by: Christophe Simonis <chs@odoo.com>

In a80775ce, some code was refactored to stop using the confusing
'animation' denomination, as in reality they were just public facing
widgets that did many things, such as loading data based on
data-attributes and other things that were not always animation related.
One instance of the animation_stop_demand event was not renamed in the
_onSnippetWillBeCloned method, which creates some problems, one of which
being that the facebook snippet's iframe wouldn't be destroyed on clone,
but since the animation was started after the clone, this would result
in one facebook page snippet with two iframes with the facebook page,
for a total of 3 instead of 2, and one of these was unconfigurable.

This commit renames the event to restore the proper behavior.

closes odoo/odoo#42311

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

The account.group model has been refactored in
https://github.com/odoo/odoo/commit/a124050511d508f6f1f8a4d4f9dfb2fa1507ad98



Although the filename was correct (.template) and one field was changed
(code_prefix -> code_prefix_start), we don't accept a parent anymore and
we have to provide the chart of account id.

closes odoo/odoo#42302

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

Before this commit, the configuration of the facebook page snippet was
done in a modal window. In an effort to streamline and unify snippet
options, the configuration has been moved into the left panel.

task-2146928

closes odoo/odoo#41104

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

New field to express the profitability percentage of a Sales Order (/SO line).

task-2033253

closes odoo/odoo#39926

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

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