- Add group bys, columns, and filters to Bank Reconciliation models for better navigation and organization
- Trigger auto-validate cron on saving Reconciliation model with auto-validate enabled
- Restore pre-filled elements when creating Reconciliation model through bank reconciliation widget (V15.2 functionality)
- Remove text ellipsis from Reconciliation model buttons in bank reconciliation widget for better readability

closes odoo/odoo#117822

Task-id: 3253304
Related: odoo/enterprise#39393
Signed-off-by: Laurent Smet <las@odoo.com>

Delete the autoplay for all iframes in the iframefallback.
The autoplay was causing issue where the sound of the previous video
was played on the background. Now we delete the autoplay for all iframe
directly.
This happened in media_iframe_video, youtube player and vimeo videos.
We can do this for all iframe source url directly as it impacts other
modules like website_slides or website_event_track_live.

task-3012952

closes odoo/odoo#112868

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

Turn the call to filtered after the search on purchase.order.line
into a call to _search. This allows to remove filtered by adding
an additional leaf in the search domain.

Add read calls to fetch fields from db and store them in cache
on recordset batches.

Example speedup: partner with 136555 POL 6.33s -> 3.42s

opw-3277299

closes odoo/odoo#122213

X-original-commit: b3e81b09
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>

The visibility of the "Print" DDT button wasn't taking into
consideration the dropshipping case.

closes odoo/odoo#122034

Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

Have an IT company configured
Activate Dropship
Create a Product P with dropship enabled and vendor configured
Create a quotation to an IT customer, add P to a line, confirm.
Purchase will be created automatically, confirm it.
Go to dropship picking, confirm, print

The DDT report does not show up correctly:
- Warehouse address is the company address
- Customer address is the vendor address

opw-3128812

Part-of: odoo/odoo#122034

Steps to reproduce the bug:
- Create a storable product with BoM:
    - add any product as component
    - save
    - Click on the BoM overview widget
    - Change the quantity of a BOM with a number that has a decimal
        value.

Problem:
The quantity is converted to an integer because this input does not
accept a decimal value.

opw-3288403

closes odoo/odoo#121801

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

Steps to reproduce:
configure easypost for international shipping (e.g. using USPS)
Make a sale order for a customer in another country
Add a discount program (e.g. 10% off)
Attempt to add shipping and get the rates
Get traceback:
`Easypost returned an error: Wrong parameter type.
- value: must be greater than or equal to 0`

To fix this we need to exclude service type products when creating
commodities from order lines (similar to creating commodities from
stock move lines)

opw-3269467

closes odoo/odoo#121123

Signed-off-by: Tiffany Chang <tic@odoo.com>

Steps to reproduce:

1. Create a bill from document,
2. Fill in PO in auto complete, confirm, check the bills list.
3. The source document is not populated in the list.

What is the current behavior that you observe?
The source document is in the log, but does not show up in the dashboard.

What would be your expected behavior in this case?
The PO should show up in the source document in the list

OPW-3284992

closes odoo/odoo#121562

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

before this commit, on creating a new payment method
will show traceback.

* using studio add a menu for payment method
* create a payment method and hit on create
* traceback is shown

after this commit, no traceback wont be shown.

closes odoo/odoo#122129

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

Before this patch the naive dsn parser `_dsn_to_dict` would choke
on `application_name` containing spaces or the equal sign.

closes odoo/odoo#122010

Signed-off-by: Fabien Meghazi (fme) <fme@odoo.com>

The value of custom ptavs is store on the sale order line.

Currently, they are ordered by ptav id but they are ordered by the ptav
sequence everywhere in Odoo.

Now, on the sale order line, custom ptav are ordered by ptav sequence.

opw-3234669

closes odoo/odoo#122161

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

To reproduce the issue:
(Need `stock_barcode` and a real barcode scanner)
1. Create two products P01 and P02, each one with a barcode
2. Barcode > Operations > Receipts, Create
3. Scan P01
4. Scan P02
5. Click on the `+1` button on the line of P01
6. Scan P02

Error: Both lines are incremented. Scanning P01 should not impact the
quantity of P01

Because of step 5, the focus is still on that button when scanning
again P02 (step 6). Moreover, the scanner ends the barcode transmission
of P02 with an `enter` -> it will generate an event on the `+1` button,
which explains why the quantity of P01 is also incremented.

