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>

task-2447695

closes odoo/odoo#65061

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

The regex was updated in JS with [1] but its python counterpart was
forgotten during forward-port.

[1]: https://github.com/odoo/odoo/pull/46898



closes odoo/odoo#65083

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

closes odoo/odoo#65082

X-original-commit: 7c6fe756e66aa98b4df5dd2f82baca81c4fc70a7
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

Steps to reproduce the bug:

-Create a time-Off request R1 for 27/01
-Refuse R1
-Create another Time-Off request R2 for the same date 27/01
-Set R1 in draft
-Try to delete R1

Bug:

A ValidationError was raised:

You can not set 2 time off that overlaps on the same day for the same employee.

opw:2447540

closes odoo/odoo#65077

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

Task-2447922

closes odoo/odoo#65071

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Steps to reproduce the bug:

- Create a promotion program PP
- Set 50 in minimal amount
- Set promo_applicability = on_next_order
- Set reward_type = discount
- Set discount_type = discount
- Create a new sale order SO with a product with price 100€
- Cancel the SO

Bug:

A coupon C had been created

PS: When reset to draft and confirm SO, C became valid

Closes #64361

opw:2431740

closes odoo/odoo#65063

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

When synced with Google, if a user adds an event to Odoo Calendar, both
Google and Odoo will send an invitation to attendees.

To reproduce the error:
(Need mailcatcher)
1. Sync Odoo Calendar with Google Calendar
2. Create an event in Odoo Calendar
	- Add at least one attendee who has an email address
3. Save

Error: Odoo's server sends an email. When synced, it should not, it
should let Google in charge of emails sending.

