Activate Google Synchronization, create on OE a recurrent event,
synchronize the calendar, then delete an event of the recursion on GC,
sync again on OE.

The event will be deleted from GC but not from OE after sync.

This appens because of this "rewrite" rule
https://github.com/odoo/odoo/blob/12.0/addons/calendar/models/calendar.py#L918


that occur on event creation from OE, altering the event parameters when
is marked "allday".

When an "allday" event is deleted from GC the unlink is triggered in OE with the
default time "00:00:00". During the creation of the exclusion '
_inverse_dates' will be called altering start and stop datetime but not
recurrent_id_date, so the new record will not match the event generating
the recursion and the exclusion will not occur. The problem require
particular carefulness because when a recurrent event is fetched from
google the '_inverse_dates' is not called, so in that case the default
time is fine.

opw-2060526

closes odoo/odoo#39580

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

Fine-tunning of 937b5c07

Have a multiwebsite setup
have a payment installed for one of the two websites

Make an order on that website and try to pay

Before this commit, the transaction doesn't come back to odoo's
payment success controller
This was because the return url was set to the web base url ICP

After this commit, the payment success page is opened as we took
the request's url as the return url

opw-2080352

closes odoo/odoo#39587

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

Steps to reproduce the bug:
- Let's consider two companies C1 and C2
- Let's consider website W
- Activate multi-company
- Disable common contact book and common catalog
- Switch the superuser in company C2
- Activate pricelist
- Create a public pricelist PL for C1 and available on W
- Set up a pricelist with compute price = formula and  based on = cost
- Go Sales > Configuration > tick Multiple Sales Prices per Product and tick Prices computed from formulas
- Create a portal user PU and set PL on him
- Create a product P with cost = 10$ and publish it on W
- Set up the product valuation as: automated
- Log as PU and go on the shop
- Put P on your cart

Bug:

The price of P was 0$ instead of 10$

opw:2092695

closes odoo/odoo#39589

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

closes odoo/odoo#39603

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Commit https://github.com/odoo/odoo/commit/c3c98e937e575853fe0b25fa6cb3c916e73fc591
introduced a z-index on parallax element to restrict the z-index -1 of
the s_parallax_bg in the snippets... this was however a bad idea as it
also restricts other positioned elements in there (like dropdown menus)
making them go under other elements in the page.

Fortunately, this z-index is in fact not needed at all since the
z-index -1 mentioned above has been removed with another commit:
https://github.com/odoo/odoo/commit/22745668cf66d802899dac526d810eba64b28c4b

However, the z-index -1 was necessary to force the s_parallax_bg under
static elements that go after it... and this was solved in 12.0 by
making those relative elements. See snippet refactoring in 12.0 with
https://github.com/odoo/odoo/commit/4dce6cc98b2b95a00249ac29245305e08f288e6c#diff-a50ffff96791f36c6dbe5c9273135e5aR783

closes odoo/odoo#39599

X-original-commit: https://github.com/odoo/odoo/commit/dc3bf304056d0e1c56724a1ee55a3b8d1c9be7c2


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

It was technically possible that two editors for the same element are
created in the same JS stack execution... and since 13.0 and the
use of native promises, it happens everytime a block is dropped in the
page.

Note: this commit fixes the problem with minimal code but the logic
should be improved in master.

closes odoo/odoo#39593

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

[FIX] stock_account: anglosaxon valuation: don't generate re-reconcile original bill and iterim lines when returning a picking for a purchase with unreconciled interim entries

To reproduce the issue fixed by this commit, on a clean DB with demo data, accounting, inventory, purchase, USD as company currency and aglosaxon accounting activated:

0) Make sure you have two currrency rates set between EUR and USD (we'll call them A and B, B being the most recent one).
1) create a PO in EUR for a product in FIFO automated valuation, validate it
2) receive the product (this will create a stock valuation account.move, using rate B)
3) create the bill in EUR for a date such as it will use rate A instead of B
4) Validate the bill. This will automatically reconcile stock interim entries and create an exchange rate entry
5) Manually unreconcile the stock interim entries and exchange rate difference that were just created
6) Create a return picking for this PO