OPW-3232437

closes odoo/odoo#122125

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

Numbers should be alinged on the right in rtl langauge same as ltr langs

Steps to reproduce the isse :
1- Change the language to arabic
2- To to the list of invoices in accounting and you can see that the numbers are aligned to the left

The origin of the problem is that rtlcss reverse the alignment from right to left

opw-3295573

closes odoo/odoo#121689

Signed-off-by: Bruno Boi (boi) <boi@odoo.com>

The discuss app uses an url regex in order to find links and
transform them to html before posting a message.

Before this commit, some unsafe url characters  were missing
from this regex, resulting in incorrectly parsed url.

This commit adds missing characters in order to match RFC1738
[1].

[1]: https://www.ietf.org/rfc/rfc1738.txt



closes odoo/odoo#122093

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

closes odoo/odoo#122042

Related: odoo/enterprise#41329
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Before this commit, trying to access "My Time Off" was
not possible if connected on a company while some leaves
were created from another company.
This commit restricts that view to the leave created from
the companies the user is logged into.

closes odoo/odoo#122039

Signed-off-by: Gvaladze Sopiko (sgv) <sgv@odoo.com>

Before this PR:
The only way to neutralize the database is running cli command neutralize

After this PR:
There is a new checkbox "neutralize database" in Duplicate database and Restore database dialog that neutralize the database after duplication/restore.
I also moved the neutralization code to the external module so it can be called also outside the cli .

closes odoo/odoo#121569

Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

Currently, if you use the automatic entry wizard to change the period of
a journal item dated prior to the lock date, you'll just get blocked
with a UserError, with no workaround.

This commit changes the date of the adjustment entry to be the first end
of month after the lock date. As a result, the adjustment entry can be
created.

Based on PR #92439

closes odoo/odoo#121566

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

At the moment, the lock date message is generated in
_compute_tax_lock_date_message. We delegate it to a separate function
in order to use this message elsewhere as well.

Note: this refactor introduces minor changes in behaviour:
- we remove the second part of the lock date message (that mentions
  other lock dates than the most blocking one), because it is too much
  information.

- we calculate the new accounting date from the existing accounting date
  rather than from the existing invoice date. This should not change
  anything in practice, since the new accounting date will be the last
  day of the period after the lock date.

task-2823170

Part-of: odoo/odoo#121566

Current behaviour:
If we add a blockquote in the `website_description` of a product on
the e-shop, we cannot checkout the product. Silent HTTP 400 error
code, due to an exception raised by
https://github.com/odoo/odoo/blob/bf772181933ce5334da35c8368455963b2478399/odoo/fields.py#L1987-L1993



Expected behaviour:
You should be able to checkout products even if they have blockquote
in their `website_description`.

Steps to reproduce:
- Install eCommerce, sale_quotation_builder (issue is present only
  after installing sale_quotation_builder)
- On a product, with the website editor, add a `blockquote` to the
  description of the product > Save
- In a private browser window, as public user, visit the product on
  the e-shop and try to checkout with it.
- Observe there is no visible error, and we do not proceed in the
  checkout process.

Reason for the problem:
The exception mentioned above is triggered when there is a
difference between the html content that is saved in the DB and after
sanitization, meaning that someone with escalated privilege saved
the HTML content by overriding the sanitization with
`sanitize_overridable`. In our use case the only diff is the
presence of the attribute `data-o-mail-quote-node` which is removed
after the sanitization.

Fix:
This issue can be resolved two ways:
1) Adding `data-o-mail-quote-node` to the list of save attributes,
   meaning it will not be removed during the sanitization process.
   Since this is an attribute that we add on `<blockquote>` nodes,
   it can be considered safe, just like `data-o-mail-quote`.
2) Remove the attribute sanitization of the `website_description`,
   just like it is done in the website_sale module.
   Since the `website_description` and `quotation_description` are both
   computed from one-another, they should have the same sanitization
   level.
I am implementing both solutions, 1) because adding the attribute to
the safe list seems safe in general, and may prevent future
issues of this sort. 2) because it is the root cause of the issue,
since the bug is present only after installation of the
`sale_quotation_builder` module.

Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- master

opw-3297237

closes odoo/odoo#120764

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

