Base: seems related fields take only 1 extra query instead of 3

Crm: assignment seems to have been slightly improved. Some randomness still
happens.

Hr Holidays: seems it was further improved beyond space frontier

Test mail: those tests were a bit random, seems random is gone (hopefully)

Test mail full: updated local counters

Test mass mailing: seems we gained one query, updated local counters

closes odoo/odoo#70486

Related: odoo/enterprise#18180
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Steps to reproduce the bug:

- Let's consider a delivery carrier DC with invoice policy = 'real'
- Let's consider a consumable product P with a weight = 1kg and sales price = 10€
- Create a sale order SO with 2 P and add DC as shipping cost
- Process the shipment for 1 P and create a backorder
- Process the second shipment with the last P

Bug:

Two lines L1, L2 with DC were created on SO but only L1 as a price unit and a description.
L2 had a price unit = 0€ and no description.

opw:2520135

closes odoo/odoo#70454

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: simongoffin <sig@odoo.com>

- use real join
- skip useless join on res_users and gamification_challenge
- skip null end_date criteria to compute less reached goal

closes odoo/odoo#69668

Signed-off-by: Christophe Simonis <chs@odoo.com>

Before this commit there would be trackback (TypeError: unsupported operand type(s) for -: 'datetime.datetime' and 'NoneType') when you will try to remove field Start date as we are using the field to compute duration.

With this commit, we compute duration when Both fields are present.

closes odoo/odoo#70466

X-original-commit: f29597fc
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

Disable the link on the forecasted inventory report  graph view, as it leads us to a undesired list view with traceback on opening it.

closes odoo/odoo#59448

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

* IMPACTED VERSIONS

  12.0+

* HOW TO REPRODUCE

locale :  Locale is en_US (or other SUNDAY based)
view:     CRM - My Pipeline - Kanban view
groupBy:  date_deadline:week (Expected closing)
records:  one record with a planned activity, on date_deadline = 2021-05-02 (SUNDAY)
          one record with no planned activity, on date_deadline = 2021-05-09 (SUNDAY)
remark:   don't keep any other record in MAY for better visibility

* PROBLEM

The progressbar of the week containing 2021-05-09 displays information about the record
from the week containing 2021-05-02

* CAUSE

1. PostgreSQL `date_trunc` function follows ISO8601 which essentially means that
  the start of a WEEK is always MONDAY. There is no argument to change this.

2. _read_group_format_result
  https://github.com/odoo/odoo/blob/27da86a138089c1838e4b94f8a6976995b9c1fff/odoo/models.py#L2210-L2219

  - Computes a label for a group of records.
  - Follows the locale for the label of the week, based on a date which is
    always a MONDAY because of `date_trunc`.

3. read_progress_bar
  https://github.com/odoo/odoo/blob/88957afca09662af7eaa19df1e40b3699e45e79e/addons/web/models/models.py#L167-L175



  - Associates a group label to a record.
  - Follows the locale for the label of the week, based on the date of a record
    which can be any day of the week. If the record is related to a SUNDAY and
    SUNDAY is the first day of the week, it would have been in a group with a
    different label in (2.) than in (3.) prior to this change.

* FIX

In 3., before associating a label to a record, we truncate the date to the
ISO start of the period, so that the label is determined for a record in the
same conditions than in 2. The locale is still used to get language-dependent
outputs with babel, but the grouping will always follows ISO8601 (date_trunc).

* TEST

Added a test for this problem case

TASK-ID : 2517848

closes odoo/odoo#70453

X-original-commit: c08f6e3e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Remove the optimization of the `product_tmpl_id` related fields which
needs a upgrade to work without any issues.

This reverts partially the commit
4c627651.

Find a other for the stable to optimise the forecasted report of product
template:
When the `product_tmpl_id` is in the domain of a read_group, it will
be replace by a equivalent clause with `product_id` instead to avoid
any sub-query which didn't help the postgreSQL planner.
The performance decrease but it still acceptable compared that before
the revert fix (test with one template with 256 variants in
a DB with 40K products and 100K moves, 1K locations, etc)
- Revert fix (which need a upgrade): 75 ms
- new fix (no need a upgrade): 130 ms
- without any fixes (before the revert fix): 500 ms (also have a bigger
scale penalty)

closes odoo/odoo#70381

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Since df312153,
the `worksheet_type` default become 'text' instead of PDF. Then,
update the demo operation to show pdf instead of empty text.

task-2523601

closes odoo/odoo#70419

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Have 2 repair records with the same partner_id, ready to be invoiced
In list view select both records and click Action>Create invoices
In the wizard check 'Group by partner invoice address', create invoices.

Separate invoices will be created, but while grouping 1 invoice should
be created joining the 2 repairs

