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>

* website, website_mass_mailing

Instead of triggering an event on the invisible element when its related
button in the left panel is clicked, the invisible element's options are
now toggled (shown if were hidden and hidden if were shown). To do that
the new 'onTargetShow' and 'onTargetHide' methods are called, and the
appropriate action can be done there.

Those two new methods are also automatically called in other cases:
- When dropped in the page, after onBuild, 'onTargetShow' is called
    for any snippet.
- Before cleanForSave: 'onTargetHide' is called for snippets with the
    'o_snippet_invisible' and 'onTargetShow' is called for the others.

In case the element visibility should be toggled another way (like the
close button of a modal), the option can trigger_up an event named
'snippet_option_visibility_update' with a 'show' parameter so that the
the UI is updated accordingly (and so that the options are hidden if
necessary).

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

Snippet enabling operations and snippet edition operations were mutexed
individually. In fact it simplifies the code and it is probably better
to chain all snippet operations, through an unique mutex.

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

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

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

Commit https://github.com/odoo/odoo/commit/eb0ea8efbe932c140302e9f8da33a839bcd73146
removed the use of the 'rte' and 'rte_inline' without removing the tests
themselves. They apparently cannot work anymore as using routes which
do not exist anymore.

This commit removes the test files.

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

Before this commit, users encountered some difficulties to tap/click
on the "optional columns" dropdown in list views.
This issue only occured on Chrome: rather annoying to use the mobile app.

"width: 10px" was used in inline list view but didn't have any sense
in the other case. Worse still, Chrome miscalculated the size of the
clickable area by a smaller one.
This is due to the fact that we add some padding that exceed 10px.
See:
https://github.com/odoo/enterprise/commit/2f1320557ec67a741201d73a23a9782ec8f9b3bb#



opw-2071605

closes odoo/odoo#42210

X-original-commit: 28b6e9c9
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

Before this -
If we have follwing configuration -
Manufacturing -> Propagate Cancel -> True
Buy -> Propagate Cancel -> True

* BOM of a Car -
	1) Component 1 -> Iron (MTO & Buy)

Now create a SO of product Car and confirm it.
It will create a MO (Car) and then PO (Iron).
Now if PO is cancelled, it will cancel its
move_dest_ids and on change of it MO will be
cancelled but delivery move will remain ongoing.

When action cancel is called on a move raw, it will
check if the production order is also cancelled.
If the MO is cancel, in this case cancel also its
move finished.

Task-2117832

closes odoo/odoo#42209

X-original-commit: 9522e51a
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Access rights
=============

Purpose
-------

Currently, the lowest access right level for Timesheets allows a user
to see the timesheets from all employees. Some companies do not want
to have this information shared.

As we already have three levels of access rights, creating a new one
would be too much. Instead, we are using this opportunity to
clean/simplify the current access right levels.

Specification
-------------

Remove the current access rights and replace them with the following:
- 'See own timesheets' the user can:
    - read/write/create/delete his own timesheets only
    - cannot timesheet on projects whose Visibility is set on
      'Invited employees' if the user is not a follower
    - see the 'My Timesheets' and the 'Timesheet App' menus
- 'See all timesheets' the user can:
    - read/write/create/delete all timesheets
    - cannot see the Timesheets of Projects whose Visibility is set
      on 'Invited employees' if the user is not a follower
    - see the 'My Timesheets' + 'All Timesheets' + 'Timesheet App' +
      'To Validate' menus
    - validate the timesheets of whom he is the 'Timesheet
      Responsible' or the 'Manager'
- 'Administrator' the user can:
    - read/write/create/delete all timesheets
    - see all menus
    - validate the Timesheets of all employees
- Write tests

New Validation Process
======================

Purpose
-------

Currently, timesheets are validated by employees as a whole. However,
as a manager, it is difficult to evaluate the timesheets of an
employee for projects you know nothing about. Therefore, it would make
more sense for a manager to validate the timesheets of his projects
and to leave the rest to the other managers.

In addition, having a date on the employees leaves room for error and
performance issues, so we are introducing a new checkbox at the
timesheet level.

