As Fedora 32 was the current release when Odoo 14.0 was released, this
should be the supported version.

Also, a few  old libs were still in mentioned in the packaging files.
They flew under the radar because they never broke the packaging.
This is not the case anymore, those libs disappeared from the Fedora
repos.

It seems that pyparsing is not used anymore since 5a1c06a1 and thus can
be safely removed from `requirements.txt` too.

pychart is not used anymore since 3425752e.

While at it, remove mix of tabs and spaces in package.dffedora, also add
missing packages to avoid installation at test time.

Now that I started down the slippery slope, also removed some `-dev`
packages in package.dfsrc as wheel's are available.

Finally, the rpm install script now detects the python ABI version in
order to avoid update this file at each ABI change in Fedora.

Fixes #63719

closes odoo/odoo#65224

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

When the suspense account is not reconcilable, 'suspense_lines.reconciled' always gives 'False' leading to a not reconciled statement line.

closes odoo/odoo#65211

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

closes odoo/odoo#64972

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

closes odoo/odoo#64810

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

With commit[1], we introduced a feature that from the sales team, we can
see the overdue opportunities for a particual teams. However, the filter
that we use for related action which is supposed to show overdue opportunities
is not not added, and the filtration is not working as expected, showing us
all the opportunites for a team.

This commit fixes the issue by adding the invisible filter with proper
domain set within opportunities' search view and thus enables us to
filter overdue opportunites.

commit[1] - https://github.com/odoo/odoo/commit/1da63f0ab0fb4212bee46f960c6bbe8ca9251cac



TaskID : 2323612

closes odoo/odoo#65248

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

Steps:
- Go to Settings > Companies > Manage Companies
- Create a company (1) with a different currency than the one you're in
- Go to inventory > Products > Products > Create a product (2)
  - Storable Product
  - Cost: 10
- Click Update Quantity
- Create a new quantity line with 1 in On Hand Quantity
- Switch to company (1)
- Go to Inventory > Products > Products > Edit product (2)
  - Storable Product
  - Cost: 15
- Click Update Quantity
- Create a new quantity line with 1 in On Hand Quantity
- Go back to the product
- Click the "Forecasted" smart button

Bug:
Traceback here:
https://github.com/odoo/odoo/blob/47bfdf0592a5dd93870ca1a9da326351d70087bb/addons/stock_account/report/report_stock_forecasted.py#L17


ValueError: Expected singleton: res.currency(2, 1)

Explanation:
The amount is the sum of the `stock.valuation.layer`s of a product
across all companies and these companies may have different currencies.

This commit scopes the computation of the amount inside the company of
the current warehouse.

Also the `stock.quant` values displayed in the "On Hand" report are not
correct for the other companies when displaying their data by selecting
all the checkboxes in the global company dropdown.
This commit also fixes the amounts in the On Hand view by using the
standard price per company and attributing the correct currency to the
`stock.quant`.

opw:2444593

closes odoo/odoo#64942

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

What are the steps to reproduce your issue ?

    1. Install project
    2. Open any project
    3. Switch to list view and display by Stage
    4. Open categoryA and select some records
    5. Open CategoryB

What is currently happening ?

    The button create is not displayed

What are you expecting to happen ?

    Don't hide create button

opw-2423701

closes odoo/odoo#64136

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

By default, the `ls` command has a width limit. Everything after this
limit will be split on a second line.

This happened when listing the modules present on the Iot Box in v12.
The list of modules was split accross two lines, the modules on the
second line were then not loaded when starting the Odoo service.

closes odoo/odoo#65226

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

Before this commit the Dynamic Products snippet was displaying a message
box instead of its content until its template and product category were
selected.

After this commit the Dynamic Products snippet is automatically
configured on drop with the first available template and the first
available product category. The message box only appears if no product
category exists yet. Also an "All Products" category was added as first
element of the list to make the snippet usable before categories are
defined.

