This commit fixes summing list of dicts returned by
_prepare_analytic_lines.

closes odoo/odoo#152819

Nb: This code is not yet covered by a test use case.
Signed-off-by: Cedric Snauwaert <csn@odoo.com>

Create a reconciliation model as follows:
- Type: Rule to match invoices/bills
- Match Invoice/bill with Label: False
- Match Invoice/bill with Note: False
- Match Invoice/bill with Reference: False
- Partner is set: False
Create an invoice for $900 and confirm it.
Create a bank statement line for $900, with no partner set.
Go to reconcile the bank statement line.

Issue: The invoice is not automatically suggested

This occurs because there is no check for the exact amount as in
previous version

opw-3648260

closes odoo/odoo#148171

Signed-off-by: Laurent Smet (las) <las@odoo.com>

        ZATCA changed the demo VAT code used with Sandbox, this commit aims to update the demo data in the l10n_sa_edi module

closes odoo/odoo#154256

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

Steps:
- In employee form
- Open studio
- Remove "Work Information" tab

Actual result:
- Traceback due to invalid xpath expression
- Invalid xpath due to duplicated name for a node

Expected result
- Tab is removed without traceback

opw-3754375

odoo/odoo@8e149728305133c6c460695a8d3eb25afbdcd17b

closes odoo/odoo#154776

X-original-commit: a566d414
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>

Since [1] when the mega menu were first introduced, to make their
edition possible, the bootstrap dropdown behavior was neutralized by
removing the `data-[bs-]toggle` attribute.

In [2] when Bootstrap was upgraded to version 5.1.3, the
`dataApiKeydownHandler` event handler that is called when up, down or
escape are pressed raises an error if `data-bs-toggle` cannot be found
on a previous sibling of the dropdown. This makes the approach chosen
in [1] incomplete.

This commit avoids this issue by temporarily adding a class that
is excluded from the event handler selector.
The patch must unfortunately be applied within bootstrap itself because
the event handler is registered right after the method is defined and
we have no way to access the registered event handlers afterwards.
This makes it impossible to patch the called method from outside, nor
its associated selector.

We cannot simply update the selector that was already patched by [3]
because it is also used by other methods.

A test is included which should mitigate the risk of accidentally losing
this patch upon bootstrap upgrades.

Steps to reproduce:
- Create a mega menu.
- Edit the page.
- Open the mega menu.
- Click inside the mega menu content to have a cursor selection.
- Press the arrow up key, the arrow down key or the escape key.

=> An error dialog was displayed.

The same issue happened with a nested menu instead of a mega menu.

[1]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
[2]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[3]: https://github.com/odoo/odoo/commit/daca8fe4e3da4a5ad5fabf3730496a3919af8abc



task-3614926
opw-3741670

closes odoo/odoo#154409

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

__getitem__() of BaseModel, reset the prefetch set of the recordset.
Fix _compute_activity_date_deadline, to batched the reading of
activity's deadline.

closes odoo/odoo#154728

X-original-commit: 8ffc0b76c9d7715c24802232b6a6ad98f42f1f76
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>

Steps to reproduce:
- In User settings add 'allocation reports' group to the admin User
- In Inventory settings enable allocation reports
- Create a stored product with 0/0 reordering rules and set a vendor
- Create an SO for that product
- Confirm the generated PO and click assign all on its receipt's allocation report
- Reduce the quantity on the SO and save

Bug:
a return is created instead of adjusting the quantity to deliver
the stock moves were not merged because their procurement method do not
match ('make_to_stock' / 'make_to_order')

Fix:
ignore procurement method when merging the moves
(introducing new config parameter)

opw-3621316

closes odoo/odoo#154658

X-original-commit: 54bd4416
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

Previously, exporting BIS3 when there is a 0% tax in the invoice will
results in the XML showing warning of UBL-CR-601. But if we do not
include any TaxExemptionReason reason at all, a fatal error BR-E-10 will
pop up.

Here is the details of those 2 rules:

```xml
(with context: /*/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory
[normalize-space(cbc:ID) = 'E'][cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT'])
      <assert id="BR-E-10" flag="fatal" test="exists(cbc:TaxExemptionReason) or
        exists(cbc:TaxExemptionReasonCode)">
          [BR-E-10]-A VAT breakdown (BG-23) with VAT Category code (BT-118)
          "Exempt from VAT" shall have a VAT exemption reason code (BT-121)
          or a VAT exemption reason text (BT-120). </assert>

and

(no context)
<assert id="UBL-CR-601" flag="warning" test="
  not((cac:InvoiceLine|cac:CreditNoteLine)/cac:Item/
       cac:ClassifiedTaxCategory/cbc:TaxExemptionReason)">
          [UBL-CR-601]-A UBL invoice should not include the InvoiceLine
          Item ClassifiedTaxCategory TaxExemptionReason </assert>
```

