The optimization 2ccf0bd0 does not take into account that to
"unblacklist" a user, you have the archive the mail.blacklist record so
only mail.blacklist active records need to be taken into account.

Added test without the fix fails with:

    AssertionError: 2 != 1 : Blacklisted ignored email number incorrect,
    should be equals to 1

opw-2536304

closes odoo/odoo#71125

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

The method filtered_domain() is broken for domains with hierarchical
terms ('child_of'/'parent_of').

To see *one* of the ways the implementation is broken, let `A` be a
model with `parent_id` pointing to `A`, and `a1` a record of model `A`
without parent (`a1.parent_id` is `False`), then this fails:

    assert a1 in a1.filtered_domain([("parent_id", "child_of", a1.id)])

The reason it fails is that on
https://github.com/odoo/odoo/blob/f5519586d214a9b34ad24683a7f97c47802a3bad/odoo/models.py#L5377-L5380
`data` is empty since `a1` has no parent, thus
https://github.com/odoo/odoo/blob/f5519586d214a9b34ad24683a7f97c47802a3bad/odoo/models.py#L5403-L5404


fails, therefore the result of `filtered_domain` is empty.

Note: the implementation of the hierarchical operators is full of quirks
that are hard to emulate otherwise than by reusing the original code.
As a consequence, the current implementation may be broken in more than
one way.

Let's see another way the implementation is broken: let `B` be a model
without a `parent_id` field and with a `friend_id` field pointing
to `B`, and let `b1` be a record of model `B`.  Then

    b1.filtered_domain([("friend_id", "child_of", b1.id)])

throws an exception of the form shown below:

    ValueError: Invalid field 'parent_id' in leaf "<osv.ExtendedLeaf: ('parent_id', 'child_of', 1) ...

Meanwhile the following code is still valid and returs b1:

    B.search([("friend_id", "child_of", b1.id)])

closes odoo/odoo#71214

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Before this commit:

  B2CS is not decreased in case of refund but it's shown in CDNUR but CDNUR has a condition that only shows a refund of B2CL.
  HSN value is not decreased in case of refund

After this commit:

  Refund is decreased from B2CS and not show that in CDNUR
  HSN value is decreased in case of refund

B2CS = Business to Consumers Small
B2CL = Business to Consumers Large (invoice value is more than Rs.2.5 lakhs)
CDNUR = Credit/Debit Notes for Unregistered
HSN = Harmonized System of Nomenclature(hsn code per product)

closes odoo/odoo#65578

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

The `groupby` function is used to builds groups of(product, lot) keys
and their corresponding move lines / quants. `groupby` groups
*consecutive* keys, which is why the input is sorted by the keys.

`sorted` on recordsets keys will not sort as we would expect in this
particular situation, as the comparison operators on records act as
Set Comparison operators on the record ids, i.e. to compare the sets
superset/subset relationships:

```
>>> env["product.product"].browse(1) < env["product.product"].browse(2)
False
>>> env["product.product"].browse(1) < env["product.product"].browse([1, 2])
True
```

Example of sorted on stock.move.line records, where the product id 7313
is both in the slots 4 and 12 instead of being consecutive:

```
>>> [l.product_id.id for l in sorted(lines, key=itemgetter('product_id'))]
[7436, 7437, 7352, 7423, 7313, 7351, 7423, 7424, 7320, 7398, 7312, 7352, 7313, 7436, 7437, 7442, 7443, 7320, 7423, 7424, 7318, 7396, 7368, 7355, 7316]
```

Now when we group by id the 2 ids 7313 are correctly placed together in
slots 1 and 2:

```
>>> [l.product_id.id for l in sorted(lines, key=attrgetter('product_id.id'))]
[7312, 7313, 7313, 7316, 7318, 7320, 7320, 7351, 7352, 7352, 7355, 7368, 7396, 7398, 7423, 7423, 7423, 7424, 7424, 7436, 7436, 7437, 7437, 7442, 7443]
```

