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>

Commit https://github.com/odoo/odoo/commit/68d71b8eafa3227269de12ba3c64b9860fbcf63c


introduced a wrong domain
Falsy m2m must be explicited and put outside of the "in [ids]" leaf

This commit corrects it

OPW 2090865
OPW 2091449
OPW 2091778
OPW 2091778

closes odoo/odoo#39208

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

Was comparing b'0x02' and '0x02'

closes odoo/odoo#39206

X-original-commit: 838cb0e8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

closes odoo/odoo#39180

X-original-commit: 25d6e9a6
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

shop page link and popover use the same route which make a write on db
to recompute coupon lines. Can lead to concurent updates if unlucky on
timing.

task-2070507

closes odoo/odoo#38996

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


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

In form views, when the window size is too small, a "More" button
appears and it should contain the overflow buttons.

On all browsers, the "More" dropdown doesn't contain the expected
amount of buttons, so it is shifted on the second line.

Before this commit:

    - The "More" dropdown doesn't contain the expected amount of
      buttons, so it is shifted on the second line.

After this commit:

    - The "More" dropdown contains the expected amount of buttons
      and it is not shifted on the second line anymore.

OPW-2079694

closes odoo/odoo#38853

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

The XML file homepage view record is not supposed to be deleted as it is used
to bootstrap newly created website.

If that view is deleted, everything's fine. But if that view's page is not
found (m2o link broken somehow), then the code would crash.

This would only appear if the user is playing in the backend in technical but
it seems to happen more than it should.

This commit will prevent the code to crash in such a case.

Step to reproduce:
1. Go to settings > technical > views (debug)
2. Find the xml homepage view (with xml_id)
3. Go to its website.page and break the m2o view_id
4. Try to create a new website, it will crash

opw-2081894

closes odoo/odoo#38897

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

Due to commit odoo/odoo@f4031c62f97fa170b74b0d13a0856b7d58ed4da6
it was not more possible to scroll in a grouped kanban.

Steps to reproduce:
* Go to project app
* Select a project with a few numbers of task
* Create as need new task to have more task than visible on the screen
* Try to scroll (BUG)

Note: we also fix the swipe in empty column

opw-2080491

closes odoo/odoo#39103

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

Actually, docker is used to test Linux packages once they are built.
The packaging process is done on the host system where package.py is
run.

Consequences:
    * difficult to reproduce an exact same build on another host
    * changing a Debian/Ubuntu target version means some upgrade steps
      on the build host (mix that with the fact that the host also
      could build old Odoo versions)
    * Fedora rpm package is built on an Ubuntu system (which is not a
      real problem but it could be)

With this commit, the package.py utility is refactored to use Docker
containers to build the Gnu/Linux packages.

closes odoo/odoo#39091

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

Without this patch, if a view defines a `<label for="forbidden_field"/>` anywhere, the web client tries to fetch the field data, but since the user has no access, it gets an error.

Now, if the label targets a forbidden field, it gets removed from the view, as happens with the related field. The client doesn't know of that field's existence and no errors happen.

closes odoo/odoo#38860

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

closes odoo/odoo#39053

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

Purpose
=======

Time to load systray messaging menu is too slow.

Time to load systray messaging menu:
- With 300 direct message channels, it takes at least 1.2 seconds.
- With 300 direct message channels and a dozen of "big" multi-user
  channels (#All, #News, #R&D, etc.), it takes at least 2 seconds.

The RPC 'channel_fetch_preview' is very slow. After some investigating,
it looks like 80% of the time takes place during message_format
postprocess when updating messages based on notifications:

Specification
=============

Now, we avoid to make query for each message.
And for attachment's message, we check attachment access rules and
search object only if the message has an attachment.

closes odoo/odoo#34863

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

closes odoo/odoo#39035

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

Before this commit, the trash icons and "OR" indicator of each filter
was too far and couldn't be seen

Now, both of them are closer to the filter and can be seen in any circumstance.

Task 2073707

closes odoo/odoo#37722

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

Commit 83bb8224 introduced some fixes to make a few test of the
normal stripe module work, but unfortunately introduced a bug in
the process.

The reference we want to find the transaction is *not* contained
in the metadata dict but indeed in the reference param of the whole
response dict. Unfortunately, even the fallback of the get call did
not work - the metadata dict is still there, we just don't use it
anymore...

opw-2080651

closes odoo/odoo#38989

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