Specification
-------------

Remove the 'Timesheets Validation Date' field on the employee
- replace it with a 'Timesheet Validated' checkbox (hidden field) on
  the timesheet entry
    - By default, this field is set to false
    - Once the manager validates the timesheets, switch the field to
      true
- Filtering on 'Validated' timesheets should display timesheets for
  which 'Timesheet Validated' is true
- Filtering on 'Non-Validated' timesheets should display timesheets
  for which 'Timesheet Validated' is false

Rename the title of the validation menus into:
- To Validate > Last Weeks -> Timesheets from Last Week to Validate
- To Validate > Last Month -> Timesheets from Last Month to Validate

Grid view: display projects on which the user timesheeted in the
past 30 days (group_expand), or the employees who timesheeted in the
past 30 days for the 'To Validate' menus)

Open the 'To Validate' menus on the oldest non-validated timesheet
you can find.

Clicking on 'Validate' should validate all the timesheets displayed
on the screen. List all the elements displayed in the view based on
the group by applied in the 'Validate the timesheets' modal.

When validating timesheets, bypass timesheets that were already
validated in the past in order to avoid performance issues

Timer list
==========

Purpose
-------

Have an overview of the timesheets you need to do during the day.
Easily track time spent on tasks using the timer instead of having to
write down somewhere at what time you started an activity. Allow more
flexibility if an activity if interrupted by another one (so you
don't need to do mental arithmetic to determine how much time the
first activity took substracted by the time spent on the second
activity).

Specification
-------------

- Move the time from fsm to hr_timesheet.
- Add fa-play-circle and fa-stop-circle icons in the 'My Timesheets'
  menu:
    - on the left of the 'Duration' field in the list view
    - on the top right corner of the kanban card in the kanban view
    - on the right of the first column in the grid view
- Display these icons
    - for non-validated timesheets only
    - if the Encoding Unit is Hours
- Clicking on the play button should start and display the timer and
   switch to the stop icon
- Clicking on the stop button should halt and stop displaying the
  timer and switch to the play icon
- While the timer is running, the 'Duration' field should not
  be editable
- Only one timer can run at the same time. If the user clicks on the
  start button of timesheet B while the timer is running for
  timesheet A, timesheet B should start and timesheet A should stop.

Time selection when invoicing
=============================

Purpose
-------

Allow selecting a timeframe to invoice when the user is invoicing on
a periodical basis. For instance, the user invoices each time at the
end of the month. For some reason (he got sick, there was a bank
holiday...), he only invoices of the 4th of the following month.
Now the timesheets that are about to be invoiced include some that
were recorded in the meantime.

Specification
-------------

- Add an 'Invoice timesheets up to mm/dd/yyyy' field on the Invoice
  Creation modal
    - display this field only when creating an Invoice for a Service
      whose Invoicing Policy is on 'Timesheets on tasks'
    - not required
    - Set today's date by default
    - if this field is set, the quantity to invoice should only
      include the not yet invoiced (and validated) timesheets up to
      this date (included)
    - if this field is not set, include all not yet invoiced (and
      validated) timesheets without distinction.
    - Add the following tooltip: Only timesheets not yet invoiced
      (and validated, if applicable) up to this date included will be
      invoiced. If no date is indicated, all timesheets not yet
      invoiced (and validated, if applicable) will be invoiced
      without distinction.

Miscellaneous
=============

Purpose
-------

Small usability improvements.

- Move 'Create SO from Task' to sale_timesheet -> Means Enterprise to
  Community).
- Add the pivot view to the 'All Timesheets' menu
- Add the 'Today' button on the grid view of all menus (see the
  Reporting > Timesheets by Project menu for reference)

closes odoo/odoo#40495

Taskid: 2088586
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Lucas Lefèvre <lul@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>

Following the removing of the vendor and customer field, when we wanted to display customer in the back end, we saw all. We added a default filter when clicking on the menu button that displays only customer with a customer rank higher than 0.
We also increase their customer ranks everytime they make an order in the front end.

closes odoo/odoo#41769

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