This commit aims to sort by "id" of the related records, to ensure the
same (product, lot) couples are consecutive.

closes odoo/odoo#63541

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

As part of the Python 3 compatibility effort,
01e35141 moved all uses of urllib(2)
to werkzeug & requests as the packages were renamed and reorganised
between P2 and P3.

For `module.py`, it looks like I confused the `urls` local variable
for an already imported `werkzeug.urls` and just tried calling
`url_parse` on that. Which doesn't work, because `urls` is a
dict.

Fixes #71076

closes odoo/odoo#71115

X-original-commit: 0cfe528d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>

This is a forward-port of commit https://github.com/odoo/odoo/commit/970387f91fea0cb47404612f7d519ffba2c9ad3b



In editable list view, moving to next cell using TAB key crash when the
following field is becoming read-only (i.e non-focusable) and an onchange()
event is triggered.

Consider an editable tree view like this:

<form>
   <field name="o2m" onchange="1">
       <tree>
          <field name="description"/>
          <field name="date" attrs="{'readonly': [('description', '!=', False)]}"/>
          <field name="type"/>
       </tree>
   </field>
</form>

1. Edit 'description'
2. Issue a TAB keypress before 'date' becomes read-only
It will crash while calling getSelectionRange() on an empty element.

opw-2523630

closes odoo/odoo#71121

X-original-commit: bd6ba50e073ffff0bd51b1a02d51260f09e36357
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>

Previous to this commit, there is a check to prevent MOs from having
no components, but there is no check to make sure any of the components
were actually consumed. This lead to a situation where you can have a
completed MO that has a state of "Cancelled" due to all quantity_done=0
moves being cancelled by stock_move.action_done() even though the MO is
"Done".

Steps to reproduce:
1. Create a MO for a product with a BOM with no components
2. Add a component with 0 to Consume
3. Complete (Validate/Mark as Done) the MO

Expected result: cannot validate the MO

Actual Result: MO is completed but state = Cancelled

Also fixes an out-of-date test that incorrectly fails due to its
component usage not being properly updated.

Task: 2463893
ENT PR (fixes test only): odoo/enterprise#16601

closes odoo/odoo#66663

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

Steps:
- Install Events
- Go to Events / Configuration / Settings
- Enable Tickets
- Go to Sales / Configuration / Settings
- Enable Multiple Sales Prices per Product
- Go to Sales / Products
- Edit Event Registration
  - Sales tab
    - Pricing
      - Pricelist: Public Pricelist (USD)
      - Price: $6
- Go to Sales
- Create a new quotation
  - Pricelist: Public Pricelist (USD)
  - Product: Event Registration
  - Event: Design Fair
  - Ticket: VIP

Bug:
The pricelist is not taken into account. Unit price should be $900 but
is $1500.

Explanation:
The original issue comes from this commit: https://github.com/odoo/odoo/commit/379f1490c93dc599a74add2d678c18fbba1efa62
The advertised amount was not the one showing up in the cart. This is
because the pricelist was not taken into account anymore when entering
the payment process.

Using `price_reduce` instead of `price` enables all kinds of discounts
on the final price.
However, `price_reduce` relies on the context to find the current
pricelist.
This commit adds the context needed to compute the price of the tickets.
This context is the same as the one in the sales module since pricelists
are working fine there: https://github.com/odoo/odoo/blob/b208570ce8399bc6d3e4a8ba02eef6558e0a6ccc/addons/sale/models/sale.py#L1494



The currency conversion is done in `product.price`. It's therefore
already done when calling `price_reduce`.

opw:2519453

closes odoo/odoo#70928

X-original-commit: fbec1a607179c8a0a1c1d72aa5b14dd060f8a25b
Signed-off-by: backspac <backspac@users.noreply.github.com>

When signing a document, characters with accents are not rendered if
they are uppercase.

