Current behavior:
When adding a "Heading" in the first 200 characters of a blog with
/Heading, the short description of the blog preview would have
unwanted stars (*) around the heading

Steps to reproduce:
- Create a blog article
- In the first 200 characters of the blog use a heading (e.g. /Heading1)
- Go back to the blog list, the description of the new article contains
  unwanted stars (*)

opw-2798595

closes odoo/odoo#88352

X-original-commit: 6cb57d2f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Before this commit, updating the voice activation threshold in one tab
would not affect the other tabs as the localStorage was only read when
discuss was initialized.

This commit fixes this issue.

task-2679234

closes odoo/odoo#88154

X-original-commit: 80c81c70787952eb4fdc4b81210bdf2893210e1a
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

With l10n_nl, create a purchase journal -> traceback
Ids was appended to ORM command list, instead of the ids list.
Moreover, it was filled even if there were no missing value.

opw-2801012

closes odoo/odoo#88732

X-original-commit: 2d6d6e81f53239942f549b16b11faf1b8f77cf41
Signed-off-by: Florian Gilbert <flg@odoo.com>

Missing translation

opw:2782254

closes odoo/odoo#87891

X-original-commit: 863537b9
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Simon Goffin <sig@odoo.com>

Commit e834173314f00e36cb3a1f99690d9f220584682c fixed an issue where editable
elements could not be removed if they were nested in a non-editable element,
because the editor considered them to be an editable root.

However, the same logic also applied when doing a history step after adding
such an element. Adding a nested editable element would make the history step
invalid and result in a rollback.

Such a situation can be encountered when adding a recaptcha legal notice to a
website form. The footer of the form is a non-editable paet of the document,
however the legal notice can still be updated by the user. This commit adds a
separate test for the addition of such editable elements that were previously
considered unremovable.

opw-2723017

closes odoo/odoo#88733

X-original-commit: f693e8ed
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Prior to this change, if a contenteditable=true element was a child of a
contenteditable=false element, it was always flagged as unremovable=true.

In fact what should happen is that this.editable should be unremovable, but one
of its subchildren can be contenteditable=true while having a parent
contenteditable=false and not be unremovable.

Task-id: 2794990
X-original-commit: 72e2fd74
Part-of: odoo/odoo#88733

Since [1] when the blog layout was refactored between 12.0 and 13.0, a
negative word spacing was introduced in the blog post snippet with the
big pictures layout.

This commit removes this negative word spacing.

[1]: https://github.com/odoo/odoo/commit/bb0cdec4594fab8c22265ed8af0c2d431a263b72



task-2822436

closes odoo/odoo#88729

X-original-commit: c0e86be9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Steps to reproduce:

• Create Record: Product Category
- Costing Method: Average
- Inventory Valuation: Automated
- Specify a price difference account (may create new account).
- Ensure Stock Interim (Received) account is reconcilable.

• Create Record: Product
- Product Type: Storable
- Cost Price: 1.01
- Product Category: New Product Category

• Create bill with this product, for a quantity of 10.5

-> The is price difference of 0.1

Issue comes from this commit 286ea6b6
which doesn't round if there is a discount.

With this commit we isolate the latter case in order to keep the
price unit rounded if there is no discount.

closes odoo/odoo#88734

X-original-commit: 643d91ef
Signed-off-by: Florian Gilbert <flg@odoo.com>

Steps to reproduce:

  - Install eCommerce module
  - Select company A and set only one pricelist with:
    - company = company A
    - website = website of company A
  - Select company B and set multiple pricelist.
  - Switch to company B
  - Archive a pricelist

Issue:

  Error: "With this action, "Website of company A" website would not
  have any pricelist available".

Solution:

  Use sudo() when searching websites to don't use multi-company
  compliant ir.rule `product_pricelist_comp_rule` (in website_sale) when
  getting pricelist_ids (and therefore allow checking all pricelists for
  all websites in all companies).

opw-2759069

closes odoo/odoo#88703

X-original-commit: 4b3404087f4541cf52b84ef668da4055da5ad9e2
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>

When creating a global time off in one resource.calendar A , it will be
propagated on any new resource.calendar B.
However the reverse is not true, if I delete the global time off in
calendar A it will not be deleted in calendar B.
During the work entry generation this is not taken into account, a
contract using calendar A will generate leave work entries because of
the global time off in calendar B.
This is due to a change in PR odoo/enterprise#15091.

The domain is now correct and will only fetch the right leaves.

TaskId-2627378

closes odoo/odoo#88725

X-original-commit: 0bac1d33a25e37ebece69de030b9fd72caa43a02
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

A field order_id has been introduce on account.analytic.line
in https://github.com/odoo/odoo/commit/dc9ef81ab21cbbf232eca1771ab94dd5a54e9345


to allow to group by order