In Knowledge, the scrollParent for the `Y` axis of an embedded ungrouped Kanban
view is the article body, which contains the draggable `container` (which is
itself contained in the scrollParent for the `X` axis).

This commit introduce 2 fixes related to the `draggable_hook_builder`:
- In `draggable_hook_builder`, `updateRects` was modifying values of the
  `containerRect` from values of the `scrollParent`. Then, the `containerRect`
  was used in `handleEdgeScrolling` to compute a scroll value to apply on the
  `scrollParent`, and when updating the dragged element position, to compute the
  boundaries for the dragged element. This commit stores values for
  `scrollParent` in `scrollParentRect` alongside the modified `containerRect`.
  `scrollParentRect` will be used to compute the scroll value based only on the
  dimensions of the scrollParent, and the modified `containerRect` will be used
  to compute the boundaries.
- The `scrollParent` in the `X` axis can be different from the `scrollParent` in
  the `Y` axis. This commit stores both of them individually so that one is not
  neglected when higher in the DOM than the other.

Task-3291771

closes odoo/odoo#121089

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

Some tests use methods that have two different implementations (one for
desktop and one for mobile). So far, the only example is deleteBackward
and its mobile counterpart deleteBackwardMobile.

This commit introduces a mechanism in the web_editor tests to avoid
duplicating such tests. When a test calls a method that has two
implementations, it uses the desktop one by default and a flag is set
that indicates the test should be re-run with its mobile implementation
next.

When errors are raised while the mobile version is in use, we prefix
their message with '[MOBILE VERSION]' to ease debugging.

Note that this mechanism relies on proper flag management by the
aforementioned methods.

Task-3054808

closes odoo/odoo#121977

X-original-commit: 712382c6ae200037c58a6677069c5f2ae783ccec
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

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

closes odoo/odoo#121861

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

An UBL Bis 3 xml can only contain one tax per invoice line. However,
there might be one or more ecotaxes on invoice lines in Belgium. Do not
block the user from generating the attachment in this case.

Note that PR https://github.com/odoo/odoo/pull/121494

 will properly
handle the fixed taxes upon generating UBL attachments.

opw-3318969

closes odoo/odoo#121854

X-original-commit: 68814f52
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>

When passing a very large expression to `literal_eval`, the odoo server crashes.
To avoid this behavior, a limit needs to be set by using the env varaible `ODOO_LIMIT_LITEVAL_BUFFER`.
If the variable is not set, it defaults to 100Kib.

closes odoo/odoo#121719

X-original-commit: 0e4f3ac4
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Signed-off-by: Dalcq Jordan (joda) <joda@odoo.com>

Two issues solved in 1 commit; as their solutions depend on one another.

** ISSUE 1 **

To reproduce the issue, on a l10n with a tax report:
- Create a misc operation with a tax on it in the same form as a sales invoice ; post it.
- Reverse that move, and post the reverse.

=> Open the tax report: the amounts of the original move (for both tax lines and base lines) are doubled.
That's not what we want ; instead, the reverse should have entirely canceled the original move.

This is due to the fact the is_refund field of account.move.line is badly computed on the reverse: both tax and base lines are considered refund. Because of that, tax_tag_invert gets inverted, and ends up doubling the amount in the report instead of cancelling it. While made on a reverse move, those lines should not be considered as refunds, since they must both use the original repartition of the reversed move , unlike invoices, which would make use of the refund repartition in this case.

** ISSUE 2 **

To reproduce, on a l10n with a tax report:
- Create a cash basis tax, and set tags on its repartition lines so that it should be taken into account by the report. Make sure the refund repartition cancels the invoice repartition.
- Create an invoice using that tax, post it
- Click the "Add Credit Note" button, select "partial refund", and post the generated refund (which will cover the full amount of the original invoice)
- Reconcile the refund with the invoice

=> Because it's a partial refund, cash basis entries will still be generated. Open the tax report to ensure they sum up to 0... And the tax lines don't !

This happens because the computation of tax_tag_invert field inverts the sign of tag on cash basis entry tax lines when they have a negative tax_base_amount. In our case, when going through the "reverse" button and making a partial refund, we actually do get a negative amount in the credit note's tax_base_amount. This is inconsistent with what a refund generated from scratch does (then, you'll get a positive tax_base_amount in our case), and should only be legit when the document contains a negative line explicitly (so, a line with a negative quantity, hence inverting the meaning of debit/credit).

