* website_event

Commit https://github.com/odoo/odoo/commit/a153ed42a09f8b7f5e0865112eb7d5affc22a353


solved a big problem which was that when an undo/redo is performed, the
whole DOM was reconstructed breaking all the JS relying on the old one.
For example, the latest blog posts which are dynamically loaded in JS
were not removed before saving since the JS relied on the old DOM... and
this broke the page because that dynamic content contained non-valid
XML markup. The solution was to destroy all JS widgets before applying
an undo/redo and rebuilding them all afterwards. Ideally this operation
should be done on the undo recording action but this would have a huge
flickering impact since many DOM would be destroyed each time the user
types text (flickering which is also bad on undo/redo but it is more
acceptable).

The problem now is the following: if a widget, like many, is declared
like this:

```
start: function () {
    this.$el.append(/* Some dynamic content on page loading */);
},
destroy: function () {
    this.$el.find(/* Dynamic content to remove */).remove();
},
```

Then it works in all standard cases: dynamic content is loaded on page
load and is removed when saving the editor. But this happens with the
undo/redo system:

1. The users types text, we record an undo, which is the whole page
   current DOM, containing all the dynamic contents.

2. The users hits CTRL-Z:

    a. We destroy all JS widgets, calling destroy, the dynamic content
       is removed from the page.

    b. We replace the whole DOM with the one that was saved. That one
       contains the dynamic content DOM.

    c. The JS widgets are recreated, calling start... creating the
       dynamic content again.

Result: the dynamic content appears duplicated. On save, depending on
how the destroy was implemented only the last generated content may be
removed or both... but in any case it appears duplicated during edition.

Hopefully, our current stable version do not contain that many dynamic
content so a perfect amelioration of all of this can be found in master.
As a fix, this commit introduces an extra step between (a) and (b):
we remove the dynamic content of the DOM-to-re-apply before applying it.
For this to work, widgets have to mark their dynamic content with the
class 'o_temp_auto_element' when creating it. They also must add the
content they replace on the 'data-temp-auto-element-original-content'
attribute.

closes odoo/odoo#43496

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

partial backport of 88681f8f

opw-2171237

closes odoo/odoo#43471

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

Purpose
=======

Clean the context to get rid of residual default_* keys
that could cause issues afterward during the mail.message
generation. Example: 'default_parent_id' would refer to
the parent_id of the current record that was used during
its creation, but could refer to wrong parent message id,
leading to a traceback in case the related message_id
doesn't exist

closes odoo/odoo#43405

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

Apparently some solutions (e.g. bitnami) deploy odoo using async
workers, and not all pg/psycopg2 features are supported in that mode,
notably COPY FROM (bulk-copying data from a stream to postgres). Work
around this issue by disabling "async mode" as we do the copy (by
resetting the wait callback) then re-enabling it.

While this is not an officially supported run mode, it should Do No
Harm™ for normal operations and could help users and clients.

Of important note: while this fixes an error running in async mode, it
will also prevent the worker from yielding while copy_from is
executing. Hopefully that doesn't take too long (as the entire point
of the copy_from is to be fast) but there you are.

Fixes odoo/odoo#24145

closes odoo/odoo#25794

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Keep the same UOM than the MO.

opw-2169377

closes odoo/odoo#43383

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

to prevent redirecting the user to web.base.url when his request did
come from a different domain we use the domain in given in the http
request to create the redirect urls for the payment providers

fixes https://github.com/odoo/odoo/issues/11638



closes odoo/odoo#43361

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

Do not crash if the commercial partner doesn't have a name.

opw-2158809

closes odoo/odoo#43338

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

If we are:

- not in sudo
- computing a compute field
- using a related_sudo field

we want to keep the env._protected dictionary when we `sudo` to get the
related value, because if we don't we lost the protection of field we
were currently computing.

Original description:

> When a "computed value A" relies on "computed value B" and
> "computed value B" needs a related value (e.g. product.product from
> product.template), then "_compute_related" in api.py will copy the
> cache if the user is not superuser.
>
> The cache is not copying the values in "_protected", causing
> "modified_draft" in fields.py to incorrectly invalidate the cache for
> already computed values which should be protected by their inclusion
> in "_protected".

note: the added test does not fail without this change, it is just a
partial backport of 12.0 to ensure what worked still worked.

opw-2146097
closes #40916
closes #42714

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

We added min-height for `o_form_sheet` in form view with a commit[1] restoring
the views design (after views refactoring).