task-2439295
https://github.com/odoo/odoo/pull/64982



closes odoo/odoo#64982

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

Before this commit dynamic snippet and dynamic carousel were always
available. To reduce the number of available snippets for new users it
was decided to make these two snippets available only in debug mode.

After this commit dynamic snippet and dynamic carousel are available
only in debug mode.

task-2446024
https://github.com/odoo/odoo/pull/64982

This is the javascript equivalent of `_("Foo %s" % bar)`
https://www.odoo.com/documentation/master/reference/translations.html#variables



closes odoo/odoo#65004

Related: odoo/enterprise#15936
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Since the issue of the synchronisation stuck at point_of_sale a few
weeks ago, it appears older translations were never synchronised.
Forcing a tx pull -f on some modules

This fixes potential problems with the caches we encountered
on certain runbot tests for l10n_pe_edi

closes odoo/odoo#63337

Related: odoo/enterprise#15297
Signed-off-by: Josse Colpaert <jco@openerp.com>

- Some errors will never get fixed until user intervention, it doesn't make sense to run the CRON when there is such error.
+ some small improvements and esthetic changes
- When we are in a CRON, we need to commit the changes between each call to web-service to avoid loss of data.
- Small refactor of edi.document prepare_jobs and process_jobs
- Added an arbitrary key to create the batches.

The name of your first customer invoice is a configuration that
determines the next ones.  The problem before is that when you
confirmed a first invoice, you could not alter its document number
anymore.  With this commit, as long as it is the first invoice,
you can still change the document number when you reset to draft.

Office Outlook doesn't take into account the [style] attribute, and it
doesn't manage width/height in percent value.

This commit set width/heigth attribute in pixels and also always set the
width/height in style attribute (keeping them in the original unit and
setting them to auto if not present).

This is a reintroduction of 2015 commit bdf58adb

opw-2447756

closes odoo/odoo#65212

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

Issue

	- Install "Contacts" and "Studio" modules
	- Go to "Contacts" and switch to Studio
	- Go to "Reports" tab
	- Create a new report
	- Select "External" layout

	Header and footer are missing on report.

Cause

	Header is displayed if 'company' has a value.
	However, here, we only check if 'company_id' is available
	in current record fields, not checking if also set.

Solution

	Check that 'company_id' is set on current record, else,
	fallback on 'res_company'.

opw-2443234

closes odoo/odoo#65202

X-original-commit: 7c451004
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>

Before this commit, dropzones were created around invisible elements
(e.g. the snippet popup). So we had 2 dropzones instead of one at some
locations.

After this commit, we avoid creating dropzones around elements that
must not have dropzones.

task-2312878

closes odoo/odoo#65198

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

- added code to DE account.tax.report.lines records
- generic Kz generation (based on code)
- support for quarter period
- added tax nr for de companies
- better xml generation

Backport of https://github.com/odoo/odoo/pull/56075/



closes odoo/odoo#65165

X-original-commit: 1b57cf25
Related: odoo/enterprise#15991
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>

Create a product with variants attributes that NEVER create variants.
Configure Variants to add some extra-prices to some variants.
In POS settings activate "Product Configurator" and
"Advanced Pricelists", add the public pricelist and one that applies 5% to
the product.

Open a session and select the product created (say price = 1$)
Select the attributes, the extra-price is added to the product (say the
total price now is 2$).
Change pricelist from public to 5% and the order line will show our
product = 0.95, not taking the extra-prices into account (so not 1.9,
i.e. 5% of the 2$ that were formerly displayed)

opw-2439445

closes odoo/odoo#64861

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

Steps to reproduce the bug:

- Go to Accounting (module)> Accounting (menu) > Journal Entries
- Create a new account move M
- Remove the default journal

Bug:

Impossible to set a journal

opw:2445553

closes odoo/odoo#65144

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

Follow-up of 13a45447

