[FIX] *: update documentation links Following the recent reorganisation of the documentation in 12.0+, the majority of the documents have been moved and their old links are no longer valid. Some redirection rules will soon be deployed, but those rules might be dropped in some years and we want the links to still work, which is why we still replace the links to the new ones.

FW-Port of odoo/odoo#70675 (13.0)

closes odoo/odoo#70728

X-original-commit: 85c24961
Related: odoo/enterprise#18283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Original issue:
Create a payment like follow:

Payment type: receive money
Partner type: customer
Destination account: whatever receivable
Amount: define an amount (i.e. 90.00)
On Save, open the draft jounral entry created.
Lower the liquidity or counterpart amount and add a writeoff
Go back to the payment, change the amount and save.
The journal entry writeoff will swap from debit to credit at every
change made to the amount. This occur also when changing currency on the
payment

opw-2475223

Otherwise, this fix is not covering all cases:
inbound with write-off in debit
inbound with write-off in credit
outbound with write-off in debit
outbound with write-off in credit

closes odoo/odoo#70807

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

When using the boxed layout, if the business document has a table, its
first row (after the table head) will have a bottom border and the last
cell in the row has a white background.

To reproduce the error:
(Need timesheet_grid. Use demo data)
1. In Settings > General Settings, Change Document Template:
    - Select the second template
2. In Timesheets, select list view
3. Select several lines
4. Print > Timesheet Entries

Error: In PDF, the first timesheet line has a bottom line and its last
cell has a white background (instead of grey).

The bottom line should only be applied on row in table header. The
background color should also be applied on first row in table body.

OPW-2478311

closes odoo/odoo#70746

X-original-commit: 88a10bdd
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

We have observed that in some circumstances, there is no field to
reflect on a given model.  Avoid an exception in that case.

closes odoo/odoo#70774

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

uuid should be unique even after copying

closes odoo/odoo#65148

Related: odoo/enterprise#15996
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

These changes have been made to be able to add some behaviors in some specific points of the flow when overridden.

Before this commit:

  When there is too much records to post and it's take time more than 15 minutes then server was restarted.
  So scheduler action will do the process with the same records again and again.

After this commit:

  post record in batch of 1000

opw-2451446

closes odoo/odoo#69738

X-original-commit: b87612d6
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: rrt-odoo <rrt-odoo@users.noreply.github.com>

The method that computs what is due and the change of an order is based
on the selected payment line which is wrong, because if you add and
remove a payment line, none will be seleced, that lead to issue in this
case because a change is computed, and it won't match the invoices
because an amount_return is sent to server.

