add signature CLA for bosaeed

closes odoo/odoo#117836

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

A small part of the accounts type were incorrectly changed in Odoo 15 by odoo/83039
We are bringing the old type back.

Task link: https://www.odoo.com/web#id=3263687&model=project.task


task-3263687

closes odoo/odoo#117837

X-original-commit: aa95e273
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>

Some databases encounter an error when they try to upgrade when
they have more than one tax with the same name that violate
the tax name unique constraint (name, company_id, type_tax_use, tax_scope).
This will adapt the update of taxes script to handle this situation
by renaming such taxes to [old] taxname, [old1] taxname, etc.

opw-3178128

closes odoo/odoo#117771

Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>

When updating taxes we send a message to accounting advisors if
we duplicated tax(es) in the process so he can check if the
original tax is still relevant. This message was wrongly sent
multiple times per advisor when there was more than one advisor.

Task: 3178775
Part-of: odoo/odoo#117771

Adds more tests to the update of taxes.

Task: 3178775
Part-of: odoo/odoo#117771

Rework tests of the taxes update and fix PEP8 docstring rule violations.

Part-of: odoo/odoo#117771

Steps to reproduce:
​- In a snippet in grid mode, resize a column.
- Drag and drop this column in a non-grid dropzone. 
​- Undo.
​=> The column is back in the grid but is still a normal column. The same
happens when doing these steps with a normal column to a grid. 

This happens because the class changes are not observed in these cases.
When fixing the drag and drop history in [1], only the style changes
were observed because the class changes are automatically recorded. But
it is not the case after a resize.

This commit fixes that by also observing the class changes.

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



task-3151207

closes odoo/odoo#114818

Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>

This commit fixes some mistakes that were found in the code of the grid
layout option. More precisely:

- When a column was dropped near a grid dropzone (so not inside it), and
if its height was bigger than the grid, the `rowCount` attribute of the
row was not updated to the correct number of rows => there was one extra
row.

- When we start dragging a grid item, if we do not go over the starting
grid at all (it happens if the move handle is placed outside of the
row), the `rowCount` of the starting grid was never updated. This is
because the resize is done at the "out" of the dropzone so if there was
no "over", it cannot be done.
=> As a fix, the starting grid is now always resized when we drop the
column.

- When dropping a grid item inside a non-grid dropzone, its `z-index`
CSS property was not removed.

- When a grid item becomes a normal column, when dropping it in a non-
grid dropzone or when toggling the normal mode, the resize classes
(`g-col-lg-*` and `g-height-*`) were not removed from it.

- When a normal column becomes a grid item, the padding and offset
classes were not removed and the `col-` class was not systematically
synchronized with the `g-col-lg-*` class.

=> The two previous points need to be fixed because after doing multiple
drag and drops, the classes could become inconsistent. This happened
especially with columns whose width changes a lot between snippets (like
with Masonry columns, because of the padding).

- When going back to normal mode, the `--grid-item-padding-*` CSS
variables were not removed from the row.

- In commit [1], a comment that should have been modified has been
forgotten.

[1]: https://github.com/odoo/odoo/commit/67d1b078329600efce414974307d74e9fa9ba9fe

task-3151207

Part-of: odoo/odoo#114818

Before this commit, in large database, openning a sale.order can take 3s.
Because in module sale_purchase_stock, _get_purchase_order use a On2many field : stock_move_ids, with inverse field group_id.

Now it takes 200 ms.

closes odoo/odoo#117724

X-original-commit: 5fc448e7
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Before this commit, the cancel button is visible in the done state and
on clicking showing the validation that it cannot be cancelled.

by the commit:
https://github.com/odoo/odoo/commit/8d37cf462badc25d911d3fa6d3382c6f7418904f
one of the cancel button in the form is made hidden in the done state,
similarly applying for the other cancel button also.

also currently on trying to delete a done repair order, it says to
cancel first and then delete the order, from the commit:
https://github.com/odoo/odoo/commit/8d37cf462badc25d911d3fa6d3382c6f7418904f