+> This had the effect of re-reconciling the bill with the stock interim entries, hence re-creating an exchange rate difference entry.

We solve that by simply filtering which kind of invoice we want to reconcile interim entries for depending on the stock move we are creating.

opw:2062040

closes odoo/odoo#39517

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

Be in Right to left

Open a m2o search more, to get onto the list modal
toggle the filters menu

Before this commit, the filters dropdown was almost invisble
and too much on the right anyway

This was because the RTL was not taken into account

After this commit, we anchor the dropdown on the right
(both as in good and as in side) side of its trigger button

Also, when modifying the dropdown, by developping the Custom Filter
we force the repositioning of the dropdown, to take those new elements
into account

It is expected though that after this commit, in RTL, the
dropdown in a modal that has a scrollbar (which is on the left)
will be slightly pushed to the right. It is usable and visible though
Some kind of plumbing using $el.data('offset', fn) from popper.js
is possible, but has been deemed not robust enough

Docs
https://getbootstrap.com/docs/4.0/components/dropdowns/#methods



OPW 2088934

closes odoo/odoo#39353

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

Have two companies A and B, A is the parent company of B.
A and B have fiscal positions set (FPA and FPB respectively). FPB has
autodetect set to True.

Before this commit, when creating a new Vendors Bill in company A, the
fiscal position of the invoice was auto-detected to FPB (from company
B).

Now, only the fiscal positions of the current company can be
auto-detected.

Closes #39085

opw-2091198

closes odoo/odoo#39458

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

Before this commit, when a refund of a salary slip was done, the 'Salary
Computation' lines where recompute from the 'Worked Days & Inputs'
lines. This generates falsely data if the structure or the contract
changes between the salary slip and the refund.

Now, when a refund is done, all the lines are copied from the salary
slip to be coherent with the salary slip.

opw-2081454

closes odoo/odoo#39412

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

The two method valid valid_alternative_icon_text and valid_title_icon
represent ~13% of an install all. Rewriting them in master
with in #36373 is the main reason of the performance improvement.

Those two method logic were broken, because
`xpath += '[not(//*[' + valid_attrs_xpath + '])]'`
will actually search for valid_attrs_xpath from view root,
not from fa- node.

-since this check will only log a warning and so only impact
 bugfix, no impact on user editing views,
-since a new check is added in master with the corresponding fix in views,
-since this check doesn't really test what it is suppose to check,
-since fa accessibility is great, but not critical

->removing those check will slightly speed up build without major impact
on views quality

closes odoo/odoo#39494

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

In the contacts app, you can select 2 partners and merge them.

Before this commit:

    - If a partner was added by a SQL query and not directly on Odoo,
      the create_date will be empty. This causes a crash because the
      merge wizard try to sort the partners by date

After this commit:

    - If a partner do not have a create_date, it will be considered
      as 01/01/1970. The merge wizard will sort the partners by IDs too.

OPW-2091925

closes odoo/odoo#39503

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

[FIX] l10n_es: change fiscal position name

[FIX] l10n_es: name suggested

[CLA] Update CLA with new mails

closes odoo/odoo#39473

X-original-commit: cbfcf710
Signed-off-by: Josse Colpaert <jco@openerp.com>
Co-authored-by: Pedro M. Baeza <pedro.baeza@tecnativa.com>

Activate Google Synchronization, create on GC a recurrent event,
synchronize OE, then delete an event of the recursion on GC, sync again
on OE.

The event will be deleted from GC but not from OE after sync.

The exclusion on OE is not correctly working in that particular case,
fixing require also to "suppress" the attendee to avoid that just
created exclusions would be detected as changes to send in a following
synchronization.

closes odoo/odoo#37884

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