However, the min-height isn't very useful when form view is opened witin a
modal (FormViewDialog). Especially, when the form view is having only few
fields, the `o_form_sheet` container occupies unnecessary height and looks
a bit ugly.

This commit fixes the issues by setting the min-height to `0` for
`o_form_sheet` container in such cases.

[1] - https://github.com/odoo/odoo/commit/250e716c3a12#diff-01e46b3171a7282967199e5d45fca0e6R15



TaskID: 2150471
PR #41619

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

Issue

    - Install Calendar with demo data
    - Change your timezone to Pacific/Tahiti
    - Check day view on calendar

    Some event disappear

Cause

    Same issue here but for another TZ: OPW-34247

    Cause from JUC:
    "The problem is the initial search_read has a domain to filter the
    events using 00:00 UTC to 23:59 UTC boundaries. Those boundaries are
    not locale aware"

Solution

    Tried on 12.0, it works good. Julien's fix was in 12.0, but there
    is a lot of changes since his commit.

    I backported as much as possible to prevent future TZ issues in
    v11.

    Backported tests are green in local.

closes odoo/odoo#43286

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

- Create the FIFO & Automated products:
  Kit ABC: 2 variants, e.g. Black and White, invoice on delivered qty
  Kit A
  Kit B
  Kit C
- Create the BOM for the variants of Kit ABC, in this order:
  Black: 1 unit of Kit A and 1 unit of Kit B
  White: 1 unit of Kit A and 1 unit of Kit C
- Receive the components
  Kit A: 10 USD
  Kit B: 12 USD
  Kit C: 13 USD
- Create a SO for Kit ABC (Black)
- Validate the picking, create and validate invoice

The COGS is incorrect: the amount is 23 instead of 22.

This happens because the BOM selected is always the first BOM of the
product template instead of the product-specific BOM.

We select the BOM the same way it is done when it is exploded in:

https://github.com/odoo/odoo/blob/95348a5e1dc4e69ce0edaf89de1124fe55ce4ec8/addons/mrp/models/stock_move.py#L161



Note that if the BOM changed between picking creation and invoice
validation, it will fail.

opw-2153629

closes odoo/odoo#43058

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Nicolas Martinelli <nim@odoo.com>

This patch completes what was being fixed incompletely in #42473.

@Tecnativa TT21386 TT21202

closes odoo/odoo#43205

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

It happens that people modify the product on done stock.move.line
(it's not possible without customisation, at least allow to import or
to modify product and lot_id in the same view).

During the write on stock.move.line only the lot,locations,package and
owner are update on the quant. Not the product since it's not suppose to
be modify. It leads to a stock.move.line with a correct information but
a total mess on the quants with a lot updated and the previous product.
Since the product is not modified, the product on the quant and the
product on the lot linked to the same quant are different.

closes odoo/odoo#42608

Task: 2119471
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Backport of commit 9ba3fc4c8767498890f7b5c4126f3bf2017efc97

Usecase to reproduce:
- Set a product with routes: MTO + Buy
- Create and valide a SO
- Cancel the delivery
- Cancel the RFQ linked

-> The delivery will be switch to confirmed state while it should remain
cancel.

It happens because the button_cancel on purchase.order call
_recompute_state on move. _recompute_state modify the state to confirm,
partially_available or available depending the reservation status.
Howver it should never be call on 'draft', 'cancel' or 'done' moves
since it would modify their state.

A fix would be to filter the set of moves in order to exclude moves that
are cancel, done or draft before using _recompute_state. However this is
easy to forget and the issue would be probably redo in the future.

A more stable fix is to add the filter in the _recompute_state directly.

closes odoo/odoo#42484

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

Steps to reproduce:
- install contacts and vat number validation
- setup your company country to "Netherlands"
- go to contacts > add a company > try to add a dutch vat number
 (NL264077921B03)

Previous behavior:
Proper vat numbers are considered unvalid and raise a ValidationError

Current behavior:
Specific check added for dutch vat numbers

Related:
http://kleineondernemer.nl/index.php/nieuw-btw-identificatienummer-vanaf-1-januari-2020-voor-eenmanszaken
https://business.gov.nl/regulation/using-checking-vat-numbers/
http://www.pruefziffernberechnung.de/U/USt-IdNr.shtml



opw-2166380

closes odoo/odoo#42681

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Nicolas Martinelli <nim@odoo.com>

- Create a journal.
- Create a vendor bill on this journal.
=> Odoo allows you to set a starting sequence number for your invoice.