This field was introduce as related readonly=False.
It has the side effect of modifying the order_id on the sale.order.line
each time a timesheet is created and thus trigger computed field that
are based on that field.

Since the field is only declared for a group by it's pointless to
make it modifiable, it will save a lot a useless computation and avoid
some issue with computed field wrongly triggered

closes odoo/odoo#88714

X-original-commit: 6916e541d272fea64fbc49e451f065b9cd614134
Signed-off-by: Thibault Francois <tfr@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>

This commit moves some handler methods from components to models,
as a step closer to having most of business code in models.

Having business code in models is desirable so that the code is much more maintainable:
easier to change and more robust code.

Task-2579306

closes odoo/odoo#88692

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Before this commit
At each iteration, the `loop_cycle_number` was reset to 0.
This caused the cycle condition to always be the same.

After this commit
The cycle condition will properly make the style cycle.

closes odoo/odoo#88686

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

On mass_mailing, the button does not have a specifc width.
Defining a width to the button makes the styling more predictible.

Task-2781002

closes odoo/odoo#88679

X-original-commit: 5f5b8065
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

The overflow: auto on the container in mass mailing generated a
scrollbar whenever the drag and drop of snippets because
of the drop zones.

Task-2781002

X-original-commit: 2af04ad4
Part-of: odoo/odoo#88679

Reduce the content of the title to make sure it fits in a single line.

Task-2781002

X-original-commit: 2b87e561
Part-of: odoo/odoo#88679

Task-2781002

X-original-commit: ab2ba08f
Part-of: odoo/odoo#88679

A mechanism is provided by the OdooEditor to circumvent certain problems while
editing links. More specifically, editable zones are patched when editing a
link. This avoids the cursor ending up outside the link whenever the link tag
is emptied.

However, the mechanism does not check if the link is also in the editable zone
before doing so. In translation mode, the editable zones correspond to the
individual translation strings. When translating link texts, this means the
anchor tag containing the translation string is outside the editable zone. The
patching mechanism still applies, resulting in the anchor tag becoming editable
as well.

This causes problems while translating links, for example oDeleteBackward
commands are being rolled back. Checking if the anchor tag is inside the
editable zone resolves the problem.

opw-2780312

closes odoo/odoo#88674

X-original-commit: 99050b26
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

For now `hr_timesheet_graphview` doesn't work with dashboard because
`board` is still in legacy and `hr_timesheet_graphview` in owl.

So we have to create a legacy version of it to adapt it to dashboard.

Similar fix: https://github.com/odoo/odoo/pull/86571/files



opw-2793729

closes odoo/odoo#88673

X-original-commit: 0b298005
Signed-off-by: Xavier <xbo@odoo.com>

Currently, the event sponsor ordering on the website is non-deterministic as it
uses a non-ordered dictionary to accumulate items, which then dictates the
order of display.

We fix that issue by using a OrderedDict that will correctly retain the order.

In addition, we force the sorting of sponsors based on their
event.sponsor.type's sequence first and then based on their own sequence.

The '_order' of event.sponsor is currently 'sequence, sponsor_type_id' which
seems wrong but has to stay that way in order to avoid backend issues.
Indeed, the backend and the "handle widget" do not have the capability to sort
on multiple levels as we would need here (sponsor type sequence, then sponsor
sequence).

To completely fix this issue, we would need to:
- Store the sponsor.type's sequence field on the sponsor (related stored)
- Modify the _order to be sponsor_type_sequence, sequence
- Only allow people to sort event.sponsors within a single category at a time

Those changes would not be doable on a stable branch, hence why we use a local
sorting when displaying sponsors on the website.

Task-2818538

closes odoo/odoo#88633

X-original-commit: c32583a2160a289748616d4b0e49cba2bd5778fb
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Task-2812497 accidentaly removed some CSS rules, causing the dialog not to be
centered properly. This commit put the rules back.

closes odoo/odoo#88653