In some case, a browser_js test with login "None" following a browser_js
test with a defined login could result in the second test being executed
with the previous user.

This was caused by a race condition, a request response comming back
to chrome just after browser clear, restoring the old cookie.
(All odoo request have the set_cookie flag set in order to refresh
cookie timeout)

The solution here is to check one more time for cookie in authenticate,
but also to remove HTTPCase session from session_store. This will
only be effective when calling browser_js without login in the same
HTTPCase .

closes odoo/odoo#39424

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

The profiler was too optimistic. If the local variable self was not a
cursor, it assumed it was automatically an Odoo model.
Instead, only do the custom tracer methods when self is an instance of
BaseModel.

Full scenario to reproduce explained at odoo/odoo#39237

In case a method like the default_get of utm.mixing was profiled, the
tracer crashed when evaluating `__bool__(request)`.
The tracer considered self as an Odoo model while it was a werkzeug
instance with its custom __getattr__ that crashed while trying to
retrieve the content of `_name`.

Fixes odoo/odoo#39237

closes odoo/odoo#39349

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

These changes were announced in the new Annex 24 RFM 2019 [1] and define
the new code for  accounts for the northern border zone. This change affects a
part of the CoA because these accounts were changed from the middile to the
end of the group.

[1] https://www.sat.gob.mx/cs/Satellite?blobcol=urldata&blobkey=id&blobtable=MungoBlobs&blobwhere=1461173776384&ssbinary=true



closes odoo/odoo#39478

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

m2ms are internally represented as "6" commands, however in domains
it's possible to compare an m2m value to a list of ids (to
investigate: whether this is an artifact of internal webclient repr or
part of the real contract).

Add a workaround in SSF modifier computation to convert the m2m
command storage to a simple ids list.

A better fix would probably have been to represent the m2m as a list
of ids internally (and only convert on load / save) however it not
completely trivial as it has to be done recursively in order to
properly handle an m2m inside an o2m. So it's a complete change of the
internal data model (which should probably go alongide more
fundamental changes e.g. properly handling parent refs, etc...)

Also add very minor support for widgets (mostly so it's possible to
set widget=many2many on an o2m field).

closes odoo/odoo#39433

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

- Create a POS user for which the corresponding partner has no email
  address.
- Connect to the POS with the created user
- Sell a product which creates a picking (e.g. Customizable Desk)

The picking is created in draft and not validated.

This is due to:

https://github.com/odoo/odoo/blob/6435b27c35faeafca452d26fa7fd50a7fe964029/addons/mail/models/mail_thread.py#L2199



We disable tracking and post the message as `sudo()`.

opw-2091808

closes odoo/odoo#39423

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

Steps to reproduce the bug:
- Install belgian accounting
- Create a tax REC with a fixed amount and affect base of subsequent taxes
- Create an invoice I with a line L
- Set the following taxes on L: REC (first position) and 0% EU G (second position)
- Validate the I
- Check the generated journal entries

Bug:

The account move line for REC didn't have the 0% EU G on the applied taxes field.

opw:2089240

closes odoo/odoo#39323

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

Steps to reproduce the bug:
- Create an event E with max available seats = 1
- Register to E with public user and leave the cart
- In backend, register an attendee for E and confirm it
- Go to the cart, try to update the line with the registration

Bug:

The line was not updated to 0 and so the customer had to buy an unavailable
ticket.

opw:2091720

closes odoo/odoo#39338

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

Before this commit, the calendar searched records on the wrong time ranges
which did not take into account the timezone of the user
It obviously resulted in some records not being there

After this commit, all the relevant records are fetched according to the right
time range in UTC, corresponding to start/end of the week/month/day of the calendar

OPW 2076114

closes odoo/odoo#39240

X-original-commit: 70ed3d54
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

closes odoo/odoo#39335

X-original-commit: 7ae417a9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Ref: https://en.wikipedia.org/wiki/Tanzanian_shilling



opw-2091857

closes odoo/odoo#39271