Where we fixed the portal *list* of opportunities but did not notice that the
associated *form* also had the same issue.

To recap the issue:

When you remove the 'company_id' on a crm.lead, you also remove the computed
'company_currency'.
When trying to view this kind of leads in the website_crm_partner_assign portal
form page, it would raise an error while trying to display the planned_revenue
in the missing currency.

Now, we display the number without any currency sign, which is a "best effort"
solution, just the same as on the crm.lead form view.
So it will look like "9000 at 47%" instead of "$9000 at 47%".

Task-2444539

closes odoo/odoo#65141

X-original-commit: 2fe4d3e7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>

Let's assume the following situation: in a form view, there is a
one2many field A displayed as a list (non editable). In the list,
there is another one2many field B displayed with no widget (it
basically displays "X records"). In A's form view, B is also
displayed, but this time as a list.

There is an onchange on the main form view that adds a line in A,
(and simply sets B to [[5]], i.e. 'No record').

Before this commit, if the user opened the newly added sub record in
A, and clicked on 'Add a line' of B, it crashed.

The cause of the crash was that the wrong viewType was used to
create the new (default) record in B: it used the original
viewType, which was undefined (B is displayed with no widget in
A's list). With this commit, we use the viewType of B that is used
to edit it, in this case 'list'.

In the slighlty different scenario where B is displayed with
widget many2many_tags in A's list, there were no crash, but wrong
fieldNames were sent to the 'default_get' RPC. As a consequence,
default values for fields in B's list were potentially not loaded.

opw-2422806
closes #64793

closes odoo/odoo#65157

Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>

When Odoo is started in worker mode with Python 3.8.5, and
gevent/greenlet installed from requirements, the following error message
is thrown:

`RuntimeWarning: greenlet.greenlet size changed, may indicate binary
incompatibility`

As a gevent developper stated [1] that gevent 1.5 is not compatible with
Python 3.8, this commit bumps the version to 20.9.0 (current version for
the next Debian and Ubuntu releases [2] [3])

This commit should not impact those who use the Debian/Ubuntu packages
of gevent and greenlet. The error does not appear with those versions.

In Ubuntu Focal, the packaged version is 1.4.0 [4] but the problem was
not reported with this version and python 3.8.

For reference, it was bumped to 1.5.0 for Python 3.7 in [5].
And greenlet was bumped too for issues with Python 3.8 and 3.9 in [6].

As a result, the requirements for greenlet/gevents gains even more
complexity and should be cleaned when python 3.6 support will be
dropped.

[1] https://github.com/gevent/gevent/issues/1260
[2] https://packages.debian.org/bullseye/python3-gevent
[3] https://packages.ubuntu.com/hirsute/python3-gevent
[4] https://packages.ubuntu.com/focal/python3-gevent


[5] odoo/odoo@bb0b32bd1a3fc0c047d0787b10e8c1c8d696daa5
[6] odoo/odoo/@648635de

Fixes #64106

closes odoo/odoo#65012

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

This should be a smarter and properly reliable version of #42071: in
that, the runner requests a port, closes it, and gives the port to
Chrome. However this apparently turns out to be less reliable than
hoped for and the port we just released can immediately be picked up
by somebody else (the original PR assumed the allocation of ephemeral
ports would be random or FIFO but that may not be the case, especially
inside containers).

This uses the same technique of requesting port 0 so the OS allocates
one, but it's Chrome requesting & immediately connecting so there
should be no race condition possible, and we keep the property that as
long as ephemeral ports are available Chrome will be able to open one
without conflicts or overlaps.

This leaves the issue of *retrieving* the port chrome got. Thankfully
it turns out we use a custom user-data-dir in which case Chrome writes
the port it got to `$DATA_DIR/DevToolsActivePort`[0]. Despite the
file's name it *also* contains the path for the devtools endpoint so
we need to only read the first line (rather than be able to read and
intify the entire thing).

Wait up to 10s before giving up entirely, and wait 100ms between each
check for the file's existence: on my machine without significant load
the file appears after 80 to 150ms, waiting up to 90ms seems ok (it's
not like we're in a super hurry as tours tend to be pretty long).

Other paths explored before moc used his eyes and brain and found out
about DevToolsActivePort:

* Chrome prints ws URL on the stderr, however because we don't know
  how much garbage Chrome might send there we need to send it to a
  continuous sink otherwise Chrome *might* end up blocking on its
  stderr because we're not reading from it. This turns out to be a bit
  of a mess of processes or additional threads.
* xdo suggested we check what ports Chrome listens on using something
  like netstat/ss (turns out `psutil` has support for that OOTB),
  which worked great except on WSL (where it didn't work at all), and
  the future-proofness was a bit questionable as Chrome might add
  other servers in the future.
* fme suggested using socket activation support[1] and passing in the
  port we'd opened without closing it, which would really have been
  ideal, however it turns out it was removed a few months later when
  chrome added pipes support[2], which was a pain to realize as chrome
  doesn't exactly do any useful error reporting (so unknown options
  just disappear into a void to be never seen or heard of ever).
* And while the pipes system[3] has *serious* positive attributes
  (even lower initialization overhead, we could remove the websocket
  dependency, also avoids wasting sockets though that's not too much
  of an issue here) it would require rewriting a lot more than just
  the initialization as it uses its own logical protocol
  (NUL-terminated JSON). TBF most of the messaging stuff is properly
  contained into just a few `_websocket` methods but still...

[0] https://bugs.chromium.org/p/chromium/issues/detail?id=624837#c4
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=624837
[2] https://chromium-review.googlesource.com/c/chromium/src/+/954405/3#message-ab7415a7db7b94787300d987216e9ce60db47bc2
[3] https://chromium-review.googlesource.com/c/chromium/src/+/954405/3



opw-2378464

Replaces #64758

closes odoo/odoo#64844

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Xavier Dollé <xdo@odoo.com>
Co-authored-by: Christophe Monniez <moc@odoo.com>

Issue

	- Install "Accounting" module
	- Ensure there is more then 20 journals ( or
	  must do a zoom-in on the browser)
	- Go to Accounting -> Reporting -> Profit and Loss
	- Click on "Journals" filter

	Not all journals are displayed.

Cause

	No scroll or max-height set on dropdown.

Solution

	Set a max-height and an overflow:auto on `.dropdown-menu`
	and `o_dropdown_menu` css classes.

opw-2430101

closes odoo/odoo#64873

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

Before this commit, when you dropped a snippet using the move button
in a modal. The modal closed after the drop.

This commit allows to define an element in which to destroy the
editors.

Part of https://github.com/odoo/odoo/pull/61998


task-2312878

closes odoo/odoo#61998

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

Before this commit, it was not possible to scroll a popup with a
dragged snippet.

Part of https://github.com/odoo/odoo/pull/61998
task-2312878

Before this commit, open invisible elements were not closed before
being deleted. This created issues like the 'modal-open' class wich
was not removed from the body when removing a modal.

Part of https://github.com/odoo/odoo/pull/61998
task-2312878

When a modal is open, allow the drop of a snippet only in this
modal.

Part of https://github.com/odoo/odoo/pull/61998
task-2312878

Before this commit, when scrolling a snippet popup, the overlay was
not updating its position.

So now, we use addEventListener instead of jQuery for the scroll event
on the scrolling element because we need the 'capture' parameter.
Setting this capture parameter to true allows us to take advantage of
event bubbling for events that otherwise don’t support it.

Part of https://github.com/odoo/odoo/pull/61998


task-2312878

Co-authored-by: Samuel Degueldre <sad@odoo.com>

- The modal content of the popup snippet had a maximum height of 100%
because of a global rule on modals. But, here, the scrollable element
is not the modal so we dont want this rule.

- For the popup to be scrolled correctly we also had to remove the
rule that adds a fixed 100% height on modal-dialog and we added a
min-height of 100% to correctly display the popup in the middle
position.

Part of https://github.com/odoo/odoo/pull/61998
task-2312878

This is not really a big issue but let us have correctly defined
rules.

Spotted during Task ID-2300230

closes odoo/odoo#65147

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

The 'custom' key was not working anymore as a key to exclude the
ability to choose a custom color from a color palette widget. It was
thus appearing for choosing the transparent color for over-the-content
headers... which is not possible to save right now.

Part of https://github.com/odoo/odoo/pull/65139



closes odoo/odoo#65139

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

*: web_editor

Users can choose one of their color combination to apply on the header.
If they then choose to make the header transparent over the content for
a specific page, the color of buttons & other components in the header
should be reset to the default website color combination's colors as the
header component are now appearing over the default content.

Part of https://github.com/odoo/odoo/pull/65139

To reproduce, product A in AVCO:
- Buy 2 product A at 1.00 $
- Buy 1 product A at 1.01 $
- Sell 3 product A.
- The stock valuation won't be correct: still remain 0.01 in
stock without quantity and the svl related to the sell
have a value of 3.00 (instead of 3.01)

To fix:
In case of AVCO, add the rounding error value to the out
stock move layer.

closes odoo/odoo#65103

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

Otherwise, this can raise the below issue during an upgrade (`-u`):
```
  File "/home/odoo/src/odoo/13.0/odoo/modules/registry.py", line 369, in init_models
    model._auto_init()
  File "/home/odoo/src/odoo/13.0/odoo/models.py", line 2529, in _auto_init
    new = field.update_db(self, columns)
  File "/home/odoo/src/odoo/13.0/odoo/fields.py", line 2456, in update_db
    return super(Many2one, self).update_db(model, columns)
  File "/home/odoo/src/odoo/13.0/odoo/fields.py", line 857, in update_db
    self.update_db_notnull(model, column)
  File "/home/odoo/src/odoo/13.0/odoo/fields.py", line 897, in update_db_notnull
    model._init_column(self.name)
  File "/home/odoo/src/odoo/13.0/odoo/models.py", line 2455, in _init_column
    value = field.default(self)
  File "/home/odoo/src/odoo/13.0/addons/utm/models/utm.py", line 28, in <lambda>
    default=lambda self: self.env['utm.stage'].search([], limit=1),
  File "/home/odoo/src/odoo/13.0/odoo/models.py", line 1648, in search
    res = self._search(args, offset=offset, limit=limit, order=order, count=count)
  File "/home/odoo/src/odoo/13.0/odoo/models.py", line 4497, in _search
    self._cr.execute(query_str, where_clause_params)
  File "/home/odoo/src/odoo/13.0/odoo/sql_db.py", line 173, in wrapper
    return f(self, *args, **kwargs)
  File "/home/odoo/src/odoo/13.0/odoo/sql_db.py", line 250, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.UndefinedColumn: column utm_stage.sequence does not exist
LINE 1: SELECT "utm_stage".id FROM "utm_stage" ORDER BY "utm_stage"
```

upg-5396

closes odoo/odoo#65129

X-original-commit: 9294c1dc
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

When checking the replenishments, it sometimes creates a new reordering
rule for a product while another already exists.

To reproduce the error:
(Need purchase,sale_management)
1. Create a product P
	- Must be storable
	- In Purchase tab, add a vendor
2. Create a reordering rule for P
	- Trigger: Manual
	- Min: 0
	- Max: 0
3. Create+Confirm a SO with P
4. Go to Inventory > Operations > Replenishment
5. On P-product's line, click on "Order Once"
6. Confirm the generated RfQ
7. Repeat 3-4

Error: There are now two lines for P-product. A second reordering rule
has been automatically created but the first one does already the job.

OPW-2431780

closes odoo/odoo#65040

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