opw-2476539

closes odoo/odoo#70404

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

Display the default name (the one displayed in the kanban view) for followers replacing
the False value for "other address" partners, this way the user won't get
confused, furthermore, this fix won't require the name to be mandatory for this
type of contacts.

Task-2514244

closes odoo/odoo#70391

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

Some aria attributes were missing or incorrectly set on these new
buttons:
- The button "Export All" was missing an `aria-label` attribute
- The button to show/hide optional columns was also missing an
  `aria-label` attribute, and its menu items (checkboxes to show/hide
  columns) were missing a proper role
- Ever since the debug manager was added in frontend on 73327db0,
  the `aria-label` attribute was not being rendered correctly on the
  button to open developer tools

closes odoo/odoo#70390

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

After the pos owl refactoring, the feature that closes pos from other
browser tabs was removed. Having multiple open pos for the same session
in the same browser session may cause issues when syncing orders because
the tabs share the same localStorage, and the localStorage is the source
of data when syncing orders to the backend.

closes odoo/odoo#70403

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

When the user creates a new account analytic line, he should not be able
to create a new journal item.

To reproduce the error:
(Use demo data)
1. In Settings, enable "Analytic Accounting"
2. Accounting > Configuration > Analytic Accounts > Administrative >
Cost/Revenue
3. Create a new one
4. Click on "Journal Item" list

Error: the list contains the "Create and Edit..." option. Such an action
should not be possible.

OPW-2481197

closes #69881

closes odoo/odoo#70380

X-original-commit: f3ef533ed18c996f7f87c9596135e450479a8c19
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

In 13.0 and above, when looking at a quiz that was completed while not published, it would incorrectly show 2 XP awarded, when 0 XP should be awarded.
With this commit, we show instead the correct 0 XP awarded.
opw-2480343

closes odoo/odoo#70333

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

ALIAS_WRITEABLE_FIELDS is used to write alias fields with sudo

Steps to reproduce:

1. Create a user
1.1. Give rights Services -> Project-> Administartor
1.2. Not given rights Administration-> administartor
2. Project app -> open any project -> Action -> duplicate -> it give validation error.

---

opw-2506566

closes odoo/odoo#70315

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

Have in a purchase order a first row with unit price 0
Export the PO adding unit price in the list of fields to export
The unit price is not reported

This occur because the first line of the order lines is meld with the
purchase order line but in the process the 0.0 values is discarded

opw-2510917

closes odoo/odoo#70355

X-original-commit: 242bf502
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>

When embedding to pdf, the name of the attached file should be 'factur-x.xml' (official specifications, section 6.2)

closes odoo/odoo#70293

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

Since the payment refactoring, the structured reference of a payment is stored in its ref field, not payment_reference like for invoices. This caused payments never to be matched with highest priorities, as payment_reference_flag was always false, and only communication_flag could match.

To reproduce:

- Have a reconcile model with match_total_amount=False.
- Create a statement line with communication a1b2c3 for 1000
- Create 3 payments:
> 500, with memo a1b2c3
> 500, with memo a1b2c3 (so, the same one)
> 500, with memo d1e2f3
- Open the reconciliation widget for your statement line

===> The 3 payments are matched, while only the two first ones should have been, as they were exact matches for the communication, and should hence have received higher priority.

closes odoo/odoo#70277

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

Steps to reproduce:

        - Create an SO for a prepaid service in company A and confirm it
        - Create a project and a task in company B and select the customer linked to the SO you previously created
        - Unselect company A from the multi-company widget; only display the records from company B
        - Timesheet on the task you previously created

Observed behavior:

        - The SOL set by default belongs to company A, thus generating an access right error when trying to timesheet on the task

Expected behavior:

        - The SOL set by default should belong to the same company as the task

task-2515259

closes odoo/odoo#69783

Related: odoo/enterprise#17921
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Steps to reproduce the bug:

- Let's consider an employee E that doesn't work on Monday morning
- Create a half day leave request LR for E on a Monday afternoon
- Save

Bug:

The duration of LR was counted as one day instead of 0.5

opw:2491784

closes odoo/odoo#68977

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

Feedback received: change the name from 'Argentinean Website' to 'Argentinean eCommerce'  in order to stay consistent with the functional name of stadand Apps

closes odoo/odoo#69959

Signed-off-by: Josse Colpaert <jco@openerp.com>

The only purpose of the module `test_documentation_examples` is to test
a few of the code examples shown in the developer documentation.

As de86b3fb79e removes the documentation sources from the repository,
the test module is removed as well.

DOC PR: https://github.com/odoo/documentation-user/pull/945



task-2352371

closes odoo/odoo#70178

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Antoine Vandevenne <anv@odoo.com>