cancelling a done record is prevented, thus modifying the warning
message and its related pot file

After this commit, the cancel button will not be visible in the done
state.

closes odoo/odoo#117714

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

Steps to reproduce the bug:

- Go to the website edit mode.
- Choose the 'vertical' template header.
- Select 'off-canvas' in the 'mobile menu' option of the navbar.
- Bug: On mobile view, the menu links are not clickable.

This is caused by the addition of the "order-first" class to the navbar
by commit [1], which causes the menu to be placed behind the backdrop in
mobile view when off-canvas is activated. This only happens with
Firefox, and there is likely a difference in how Chrome and Firefox
handle the "order" property based on the positioning of elements.

[1]: https://github.com/odoo/odoo/commit/2a000e33c5a44ddf0a777b43d8266cc413d8e4e2



opw-3009202

closes odoo/odoo#117648

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

Steps to reproduce:

- Install website_mass_mailing
- Go to the frontend and activate the editor.
- Add a newsletter block, change it to subscription form.

Issue: The name of the newsletter is displaying also the number of
subscribers (e.g. "Newsletter (1)").

Solution: Change the name we are using to display the newsletter name to
use the `name` and not the `display_name`.

opw-3145571

closes odoo/odoo#117582

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

After the migration of Bootstrap to 5.1.3, the `col-*` elements no longer
have a relative positionning. As a result, most elements having an absolute
position and placed relatively to those elements will be incorrectly placed.

In website_event, the badges of the event cards are currently placed on
the upper border of the card because they are now placed relatively to
the whole card instead of the card body container having a `col-*` class.
As a result, the badges isn't where it should be and get cropped by the
container.

Steps to reproduce the issue:
1. Create a new event
2. Set a template
3. Go to the /event page
4. Click on the edit button from the Odoo navbar to edit the page (editor)
5. Go to the "Customize" page
6. Click on the "Templates" toggle button

To fix that issue, we will add a `position-relative` class on the card
body container having the `col-*` class. This ensure that the badge will
be placed as before between the card body and the card image.

task-3251110

closes odoo/odoo#116879

Signed-off-by: Stéphane Debauche (std) <std@odoo.com>

Steps to reproduce the bug:
- Go on the blog of the website.
- Edit.
- In the "Customize" section, apply the "List" "Layout" and activate
the "Sidebar".

-> The sidebar appears at the bottom of the page instead of on the
side.

The situation looks like this:
```html
<div class="container">
    <div class="row">
        <div class="col"></div>
        <div class="border-end"></div>
        <div class="col-12"></div>
    </div>
</div>
```
The bug comes from the fact that the `div` with the `border-end` class
is inside a `row` class. Due to that, a bootstrap 5 css rule applies
and puts the `width` of the `div.border-end` element to `100%`. Because
the element tries to fill the entire width of the `div.row`, it is put
at the bottom of the page as well as its following elements (in this
case, the sidebar). By applying an automatic width for the
`.border-end` elements inside `.row` element, the border as well as the
sidebar are displayed as wanted.

opw-3217775

closes odoo/odoo#116354

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

before this commit the lot field is visible even without activating the
lot and serial number feature from the settings.

after this commit the field will be visible only when the feature is
activated in the settings.

closes odoo/odoo#113030

X-original-commit: fb0940d6
Related: odoo/enterprise#37251
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

The analytic distribution json field may contain a deleted analytic account.
This causes 2 issues:
- When retrieving plans - the analytic account ids are used to force additional plans (maybe applied by a model) - causing a record does not exist error
- Opening and closing the popup is required to 'clean' the distribution. this is not ideal as a draft invoice will not display the deleted account, but it is still in the json.

With this fix, the analytic accounts existence is checked, and the distribution json is saved without the deleted account.

closes odoo/odoo#117762

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

When opening the Time Off App, the JS performs an rpc to call
hr_leave_type.get_days_all_request. Inside this method there are
some __get__ on non-stored computed fields. This triggers
a recomputation of said fields in _compute_leaves. _compute_leaves
uses _get_employees_days_per_allocation.