X-original-commit: 4dbe922a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

closes odoo/odoo#39139

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Old outdated Odoo screenshots, and UI guidelines have no worth in the doc...

Werkzeug 0.15 modified ProxyFix such that by default it only forwards
the REMOTE_ADDR when enabled, whereas before 0.15 it would also
forward scheme and host. This breaks proxied odoo as the base url
becomes incorrect (cf #34412).

Use properly configured ProxyFix when running with werkzeug 0.15, old
configuration otherwise.

Backport of 4057227d which was merged
in master, because many people apparently run 0.15 now.

Closes #35085
closes odoo/odoo#36212

closes odoo/odoo#37709

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

To reproduce this issue, a transaction retry must be forced:
— Put a breakpoint in a line of the function process_bank_statement_line
    in addons/account/models/reconciliation_widget.py;
— Open the bank statement reconciliation;
— Click in validate;
— When the code is in pause;
— Open psql and modify a line of the database that affects the current
    reconciliation, for example you can change the partner_id of the
    table account_bank_statement_line for the line that is modified in
    https://github.com/odoo/odoo/blob/3e2d968c55542426746b287c556b5fb05d59fdcb/addons/account/models/reconciliation_widget.py#L35;


— Continue the process;
— This will generate an 'ERROR: could not serialize access due to
    concurrent update' and a transaction retry.

Before this commit, a KeyError is raised, this occurs because
counterpart_aml_id was deleted from the dictionary in the first passage,
then when in the second passage triggered by the 'retry transaction',
counterpart_aml_id doesn't exist any more in the dictionary.

Now, the data is copied and there is no problem when the 'retry
transaction' is called.

Fixes #23816
opw-2085822

closes odoo/odoo#39314

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

In e-commerce module, when you have a free product and 2 delivery
methods:
    - Free
    - Any delivery method with a fixed price

When you confirm your cart, you have to choose a payment method.

If you select "free delivery" and "wire transfer":

Before this commit:

    - You get an internal server error

After this commit:

    - You are redirected to the wire transfer confirmation

OPW-2083778

closes odoo/odoo#39304

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

- Create a product A with a barcode, UOM as 'Unit(s)' with a BOM
- Create a MO for A with more than one unit, validate
- Print the 'Finished Product Label (PDF)'

A single label is printed for all units, although it is not logical: a
label should be printed for each unit, as already done for the Zebra
labels.

In case the product UOM is 'Unit(s)', we print a label per unit. At the
same time, we remove useless horizontal lines.

opw-2091663

closes odoo/odoo#39247

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

closes odoo/odoo#36149

closes odoo/odoo#39192

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

Some external ids of account.fiscal.position.tax.template were
duplicated

closes odoo/odoo#38843

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

The message was not evaluted

closes odoo/odoo#38578

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

When duplicating maintenance request, the stage should be reset to the
first one (which is +/- what the default does).

Fixes odoo/odoo#38558

closes odoo/odoo#38573

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

Makes it easier for users to match Odoo payments with information
from the Stripe dashboard.

closes odoo/odoo#39136

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

In the leaves app, you can create an allocation request where you can
select a leave type.

Before this commit:

    - The leaves type order is not correct when you have a lot of them.
      You should have your remaining leaves on the top of the list
      and for the leaves who has 0 remaining they should be at the end
      of the list.

      When you click on search more, the order is correct.

After this commit:

    - The leaves type order is correct.

Odony's comment: Leave types are reordered after each search(), based on
some context-dependent, non-stored conditions. The problem is that the
initial search() applies the given *limit*, so the "post-sort" will only
sort a limited number of random result from the initial search,
rather than all types matching the domain.

If you have more than 7 leaves types matching the domain, you have a
chance that the m2o auto-completion on the leave request form will not
suggest the correct leave types, because the post-sort will not even
receive them. So you may not see a leave type for which you have
remaining leaves!

OPW-2089593

closes odoo/odoo#39158

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