In odoo/documentation-user#945, the developer documentation is merged
with the user documentation in a single repository and build config.

This commit then removes source files for the developer documentation
from the odoo/odoo repository.

DOC PR: https://github.com/odoo/documentation-user/pull/945



task-2351938
task-2352371
task-2205684
task-2352544

Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Antoine Vandevenne <anv@odoo.com>

When adding a product to a repair order, the module automatically adds
all product's taxes, even if some taxes belong to other companies.

To reproduce the error
(Need 2 companies C01 and C02. Let C01 be the current company)
1. Create a product P
    - Must have a tax T_C01
2. Switch to C02
3. Edit P
    - Add a tax T_C02
4. Activate C01
5. Create a Repair Order
    - Add a customer
    - Add a line with product P

Error: Both T_C01 and T_C02 are added. However, since C02 is the current
company, T_C01 should not be added.

(Similar issue possible with `repair.fee`)

OPW-2486791
closes #68079

closes odoo/odoo#70319

X-original-commit: 6b93d5aa
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

What are the steps to reproduce your issue ?

    1. Create a record and add two attachments
    2. Navigate quickly between these attachments

What is currently happening ?

    Traceback
    TypeError: Cannot read property 'complete' of undefined
        at AttachmentViewer._handleImageLoad (https://www.odoo.com/mail/static/src/components/attachment_viewer/attachment_viewer.js:163:20

)

opw-2521901

closes odoo/odoo#70309

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Updating a completed survey will raise an error with a traceback.

To reproduce the error:
(Use demo data)
1. Survey > Participations
2. Select a completed form
3. Change one answer, Save

Error: A traceback appears "[...] ValueError: Computing score requires a
question in arguments."

Here is an extract from the method concerned:
```python
@api.model
def _get_answer_score_values(self, vals, compute_speed_score=True):
    """
        [...]
    """
    user_input_id = vals.get('user_input_id')
    answer_type = vals.get('answer_type')
    question_id = vals.get('question_id')
    if not question_id:
        raise ValueError(_('Computing score requires a question in
arguments.'))
```
This method needs some information to work properly.

OPW-2488974

closes odoo/odoo#69842

Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

- Fix tends to prevent precision overflow in forecasted report

Current behavior before PR:
- If there are 2 units in stock and product_uom_qty is set to 0.66 the free_stock will be equal to 1.3399999999999999

Desired behavior after PR is merged:
- If there are 2 units in stock and product_uom_qty is set to 0.66 the free_stock should be equal to 1.34

opw-2425473
opw-2459650
opw-2448443
opw-2446985
opw-2440853
opw-2464507

closes odoo/odoo#70287

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

Description of the issue/feature this PR addresses and current behavior before PR:
There is a discrepancy in the wording of the error message provided. The error reads that an 'internal user' is linked but really its a 'portal user.'.

Desired behavior after PR is merged:
The wording of the error is clearer, and it now says 'portal user' instead of 'internal user'.

OPW: 2498139

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#69925

X-original-commit: cdd94cdd
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Kamen Zhekov <kzhekov@users.noreply.github.com>

In eg. 13.0 when refreshing sales analysis action of a product, we would
get an error because we have a single active_ids which is not expected
by the code.

With this commit, we use .toString() on the jQuery BBQ parsed active_ids
as it was done before 32b8cec5 refactoring (january 2018).

The added test with the fix fails with an error:

  TypeError: state.active_ids.split is not a function
  at Class.loadState (/web/static/src/js/chrome/action_manager_act_window.js)

opw-2471982

closes odoo/odoo#70279

X-original-commit: bf9a985f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: pvh-odoo <SwagSamaSempai@users.noreply.github.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>

This "depends context" was missing fields and the compute of the stock qty's were not correct in several cases.
We add the same as the fields "force_company".

closes odoo/odoo#70268

X-original-commit: d6bd78e5
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Before this commit, User can select Cancelled MO before selecting Product.
but it is already blocking since we already have constrains to not allow ubnuilding
Cancelled MO.

With this commit, We are always showing Done MO.

closes odoo/odoo#70214

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

The button plan of in the manufacturing order tree view doesn't
confirm correctly the draft MO selected (but only the related moves).

task-2479111

closes odoo/odoo#69409

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Before this commit, Creating Unbuild order using
 Unbuild Button was resetting Bom as it was calling
`_onchange_product_id` after setting `mo_id` which was
resetting Bom on Unbuild order.

To Fix Issue, We setting `default_product_id` so It would not
reset `bom_id` when `_onchange_product_id` is called.

Fixes: #70216
Odoo Ticket: 2521788

closes odoo/odoo#70218

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

Before this commit, the routing map generated and used would be the one from
the website the request is performed, instead of the one from the `fw` website
ID which will be the one we redirect the user to.