When there is an hr.leave.type with request_unit = 'hour', you may
get lots of validated allocations by employee. When this is the case,
_get_employees_days_per_allocation gets quite slow, especially the last
part about 'Future available leaves'.

This commit optimizes this part of _get_employees_days_per_allocation.
In this part the allocations are grouped by employees
and Intervals instances are of the form (start, stop, records). This means
that for a given employee_id, all the records of one Intervals will have
the same start and stop values. This allows us to move the call to
_get_work_days_data_batch outside of the
for future_allocation_interval in future_allocation_intervals._items loop.
Because _get_work_days_data_batch is quite expansive, moving it out
grealty speeds up the _get_employees_days_per_allocation method.

Example speedup: in a database with 50 validated allocations for
the same hr.leave.type and employee_id, the timing of
_get_employees_days_per_allocation 7.39s -> 158ms

opw-3123457

closes odoo/odoo#117754

X-original-commit: 5a2efd2e
Signed-off-by: Kevin Baptiste <kba@odoo.com>

Issue:
With the "Extra Step During Checkout" setting,
it is possible to click on the "Configure Form" button
which should redirect us to the form in order to edit it.
However, we will always be redirected to the first website
(even if we have modified it in the settings).
Furthermore, if we don't have a cart in progress,
we will be redirected to the shop.

Solution:
Add a parameter specifying that it is for editing.
In this way, we can modify the form without having to create a cart.
Due to a technical limitation (reloading settings after saving),
we will always be redirected to the first website.
But it is possible to change the website (with the website editor)
and modify the second website if necessary.

opw-3245772

closes odoo/odoo#116975

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Before this commit: if there wasn't any mail group, and you add a
"Discussion Group" component to the website it will raise an error. The
problem is that the `'website.prompt` wasn't loaded.

The solution is to add the `website.xml` file path to
`web.assets_backend` in the website manifest.

opw-3184203

closes odoo/odoo#114476

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

Remove an option used by the phone widget in the res_user view.

task - 3246848

closes odoo/odoo#116727

Related: odoo/enterprise#38719
Signed-off-by: Kevin Baptiste <kba@odoo.com>

Steps:
- Install Project
- portal view > task

Issue:
- the private task was displayed in the portal view

Cause:
- the domain was not set for the private portal project

Fix:
- displayed task whose project_id is not false
- so private project was not displayed in the portal view

task-3147011

closes odoo/odoo#117617

X-orignal-commit: https://github.com/odoo/odoo/pull/111456/commits/2c00c7d37cf66601e7a25e22d6170973ea78b158


Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

When we use a 12 hour time format (without the `%p`), the time set is
always in the morning regardless of the period used (AM or PM).
Using `preparse` and `postformat` in the locale to change the symbols
used for numbers prevents the user from changing the date in the
datepicker because the date will be unparsable

Steps to reproduce:
1. Install Calendar
2. Go to Settings > Translations > Languages and open 'English (US)'
3. Set the time format to `%I:%M:%S`
4. Open Calendar and create a new meeting in the morning
5. Edit the meeting, set the time period to 'PM' and save
6. The time of the meeting doesn't change

Solution:
Get the time from the event passed when we close the bootstrap
DateTimePicker and convert it to luxon.
The period displayed when we open the datepicker is always 'AM'. This is
a limitation with the bootstrap DateTimePicker that uses the value from
the element[^1] (which is already formatted with the 12 hour format,
without the period info). Hence, the time is always in the morning

Problem:
The value of the element is used to set the date but this value is
already formatted with the 12 hour format (without the period info) so
it's always in the morning

opw-3150033
opw-3233229

[^1]:https://github.com/odoo/odoo/blob/16.0/addons/web/static/lib/tempusdominus/tempusdominus.js#L395



closes odoo/odoo#117141

Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

Steps to reproduce the bug:
- Go to the warehouse settings:
    - enable “3 steps for manufacturing”
