When moving a package, the quant at source location is not
automatically removed

To reproduce the issue:
1. In Settings, enable
   - Packages
   - Storage Locations
2. Create a storable product P
3. Update the on hand quantity
   - 1 x P at WH/Stock in package PK
4. Create a planned delivery D with 1 x P
5. Confirm and reserve D
   - PK should be reserved
6. Validate
7. Open the package
   - Its location is "Partner Locations/Customers", which make sense
8. Inventory > Configuration > ... > Locations, open WH/Stock
9. Current Stock

Error: There is a line with PK. The quantity is 0 but still, it
create some confusion for the user who could believe that the package
is still in WH/Stock

This issue does not occur if the user goes through the product form
and click on the on hand quantity. The "incorrect" quant will not be
there. This is because, when loading the action, we call
`_quant_tasks`:
https://github.com/odoo/odoo/blob/05a7f5c04804423cfc3a833a1b3f0b5eec3fc147/addons/stock/models/stock_quant.py#L296-L300
This method will clean the quants (merge & unlink)

However, in the above case (step 9), the action is defined on XML side:
https://github.com/odoo/odoo/blob/7d4dfeb0e26b387dee312897264a68963f90267f/addons/stock/views/stock_location_views.xml#L24-L26
https://github.com/odoo/odoo/blob/d956e719d43c68abe6210e3136db576aaa6f60b8/addons/stock/views/stock_quant_views.xml#L190-L196


So, we can't make it behave as it does from the product form,
unfortunatly.

As alternative, we can try to call `_unlink_zero_quants` when we are
moving a package (and not `_quant_tasks` for perf matters as, so far,
we will not have any quant to merge)

OPW-3292238

closes odoo/odoo#122768

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

A raw query is not necessary to produce the desired result, found
activities need to be kept only if the corresponding record can be found
with standard search (which includes multi-company check).

Part of task-3266643

closes odoo/odoo#122698

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

Before this commit, the reversal of a passed exchange
move was not created on the correct date:

- If sequence is reset by month, the reversal should
  be created at the end of the month of the exchange
  move, and if sequence is reset by year, at the end
  of the year.

Steps:

- With a foreign currency X activated and two different
  rates few months in the past.
- Create and confirm an invoice with currency X at the
  date of the first rate.
- Register a payment at the date of the second rate
  (an exchange move is created).