Based on these rules, we can conclude that:
- TaxExemptionReason must not appear in InvoiceLine/Item/ClassifiedTaxCategory
- TaxExemptionReason must appear (when some line in invoice has exempt tax)
  in TaxTotal/TaxSubtotal/TaxCategory

Previously, the TaxExemptionReason will appear on both places.
This commit fixes that and adds a test to ensure that when a 0% tax is
present, TaxExemptionReason only appear in TaxTotal/TaxSubtotal/TaxCategory

closes odoo/odoo#154597

Task-id: 3703206
X-original-commit: ff95a982
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Yosua Nicolaus (yoni) <yoni@odoo.com>

Steps to reproduce:
[account, iap credit]
- create a new invoice
- start to write "test" for the partner

Issue:
The partner autocomplete is not displayed

Cause:
in #150106 we add a condition for the quickCreate bypassing the possibility of having createEdit set to true

opw-3698400

closes odoo/odoo#153608

Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>

Before this commit, if a tax had multiple distribution lines, the
base amount was calculated for each line. This resulted in the base
amount being multiplied by the number of distribution lines. This issue
has been resolved by ensuring the base amount is counted only once for
each tax and line.

opw-3696800

closes odoo/odoo#152823

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

Issue:
=====
When you undo a column command, you won't be able to write on that line
anymore.

Steps to reproduce the issue:
=============================
- Go knowledge
- Use column command to add columns
- Do ctrl+z
- Try to write anything

Origin of the issue:
====================
When we apply a columns operations , it will use the current block and
insert it under the first column so the `ouid` of the block will change
to the `oid` of the div (the column) so will will have 2 mutations : one
to remove the block from the root and one to add the block under the
column.
Reverting history will do the operations in reverse order, so it will
remove the block from under the column and the add it under the root but
the `block.ouid` is already set to `oid` of  the column which is
different from the actual `ouid` which is `root` so adding any text to
the block will first add a textnode with `getOuid(node,true) =
block.ouid) != "root"` and `getOuid(node,false) = "root"` so it will
mark `this._toRollBack` as true and the operation is rolled back that's
why we can't add anything anymore.

Soltuion:
=========
Mark the `ouid` of the removed elements as undefined so when we insert
them again we can recalculate it correctly.

task-3693076

closes odoo/odoo#150431

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

When installing a new module, the access of the Default Template User
is propagated to any existing employee (introduced at
aefb05eb). This can be problematic in companies that don't
want all their employees to become manager by default.  Allow to
disable this behaviour in a settings.

This is the version of the patch targetting stable version that is not
configurable through the interface, manually creating an ICP
base_setup.default_user_rights_minimal=True as the way to change the
behaviour.

Closes odoo/odoo#149224
Task-id 3685856

closes odoo/odoo#150391

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

Steps to reproduce:
-------------------
- create a workorder that accepts employees;
- with a session for a user X, go to the "tablet view" and use employee A;
- with an other session for a user X, go to the "tablet view" and use employee B;
- leave employee A's tablet view.

Issue:
------
Employee B's time tracking is stopped instead of employee A's.

Cause:
------
The domain for selecting the `mrp.workcenter.productivity` record
does not take into account the employee, only the user.

We will therefore update the tracking time for the first record found,
i.e. the last record inserted in the database.

Solution:
---------
Override the domain which selects the record to be updated in the `mrp_workorder_hr` module,
so that a condition can be added to take account of the employee.

opw-3641703

closes odoo/odoo#149372

Related: odoo/enterprise#54301
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Bug
===
Because a context key is missing, the test will try to fetch the
metadata over the internet, and therefore trigger a warning on the
runbot.

closes odoo/odoo#154687

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

Steps to reproduce:
[l10n_sa_edi] [phonenumbers must be pip installed]
- create a customer with all needed information
- create an invoice with the customer
- confirm and process

Issue:
There will be a warning

Cause:
`phonenumbers` format the phone numbers with spaces -> len(phone) > max
size authorized by api

Note:
revert the https://github.com/odoo/odoo/pull/148124
and only apply the fix for l10n_sa_edi in order to avoid test break from https://github.com/odoo/odoo/blob/dceaf735fd2e46342dcd144c1969853a55d7b661/addons/l10n_account_edi_ubl_cii_tests/tests/test_xml_ubl_de.py#L104