This number must always use the sequence used when posting the invoice.
However, the invoice date was taken instead of the accounting date.

Before this commit, when setting an invoice date at Y and an accounting date at Y - 1,
the edited sequence was the one in Y - 1 but at the one in Y was used at the validation.

closes odoo/odoo#42896

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

The `unsubscribe` feature of mass mailings repose on having a link with
HREF attribute `/unsubscribe_from_list` inside the mail message.

When the mass mailing is sent:

- relative URL are replaced by absolute URL (`/unsubscribe_from_list` is
  replaced by `{system parameter web.base.url}/unsubscribe_from_list`)

- `{system parameter web.base.url}/unsubscribe_from_list` is replaced by
  the real mass mailing link containing info that will be used to
  unsubscribe the user.

But there was an issue in the case of multiple domain, if this scenario
happened:

- system parameter web.base.url is http://domain1
- a user use "Test" button on a mass mailing
- system parameter web.base.url becomes http://domain2


- the mass mailing is sent

The unsubscribe link is broken, this is because the implementation of
"Test Mailing" feature would update the mass mailing with absolute
links, so if the domain change, we the `unsubscribe` link is no longer
found and replaced into the source.

opw-2124890
closes #42373

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

Purpose
=======

Steps to reproduce:

- Log in as admin
- Make demo user 'Leaves Manager' in Settings/Users.
- Log out and log in again as demo
- Go to Leaves/Leaves to approve/Leaves
- Select Pieter Parker's leave request and click 'Approve'.

Current behavior:
Access error occurs due to security restrictions on Analytic Line,
Operation: write

Expected behavior:
The leave request should be approved as the Leaves Manager should have
permission to approve leave.

Closes #25114

closes odoo/odoo#42772

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

Purpose
=======

Steps to reproduce:

Make sure you have multiple companies A, B and C.

- UserA is HR manager but has rights for companies A, B and C.
  And he is allowed to approve the leave request.
- UserB create a leave request in company B
- UserC create a leave request in company C

Odoo CE, If you go to the left menu: "Leaves to Approve" > Leaves, you
can remove all the filters "To Approve" and "My Department Leaves". Now
you see all the leaves.

If you click on the request of UserB you get the error:
(Document type: hr.holidays.status, Operation: read).

Current behavior:
The view "Leaves to Approve" > Leaves (hr.holidays.allocation.tree) allows
to much. You can see all the request over all the companies. And when
you try to open one, you get the error.

Expected behavior:
The view "Leaves to Approve" > Leaves (hr.holidays.allocation.tree). should
only show the request of the current company.

Closes #23162

closes odoo/odoo#42766

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

`run_action_` hooks don't always return a value, in which case
invoking run() over RPC will raise a TypeError (though the call itself
should still succeed).

Somewhat oddly, "standard" hooks (e.g. in mail) generally do
things safely and return a `False`, but the "builtin" hooks (code,
object create and object write) tend to return nothing, and thus break
when invoked over RPC.

Fixes #42268
Closes #42272

closes odoo/odoo#42752

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Closes #21527

closes odoo/odoo#42754

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

Let's assume a list view with a many2one field with enough related
records to have the 'Search More' option. Let's click on it such
that another list view opens in a dialog. Group this list.

Before this rev., it crashed when the user clicked on a group to
open/fold it.

The crash occured because the (toggle_group) event handled by the
list in the dialog wasn't stopped, so it was also handled by the
other list, which had no clue of the group it had to toggle.

Closes #36543

closes odoo/odoo#42602

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Canceling a move creates an activity to the related PO. However mail_activity
creation requires write permission on PO's which is not granted in all
cases. Activity creation being a side effect of the main business flow
it can be sudo-ed.

Allow Inventory Users to cancel Transfers originated from Purchase Orders.
Unless user has Purchase User/Manager permissions he can't cancel transfers
created from Purchase Orders.

closes odoo/odoo#42555

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

Let's assume a many2many_checkboxes widget in a form view with a
dynamic domain (depending on another field in the view). At first
rendering, the widget contains a checkbox for each value matching
the domain.

Before this rev., if the user changed the value of the field used
in the domain, the many2many_checkboxes wasn't redrawn, so it still
displayed the values matching the previous version of the domain.

Closes #38509
Closes #40173

closes odoo/odoo#42564

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>