- Unreconcile the payment from the invoice.
-> A reversal of the exchange move is created, but the
   date is wrong (set to today's date).

opw-2856385

closes odoo/odoo#122167

X-original-commit: d47cf44f
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>

Previous commit (https://github.com/odoo/odoo/pull/116570

) renamed
this method _get_subtasks_recursively.
But instead of calling itself in the return statment, the
method _get_all_subtasks was called resulting in a non-recursive
function and to potential undesired behavior as _get_all_subtasks calls
_get_subtask_ids_per_task_id that calls _get_subtasks_recursively in
some cases.

With this commit, we just call _get_subtasks_recursively on the children
to make it actually recursive, like it was in the first place.

closes odoo/odoo#122331

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

before this commit, in the payment transaction form
the field state_message(Message) is showing value
 too compactly

* accounting -> configuration -> payments ->
payment transactions

after this commit, the field will display value
properly utilizing the full width

closes odoo/odoo#122821

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

Steps to reproduce the bug:
- Drop the "Form" snippet on the website.
- Add a new field.
- Replace the field label by two quotation marks (`""`).
=> Traceback appears.

Since [1], it is possible for the user to create forms whose fields can
have a conditional visibility, meaning that the field is only visible if
another field in the form meets certain conditions. Due to that, there
is a mechanism that verifies if a condition on a field should be updated
when the user modifies the label of a field. To do so, a `querySelector`
is searching for an element that has a `data-visibility-dependency` set
to the previous field name by doing a querySelector of type
`querySelectorAll('.s_website_form_field[data-visibility-dependency="${previousInputName}"]')`.
Because `previousInputName` is set to `"`, it is not considered as a
character and an error is thrown.
To resolve this problem, strings that are stored in `name`, `data-name`
and `data-visibility-dependency` are encoded: All the occurrences of `"`
are replaced by `"`, all the occurrences of `'` are replaced by
`'` and all the occurrences of ``` ` ``` are replaced by `‘`.

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



opw-3246341

closes odoo/odoo#122769

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

The goal of this commit is to be able to use the `addCustomField`
function with a `type` argument that is different of `checkbox`,
`radio` or `select`.

opw-3246341

X-original-commit: 34b3770a
Part-of: odoo/odoo#122769

When processing several SMLs at once, the 'same product' policy of a
storage category is not respected

To reproduce the issue:
1. In Settings, enable:
   - Multi-Step Routes
   - Storage Categories
   - Packages
2. Create a Storage Category SC:
   - Allow New Product: same
3. Create two locations L1, L2:
   - Parent: WH/Stock
   - Type: Internal
   - Storage Category: SC
4. Create a putaway rule:
   - When in: WH/Stock
   - Package type: Pallet
   - Store to: WH/Stock
   - Having Category: SC
5. Edit the warehouse:
   - Incoming Shipments: 2 steps
6. Create two products P01, P02:
   - Type: Storable
7. Create a planned receipt R:
   - To: WH/Input
   - Operations:
     - 1 x P01
     - 1 x P02
8. Mark R as Todo
9. Create two packages:
   - 1 x P01 in PK01 (! PK01 must be a Pallet)
   - 1 x P02 in PK02 (! PK02 must be a Pallet)
10. Validate R
11. Open the related internal transfer

Error: Both packages are redirected to L1. Considering the product
policy of SC, one line should be redirected to L1 and the second one
to L2

To apply the product policy, the code looks at the quants of each
location. But it does not consider the incoming SMLs. Therefore, when
applying the putaway rule to the first SML, it selects L1 (which
makes sense). Then, for the second SML, because it does not see the
first one, it considers that L1 is empty and can be selected, hence
the error.

OPW-3204924

closes odoo/odoo#122742

X-original-commit: 8bde894638838b449d097e7d75092aa15c646c74
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

Since https://github.com/odoo/odoo/pull/121355

,
add_to_compute on no-store compute field, lead to recompute the field
at the end of request and it can lead to some non deterministic bug
(compute with a bad context by example).
Avoid to add_to_compute no-store or no-compute fields.

closes odoo/odoo#122496

Signed-off-by: Raphael Collet <rco@odoo.com>

We are reverting this commit (f9da3590) because
it is not compliant to the stable policy and is blocking users that had more than one cash
payment methods in configuring their pos.

opw-3331677

closes odoo/odoo#121959

X-original-commit: e61ceb54
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>

The fix introduced in odoo/odoo#114903 created another issue: changing
the work email would change the private email also, breaking the
seperation of the contacts for the employee.

The initial behavior was correct:
 - a res.partner for the work details (email, phone, etc.)
 - a res.partner (of type private) for the personal details of the
employee.

task-3284664

closes odoo/odoo#119460

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

Failing use case: While having purchase_stock installed, create and confirm a request for quotation, received some products but no bill for it. Now select the PO is the list, click on 'Action > Accrued Expense Entry'. Make sure the wizard will effectively create an accrued expense entry (it should be the case if you have some product received and not billed).
Upon confirmation of the wizard, the system will recompute the received quantity on the original PO, logging notes that pollutes, confuses and spams its followers.

The reason is that we use a new record to compute the difference between the received and billed quantities at a given date in the past, and even if track_qty_received is called on a newid, it will find back the original PO where doing line.order_id.

The solution is to check in the context if we're in such use case before logging, because we know that calling the accrued expense entry wizard aims not to change the received quantity in any wase

closes odoo/odoo#122662

X-original-commit: b31f1ad7
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

When performing the picking action in the context of savepoint, the env
inside the action can randomly change causing an AccessError which is
caught as UserError (in the current point_of_sale code). Flushing before
calling a method in a savepoint will deterministically avoid this issue.

Note that the weakset used to store environments was modified in #121604
to avoid this kind of issue.

When using a cr.savepoint, the transaction must be flushed but in we
don't have any reference to the env that should be used on the cursor,
meaning that the env is chosen in the list of existing env. This choice
is random because Transaction.envs is using a Weakset.

In some case, the chosen env does not have the correct access right
because the context allowed_company_ids is corresponding to a company
coming from another test, leading to an access error, hidden by the try
except.
Flushing the environment before creating the savepoint will help to
prevent this issue by flushing on a well defined environment.

Note that the weakset used to store environments was modified in #121604
(master)

closes odoo/odoo#121849

X-original-commit: 211f2fce
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

Before this PR, it wasn't possible to add a custom margin bottom into specific paperformat args.

closes odoo/odoo#112674

Task-id: 3171683
Related: odoo/enterprise#36760
Signed-off-by: John Laterre (jol) <jol@odoo.com>

[FIX] web, hr(_recruitment) : Fix the phone field widget text breaking in multiple lines This PR Fixes the phone widget in the hr views and adds back the possibility to SMS to mobile and phone task - 3242157

closes odoo/odoo#116168

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

Complement module to allow generate the PLE reports.

- Missing purchase tax groups and taxes added to complete the vendor
  bills flow
- Demo data completed to has data to allow generate the PLE reports
- Document types for vendor bills completed in the data
- Method to improve the domain in document types for customer invoices
  added
- Extend method to autocomplete the number on vendor bills with the
  standard expected by the document type.

closes odoo/odoo#118970

Related: odoo/enterprise#37382
Signed-off-by: Josse Colpaert <jco@odoo.com>

Before: in the accounting dashboard setup, an opening move was created in step 1 (accounting periods) and step 4 (chart of accounts)

Now: the opening move is only created in step 4 only when a first opening debit/credit is entered manually by our user.

Task-ID #3177315

closes odoo/odoo#120089

Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>

Before this commit, the widget value was updated (based on the current
state) prior to updating the snippet UI. As a result, the widget value
reflected used the non-updated UI labels.

task-3112890

closes odoo/odoo#122722

X-original-commit: 2eeab71c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Divyesh Vyas (divy) <divy@odoo.com>

With this commit, we make sure that the name
of an entry is well computed when changing
the journal in the form view.

Steps:

- With fresh db
- Open a new journal entry form
- Change the journal
-> The name doesn't change, it should change
   regarding the code of the journal

Also add a test for the fix which introduced
the issue 46e6ae29.

opw-3332590

closes odoo/odoo#122505

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

Steps to reprodue:
- Create a dropshipped product
- Sell the product to a client with a different language set
- Print the delivery slip

Bug:
delivery slip is currently being printed in the vendor's language

Fix:
Print the delivery slip in the client language when possible

opw-3193015

closes odoo/odoo#122789

X-original-commit: 2604caa305d82b53b6fc6b5f690135d6c715b496
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

The foreign currency should not be computed if it has already been set.
In cases where the transactions were imported with a foreign currency amount, it should not be changed when the user modifies the date.

Fix for
Task-3338560

closes odoo/odoo#122728

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

Ensure that, when creating a down-payment invoice for a SO with an incoterm, this invoice should have the same incoterm as the SO.

Steps:
1. Create a SO with an incoterm
2. Create a down-payment invoice for this SO
3. The new invoice should have the same incoterm as the SO

closes odoo/odoo#122538

Opw: 3284556
X-original-commit: 87542160
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: malv-odoo <malv@odoo.com>

This reverts commit bfadb8e4.

Since that commit, the domain may be double-encoded in the database if
the user reorganizes the layout of his dashboard: once by the JavaScript
code, and once by the serialization of the innerHTML property.

However, there is no need to have it double-encoded, and some tools such
as the upgrade scripts will fail upgrading the domain.

With this commit, we are serializing the document to XML instead of HTML
and therefore the produced output is valid XML that will be correctly
interpreted by all the tools.

However, double-encoded domains might still be present in existing
databases, so we also need to take this into account when reading the
domain.

OPW-3130117

closes odoo/odoo#119518

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/d27e9984 [REL] 16.0.11
https://github.com/odoo/o-spreadsheet/commit/7ae88427 [FIX] Chart Pannel: fixes updateChart process
https://github.com/odoo/o-spreadsheet/commit/57caf629

 [FIX] ColorPicker: modified add custom color icon Task: 3258627

closes odoo/odoo#122487

Related: odoo/enterprise#41577
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>

Fix a sign error in reconciliation that happened when
reconciling items in foreign currency and a not fully
matched credit, causing inconsistent partial amounts.

closes odoo/odoo#122644

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

If applied, this commit will solve the issue of keyError when we confirm the
manufacturing order and work order (s) are deleted.

Steps to produce:
- Configure BOM with 'Operations'.
- Set operations in the 'Consumed in Operation' field which is in 'Components'.
- Create MO using that BOM.
- Delete the work order(s) from MO.
- Click on the 'Confirm' button.

Fix this issue when the work order is not available for that operation,
setting False in stock.move record(s).

sentry - 4171798106

closes odoo/odoo#122115

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

When we create a public time off,
we save the start date and the end date in utc.
Unfortunately, to calculate the utc, we don't use
the calendar timezone linked to these public time off.

Issue:
For example, with the "timesheet_grid" module,
the timesheets created for these time offs
will not be correct for employees who have a calendar
in a different timezone than the user who creates the public time off.

Solution:
Convert the dates received in the calendar timezone.

opw-3302925

closes odoo/odoo#121171

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Since [this other commit], a traceback is displayed when the user wants
to see the pages of his site when he has only one site. Steps to
reproduce the bug fixed by this commit:
- Launch Odoo without any app installed and without demo data
- Connect to the DB
- Activate the Website module
- Skip the configurator
- Choose a theme
- Discard edit mode
- Go to Site > Pages
- Go to kanban view

=> An error is displayed because the record has no website_id.

[this other commit]: https://github.com/odoo/odoo/commit/f23399db1dfb816a68ecf1be4367234b6e9a28bc



task-3316267

closes odoo/odoo#121016

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Before this commit, calendar view in dark theme did not visually
show the disabled date, such as weekends.

In white theme it's fine because bg-view is white, so gray-200 on
white is visible. In dark theme, however, bg-view is identical to
gray-200, so it's not visible.

This commit fixes the issue specifically in dark theme by showing
disabled dates with gray-300.

closes odoo/odoo#119984

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

This commit fixes the issue of having duplicate iframes when dropping a
custom "s_map" snippet that has been saved by the user.

This issue was introduced by this commit [1].

Steps to reproduce the bug:
- Drag and drop a "s_map" snippet onto the page.
- Save this "s_map" snippet by clicking on the custom snippet "save"
button.
- Drag and drop the saved snippet onto the page.
- Observe that a duplicate iframe is created in the snippet.

This commit adds a check to verify if an iframe already exists before
adding it when dropping a "s_map" snippet.

[1]: https://github.com/odoo/odoo/commit/88194dd94182ad1bbdcb9aa8f855f30f6369d148



task-3340644

closes odoo/odoo#122645

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

The orginal PR and it's forward ports https://github.com/odoo/odoo/pull/121048


intorduced an unexpected AttributeError when using OAuth for incoming
mail servers (fetchmail.server). Since `smtp_user` is not a defined field
in fetchmail.server (it uses the field `user` instead), we had to change
the approach.

To prevent this error, we move the UserError call into the respective
ir_mail_server models, which should check the contrains at that level.
This means that before the form gets saved, trying to connect using an
OAuth account, should prompt the user to first specify an smtp_user before
proceeding.

X-original-commit: fcfd72a5
Original author: niyasraphy <niyasraphyk@gmail.com>
Conflict resolution for saas-15.2, 16.0

closes odoo/odoo#122613

X-original-commit: 3de5e2a1a0238b3edc5537aa5e3842ad5430a186
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>

[REF] account: Create function _get_aml_default_display_map to allow other modules to inherit and add new key pairs

closes odoo/odoo#122426

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

closes odoo/odoo#122334

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

Expected singleton: res.currency() when currency not provided
also when remove company in invoice.

Steps to Produce:-
- While go to invoice and click on `REGISTER PAYMENT`
- Remove currency from wizard

Traceback will be generated.

Applying this changes will resolve this issue.

sentry - 4149615534

closes odoo/odoo#121625

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

When working on an operation in workcenter that requires login, we can add multiple timers.
However, if multiple timers do not have an `end_date` and have different `loss_id`, we will get a traceback (expected singleton) when computing the interval duration.
After this fix, `_convert_to_duration` can be called with multiple productivity loss.

OPW-3292374

closes odoo/odoo#121112

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

And resynchronise terms based on pot

closes odoo/odoo#120331

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

closes odoo/odoo#122537

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

1.

Infinite loop may happen on using `parent_of`\`child_of` when there is a
recursion in the tree (e.g. a record is marked as a parent of itself). Fix it by
excluding seen records from the next iteration.

2.

Another problem with `child_of` is `parent_id` that references to another model.
For example, the `parent_id` may come from inherited model. It's the case with
`res.users` and `res.partner` models. It may lead to a random search results.
Avoid that by raising exception in case of wrong usage of the `child_of`
operator.

STEPS:

In demo data, there is a partner called "Wood Corner" that is `res.partner(9,)`
that has 3 sub-contacts. If we give Portal access to two of them, we end up with
a database, where we have a `res.users(9,)` record that has a partner, which has a
`parent_id` to "Wood corner". So this way, the user id is the same as the user's
partner's parent contact id.

After that open a shell and type:

```
env['res.partner'].search([["user_ids", "child_of", 9]])
```

BEFORE: infinite loop (without change n.1) or random search results (when change
n.1 is applied)
AFTER: ValueError exception

---

opw-2729740

closes odoo/odoo#122524

X-original-commit: a7352c644f5f12ca075546bd57912f849f9e20f2
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>

When user enters empty space in name field instead of entering an
actual name and confirm their billing, shipping address then when
they click on paynow to confirm order they will face the issue
'list index out of range'.

Note : Do the paypal configuration before following below steps.

Steps to produce:
1) Vist the website as a public user.
2) Create a sale order by adding some products to the cart.
3) While entering shipping and billing address, in the name field enter
some space.
4) Click on next button.
5) Now a sale order is created.
6) Go to orders through 'website' module.
7) Open the order created and generate a payment link.
8) Paste that payment link in another tab or browser .
9) Click on pay
10) By following above steps you will encounter the error.

This commit will prevent the above error.

sentry - 4177783431

closes odoo/odoo#122521

X-original-commit: 46f7bc3cdd80313290b4b72b9a9da49a09e548a4
Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>