opw-3666195

closes odoo/odoo#154255

X-original-commit: 5d845bd1
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>

This refactoring of action_unbuild() enhances its extensibility for stock_move_line creation.
Previously, passing additional values to the unbuild move lines necessitated a complete override
of the method due to its rigid design. With this refactoring, it is now possible to extend
the respective methods for preparing move line values, allowing for the addition of new values
or modification of existing ones.

closes odoo/odoo#151983

Signed-off-by: Steve Van Essche <svs@odoo.com>

It seems some people are getting an "unassigned variable 'balance'".
This shouldn't happen with the standard code because _get_write_off_move_lines_dict is only
called from the manual reconciliation widget in which, you only have access to models having
strictly lines being percentage or fixed (see get_reconcile_modelds_for_manual_reconciliation).
This method is not called from the bank reco widget pointed by "RECONCILE x ITEMS" on the accounting dashboard.
It probably comes from some customization but I don't know which ones.

github issue: 116064

closes odoo/odoo#154551

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

When a tax is set to inactive, the fiscal positions mapping other taxes to it continued to apply, disregarding the fact that it shouldn't be used anymore. Not anymore with this fix.

closes odoo/odoo#154464

X-original-commit: 91ad6a0c
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

When moving a product. We always do those operations:
- Search the quant for staring location
- Update it
- Search the quant for ending location
- Update it

However it's done for each `stock.move.line`.
So in case for example when you receive 10 000 serial numbers.
Their quant doesn't exist since they arrive in stock (main case,
exception could occurs). The system will be slow because it will
call search 10 000 * 2 to find some quants to update that doens't
exist yet.

In order to avoid a lot of useless queries. We do a more global search
on quants related to the selected moves and order them in a dict.
Later when we need them we just look in the dict values and pick them
from there.

closes odoo/odoo#146494

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

Currently it does a search for each lot name. It could be process only
once to find the existing ones.

Part-of: odoo/odoo#146494

use a set instead of recordset. Removing an item from the recordset is
O(n) and it's done at each loop operation resulting in a O(n²)

On top of it. The variable is call in a depends_context of a compute.
Extract the part of the computation that depends of it in another
private function and call it when needed.

Part-of: odoo/odoo#146494

This commit changes the computation of product having a negative forecasted
quantity to create manual orderpoints. The issue was that each replenish
location needed multiple `_read_group` on `stock.quant` and `stock.move`
on all storable product.

This commit makes only 3 `_read_group`s for all products x locations and
post process the group and quantity sum by location in Python.

This method gives some performance gain in time as well as in memory
consumption

closes odoo/odoo#149966

Task: 3653272
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

action_set_supplier doesn't have to overwrite the orderpoint.route_id if it already has one that fit the requirements (action = 'buy').

OPW-3746624

closes odoo/odoo#154436

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

'date_deadline' is always present in a 'stock.move' and in some specific cases, can prevent the merge of moves in the same transfer.
In the example bellow, new moves are added to the same transfer every day (for each scheduler run), but the moves are not merged together. There is 2 thing we could d oto fix this situation:
- Create a new transfer for each date_deadline
- Merge the move with distinct date_deadline

Usually, it makes sense to not merge moves with distinct date_deadline, but it also makes sense to not create a new resupply transfer every day.
So for now, we treat this situation as a limitation, but we still provide a workaround:

By adding a system parameter, we give the possibility to the user to ignore the date_deadline when merging moves.

## HOW TO REPRODUCE:
- Create new Warehouse 'Warehouse 2' WH2
- Create Custom Route to resupply 'WH/Stock' from 'Transit' From 'WH2/stock' (see screenshot)
- Create product P1 (storable, with custom route selected)
- Create reordering rule on default warehouse, with min=1, max=1, route=custom route
- Create Sale Order for 10 units of P1, confirm => New Receipt from 'Transit' -> 'WH/Stock' generated
- Wait 1 day (alternative is to increment the Lead Time on the Stock Rules).
- Create Sale Order for 10 units of P1, confirm => Same Receipt used, 2 lines are present.

OPW-3633551

closes odoo/odoo#154211

X-original-commit: 8bed8f89
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>

When the user creates a new record having a property field, the system
fetches the property definition of the parent record to retrieve the
field's default values (see: `_add_default_values`). If the user lacks
read access on the parent record, the user gets an access error when
retrieving the property definition of the parent record.