- Create a storable product “P1” with 2 BoM
- Create an orderpoint:
    - Preferred route: Manufacturing
    - Product: “P1”
    - BoM: select the second BoM
    - To order: 1

- Click on the “Order once” button

Problem:
The manufacturing order is created with the first BoM instead of the
second.

As we are in 3 steps, the “run_pull” function is triggered first, with
values prepared from the orderpoint so the bom is well set:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_orderpoint.py#L515-L523

Then the “run_manufacture” function is triggered but with vals prepared
from the move, not from the orderpoint, so we lose the BoM information
that the user has selected:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_move.py#L1334-L1340



opw-3217945

closes odoo/odoo#117703

X-original-commit: 2371cd29e1c0cfa54b682b2100b9db7f5633a7b4
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>

Incorporate Andy Quijada (ajqn9094) as Vauxoo's contributor.

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#117697

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

Steps to reproduce:
- Activate Analytic Account
- Create a Service Product - create project on order
- Create a quotation with the product
- Confirm the quotation
- Go on the project -> analytic account is "order # - partner_name"
- On the quotation - Create Invoice

Issue 1:
- The invoice has "order #" has the analytic account and not the "order # - partner_name"

Issue 2:
- if you create an invoice and wants to select the analytic account
  you cannot search it by the partner name, only by the "order #"

Cause:
When confirming the quotation, we create an analytic account. The
default name of the analytic account is the order name:
https://github.com/odoo/odoo/blob/bba5b6a440544151cc610bbc6848adfbadb38bfb/addons/sale/models/sale_order.py#L1416

Why is the analytic account displayed correctly on the project?
Because we use the `get_name` is triggered:
https://github.com/odoo/odoo/blob/bff34e0e8a8b2d211ef90ffea4f43c514e8cad28/addons/analytic/models/analytic_account.py#L115-L123



In the analytic distribution view, we only render the name of the
analytic account as it is defined primarly.

opw-3165655

closes odoo/odoo#113737

Signed-off-by: William André (wan) <wan@odoo.com>

duration_percent field is a stored integer.
In postgresql, integer are 4 Bytes long, which create a range of -2147483648 to +2147483647.
With a small duration_expected, and a big duration, we can easily break these limits.

OPW-3253333

closes odoo/odoo#117737

X-original-commit: 97892d04
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>

closes odoo/odoo#117685

X-original-commit: 8b98ad868f7810d9fdcf26a355a646b3eed53410
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

[FIX] account_edi_ubl_cii: wrong journal selected when uploading an invoice in a company with multiple journals of the same type

Steps to reproduce:
- Create two sales journals
- Select the second journal
- Upload an invoice
- The invoice is in the first journal instead of the second

Fix:
We can simply use the context to retrieve the current selected journal
if it's given, otherwise we use the previous fallback (infering the
journal with the move type)

task-id 3258956

closes odoo/odoo#117491

Signed-off-by: William André (wan) <wan@odoo.com>

steps:
project > kanban card > task analysis > list view of report

cause:
trying to open a project from the list view

issue:
looking for __count in read_group

fix:
add no_open to project_id in the list view because we can open a project from
kanban card and configuration

task-3111378

closes odoo/odoo#110405

Related: odoo/enterprise#34517
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Before this commit, having an accrual plan with no
level before a certain amount of time would result
in a crash because no relevant level is found.
This commit avoid that error.

closes odoo/odoo#117635

Signed-off-by: Kevin Baptiste <kba@odoo.com>

Current behavior:
In the pos order report the margin is not shown for products with no
cost.

Steps to reproduce:
- Create a product with no cost
- Open a pos session, add the product to the order and validate it
- Go to the pos order report and check the margin for the product
- The margin is not shown

opw-3232131

closes odoo/odoo#117328

X-original-commit: 08fa7015
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>

Since 8fb53c53, Order model is no longer
a backbone model therefore, we can no longer call the "trigger" method
on it. Normally, the old "trigger" call means we want to rerender the
screen and persist the new order information in the local storage.
The order object is already setup to do those mentioned (rerendering
and saving to local storage) when it's mutated. Therefore, we can just
simply remove the "order.trigger" and "this.render" calls as proposed
in this commit.