Issue from rim:

    In runbot 12.3
    - Go to Purchase
    - Create a PO with one product line: qty 1 / unit price 1000
    - Validate the PO and create the Invoice
        => DON'T VALIDATE THE INVOICE YET
    - Go back to the PO, change the unit price to 2000
    - Go back to the invoice, validate it
    ==> the PO is marked as "fully invoiced" because the qty "1 unit"
        is counted as "invoiced"

    => we should not be able to change the price of a line that has
        already been invoiced, even in draft

Cause

    It seems that in all the PO's invoices state, we can edit a PO line.
    No restriction?

Solution

    Set the line price column to read only when they have a linked
    invoice.

OPW-2161477

closes odoo/odoo#42583

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

The correct name for the province is Chubut,

More info [here](https://es.wikipedia.org/wiki/Provincia_del_Chubut

)

closes odoo/odoo#42632

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

Reexport pot and remove unnecessary references to company specific
records (external ids with 1_.. are generated for the company with id
1)

closes odoo/odoo#29886

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

Mastercard has received an additional range of 2-series numbers (range
222100-272099) to add to the 5-series (range 510000-559999) [1]. In
order to support these cards, we need to update the regex of the
`jquery.payment` library.

Note that a more recent version of the library already implements this
[2].

[1] https://www.mastercard.us/en-us/issuers/get-support/2-series-bin-expansion.html
[2] https://github.com/stripe/jquery.payment/blob/67c4e3e7091107a01d0b3f4965693009605cd932/lib/jquery.payment.js#L52



Fixes #35139

closes odoo/odoo#42483

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Before this commit, the corrected test crashed when the current
date was before the arbitrary dates of the test
because the wrong exchange rate was taken

After this commit, the test passes

closes odoo/odoo#42603

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

This reverts commit 404fa816.

The commit acts on some special case. But it seem to break some case
when there is a t-ignore or other directive at that same element.

Reverting because a good solution would need to take
into account t-attr-class and this might not be possible easily.

opw-2122947

closes odoo/odoo#42545

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

A new tax of 10% has been introduced in October 2019 in Japan.
Add this tax and relative tax group, fiscal position, etc.

Conserve the 8% tax as some sale could use it as a reduced tax rate.

closes odoo/odoo#40680

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

If for any reason, any of the modules listed a few lines above is
missing in the database, user wouldn't be able to browse the
website backend panel.

This can happen if an adventurous user deletes an uninstalled
addon, or if some deployment system restricts the addons available
for Odoo.

That's not a very common scenario, but in any case the fix is
quite easy and here it is. It helps also downstream in case some
additional apps are suggested to be installed using this same mechanism.

@Tecnativa TT21202

closes odoo/odoo#42473

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

- Assign demo user to the Inventory / Manager group
- Login with demo user
- Open a picking, put some quantity in pack and validate
- Go to the package
- Unpack

An AccessError is raised because writing on `stock.quant` in not
allowed.

Fixes #42135
opw-2159512

closes odoo/odoo#42406

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Collisions in table names of ORM models with built-in PG structures such
as "attributes", "domains", "routines", "parameters", ... could occur
and render the result of `table_kind` meaningless.

Based on what was done via https://github.com/odoo/odoo/pull/16651

 more
than 2 years ago, it seems relying on our tables being in the 'public'
schema is safe, even though it's only a default from PG. We reuse that
same logic rather than the alternative of excluding
('information_schema', 'pg_catalog', ...), even though it looks safer at
first. If we did the latter we'd have to change the other comparison for
consistency, i.e. more risks.

closes odoo/odoo#41574

Signed-off-by: Denis Vermylen <Icallhimtest@users.noreply.github.com>

Before this commit nothing prevented high concurrency on a threaded http
server to consume too much resources, ending up failing requests either
because the OS is unable to spawn that many threads
(`RuntimeError: can't start new thread`), either because the Odoo db
connection pool is full (`PoolError: The Connection Pool Is Full`).

This commit adds the ODOO_MAX_HTTP_THREADS environment variable which
allows to limit the amount of concurrent socket connections accepted by
a threaded server, implicitly limiting the amount of concurrent threads
running for http requests handling.

Note that if a value has been provided to ODOO_MAX_HTTP_THREADS that cannot
be parsed as an integer, a value will be automatically set to half the
db connection pool size (which defaults to 64). This dynamic value is
chosen because while most requests will borrow only one cursor
concurrently, there are some exceptions where some controllers might
allocate two or more cursors.

closes odoo/odoo#42021

Signed-off-by: Fabien Meghazi <amigrave@users.noreply.github.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#42306

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

closes odoo/odoo#39389

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