The root of the issue is that the tax_base_amount of the tax line uses the tax_tag_invert of the base line to define its sign. And tax_tag_invert was omitting to set copy=False. When reversing a move, the first step is to copy it. Because of the missing copy=False, tax_tag_invert was copied, and never recomputed (since it's a computed editable field) on the base line, giving it an inconsistent value, and ending up inverting the sign of tax_base_amount on the tax line. In turn, the tax line got a wrong tax_tag_invert because of that, and would propagate that to the cash basis entry when generating it.

This commit adds the missing copy=False to tax_tag_invert, but also fixes the computation of tax_tag_invert so that in does not rely on tax_base_amount anymore. This way, existing data will also benefit from the fix without having to recompute the field. Additionnally, there are currently plans to remove tax_base_amount in master, so this would have had to be done eventually anyway.

OPW 3255511

closes odoo/odoo#121605

Related: odoo/enterprise#41162
Signed-off-by: Quentin De Paoli <qdp@odoo.com>

When we have automatic invoicing enabled , the email sent to the user
when he confirms his payment online will contain a button 'View Journal
Entry'

To reproduce the error :
1- Install accounting, website, ecommerce, sales apps
2- Go to website settings and activate automatic invoice
3- Install test payment method and activate it
4- Log out of the current account
5- Make a purchase of any item and confirm the payment
6- You will receive 2 emails , the second one will have the invoice and
it will contain a button View journal entry

The origin of the problem is not providing model_description when
sending the invoice so it will take the display_name of the model
'account.move' by default which is Journal entry.

opw-3271345

closes odoo/odoo#121525

X-original-commit: 8d791167
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>

When we input some string in many2many field under Coins/Bills in configuration
setting of point of sale module . it will give an error with the message -

'could not convert string to float'

Steps to Produce:-

1. Go to Point of Sale then configuration
2. click on 'Settings'
3. Under 'Payment' input some string in Coins/Bills

Trace-back will be generated.

Reason -
The 'name_create' method of the 'pos_bill' model generates an error when a
string is provided as input for the 'name' field, since the expression
'float(name)' is unable to convert a string to a float.

Applying these changes will resolve this issue.

Sentry - 4122478677

closes odoo/odoo#120207

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

Steps to reproduce:
In an account move, if the partner_id is changed to one that does not have a value assigned in the property_purchase_currency_id field and with a value in the context for default_currency_id,
when passing through the _onchange_partner_id function of the purchase module,

Cause:
the variable currency_id will take the value in the context as second option causing an error when trying to get the value in currency_id.id because currency_id will be an integer and not a record.

issue-121232

note fw 16:
The record must be saved in order to trigger the compute in
https://github.com/odoo/odoo/blob/5a256af35e5d612efed9ed8af1cf23fd62bd83f4/addons/account/models/account_move_line.py#L449-L457


in order to recompute the currency of the lines

closes odoo/odoo#121957

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

Initialize a DB. Install website when it is initialized.
Launch tests of the class TestBaseDocumentLayout

Before this commit, there was a crash because those tests render the report_layout and its
assets.

The full explanation is that, the module website adds an ir.asset `website.s_badge_000_variables_scss`
that the report wants to fetch. But, the class of tests is executed at_install. Given the topological order
and the order of the modules installation, website is not in the registry at that point, but the ir.asset is retrieved
from the database.
The ir.asset algorithm determines at that point that `/website/` is not an admissible path and raise an exception.

This commit solves the problem by tagging this class of test "post_install" and not "at_install".

runbot-error-21203
runbot-error-21204
runbot-error-21205
runbot-error-21206
runbot-error-21207
runbot-error-21208
runbot-error-21352
runbot-error-21353
runbot-error-21354
runbot-error-21355
runbot-error-21356
runbot-error-21357

closes odoo/odoo#121970

X-original-commit: 48b83351
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Steps to reproduce:

- Go to a website page > Add a 'Form' block > Set an input "Placeholder"
value.
- Go to the page (in 'edit_translations' mode) > The translation of the
input "Placeholder" attribute doesn't mark the input as translated and
even after saving the translation, the input is still marked as
"to_translate".

The goal of this commit is to fix this issue by extending the same
behaviour on the translated `<select/>` options (using `.oe_translated`
class) and setting the right translation state on the input from the
linked attribute translation `<span/>`.

task-3323245

closes odoo/odoo#121843

X-original-commit: 9276afdc
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>

Before this commit:
when en_US is not activated and the user changes terms slightly for
ir.ui.view.arch, the new term will be treated as a typo fix or style change, and
won't be populated to other languages. As a result, in the form view, arch_base
field which displays the en_US translation of the arch_db will still be the
content before the change(wrong and strange).

After this commit:
when write a model_terms field when en_US is not activated, its en_US value will
always be overwritten.

opw-3265418

closes odoo/odoo#121253

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

before this commit
When users open the translation dialog for an empty field, and directly update
and save all translations in the translation dialog, nothing will be saved for
backend

after this commit:
these translations will be saved.

opw-3297748

closes odoo/odoo#121139

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

It takes 70s to generate a receipt with 2000 serial numbers.

It happens because during the first part of the loop
(model `stock.move.line` in the `create` method).
It will update the initial demand of the move based on the new
stock.move.line and their qty_done.
Writing the initial demand of the `stock.move` will try to reassign
it (useless in our case) and rewrite the same value on its state's field.
The consequence is the invalidatation of the field on
the `stock.move.line` because it's a related to the `stock.move`.
In the second part of the loop, it check the sml state. Since it
was invalidate upper, it recompute it. That prevent a correct prefetch
and cause a performance issue.

We fix it by writing only once the information by move. And it
prevent the recompute later since the state is not write during the
loop.

closes odoo/odoo#121919

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

The json fields are not supported in lists at the moment because they
require additional RPC to fetch the display value as long as its
formatting.

closes odoo/odoo#121532

Task: 3324679
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>

Current behaviour:
When activating "Prevent Sale of Zero Priced Product",
zero priced products could still be added to cart,
using the wishlist.

Expected behaviour:
Zero priced products should not be added to cart

Steps to reproduce:
1. Activate the setting "Prevent Sale of Zero Priced Product"
2. Create a product with a sales price of zero
3. Go on the product selling page, cannot be added to cart
4. Add the product to your wishlist
5. Go in the wishlist
6. The product can be added to the cart

Cause of the issue:
add_to_cart_button was overriden

Fix:
Added condition on override

opw-3283057

closes odoo/odoo#121531

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

Before this PR when a demo data error occurred (and the errors is too big). You could click on the error and a form view appeared. But if the error was too big, the text for module_id and wizard_id were impacted and were way too small to be readable (like a missing colspan). By adding a form view form this specific model it seems to solve the issues.

closes odoo/odoo#117002

Task-id: 3252698
Signed-off-by: John Laterre (jol) <jol@odoo.com>

Before this commit:

When a new list is created and any list item is applied a style
like h1, bold ,itallic etc.. and when when toggle that list, the list
style breaks

After this commit:

Toggling through the list does not break the style.

closes odoo/odoo#121892

Task-id: 3269908
X-original-commit: d06e043c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

The method _assign_and_convert_leads() gets called when the CRM: Assign Leads cron is called.
The values in the list `weights` gets caluclated in a way that memebers with a lower
`lead_month`count` value gets a higher weight when randomizing assignement of a new lead. Assuming that the
max assignment per member is consistent (or default = 30).
Assume that each sale member belonging to any team has around 500 leads assigned to them the previous
month(`lead_month_count`) and `work_days` is set to `0.2`. The return value of the method
`_get_assignement_quota()` in this case would be 0 for every member, which causes the list `weights`
to get populated with just zeros. This raises a `ValueError: Total of weights must be greater than zero`.

Fix:

Make sure the minimum weight for each member is at least 1 and not 0.

opw-3171085

closes odoo/odoo#121877

X-original-commit: 15e2a1eb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Previously, when conducting a refund on a table, the system would
switch the active table to the table associated with the refunded
order. This was not the desired behavior, as it resulted in the details
of the order disappearing, requiring the user to navigate back to
the refund process.

Steps to reproduce the issue:

 - install PoS restaurant
 - pick a table, do an order and pay it
 - pick another table, refund
 - choose the previous order and refund
-> the order details disappear directly. You have to go back to refund.

opw-3301603

closes odoo/odoo#121351

X-original-commit: 1b28952d42c4c0830a1e9a73c6d1dd7f334e122b
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>