To prevent this error, we will perform a sudo call on the parent record
before reading the property definition of the parent record. This allow
the user to create a new record, even if they do not have access to the
parent record.

task-3594814

closes odoo/odoo#146265

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

Reproduction:

1. In project -> task, create a new task
2. In the description, make a table of 1 row 2 columns, type two line
long string in the second cell
3. Create a row above, type anything short, save
4. Add the portal user as follower, e.g. search user joel
5. In an incognito tab log in with portal portal, check the task and the
table is out of the field

Fix: we should not fix the columns' width when create a new head row in
the table, for extra long table, it should be scrollable

task-3559104

closes odoo/odoo#139016

Signed-off-by: Antoine Guenet (age) <age@odoo.com>

        This commit does two things:

        1) Global Discounts: When creating an invoice with a negative line, such as a Tax Invoice with global discount, we process the line as a document level allowance as required by ZATCA, and remove it from the lines sent in the UBL. This allows us to provide support for global discounts, such as those applied by promotion programs

        2) Add support for down-payment document type in _l10n_sa_get_invoice_type method: 386

closes odoo/odoo#154437

X-original-commit: a5aa6c9a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Mehdi Bendali Hacine (mebe) <mebe@odoo.com>

Description:
In a multi-company environment, `payment.provider` records are specific to each company. After activating Stripe on Company 1,
you can set a Website for the record if you wish. If you wish to activate Stripe for Company 2, Odoo will use `.copy()`
to create a new `payment.provider` record for Company 2. However, this will lead to differing incorrect behavior depending
on the version.

On 16, a new `payment.provider` record will be created, but will be connected to the Website set on Company 1's provider.

On 17, Odoo will throw an error after a `check_company` call reveals that the Website set on the new record is for the
wrong company, preventing the record from being created.

In both cases, the `.copy()` grabs the optional Website set on the existing `payment.provider` record to be used incorrectly
for the new record.

Desired behavior after PR is merged:
The Website relation is always neutralized when Odoo creates a new Stripe `payment.provider` record using the `.copy()` method

opw-3683338

closes odoo/odoo#154280

Signed-off-by: Joel Bluemel (jobl) <jobl@odoo.com>

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/c0cefe80a [REL] 16.0.33
https://github.com/odoo/o-spreadsheet/commit/02868d9ac

 [IMP] cell: avoid useless UPDATE_CELL Task: 3716689

closes odoo/odoo#154425

Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Steps to reproduce:
- Install Accounting and Purchase
- Create a PO with Purchase Representative different from current user
(e.g. Marc Demo)

1) - Mark the product as received
   - Create a bill from PO

2) - Go to Accounting
   - Create a bill
   - Select the PO in Auto-Complete field
   - Save the bill

Issue:
The Purchase Representative of the PO is set as Salesperson (hidden field) of the bill.
He should not. The default user (i.e. the current user) should be the Salesperson.
In the second case, by adding the purchase representative as Salesperson of the bill,
he is also added as a follower of the bill and he receives a notification about being
assigned to the bill.

opw-3677713

closes odoo/odoo#154318

X-original-commit: ea82d6e1936e285b9450409452ebab71d980f00f
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>

In cases where the cursor is at the end of the current block and the next block
begins with a zero-width space, the mechanism that skips these characters while
using arrow keys should not traverse all the way to the end of the zero-width
space in the next block. Because this mechanism operates before the browser
applies its own behavior for arrow keys, potentially causing the cursor to jump
to the start of the third block when second block only contains a zero-width
space, completely bypassing the second block. Conversely true for the arrow left
keys.

This commit ensures that the navigation does not extend beyond the current block
when searching for a `newFocusNode` when moving with arrow keys near zero-width
space.

task-3653307

closes odoo/odoo#153217

Signed-off-by: Antoine Guenet (age) <age@odoo.com>

When applying font color to a completely selected `td` containing  a empty `p`
tag, it results in a creation of a `font` tag after the `p` tag, as it checked
whether the `node.parentNode` is `EmptyBlock`.  Alongside with this, it should
also check if the node is 'BR'.

Part-of: odoo/odoo#153217

This commit fixes the issue of partial coloring of table cells.

Before this commit, if one colors part of the text in the cell
and then seeks to color the whole cell, the last coloring
would not apply on the previously colored text.

We do that by preventing the cell coloring to be done differently
than other elements except if we want to change the
background color.

task-3454903

Part-of: odoo/odoo#153217

If user created pricelist which applied discount on fixed prize delivery
and set the discount visibilty to be shown in sale order, the discount
would be applied twice. Due to stable version limitation, the visibility
of discount on sale order for pricelist discount for delivery is removed.