closes odoo/odoo#116642

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Incorporate Rolando Duarte (rolandojduartem) as Vauxoo's contributor.

I confirm I have signed the CLA and read the PR guidelines at:
www.odoo.com/submit-pr

closes odoo/odoo#117600

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

On a calendar event, the 'free' option does not hide the element.
So that the user doesn't expect this behavior,
you have to modify its description.

opw-3047999

closes odoo/odoo#117599

X-original-commit: ecc850f4
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>

Current behavior:
When you create a contact and a delivery adress for this contact. If you
add the delivery adress as a vendor to a product, and purchase this
product from the delivery adress, the contact will be added to the
product vendor list.

Steps to reproduce:
- Create contact C
- Create delivery adress D for C
- Create product P
- Add D as a vendor to P
- Create PO for P from D, and confirm it
- Go to P, and check the vendor list (C is there)

opw-3177309

closes odoo/odoo#117594

X-original-commit: c98a0d0454150a2f9d2fae56daf60a45ebe2fa84
Signed-off-by: Engels Robin (roen) <roen@odoo.com>

If applied, this commit will solve the issue of the archived pos config issue
while session accessed from another tab, another device, or another user.

Steps to produce:
- Open the pos session.
- From another device or another tab archive the pos.config record.
- Refresh the opened session.

sentry - 4057306284
see - https://tinyurl.com/2opdugz4



closes odoo/odoo#117584

Signed-off-by: Achraf <abz@odoo.com>

PaymentScreenTotalDueWithOverPayment result to random runbot error because the
test is performing a series of steps that clicks the validate button which will
randomly result to going to the ReceiptScreen which is not the goal of the test.

In this commit, we replace the use of `pay` method with a more granular series
of steps to make sure that the test doesn't click the validate button and will
properly make the succeeding checks on the amounts in the PaymentScreen.

closes odoo/odoo#117501

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

Steps to reproduce the bug:
- Create a Storable product “C1” tracked by Lot:
    - Update the Qty to 10

- Create a Storable product “P1”:
    - Add a BoM:
        - add 1 unit of  “C1” as component

- Enable 3 steps for the manufacturing operation in warehouse settings

- Create a Mo to produce 1 unit of “P1”:
    - Confirm the MO
    - Click on related transfer:
        - Select the “Pick component”
        - check that the qty is reserved correctly
        - Try to validate it without setting Qty done
        - The immediate transfer is triggered, validate it

Problem:
The backorder's wizard triggers when it shouldn't

To know if we should create a backorder, we check if the qty reserved
is equal to the qty done, and as the qty done was not set correctly
during the validation of the immediate transfer, the two quantities
are not identical, therefore the widget is trigger:

https://github.com/odoo/odoo/blob/15.0/addons/stock/models/stock_picking.py#L1128-L1132



opw-3240264

closes odoo/odoo#117467

X-original-commit: dff171b22cd38bb33a360ef87bf82dafbab953cd
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>

Current behaviour:
Cannot add a Work Order to a Manufacturing Order
if the analytic account linked to the MO doesn't
have an associated company.

Expected behaviour:
Should be able to add a WO to a MO even
if the linked analytic account doesn't have
an associated company.

Steps to reproduce:
1. Activate analytic accounts
2. Activate work orders
3. Create an analytic account without company associated
4. Create a Manufacturing Order
5. In miscellaneous, link the analytic account
6. Try to add a WO line
7. Error log

Reason for the problem:
When trying to add a WO line, if the MO has been linked
to an analytic account, it checks for the currency in
the company in the analytic account, which was not
existent, since the company didn't exist.

Fix:
When trying to access currency, if the company in the analytic
account doesn't exist, it defaults to the company in the WO.

opw-3210708

closes odoo/odoo#117410

X-original-commit: b7826da2
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Demany Antoine (ande) <ande@odoo.com>

closes odoo/odoo#115770

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