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>

*website

Steps to reproduce the bug:
- Add a Cover and a Picture snippet on the website.
- Change their visibility to "Conditionally".
- Change the order of the two snippets on the page either with the drag
and drop tool or with the "move up" or "move down" option.
=> Their order on the "Invisible Elements" panel has not been updated.

The problem is fixed by calling `_updateInvisibleDOM()` at the end of
`moveSnippet()` and `_onSnippetDragAndDropStop()`. Note that before this
commit, all the snippets with a conditional visibility were hidden at
the call of `_onSnippetDragAndDropStop()`. This is due to the call of
`cleanForSave()` from `_destroyEditors()`. `_onSnippetDragAndDropStop()`
has been adapted in order to, as for the "move" option, do not change
the visibility of those elements.

task-3203914

closes odoo/odoo#122454

X-original-commit: https://github.com/odoo/odoo/commit/e8ff70b1b85dc104750ca8a81833444a17a2e9bb


Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>

*web_editor, website

Steps to reproduce the bug:
- Add a Text-Image snippet.
- Change its visibility to "Conditionally".
- Save.
- Edit again.
=> The eye icon indicates that the snippet is not visible but the
snippet is displayed.

Note that [1] introduced a mechanism to solve this problem (the
`cleanForSave()` of the `ConditionalVisibility` option) but the code was
not working correctly since [2].

Let's first remember that when calling `toggleTargetVisibility()`, two
main actions are performed:
- The addition or suppression of the `data-invisible` attribute from the
dataset of an invisible element. This attribute is responsible for the
crossed or not of the eye icon in the "Invisible Elements" panel.
- The call to `onTargetHide()` or `onTargetShow()` that performs among
other things the addition or the suppression of the
`o_conditional_hidden` class on an invisible element. This class is
responsible for the visibility of the element on the page in edit mode.

This being said, here is what happened at the "Save" before this commit:
- `cleanForSave()` of `snippetEditor` is called. If the related element
has the `o_snippet_invisible` class, `toggleTargetVisibility(false)` is
called (meaning that the `o_conditional_hidden` class and the
`data-invisible` attribute are added to the element).

- `cleanForSave()` of the `ConditionalVisibility` option is called and
before [2], the `data-invisible` attribute was removed from the
corresponding element.

- At the `DOMContentLoaded`, the `o_conditional_hidden` class is removed
from all the elements that have a conditional visibility. The visibility
of those elements on the page now depends on the rule set by the user.

The goal of this commit is to restore the mechansim of the remove of the
`data-invisible` attribute from the conditionnal elements at the
`cleanForSave()`.

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

task-3203914

X-original-commit: https://github.com/odoo/odoo/commit/aae9053cbab6e0d3eda256a67fce98aced183ee7
Part-of: odoo/odoo#122454

Steps to reproduce the bug:
- Add a form snippet on the footer of the website page.
- Change the visibility of the form snippet to "conditionally".
- On the footer settings, deactivate the "Page Visibility".
=> The form snippet is still present on the "Invisible Elements" panel
but clicking on it has no effects. Indeed, it is inside the footer which
is hidden.

The goal of this commit is to reorganize the "Invisible Elements" panel
in order to better visualize the hierarchy between the different
invisible elements. To do so, the list of the invisible snippet elements
(`[...$invisibleSnippets]`) is scanned. Each invisible snippet that is
the descendant of another is discarded of the list (to only keep the
"root" ones) and a map is created with its `keys` set to invisible
snippets that have invisible descendants. The `value` corresponding to
an invisible snippet element is a list filled with all its descendant
invisible snippets except those that have a closer invisible snippet
ancestor. The list of the root snippets is then scanned. Each root
snippet is inserted in the DOM as well as their descendant snippets
found thanks to the newly created map.

Note that thanks to this commit, another problem is solved:
- Add a cookie bar on the website.
- Add a Text-Image snippet and change its visibility to "conditionally".
- Save and edit again. Note that the "Cookies Bar" is above the "Text-
Image" on the "Invisible Elements" panel.
- Click to display the cookie bar.
=> The order of the "Cookies Bar" and the "Text-Image" is switched on
the "Invisible Elements" panel.
Indeed, before this commit, the order of the snippets was influenced by
the order of their snippet editor creation. Because this order was not
always the same from one call to `_updateInvisibleDOM()` to another, a
glitch could happen when toggling a snippet visibility.
This is now fixed as the order of the invisible snippets in the
"Invisible Elements" panel is determined either by their order in the
list `rootInvisibleSnippetEls` or their order in the lists contained as
value in the map `descendantPerSnippet`.