opw-3517879

closes odoo/odoo#152816

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

Current behavior:

Creating an SO with negative quantities for a storable product with an
invoicing policy of type "delivered quantities" automatically generates
a return move for the stocks. However, when this delivery is validated,
the delivered quantities are not updated on the SO. This is problematic
as these quantities are therefore not taken into account on the
associated invoice.

Expected behavior:

The delivered quantities should be updated negatively on the SO to
enable the invoicing of these lines.
This is already the behavior in the POS application and when you
create an SO with positive quantities followed by a return
for a larger quantity than the one delivered.

Steps to reproduce:

Create a storable product with an invoicing policy of type "delivered
quantities".

Create an SO with 2 lines:
   - a line with positive quantities for any other product.
   - a line with negative quantities for the product you created.

Confirm and validate the corresponding deliveries.
Return to the SO. The quantities for the second line are not updated.

Create an invoice. The second line is not taken into account.

Cause of the issue:

The to_refund field of the stock.move model defined in the stock_account
module enables a decrease of the delivered quantities in the associated
Sale Order. This field is set to True for "classic" returns but not for
the stock.move generated from sale.order.line with negative quantities.

Fix:

We rely on the _get_custom_move_fields method to add the to_refund
field in the procurement 'values' arguments in case the stock_account
module is not installed. It is then available to use in the
_get_stock_move_values method where we set its value to True if the
quantity is negative (so that the move should be considered as a refund)

opw-3676045

closes odoo/odoo#152466

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

Since commit [1], there is no outline when focusing a hoverable dropdown
by using the Tab key. This happens because of a CSS rule that was added
so no outline would appear when hovering the dropdown menus with the
mouse. However, it should still be displayed when using the keyboard,
for accessibility reasons.

This commit fixes that by always allowing the focus on the hoverable
dropdowns, except when they are hovered. If a focus was present on an
element in the document when hovering, its focus is kept (to have the
same behavior as in previous versions).

Steps to reproduce:
- Add a submenu and a mega menu with the menu editor.
- In edit mode, set the dropdowns as hoverable (set the "Sub Menus"
option to "On Hover") and save.
- Use the Tab key to navigate through the menus.
=> The simple menus have an outline but this is not the case for the
dropdowns.

[1]: https://github.com/odoo/odoo/commit/5846a05fe7bf587d3bfb3ace3e863cb4abd52132



task-3709755

closes odoo/odoo#151825

Signed-off-by: Robin Lejeune (role) <role@odoo.com>

Commit [1] added a rule whose intention was to unify the way our editor
labels look: capitalized. However, this is not working as intended for
translations as some languages have different rules for capitalization.

In the future, we will rely solely on the labels being written with the
intended capitalization in the first place (which is currently not the
case for dozens of English labels). As a fix, we keep the auto CSS rule
for English languages only. Hopefully, the amount of translations made
by translators being better than their auto-capitalized versions is
greater than non-capitalized English labels translated by mistake
without the auto-capitalization.

Note: this is the way python fields work too, they are not displayed
auto-capitalized in the webclient, although we want them to be.

[1]: https://github.com/odoo/odoo/commit/5db73c12d3ed14239dc81f60eec6c21d0f65af26



closes odoo/odoo#153661

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

Steps to reproduce
==================
1. Visit the website and open the event tab.
2. Access an event with the talks and exhibitor sub-menu.
3. Select the talks sub-menu and search for a talk
-> Even if the talk exists, the search count shows zero
-> The same thing happens in the exhibitor sub-menu

Technical
==========
When searching for the talk or the exhibitor we didn't send the search_count due
to this, it is always showing zero.
A variable sponsor is renamed to sorted_sponsors as it was redeclared in the
loop before the return dict.

After this commit
=================
Now the search_count will display the accurate result.

Task-3659940

closes odoo/odoo#147876

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

Issue:
=====
Undo of resize operation on table do 2 undos in a row.

Steps to reproduce the issue:
=============================
- Go to website editor
- Add a text block
- write `/table` to insert a table
- Resize the table
- Press `ctr+z` to undo
- The table is removed

Origin of the issue:
====================
The resize operation wasn't saved a step and is considered as draft
then it will be discarded and then the undo applied on the last saved
step that's why it appears as 2 undo in a row.

Solution:
=========
Call `historyStep` when we stop resizing.

task-3743697

closes odoo/odoo#153809

Signed-off-by: Antoine Guenet (age) <age@odoo.com>