To reproduce you can follow this simply procedure:
    - set rounding half-up to 0.05
    - create a product at 0.98
    - open POS and create an order with the product
    - go to payment screen
    - add cash payment (1€ auto filled)
    - add bank payment (It'll autofill -0.02 not really a problem)
    - remove the bank payment => It'll show 0.02 due (it is caused because of no payment method is selected)
    - Set a customer and check the invoice => unbalanced (0.02 probably because it is set in amount_return of the request)

closes odoo/odoo#70825

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

[FIX] account: bug fix and rewrite query of function _adapt_parent_account_group and _adapt_parent_account_group

before this commit:

_adapt_parent_account_group or _adapt_parent_account_group call with multi-company record then raise singleton error

after this commit:

singleton error is fixed

closes odoo/odoo#69323

Signed-off-by: William André (wan) <wan@odoo.com>

This bug is cause in this PR https://github.com/odoo/odoo/pull/70312



closes odoo/odoo#70810

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

When exporting the tax report's monthly xml with enterprise, the file wasn't accepted by the government in case 0% taxes were used.

Grid 033 is optional, and can be used for custom tax rates. If specified, it MUST always go with grid 403 (giving the tax rate) and 042 (giving the tax amount). In Odoo, we made the choice to use it for 0% taxes, so 403 and 42 will always be present, and always 0.

In community, grids number were missing on the lines' labels, and the codes (used to retrieve the value of each grid when generating the XML) were not correct.

closes odoo/odoo#70754

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

/shrug

closes odoo/odoo#70753

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

The `search` function of the `re` package can return `None` if the
provided string does not match with the provided pattern
(https://docs.python.org/3/library/re.html#re.Pattern.search

).

On the `_parse_youtube_document` function of the `slide.slide` model,
we are directly accessing the capture groups from the returned value
of the `search` function without checking that the returned value is
actually a 'match' object. As a result, an exception can be throw if
there is no match as, in that case, the `search` function will return
`None` and the `group` function will not be defined on `None`.

To avoid throwing an exception, we will check that the returned value
of the `search` function is not `None` before accessing the capture
groups via the `group` function.

LINKS

Task id: 2525007

closes odoo/odoo#70743

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

In case X several recurrences are processed in the same cron execution,
only the last recurring task was created X times, while the other tasks
were not created. There is also a missing id preventing a correct use of
the default stage for the new created task.

closes odoo/odoo#70633

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

Regarding of the `display_default_code` context value, `display_name` is
supposed to return the product code or not, eg:
> product.display_name
> '[FURN_6666] Acoustic Bloc Screens'
> product.with_context(display_default_code=False).display_name
> 'Acoustic Bloc Screens'

But since the context was not considered when accessing this field, it would
always return the cached value, which was set from the first time that field
was read, with the `display_default_code` value used at that time.

tl;dr: `display_name` was ignoring the context once cached.

One of the critical issue was that internal code were displayed on the eshop
cart (not the eshop itself), see `name_short`.

task-2517830

closes odoo/odoo#70727

X-original-commit: b5b4d38a
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

Before this commit, some requests could be sent to the actual IAP
servers during testing. These calls weren't always mocked as many
of these requests are sent in background while performing usual
tasks such as creating a bill.

Now, any call to the function iap_jsonrpc during testing will result
in an AccessError.

closes odoo/odoo#63096

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

closes odoo/odoo#70687

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

When building a domain `(=|!=)` with
a Binary field stored in attachment and
the right part of the domain is not null,
the full binary content is logged, giving
the logs a huge size.

Now, the content of the binary is cropped to
20 chars as it is useless to log more.

opw-2527629

closes odoo/odoo#70699

X-original-commit: d54b30bb
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

On large database with million of channel made by one partner.
When you try to update the email of partner, it take lot of time (CPU time limit).

closes odoo/odoo#70436

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

On large database with million of messages made by one partner.
When you try to update the image of partner, it take lot of time (CPU time limit).

When purchase order line is removed, related stock moves procure method stays as "Advanced" which doesn't allow reservation from stock

closes odoo/odoo#70643

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

The deletion of `account.payment` were slowed down
because of the missing index

```
                                                                                  QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Delete on account_payment  (cost=20.37..44.45 rows=10 width=34) (actual time=0.449..0.450 rows=0 loops=1)
   ->  Nested Loop  (cost=20.37..44.45 rows=10 width=34) (actual time=0.383..0.404 rows=10 loops=1)
         ->  HashAggregate  (cost=19.95..20.05 rows=10 width=32) (actual time=0.378..0.380 rows=10 loops=1)
               Group Key: "ANY_subquery".id
               Batches: 1  Memory Usage: 24kB
               ->  Subquery Scan on "ANY_subquery"  (cost=0.42..19.92 rows=10 width=32) (actual time=0.035..0.371 rows=10 loops=1)
                     ->  Limit  (cost=0.42..19.82 rows=10 width=4) (actual time=0.032..0.365 rows=10 loops=1)
                           ->  Nested Loop  (cost=0.42..186848.76 rows=96312 width=4) (actual time=0.031..0.364 rows=10 loops=1)
                                 ->  Seq Scan on account_payment_pre_backup pay_backup  (cost=0.00..14763.48 rows=277317 width=4) (actual time=0.015..0.086 rows=53 loops=1)
                                       Filter: ((state)::text <> ALL ('{draft,cancelled}'::text[]))
                                       Rows Removed by Filter: 166
                                 ->  Index Scan using account_payment_pkey on account_payment pay  (cost=0.42..0.62 rows=1 width=4) (actual time=0.005..0.005 rows=0 loops=53)
                                       Index Cond: (id = pay_backup.id)
                                       Filter: (move_id IS NULL)
                                       Rows Removed by Filter: 1
         ->  Index Scan using account_payment_pkey on account_payment  (cost=0.42..2.44 rows=1 width=10) (actual time=0.002..0.002 rows=1 loops=10)
               Index Cond: (id = "ANY_subquery".id)
 Planning Time: 0.294 ms
 Trigger for constraint account_move_line_payment_id_fkey: time=1.236 calls=10
 Trigger for constraint account_payment_sale_order_rel_account_payment_id_fkey: time=0.195 calls=10
 Trigger for constraint credit_token_payment_id_fkey: time=1.308 calls=10
 Trigger for constraint payment_transaction_payment_id_fkey: time=0.288 calls=10
 Trigger for constraint account_invoice_payment_rel_payment_id_fkey1: time=0.191 calls=10
 Trigger for constraint account_move_payment_id_fkey: time=6015.799 calls=10
 Trigger for constraint account_payment_account_bank_statement__account_payment_id_fkey: time=0.444 calls=10
 Execution Time: 6019.988 ms
```

upg-12139

closes odoo/odoo#70712

Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

A product with single novariant attribute is normally not shown.

But in the configurator modal it was shown and then added in the product
description when doing exactly the same scenario (add the product) than
without the configurator.

With this changeset, we add is_single attribute and only add a no_create
variant if it is not a single value or a custom value.

opw-2494331

closes odoo/odoo#70680

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

If country is updated on a record inheriting from mail.thread.phone
its sanitized number should be computed again. Indeed without this
trigger it is not computed and may lead to inconsistencies between
phone numbers and sanitized number.

Task ID-2528169

closes odoo/odoo#70684

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

Currently phone_sanitized computation on lead model works only if crm_sms
is installed. Indeed an override of ``_phone_get_number_fields`` is missing.
However ``_sms_get_number_fields`` coming with ``crm_sms`` and its ``sms``
dependency hides the issue as those modules are auto-install. However if
``crm_sms`` is uninstalled phone_sanitized is not correctly computed anymore.

Task ID-2528169
Oversight of odoo/odoo#45315

In database with front end, there are lot of bad query like this:
bad query: UPDATE "website_visitor" SET "timezone"='Europe/Paris',"write_uid"=116,"write_date"=(now() at time zone 'UTC') WHERE id IN (15414)

closes odoo/odoo#70507

Error: Could not serialize access due to concurrent update
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

You can, in a production order, change the quantity done of a stock move
raw and change its initial demand ('To Consume' field) in the same
transaction. This can lead to some issue as changing the quantity done
will update the stock move line and changing the initial demand will
unreserve the stock move thus impacting the stock move lines too.

This commit will split the values to update of a stock in move in case
the two fields have to be updated. First the stock move lines, then the
initial demand.

This commit also remove the default_product_uom_qty in the move_raw_ids
fields. This ensure the onchanges do not create/edit any stock move lines
with some reserved quantity.

opw : 2451298

closes odoo/odoo#69377

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

[FIX] account: Partial revert of https://github.com/odoo/odoo/commit/39fb6b2990e5d6fda0d5f12dbd64d26ef77b9d0c



It seems some ppl are sharing the same bank account accross multiple journals.

issues:
2527148
2527994
2527894
...

closes odoo/odoo#70676

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

During closing a livechat session an error occur :
_get_visitor_leave_message() got an unexpected keyword argument 'speaking_with'
Because argument 'speaking_with' is pass in this method https://github.com/odoo/odoo/blob/14.0/addons/im_livechat/models/mail_channel.py#L182

, it should be operator.

closes odoo/odoo#70630

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

This commit makes few changes in the event tour as
listed below:

 * Remove the step asking user to save the event, as the next step is
   redirecting to the website which already triggers a save
 * Make the tip for website redirection appeaer in edit mode also
 * Fix a typo ("registering" instead of "registrating")
 * Instead of having to go to a specific stage, moving to any stage is
   now enough for going to next step

taskID-2446215

closes odoo/odoo#68235

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

What are the steps to reproduce your issue ?

    1. From the product form, go to the website version, edit it to add tabs
    2. Using studio, add the field "Description for website" to a tab of the notebook
    3. Save, click Edit, go to the tab that has the field

What is currently happening ?

    Traceback:
    form_renderer.js:258 Uncaught (in promise) TypeError: Cannot read property 'querySelector' of undefined
        at Class.setLocalState (form_renderer.js:258)
        at Class.setLocalState (form_editor.js:131)
        at Class.prototype.<computed> [as setLocalState] (class.js:90)
        at view_editor_manager.js:184

What are you expecting to happen ?

    Correctly add product description without tracebacks

Why is this happening ?

    Because the number of tab is not equal to the number of pages

How to fix the bug ?

    Before accessing the element, check if it exists

opw-2378743

closes odoo/odoo#70513

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

The num2words Debian package exists in Debian Buster [0] and Ubuntu
Focal [1].

[0]: https://packages.debian.org/buster/python3-num2words
[1]: https://packages.ubuntu.com/focal/python3-num2words



closes odoo/odoo#70637

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

closes odoo/odoo#70079

Related: odoo/enterprise#18034
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

Currently, none of the classes derived from Interface use `super`. If
it's added, for example by adding this to `SocketInterface`:

```
def __init__(self):
    super().__init__()
```

, a deprecation warning will appear in Python 3.6 and 3.7:

```
2021-04-30 13:14:25,000 24736 WARNING ? py.warnings: /home/pi/odoo/addons/hw_drivers/iot_handlers/interfaces/SocketInterface.py:11: DeprecationWarning: class not set defining 'SocketInterface' as <class 'SocketInterface.py.SocketInterface'>. Was classcell propagated to type.new?
  class SocketInterface(Interface):
```

In Python 3.8 this is no longer a warning and becomes a `RuntimeError`.

The reason this happens is that `InterfaceMetaClass` caches the results
of the `__new__` calls it does in `interfaces`. CPython's data model
specifies that when calling `__new__`, the cell for `__class__` needs to
be passed along to the parent class: https://docs.python.org/3/reference/datamodel.html#creating-the-class-object .

See https://docs.python.org/3/c-api/cell.html for a definition of what
a cell is.

Because of the caching, this doesn't happen when `__new__` is called
multiple times for the same class. In the case of the `SocketInterface`
example, `__new__` is called twice: first when it's imported directly by
`load_iot_handlers` (https://github.com/odoo/odoo/blob/841c016913a87133bf7257c62ae5f6bf7d99e06d/addons/hw_drivers/main.py#L81)
and second when `IngenicoDriver` imports it. The `__class__` cell is
different each time in that case. With the caching present, this means
the second cell isn't propagated correctly, resulting in the warning /
error.

After `load_iot_handlers` has finished, the `Manager`'s `run` method
iterates over `interfaces`, instantiating and starting the loaded
classes. Because of this, simply removing the caching appears to be
sufficient to avoid the issue while keeping the end result the same.

This issue was encountered while forward-porting a V13 PR, which adds a
`super` use to `SocketInterface`. The issue didn't occur in V13, because
the metaclass doesn't have a cache there.

I found a second problem resulting from the caching. I had noticed that
the `socket_devices` dict the `IngenicoDriver` had access to did not
have the same contents as the one the `SocketInterface` was operating
on. This means that whenever you called the `disconnect` function on the
`IngenicoDriver`, which deletes its entry from `socket_devices`, it will
always fail. The bluetooth driver seems to be impacted by the same.

It turns out the reason for that is how downloaded modules get loaded in
`load_iot_handlers`. That logic (using `exec_module`) doesn't actually
import the module, it just executes the code (registering the interfaces
and drivers as a side-effect). This means the module doesn't get cached
in sys.modules. That means that when another module (`IngenicoDriver`)
imports that same module (`SocketInterface`), Python will execute the
entire contents again, in this case effectively replacing socket_devices
with a new dict, which `IngenicoDriver` gets a reference to, while the
`SocketInterface` thread that runs is still using the old reference to
the original dict. Meaning the two are out of sync. See
https://docs.python.org/3/reference/import.html#the-module-cache for
details on how the import caching works.

The reason the classes get out of sync is because the metaclass doesn't
update interfaces when the second actual import happens, so the
`SocketInterface` class that gets instantiated holds a reference to the
old `socket_devices` dict. Removing the caching removes that problem as
well. If there's no caching, both the `SocketInterface` class and
`IngenicoDriver` will hold a reference to the same instance of
`socket_devices`.

This commit was originally part of a larger commit related to an
Ingenico double connection deadlock bugfix in V13, but in V14 most of
the related code has moved to enterprise. When a driver thread is
running, calling `disconnect` on it will delete it from iot_devices. If
the driver thread gets added to iot_devices in the Interface thread
after starting it, this means there is a tiny window of time where
`disconnect` could be called and the thread wouldn't be in iot_devices
yet, resulting in an exception. This change puts the driver thread in
iot_devices before starting it, avoiding that scenario and the need to
check in `disconnect` for that happening.

When we get the values to embed to pdf, these values can be False if
there is no edi attachment on the account_move so try to assign something
to 'values' will fail.

Now there is a check before assignment.

opw-2526280

closes odoo/odoo#70613

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

Create a draft payment with payment type and 0 amount.
Save.

The payment type will be overwritten

opw-2495461

closes odoo/odoo#70603

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

Acronyms:

SRL : receivable lines in the session's account move that balances
the receivable lines in the session's invoices
IRL : receivable lines of the invoices in the pos session

When closing a pos session, a single account move is created to capture
all the transactions, but, invoices are kept (each is an account move).
During the construction of this single account move, SRLs are
reconciled with IRLs.

Prior to this commit, when closing a pos session, SRLs are grouped
by `property_account_receivable_id` of the partners in the invoices.
Because of this, SRLs are blind of the partners that they are linked
to. This causes issues on tracking the 'due' in the partners that are
invoiced using the pos application.

To fix the issue, we now group the SRLs by partner before reconciling
them the the IRLs.

Same concept is employed for receivable lines generated from split
cash payments, we also assigned partner to them if applicable.

closes odoo/odoo#70580

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

Bug
===
1. Create an event which allows track proposal
2. Follow it and subscribe to "New Track"
3. Log in in incognito and submit a proposal

The email is not sent, because it's sent as the public user, which has
no email address set. And so it the 2 system parameters
<mail.catchall.domain> and <mail.default.from> are not set, we can not
know which email address used to send the email.

Note that this bug also occurs if you create a track with a user without
an email address set.

Task 2510181

closes odoo/odoo#69890

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