To reproduce the error:
(Need sale_management)
1. Create a SO
2. Customer Preview
3. Sign & Pay
4. Select "Auto" with this Full Name: ÜÄÏÖ

Error: None of the letters are rendered

Backport of 0684219d

OPW-2475740

closes odoo/odoo#70725

Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>

When updating the quantities available for a product, an inventory move
is generated without setting the product_tmpl_id, as this field is related
to the product_id of the move. However, when creating the move, Odoo will
consider it a default missing value and will try to fill it in the method
default_get.

When navigating to the product variants of a template from the template form,
a default_product_tmpl_id is set in the context pointing to the template. This
context is propagated to the update quantity action to create/update quants for
the variant.

The problem when dealing with kits is that the products available to update
their quantities are the components of the kit. When navigating to a variant
and updating the quantities of a component of the kit variant, the default product
template in the context will be the kit template.

This is causing that, when generating the inventory move, the move is created with
product_id of the component, and product_tmpl_id of the kit template.

This issue creates a critical data inconsistency as the component's template is set
to the kit's template, which apart from making no sense generates a recursion error.

To fix this, when triggering the action to create/update quants for a kit product, it
must be ensured that no default product template is being set.

closes odoo/odoo#71037

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

- Enable 'product configurator' and 'variant grid entry'
- Go to product [DEMO]:
  - Add an optional product.
  - Go to the variants tab and add some variants
- Select 'order grid entry'
- Remove all the variants
- Create a SO adding [DEMO]

Traceback will occur

opw-2439764

closes odoo/odoo#71024

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

Manually adding a line should not trigger the computation of the field,
just like modifying the line fields that occur in the field's domain.
In other words, the dependencies of the field should be limited to the
ones declared on field or its compute method.

closes odoo/odoo#70773

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

We create payment methods only if the company has default pos receivable account (which only happens if the chart of accounts has the default set). But we may have charts that don't have that default set, so we filter the companies to avoid the not-null constraint.

closes odoo/odoo#70809

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

When there is a materialized view that has not been populated any select
on it will fail.

Example of traceback:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/12.0/odoo/service/server.py", line 1162, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 86, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/12.0/odoo/modules/loading.py", line 367, in load_modules
    registry.setup_models(cr)
  File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 262, in setup_models
    env['ir.model']._add_manual_models()
  File "/home/odoo/src/odoo/12.0/odoo/addons/base/models/ir_model.py", line 321, in _add_manual_models
    cr.execute('SELECT * FROM %s LIMIT 0' % Model._table)
  File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 148, in wrapper
    return f(self, *args, **kwargs)
  File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 225, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.ObjectNotInPrerequisiteState: materialized view "x_bi_sql_view_report_copy" has not been populated