This issue was introduced with the routing map by website, be8fc229 and is
restricted to a single case: a publisher using the website switcher, and it
won't happen on next page naviguation/refresh as the `fw` website id will be
the same as the current website's ID. Thus there won't be any routing map
mismatch.

Step to reproduce:
  - Create a page on website 2, set it as homepage
  - Naviguate to website 1 on '/' url
  - Naviguate to website 2 on '/' url
This will raise a werkzeug error about `EndPoint not iterable`.

----- Technical analysis ------

This is the current flow:
1. `_dispatch()` is setting `website_routing` to `get_current_website()` -> 2
2. `_dispatch()` is calling `_match()`
3. `_match()` is calling `routing_map()` with key = `website_routing`, which
   was set to 2 in step 1.
4. `routing_map()` is calling `_generate_routing_rules()` which generate the
   rules based on `website_routing`, which was set to 2 in step 1.
5. `_dispatch()` authenticate the user by calling `_authenticate()`
6. `_dispatch()` is calling `_add_dispatch_parameter()`, where URL param `fw`
   is forced in session, so `get_current_website()` now return the correct
   `website_id` -> 1

The issue: in order to handle the `fw` URL parameter (step 6.), we need to
check the rights to ensure we can allow the website switch.
To check rights, user need to be authenticated (step 5.), which is done after
generating the routing map (2. & 3. & 4.).
The routing map is generated based on the current website (step 1.)

Step 6 depends of steps 5 which depends of steps 2/3/4 which depend of step 1,
but step 1 should depend of step 6, which is an impossible cycle.

closes odoo/odoo#70278

X-original-commit: 878e28f9
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

- Create an invoice with an empty fiscal position
- Create a line with a product having 100.0 as sale price and 21.0% price-included tax
=> price_unit equals 99.99

This is because 100 / 1.21 ~= 82.64 but 82.64 * 1.21 ~= 99.99 != 100.0.
The bug only appears when managing a fiscal position because the code is trying to adapt the product price_unit to the newly computed taxes.

closes odoo/odoo#69836

X-original-commit: e2247a86
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

When changing the product price precision, this can lead to incorrect
stock valuations.

To reproduce the error:
(Enable debug mode)
1. Go to Settings > Technical > Database Strucutre > Decimal Accuracy
2. Edit Product Price:
    - Digits: 4
3. Create a Product Category PC:
    - Costing Method: FIFO
4. Create a Product P:
    - Product Type: Storable Product
    - Product Category: PC
5. Create a RfQ with product P:
    - Quantity: 1000
    - Unit Price: 0.035
6. Confirm Order, Receive Products, Validate
7. Click on Valuation

Error: The total value is equal to $40 instead of $35. The calculation
was done after rounding the unit price: $0.035 becomes $0.04, then
1000*0.04=$40.

When confirming the RfQ, a stock move is created. To do so, the method
`_get_stock_move_price_unit` is called. When validating the delivery, it
recomputes the unit price thanks to method `_get_price_unit`. In both
situation, and if the line has taxes, the method `compute_all` is called
like this:
```python
price_unit = line.taxes_id.with_context(round=False).compute_all(price_unit,
	currency=line.order_id.currency_id, quantity=1.0)['total_void']
```
But here is the problem. In this method, total amount is computed with
this line:
```python
base = currency.round(price_unit * quantity)
```
However, `quantity` is equal to 1 and the multiplication is rounded
using the currency precision. As a result, `base` is equal to $0.04.
Then, all computations will use this value and will be incorrect.

This fix applies the real quantity so `base` will have the correct
value:
```
base = currency.round(price_unit * quantity)
     = currency.round(0.035 * 1000)
     = 35
```

OPW-2472192

closes odoo/odoo#70080

X-original-commit: a57dc071
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Added a check to make sure that we do not set a timeout to update the
option panel when said option panel is already open.
This could sometimes occur which could cause all openned select to close
and could fail some tests if said events happened in the middle of
selecting an option.

task-2502297

closes odoo/odoo#69119

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

Previously :
Once a user enabled the cookie bar, it prevented him from dropping
snippets in the main area of the page because the focus was on
the cookie bar. Dropping snippets there has a confusing behavior and
might make the user think the editor is broken.

Reason :
The cookie bar has an oe_structure class and takes over the body
if it's not hidden or dismissed. The oe_structure allows to drop
snippets.

Fix :
Hiding the cookie bar when user enters edit mode to avoid dropping
snippets in it by mistake.

task-2477430

closes odoo/odoo#68938

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

Before this update if you would update the module the default livechat details would be reset.
By wrapping it in a no-update they're not updated with a module update.

closes odoo/odoo#70006

X-original-commit: 45c330c1
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>