(Similar to #62383)

OPW-2440485

closes odoo/odoo#64902

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

task-2447939

closes odoo/odoo#65074

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

- Install purchase and stock;
- Activate Units of Measure (uom);
- Create a new storable product;
- Choose a different uom for: 'Unit of Measure' (e.g., Dozens) and
    'Purchase Unit of Measure' (e.g., Units);
- Update the Cost (e.g. $ 300.00 per Dozens)
- Create a PO;
- Add the product.

Before this commit, the price on the PO will be 300 and the unit of
measure will be 'Units'.

Now, the price will be adapted to the 'Purchase Unit of Measure', in
this example it will be $25.0 per Unit.

opw-2439506

closes odoo/odoo#65041

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

Generate a coupon code, print it

opw-2444242

closes odoo/odoo#64961

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

If a product is a kit and has a storable component, if this component is
already ordered (with sufficient quantity), when running the scheduler,
the ordered quantity of this component will still be increased.

To reproduce the error:
1. Create two products P_kit and P_compo
	- Both are storable products
	- P_compo must have at least one vendor
2. Create a BoM for P_kit:
	- Must be a kit
	- Add P_compo to components
3. Set a reordering rule for P_kit
4. Inventory > Operations > Run Scheduler
5. Go to Purchase and find the generated RfQ
	- The ordered quantity is correct
6. Repeat 4-5

Error: This time, the ordered quantity is incorrect. While you don't
have any P_kit on hand, each time the scheduler is run, the ordered
quantity will increase.

A similar issue has already been fixed: #63891. The original commit
targets the version 13, but the fix has also been applied to v14 (#64277).
However, here the case is slightly different: the user run the scheduler
twice while the first RfQ is not yet confirmed and received. In such a
case, the scheduler must also check the "quantity in progress". In version
14, it seems nothing computes this quantity for the kits.

OPW-2421841

closes odoo/odoo#64699

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

with this commit we are updating sequence of onboarding tours

task-2444153

closes odoo/odoo#64846

Related: odoo/enterprise#15886
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Issue

        - Install "Manufacturing" module
	- Go to settings and activate "Master Production Schedule"
        - Install Dutch language
        - Switch user language to Dutch
        - Go to Manufacturing -> Planning -> Planning by Production
        - Hover work order

        Dates are not displayed with user locale.

Cause

        Date are formated to "YYYY-MM-DD HH:mm:ss",
        regardless the locale.

Solution

        Format date instead with locale format letters (L, LL, LTS, ...)

Doc : https://momentjs.com/docs/#/parsing/string-format/


      Go to "Locale aware formats" section

opw-2430570

closes odoo/odoo#65049

X-original-commit: 640d964e
Related: odoo/enterprise#15954
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>

with this commit we fixes various tour steps, remove steps from crm and sale
tour and improve step selector in project tour.

task-2444272

closes odoo/odoo#64835

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

Bug
===
Since 569d35bc a fix have been provided
to fix the vertical position of the emoji widget in mobile view.

But the fix have been done in a wrong way and we should use the Odoo CSS
class instead to detect mobile (and not a bootstrap media query).

Task 2253851

closes odoo/odoo#64689

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

Steps to reproduce the bug:

- Let's consider two companies C1, C2 and a website W1 in C1
- Set C2 on the payment term Immediate payment
- Go to the shop
- Add a product in the cart

Bug:

A traceback was raised because Immediate was not in company C1

opw:2431705

closes odoo/odoo#65045

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

task-2426357
task-2426366

closes odoo/odoo#64009

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

Before this commit saving a custom snippet inside an email template
produced a "cross origin" error related to the combination of the save &
reload mechanism with the fact that the email template editor is inside
an iframe.

After this commit saving a custom snippet inside an email template is
not available anymore.
Given that fixing the reload problem would be only temporary -while
quite complex-, it has been decided to disable the feature until the
editor allows for cleaning snippets without saving them.

Decided during task-2374802

closes odoo/odoo#64922

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

The uom must be displayed to the customer in any case.
Otherwise a customer couldn't know the modalities of a contract
(ex: a contract of one year or one day)

Fine tuning of 342dd5ff

opw:2411108

closes odoo/odoo#65037

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

Modifying product attributes involves discarding product variants via
the method _unlink_or_archive(), which tries to delete variants, and
archive the ones for which the deletion fails.  This process is very
slow when most product variants must be archived.  Instead, we filter
out the variants that must be archived anyway (like the ones used in
sales or stock), in order to avoid the variants that cannot be deleted.

On a product with ~200 variants, the time goes from more than 15 minutes
(the request times out) to around 5 seconds!

opw-2440417

closes odoo/odoo#65024

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

The uom must be displayed to the customer in any case.
Otherwise portal user couldn't sign their online quote if
they couldn't read the uom (ex: a contract of one year or one day)

Fine tuning of https://github.com/odoo/odoo/commit/342dd5ffb8281cb5c37fea4fb96db2b570c30122



opw:2411108

closes odoo/odoo#65010

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

Issue

	- Install calendar
	- Go to calendar and set 'week' view
	- Go to first week of the year
	- Add a 'Full Day' event
	- Add an event of 'few hours'
	- Click on filters -> Date -> Q1

	Only 'Full Day' events remains displayed.

Cause

	'start_date' is used to in the 'Date' filter
	and this field is set only on 'Full Day' events.

Solution

	Use 'start' field instead since always set.

opw-2439460

closes odoo/odoo#64992

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

Be sure that we have a beautiful error page and not a black/white error
Be sure that slug_matching with 308 redirect works as expected and don't
raise a RequestUID exception.

closes odoo/odoo#64889

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

Before this commit, a 308 on a route with a modelconverter for a model
that have a seo_name field will crash with an exception:
Cannot iterate on RequestUID

Another simplest solution was to use a with_user(SUPERUSER_ID) but in this case
it bypass the security set and display the name of the record even if not yet
published.

How to reproduce:

Create a 308 from /shop/<product> to /mag/<product>
Unpublish product 10
Try to access /shop/product-10

You have an unmanaged '500 internal error"
because slug_matching -> build -> to_url -> slug with a record with Requestuid
as env._uid.

Replace the hardcoded year in the footer by the year dynamicaly
fetch from the current date.

task-2431308

closes odoo/odoo#64677

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

The affixed header was not reappearing if page content was removed and
the page thus indirectly scrolled.

task-2446020

closes odoo/odoo#64990

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

Before this commit, when the user with no access right to Timesheet App
wants to see the tasks in a project and sale_timesheet module is
installed, the user has a traceback saying remaining_hours field is not
find in the parent view of
`sale_timesheet.view_task_form2_inherit_sale_timesheet`.

This traceback is raised because the
`hr_timesheet.view_task_form2_inherited` is not used if the user has no
access right to Timesheet App and then remaining_hours field is not
defined for this user because this field is appeared in the view in
hr_timesheet module.

This commit revises the views inherited from the project.task model to
give the user without access rights in Timesheet the possibility to see
the tasks in any project he can see.

opw-2429662

closes odoo/odoo#64900

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

The uom must be displayed to the customer in any case.
Otherwise portal user couldn't sign their online quote if
they couldn't read the uom (ex: a contract of one year or one day)

opw:2411108

closes odoo/odoo#64987

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

The mobile app's authentication bases its feedback to the user on the
error message returned by the server.
Sadly, in case of multi-databases, no error message are properly
returned when the user provides wrong credentials (presenting only an
empty Snackbar).

This difference of behaviour was introduced in the commit
odoo/odoo@07d5ea3 which goals was to give more power for JsonRequest's
error handling customization. To do so, the catching of the exception
(if one happens) was delegated to the caller instead of the JsonRequest
itself.

This change indirectly introduced a difference about the treatment of an
exception between mono and multi-database :
* mono-database was already catching the exception and handling it
properly (see in
https://github.com/odoo/odoo/blob/f05f8ef647a4eaba49d8a20eb8068f1c7a702297/odoo/addons/base/models/ir_http.py#L235-L241

).
* multi-databases didn't catch it.

This commit restores the parity between both use cases by applying the
same behaviour (as described in the commit odoo/odoo@07d5ea3):

```python
ir_http.dispatch():
	try:
		request.dispatch()
	catch Exception as e:
		ir_http._handle_exception(e)

ir_http.handle_exception(e)
	request._handle_exception(e)
```

Steps to reproduce:

1. Open the mobile app;
2. Try to register an account with a wrong password with multiple
   databases;
3. The snackbar is empty and no error is shown => bug;

Task ID: 2287176

closes odoo/odoo#64856

Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

In 13.0, some account.move.line fields (amount_currency, debit, credit
and account_id) couldn't have a value when the line is of type 'note'.
Skiping them during line copy for notes is not an issue.

During 12.0->13.0 migration, we were facing issues with "grouped similar
invoice lines in a single move line", because this feature is not
available anymore in 13.0. To avoid any "loss of data" during migration,
we used lines of type note to create "missing" invoice lines in move
lines without altering accounting in any way. As a consequence, we have
13.0 databases with lines of type note having values for fields who
couldn't have ones.

closes odoo/odoo#64954

X-original-commit: 677edafe
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

from #64626

closes odoo/odoo#64928

X-original-commit: 1a34778b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>

Before this commit the custom snippets were saved across websites
because the RPC mechanism used by the save & reload does not include the
context by default.

After this commit the custom snippets are saved for the specific website
as initially intended.
No migration is needed: already created snippets that have been created
across all sites will have the correct lifecycle because of the
copy-on-unlink system: trying to delete one will make it specific on
other websites.

Related to task-2374802

closes odoo/odoo#64917

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

When you are selling a kit in point_of_sale, the associated picking is
not validated. Because no quantity done is set on its component move
lines.

This has been caused by modifications made in following commit: https://github.com/odoo/odoo/commit/f9dd1d88d0d24914028464cc12b69ff0878346f8



OPW-2426992

closes odoo/odoo#64930

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

Following https://github.com/odoo/odoo/commit/d675dbaa4c7174591e0e7c1a3caf3e76877312ce



Also updated tests to be more consistant.

Regex used to find problematic lines:
`\btype\b.*\b(out|in)_(invoice|refund)\b`

closes odoo/odoo#64915

Related: odoo/enterprise#15908
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>