HINT:  Use the REFRESH MATERIALIZED VIEW command.
```

Several upgrade requests have or had had this error which has been
solved with specific scripts.

Related to #40930

closes odoo/odoo#70998

X-original-commit: b208570c
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Steps:
- Go to Website
- Click "Go to Website"
- Create a new page
- Add a Form Builder block
- Try to edit the Send button

Bug:
The Send button is not editable

Explanation:
This commit adds the `contenteditable` attribute to the button when in
edit mode.

opw:2481364

closes odoo/odoo#70982

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

data-parent fields were set on tab link and not on the tabpanel
div. It prevented the accordion of having the right behavior:
closing all the other tabs when a tab is clicked to be opened.

closes odoo/odoo#70471

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

On unbuild order creation, when the user selects a manufacturing order,
the UoM of the quantity will be defined with the product's UoM instead
of MO's UoM.

To reproduce the error:
(Use demo data)
1. In Settings > General Settings, enable "Units of Measure"
2. Create two products P_finished and P_compo
    - Both are storable
    - Qty on Hand of P_compo = 12
3. Create a Bill of Material
    - Product: P_finished
    - Component: 1 x P_compo
4. Create a Manufacturing Order MO
    - Product: P_finished
    - Quantity To Produce: 1 Dozen(s)
5. Check Availability, Produce, Mark as Done
6. Create an Unbuild Order:
    - Manufacturing Order: MO

Error: The unit of measure of the quantity is incorrect, this is
Unit(s), it should be Dozen(s)

The method `onchange_mo_id` defines the product, therefore the method
`onchange_product_id` is also called and here is the issue:
`onchange_product_id` will override the UoM using the product's UoM.

OPW-2467017

closes odoo/odoo#70860

X-original-commit: 39579d71
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Before this commit, when the user edits the description of a task with
use_pad=True and then change the project of this task to one with
use_pads=False. The description written in the pad server is not copied
in the description field of the task.

This commit copies the content of the pad for this case when the use_pad
changes to become False and description_pad is set.

Step to reproduce:
-----------------

1. Go to Settings of the Project App and enable the Collaborative Pads
2. Go to the Project App, in the Projects dashboard (kanban view of projects)
3. Create two Projects (one called "Project A" and the other called "Project B")
4. Edit the Project B to activate the pad, that is, check the Use
collaborative pads checkbox.
5. Go to the view list of tasks in the "Project B"
6. Click on "Create" button to create a task in the task form view.
7. Write a description for this task.
8. Change the project of this task by the "Project A". With this change,
the collaborative pad is disabled for this task since the Project A has
not the pad, and then the description field is empty rather than have
the content that we have just written.

task-2515150

closes #70401

Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>

Before this commit, in Project App, when the "Collaborative Pads" is
enabled in the Settings of this app, if the user create a task without
project or in a project that has not the pad enabled and he writes a
description for his new task and select (another) project in which the
pads is enabled then the description field in the form view changed to
have the collaborative pad and the problem is the description is not
copied in the pad and seems erase/delete for the user.

This commit checks if the pad_content_field is not empty after
generating the pad url for the new task/record, if it is the case then
we copy the content in the pad and the user can continue his edition
before saving the task/record.

Step to reproduce:
-----------------

1. Go to Settings of the Project App and enable the Collaborative Pads
2. Go to the Project App, in the Projects dashboard (kanban view of projects)
3. Create two Projects (one called "Project A" and the other called "Project B")
4. Edit the Project B to activate the pad, that is, check the Use
collaborative pads checkbox.
5. Go to the view list of tasks in the "Project A"
6. Click on "Create" button to create a task in the task form view.
7. Write a description for this task.
8. Change the project of this task by the Project B. With this change,
the collaborative pad is actived for this task since the Project B has
the pad, and then the description in the pad is empty rather than have
the content that we have just written.

task-2515150

closes #70401

This reverts commit d89562e8fe473692296cb209651beb2ce7a715e4.

Since this commit, the taxes mapped by fiscal position wasn't managed by the _fix_tax_included_price_company method anymore.
Otherwise, some customizations exist on this method that are no longer called.
The 2527940 issue is also due to a remaining bug: the total_excluded price should be divided by the quantity but:
- what if the quantity & price_unit are both signed?
- what if the number of digits for price_unit and the currency are different? Should we skip the rounding of taxes?
Since this commit is not perfect and has a lot of dependencies in others modules, we decided to revert it.

Original PR: https://github.com/odoo/odoo/pull/68997
Revert PR: https://github.com/odoo/odoo/pull/70858



closes odoo/odoo#70858

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

Issue

	- Install "Contacts" & 'base_address_extended' modules
	- Go to contacts and create a contact with value:
	  - street name : Chaussee de Namur
	  - House : 40
	- Save and edit again
	- Set country to 'Netherlands' then save.

	Address not splited well (wrong values for street name and house).
	The issue is not present in UI but is in tests.
	(Issue in UI from odoo 14.0+)

Cause

	There is 2 '_split_street_with_params'
	(inverse function that set street fields):
	- partner_autocomplete_address_extended (removed in 14.0)
	- base_address_extended

	The 'spliting' logic is not the same in both function.

	In UI, looks like it does not call '_split_street_with_params'
	from 'base_address_extended' since no super(Partner, self)...

	However in testing, it does call it from module
	'base_address_extended' and therefore trigger the issue.

Solution

	Adapt _split_street_with_params function
	(in 'base_address_extended' module):
	If previous field (from 'street_format') to parse
	in 'street_raw' is 'street_name', then:
	- set `tmp` to: splitted (max 1 split) street_raw
	  with current field seperator
	- set `append_previous, sep, tmp[0]` to:
	  splitted tmp[0] (first part of splited street_raw) with `rpartition(' ')`
	- add 'append_previous' to 'street_name' value
	- join 'tmp' values and set it to street
	  (should equal to what left from `rpartition(' ')` split
	  + seconf part of first normal split)
	- continue normal parsing flow

opw-2476096

closes odoo/odoo#70775

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

The parent method _get_computed_account in the account module it already forces
the company to get the correct account, but in the stock_account module the method
is overriden when dealing with anglo-saxon accounting. In the latter, the company
is not being forced, so it leads to multi-company errors.

The fix simply enforces the correct company to prevent the error.

closes odoo/odoo#70848

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

Purpose
=======
We want to be able to force the FROM headers when we sent email in
SMTP. So we can avoid the emails to be considered as spam.

Specifications
==============
This is done with 2 system parameters.

If the system parameter `mail.force.smtp.from` is set we encapsulate all
outgoing email from with the given value.

If the previous system parameter is not set and if both
`mail.dynamic.smtp.from` and `mail.catchall.domain` are set, we
encapsulate the FROM only if the domain of the email is not the same as
the domain of the catchall parameter.

Otherwise we do not encapsulate the email (same behavior as before this
commit).

Task 2367946
See odoo/odoo/pull/61853

closes odoo/odoo#70835

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

When using the boxed layout, if the business document has a table, its
first row (after the table head) will have a bottom border and the last
cell in the row has a white background.

To reproduce the error:
(Need timesheet_grid. Use demo data)
1. In Settings > General Settings, Change Document Template:
    - Select the second template
2. In Timesheets, select list view
3. Select several lines
4. Print > Timesheet Entries

Error: In PDF, the first timesheet line has a bottom line and its last
cell has a white background (instead of grey).

The bottom line should only be applied on row in table header. The
background color should also be applied on first row in table body.

OPW-2478311

closes odoo/odoo#70742

X-original-commit: 88a10bdd
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Batch the bom_search of bom_lines in mrp_bom.explode.
If we represent the bom hierarchy as a graph, essentially
switch from a depth-first to a breadth-first search, allowing
to batch search boms for each depth level, hence improving
the overall performance.

closes odoo/odoo#68637

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

When partner is not selected, Odoo sends name_search request
`[..., ('partner_id', 'child_of', [False])]`. It's not obvious what does such
domain mean ( see #70584 ). This commit clarifies what do we expect to get:
we want all records without restrictions on `partner_id` value.

This also fixes performance issue because domain leaf `('partner_id',
'child_of', [False])` is converted to where-clause `<table>.partner_id in <all
or almost all ids>`

---

opw-2524010

closes odoo/odoo#70638

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

Issue

    Use Safari (or equivalent) browser

    - Install e-commerce
    - Go to Website -> Configuration -> Payment Acquirers
    - Activate Ingenico in test mode
        (write aaa in required fields)
    - Go to shop, and add product to card
    - Go to checkout
    - Select Ingenico payment mode
    - Click on Pay button
    - When on the ingenico page, press back

    The page is blocked and the button is disabled.

Cause

    When clicking on Pay button, the page is locked and
    the button is disabled.
    With Chrome, when coming back to previous page,
    this one is regenerated and therefore adapt the button.
    In Safari, it is not the case.

Solution

    On `pageshow` event, if event have `persisted` attribute set to
    to true, meaning using cache, then reload page.

Fixes https://github.com/odoo/odoo/issues/69453



opw-2510281

closes odoo/odoo#70767

X-original-commit: 2b5aa8554a13d947c4f4f535f54a5b1ea8185b6c
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

This bug is cause in this PR https://github.com/odoo/odoo/pull/70312



closes odoo/odoo#70800

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

When exporting the tax report's monthly xml with enterprise, the file wasn't accepted by the government in case 0% taxes were used.

Grid 033 is optional, and can be used for custom tax rates. If specified, it MUST always go with grid 403 (giving the tax rate) and 042 (giving the tax amount). In Odoo, we made the choice to use it for 0% taxes, so 403 and 42 will always be present, and always 0.

In community, grids number were missing on the lines' labels, and the codes (used to retrieve the value of each grid when generating the XML) were not correct.

closes odoo/odoo#70744

Related: odoo/enterprise#18287
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

The `search` function of the `re` package can return `None` if the
provided string does not match with the provided pattern
(https://docs.python.org/3/library/re.html#re.Pattern.search

).

On the `_parse_youtube_document` function of the `slide.slide` model,
we are directly accessing the capture groups from the returned value
of the `search` function without checking that the returned value is
actually a 'match' object. As a result, an exception can be throw if
there is no match as, in that case, the `search` function will return
`None` and the `group` function will not be defined on `None`.

To avoid throwing an exception, we will check that the returned value
of the `search` function is not `None` before accessing the capture
groups via the `group` function.

LINKS

Task id: 2525007

closes odoo/odoo#70583

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

Following the recent reorganisation of the documentation in 12.0+, the
majority
of the documents have been moved and their old links are no longer
valid.
Some redirection rules will soon be deployed, but those rules might be
dropped in some
years and we want the links to still work, which is why we still replace
the links to the new ones.

FW-Port of odoo/odoo#70675 (13.0)

closes odoo/odoo#70726

Related: odoo/enterprise#18281
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Regarding of the `display_default_code` context value, `display_name` is
supposed to return the product code or not, eg:
> product.display_name
> '[FURN_6666] Acoustic Bloc Screens'
> product.with_context(display_default_code=False).display_name
> 'Acoustic Bloc Screens'

But since the context was not considered when accessing this field, it would
always return the cached value, which was set from the first time that field
was read, with the `display_default_code` value used at that time.

tl;dr: `display_name` was ignoring the context once cached.

One of the critical issue was that internal code were displayed on the eshop
cart (not the eshop itself), see `name_short`.

task-2517830

closes odoo/odoo#70671

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

When building a domain `(=|!=)` with
a Binary field stored in attachment and
the right part of the domain is not null,
the full binary content is logged, giving
the logs a huge size.

Now, the content of the binary is cropped to
20 chars as it is useless to log more.

opw-2527629

closes odoo/odoo#70691

X-original-commit: d54b30bb
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

closes odoo/odoo#70478

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

A product with single novariant attribute is normally not shown.

But in the configurator modal it was shown and then added in the product
description when doing exactly the same scenario (add the product) than
without the configurator.

With this changeset, we add is_single attribute and only add a no_create
variant if it is not a single value or a custom value.

opw-2494331

closes odoo/odoo#69411

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

- Open a product page, open the reordering rule menu
- Create a new record, a sequence will be preset on the record
- Save the record, it's sequence will change to the next step

opw-2519133

closes odoo/odoo#70524

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

When purchase order line is removed, related stock moves procure method stays as "Advanced" which doesn't allow reservation from stock

closes odoo/odoo#70312

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

The web editor does not work well with the e-learning fullscreen view.
It actually completely closes the fullscreen view and opens the edition on a
blank page.

To avoid this, we intercept the click on the 'edit' button and redirect to the
non-fullscreen view of this slide with the editor enabled, whose layout is more
suited to edit in-place anyway.

A small testing tour was added to ensure this behavior is kept.

Task-2507179

closes odoo/odoo#69363

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