task-3203914

X-original-commit: https://github.com/odoo/odoo/commit/3f10fc99c92176c7379ec7d460afb2feb87ecc23
Part-of: odoo/odoo#122454

ZeroDivsionError: float division to Zero is generated because for assigning
value to 'factor' of uom in method '_set_ratio', it tries to divide value by
Zero for uom_type 'Bigger'.

Steps to reproduce:
1) Install 'Inventory' module.
2) Click on 'Configuration' > 'Settings'.
3) Activate 'Units of Measure' > click on 'Units of Measure' button under it.
4) Click on 'Create' button to create new uom category.
5) Give any name > in 'Units of Measure' page, click on 'Add a line'.
6) Enter name and select type as 'Reference unit of measure for this category'.
7) Now, add another line and select type as 'Bigger than the the Reference unit
   of measure' and set the 'ratio' value to Zero, Error will be generated.

By applying this,it will check for the value of 'ratio' to prevent division by 0

sentry - 4174584503

closes odoo/odoo#122333

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

before this commit, on changing the product from bom is
not clearing the product variant field, if the product
variant feature is not activated in the database.

* activate the product variant in the db
* create a product and variants
* open bill of material, and set the created
product as product and set any variant in product
variant field
* now go to settings and disable product variant feature
* come back to same bom and change the product
* the product variant field will still have the other
product

onchange_product_tmpl_id is written to clear the
product variant field value, but as the product
variant field has group the onchange value is
not getting updated.

after this commit, on changing the product the product
variant field will get cleared even if the product
variant feature is not activated.

closes odoo/odoo#121859

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

Handling of 'None' return value from 'get_url_from_code' to
prevent crashes in 'request.redirect'

https://github.com/odoo/odoo/blob/05fc9a67335d5a96752d828defa066d4fdabe301/addons/link_tracker/models/link_tracker.py#L248-L255

Apply same logic as

https://github.com/odoo/odoo/blob/c46f4b908a73658ce2aa7fd9987fbac76a0dda00/addons/link_tracker/controller/main.py#L21-L24



sentry-4183731887

closes odoo/odoo#121405

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

- We refactored the VAT validation from a validation error to a warning that is stored in l10n_ec_vat_error
- Remove the "-" and "EC" from the base_vat in the EC validation/example
- Only validate the length in the base_vat
- Add compute field with the warning message in the l10n_ec

closes odoo/odoo#121099

Signed-off-by: Josse Colpaert <jco@odoo.com>

closes odoo/odoo#122570

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

qty_received_method is not recomputed if the product type change, and can lead to issues on existing purchases when trying to generate a Vendor Bill.

# HOW TO REPRODUCE:
- Create product P, type: Service, Control Policy: 'On Received Qty'
- Create PO for 1 unit of P (do not confirm)
- Update type of P to Storable
- Confirm PO, Receive Products
=> Qty Received is 0, not able to generate Bill

closes odoo/odoo#122353

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

When user create a pos category from 'restaurant.printer' model in
'pos_restaurant' module. it will give an error with the
 message -

'sequence item 0: expected str instance, bool found'

Steps to Produce:-

1. Install 'pos_restaurant' module
2. Go to 'point_of_sale' module
3. Go to 'Configuration' -> 'Order Printers'
4. Click on any printer or create new
5. Under 'Printed Product Categories' click 'Add a line'
6. Click 'New'

Trace-back will be generated.

Applying these changes will resolve this issue.

sentry - 4072172292

closes odoo/odoo#120519

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

**TicketBAI features**

- Generation of XML documents for invoices
- Automatic signing of documents with certificates
- Sending XML to the appropriate tax agency's servers
- Parsing and storing their response
- Preserving the invoice signature chain integrity
- Displaying the TicketBAI QR code on the invoice PDF
- Downloading XSD files for local validation
- Test mode using tax agencies' test servers

**Supported accounting flows**

- Posting and canceling invoices
- Foreign and national customers
- Multi-currency
- Refunds (credit notes)
- Discounts
- Simplified invoicing

**Not supported accounting flows**

- Specific VAT regimes
- Handling of third-party invoices
- XML generation and EDI operations for vendor bills (Bizkaia LROE)
- Modelo 140 (Bizkaia LROE)
- Invoice batching (Bikzaia LROE)

closes odoo/odoo#109907

Signed-off-by: Josse Colpaert <jco@odoo.com>