X-original-commit: 3f8fd3d57c77a7eef41685d007bbc0a20d3bb290
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Steps to follow

  - Go to Accounting > Accounting > Sales (account.move.line model)
  - Remove any existing group by
  - Group by Products
  - Select multiples lines of the same product
  - Try to modify the account of the select line
  -> `this.localData[value] is undefined

Cause of the issue

  When grouping by a field not in the view, `list.__data` contains the
  groupedBy field value because we fetched the group through a web_read_group

Solution

  Filter out absent fields before creating the group datapoint

opw-2784995

closes odoo/odoo#88634

X-original-commit: d6585235
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>

This commit moves some handler methods from components to models,
as a step closer to having most of business code in models.

Having business code in models is desirable so that the code is much more maintainable:
easier to change and more robust code.

Task-2579306

closes odoo/odoo#88594

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Since [1] when the fuzzy search was introduced, the candidate words used
for the fuzzy matching were split on non-'\w' (all non alphanumeric
characters + underscore).

This commit adds '-' (hyphen) to the list of characters that should be
considered part of the same word.

Steps to reproduce:
- Specify a product with name 'micro-vis'
- search for 'micro-vis' or 'microvis'
=> Was not returning any match
=> Now returns fuzzy match even for 'micro-vs'

opw-2801704

[1]: https://github.com/odoo/odoo/commit/c6ba756e4b4704089d02434871788a82d90cb195



closes odoo/odoo#88591

X-original-commit: 10d54d3c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Steps to reproduce:

Decimal Accuracy - Product Price = 2
- create a product `alc 50%` with BOM (10 unites = 1 unit Water [cost=0.14]; 1 unit Alc [cost=0.08])
- Set `quantity on hands` = 10,000
- Trigger `Compute Price from BoM`

-> In Reporting > Inventory Valuation; click on the layer; in Other Info: You will see "Product value manually modified (from 0.0 to 0.022000000000000002)"
=> It can cause computing mistakes as we changed the costs

Cause:

The value is calculated as the difference between the New Price (cost) and and the current Product Standard Price (cost).
But, on one hand the Product Standard Price is rounded to the number of digits defined in the Decimal Accuracy for the Product Price.
On the other hand, the New Price is used as is with no rounding.

If we add an extra step and modify the cost of the Water to 0.45 and trigger again the `Compute Price from BoM` we will have:
"Product value manually modified (from 0.02 to 0.053000000000000005)"

Solution:

Use for the New Price the same rounding precision as we use for the Standard Price.

Example:

Product		Price/unit
--------------------------
Water		0.14
Alc. 100%	0.08

BoM: Alc. 50%
Product		Quantity Needed
--------------------------
Water		0.1
Alc. 100%	0.1

Cost/unit of Alc. 50%: 0.022 => 0.02 (standard_price is rounded)
Set Quantity on Hand: 10,000

Stock Valuation: 200 = 10,000 * 0.02
=> The standard_price is rounded to the second digit when intialized

Product         Price/unit
--------------------------
Water           0.45
Alc. 100%       0.08

BoM: Alc. 50%
Product         Quantity Needed
--------------------------
Water           0.1
Alc. 100%       0.1

Cost/unit of Alc. 50%: 0.053
Set Quantity on Hand: 10,000

Stock Valuation WITHOUT FIX: 530 = 200 (first layer) + 330 (second layer) = 0.02 * 10,000 + (0.053-0.02) * 10,000
Stock Valuation WITH FIX: 500 = 200 (first layer) + 300 (second layer) = 0.02 * 10,000 + (0.05-0.02) * 10,000

=> Without fix, the value is computed with the rounded standard_price and the not rounded new_price.
=> With fix, the new_price is rounded the same way as the standard_price

opw-2724975

closes odoo/odoo#88616

X-original-commit: 2d6f4213
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>

closes odoo/odoo#88599

X-original-commit: e7e7bedd8f486e7b64053908fc1a39255cca82ea
Signed-off-by: Josse Colpaert <jco@odoo.com>

This is a view concern and prevents from refactoring the composer model.

Part of task-2390637

closes odoo/odoo#88588

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Before this commit, the `grid` is asked in a window action used when
the user clicks on the stat button to see the timesheets related in
account move form view. When the user clicks on that button he has a
traceback because the grid only exists in the enterprise version and not
in community version.

This commit removes the 'grid' in the `view_mode` of that action since
in community version the grid view does not exist.

closes #88274

closes odoo/odoo#88581

X-original-commit: 6613ac1d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>

This owl update is significant: it introduces a change in the way
components are rendered: now, child components check if there is a
current rendering somewhere in their ancestors. If this is the case, the
rendering will be delayed.  This prevents lots of issues where a
child components may be in some kind of corrupted state after some state
changes.

closes odoo/odoo#88572

X-original-commit: 93710d082bf860d0ea576fe99db9506af9bb42b0
Related: odoo/enterprise#26135
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>

Going to Inventory > Reporting > Inventory Report, the on hand
quantities are not added up.

The corresponding field (`inventory_quantity_auto_apply`) is not stored,
so the condition to aggregate the values is not respected:
https://github.com/odoo/odoo/blob/e9c83f6623f74970e7d0c29427a09dd26ded039a/odoo/models.py#L2525-L2527

Considering how the field is computed,
https://github.com/odoo/odoo/blob/91f3005477b92d763e6c35f41804b1ab7c9eb639/addons/stock/models/stock_quant.py#L145-L148


we can use `quantity` to have its aggregated value

OPW-2803350

closes odoo/odoo#88550

X-original-commit: f48f8a73
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

The problem is that we have a limited space in the filename for
differentiating one file from the other. Only the five characters at the
end of the filename are used, this looks like:

    <CODICE_FISCALE>_NNNNN.xml (where N is a character a-zA-Z0-9)

The current version utilises the invoice id to get the unique filename.
This has a couple of problems:
 - It doesn't utilise the (lowercase) a-z characters
 - Draft invoices still have invoice ids
 - In a multicompany environment, the invoice ids are not unique to the
   company (i.e. another company creating an invoice will increment the
   value of the invoice.id on your company)
These above problems mean that we're not currently utilising the hashing
space available to us by the characters of the filename.

The solution is to utilise an ir.sequence, that is used to determine
each filename. This has the benefit of being editable by the user, so if
they continue to get duplications, they can offset them by adjusting the
value of the sequence's next number.

A more descriptive error message and its translation term have also been
added for when a filename duplication occurs.

relates to

closes odoo/odoo#88324

Task-id: 2813957
Ticket-id: 2788927
X-original-commit: d0f8ca31
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>

Since bcf665a2, this helper has moved.

closes odoo/odoo#88559

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

On an heavy database searching for company leads or assigned leads can be
costly. Having an OR does not necessarily triggers index usage and query plan
uses an index scan.

It is less costly to do two searches: one for the base domain (based on
commercial entity) and one for the assign domain (based on partner assigned).

Task-2770994

closes odoo/odoo#88538

X-original-commit: 6957d7a57cb3bf25d552d3f8f2760db46ace5e3a
Signed-off-by: Thibault Francois <tfr@odoo.com>

Fixes odoo/odoo#86216
When printing qweb report use the current company.
For example, the company logo printed was always from user company
default instead of the current company.

closes odoo/odoo#86356

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

X-original-commit: b9e2a7c189c2defb7eb9ab089d12cf00145e4525
Part-of: odoo/odoo#86356

Before this commit, this bug was present in edit mode:

- Go into edit mode on an empty page.
- Click on the THEME tab on the right.
- Click on the empty "DRAG BUILDING BLOCKS HERE" area.
- Click on the THEME tab again.
- The content of THEME is empty.

It was because since this commit [1], clicking on an 'oeStructure'
activate the Blocks tab but without updating the options in the tabs.

Another similar bug was present when clicking the style tab and then
clicking on the theme tab.

About the first bug, actually a call of '_updateRightPanelContent' is
already done in '_activateSnippet()' (and the Blocks tab is activate by
default) so we only have to use '_activateSnippet(false)' to activate
the Blocks tab. This commit also remove '_updateRightPanelContent' from
the click event of the Blocks tab where it was not necessary.

For the second bug, we can't do the same fix, because it's not possible
to activate the options tab with only '_activateSnippet(false)' so we
had to combine the two functions.

[1]: https://github.com/odoo/odoo/commit/fbe048c202ff7878984adf26bef0651a45851f0a



task-2794266

closes odoo/odoo#88537

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

before this commit:
===================

if there is multi tag on one tax line then condition is not working as expected
see below test code
```
tags
account.account.tag(33, 34)
>>> self.env['account.account.tag'].browse([33]) in tags
True
>>> self.env['account.account.tag'].browse([33, 34]) in tags
False
```

after this commit:
==================

if there is multi tag on one tax line then condition working as expected
see below test code

```tags
account.account.tag(33, 34)
>>> any(tag in tags for tag in self.env['account.account.tag'].browse([33]))
True
>>> any(tag in tags for tag in self.env['account.account.tag'].browse([33,34]))
True
```

introduced from here https://github.com/odoo/odoo/commit/aa43799ed9e03d473f48c34ee470330e027ae462



closes odoo/odoo#88513

X-original-commit: 7cd2b25a7595cecd3b5c6a9d410f4ac31b76e8ac
Signed-off-by: Florian Gilbert <flg@odoo.com>

Localisation modules are converted to English and published in a
separated project on Transifex
https://www.transifex.com/odoo/odoo-15-l10n



Every localisation module will progressively be converted to have the
source in English and translated via Transifex.
This will allow developers to improve the localisations without having
to work with translators directly.

closes odoo/odoo#88439

X-original-commit: e5dfe8613723ba522e20334568c5637188ff2252
Related: odoo/enterprise#26091
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Previously, some lifecycle hooks were not called when using a
ComponentWrapper in an iframe, this is because to know whether we should
call mounted, we check whether the target/el is in the document, but
when using iframes, the document in question is not the top-level
document and so the check returns false.

This commit fixes that by checking if the elements are inside their
ownerDocument instead.

closes odoo/odoo#88435

Signed-off-by: Géry Debongnie <ged@odoo.com>

Before this commit:

In discuss, livechat website visitor info is displayed above thread view topbar.

After this commit:

Livechat website visitor info will be displayed below the thread view topbar.

Task-2668036

closes odoo/odoo#88532

X-original-commit: 5294def72da677c75f980ffcfb1bb50508ee0760
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>