Steps to reproduce the issue:

- Install the module eCommerce
- Activate PayU Latam payment acquire in test mode and
  set it to Website 2
- Set a domain for each website
- Go to Website 2
- Add any product to cart and go to checkout
- Select PayU Latam as payment acquire and click on pay
- Select any payment method, finish the payment and click
  on the "Back to the store" button

Issue:

  Redirect to the first website (instead of Website 2),
  therefore the user has not the receipt of the payment.

Cause:

  The domain of the response url is set to the ir.config_parameter
  'web.base.url'.

Solution:

  Use the function `self.get_base_url()` to get the right domain
  (already what is done in other payments acquires).

opw-2652582

closes odoo/odoo#80538

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

Steps to reproduce the bug:
- Create a storable product > add a BOM
- Create a MO> add the product > confirm > Mark as done
- Go to the product form > click on product moves
- The move linked to the MO is displayed
- Add the "Manufacturing" filter
- No move is displayed

Solution:
Display all "stock.move.line" which are linked to a "stock.move" with a "mrp.production"

Bug2:
The "Manufacturing" filter should be defined in the MRP module instead of the stock
otherwise, users who do not have MRP installed will have access to this filter as well

opw-2697254

closes odoo/odoo#80383

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

Steps to reproduce the bug:
 - Create a BOM:
    - Set the quantity of the finished product and component as more than 1
- Save > Go to BOM Structure & Cost > the quantity in the input is set on 3
- Print

Problem:
The report generated shows the qty and cost for production of 1 unit of product, regardless of the BOM quantity set in the input

The "_onClickPrint" function tries to get the quantity of the bom in the context,
but since the value of "this.given_context.searchQty" is null, the function will use the default value of 1.
The "searchQty" is only set in the "onchange", so we can manually trigger it when initiating the page so that the "searchQty" is set correctly

opw-2691632

closes odoo/odoo#80435

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

Renames "DHL", "DHL USA" and "DHL Express" into "DHL Express Connector".

task-2581265

closes odoo/odoo#80471

Signed-off-by: Arnold Moyaux <arm@odoo.com>

Steps to reproduce:

- Install Argentinian Accounting
- Enable multi-currency
- Create a customer invoice in USD
- Product X, quantity 10, price 17.82, VAT 21%
- Save and click on preview

Issue:

On tax line, "VAT 21% on $178.20" is displaid instead of just "VAT 21%"

Cause

This is the result of a rounding issue inherent to python, when passing in Currency.round method, 178.20 became 178.20xxx001.

Solution

Overwritte the _get_rendering_context method in order to be able to use the float_compare method instead of a strict comparison in xml report.

opw-2677160

closes odoo/odoo#79740

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

When using a mobile, scanning a product to manage a delivery won't work

To reproduce the error:
(Need stock_barcode. Use demo data)
1. In Operations Types, edit "Delivery Orders":
    - Enable "Show Detailed Operations"
3. Create a planned delivery order DO:
    - 1 x [FURN_1118] Corner Desk Black
4. Mark a Todo
5. Switch to a mobile view
6. Edit DO and scan 601647855640 (i.e., the barcode of FURN_1118)
7. Save DO

Error: An error is displayed "The operation cannot be completed [...]
Model: Product Moves (Stock Move Line) (stock.move.line), Field: From
(location_id)"

The kanban view does not include both `location_id` and
`location_dest_id` although they are required

OPW-2688915

closes odoo/odoo#80162

Signed-off-by: Adrien Widart <awt@odoo.com>

Improve the factur-x export in two ways: make the exported PDF
PDF/A-3B compliant, and add the factur-x XMP metadata inside the file.

The added .ICC profile comes from https://www.color.org/srgbprofiles.xalter
License terms can be found here: https://www.color.org/profiles2.xalter#license



Task id # 2668919

closes odoo/odoo#78974

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

According to the Argentinean law N° 27440, it is required for MiPyMEs
document types to show in the report the total amount in letters.

closes odoo/odoo#78314

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

Before this commit, when the user made an error in the HTML/SCSS editor
(most of the time due to user pasting HTML code while our code excepts
*XML*), the user was stuck most of the time because the error indicator
did not always appear. And even if it did, it disappeared on scroll and
the user had to guess where to click to show the error message.

Now, the UI for the error is way clearer, with the error message opening
itself directly and pointing at the line where the error occurs. The
UI of that error message is now more robust (even though suffering
because of the ace editor which likes to re-render itself at unknown
times). The error message is also still not super clear (default error
message given by the browser) although some parsing is now done on it to
try and display it better.

task-2698641

closes odoo/odoo#80286

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

By default show the user_custom_rules.scss one as some people would
write rules in user_custom_bootstrap_overridden.scss otherwise, not
reading the comment inside explaining how that file should be used.

task-2698641

Part-of: odoo/odoo#80286

When switching to files that can only appear in debug mode in the HTML /
SCSS editor and editing them, the page reloads... and crash for no
reason. This was because the filter that allows those files to appear
is lost after reloading, now we simply ignore the file switch if not
present in the default filter.

task-2698641

Part-of: odoo/odoo#80286

Bug introduced by:
https://github.com/odoo/odoo/commit/bc131c0cfb51c953de8ec41fb820c8c7831eefb5



closes odoo/odoo#80370

Issue: 2668902
Signed-off-by: Olivier Colson <oco@odoo.com>

closes odoo/odoo#78914

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

Commit [1] and its forward-ports introduced a test tour (properly added
in assets_tests) but was not declared as a test one. Meaning that if you
were in debug=tests, you were able to follow a strange tour not meant
for user testing.

[1]: https://github.com/odoo/odoo/commit/3c194faa930b0d3a537ca8b893b2c0442b5464e7



closes odoo/odoo#80354

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

Before this commit, when the user creates a quotation and add a SOL with
product contained a project in `project_id` field, the
'Project Overview' stat button is shown even if the quotation is not
confirmed.

This commit changes the visibility condition of this button to display
it only if at least a project is contained in `project_ids` field of
`sale.order` model and if the quotation is confirmed that is when the
quotation becomes a sales order.

Step to reproduce:
=================
1) Go to the Sales app
2) Click on 'Create' button to create a quotation.
3) Add a SOL with 'Customer Care (Prepaid Hours)' product

Actual Behavior:
===============
The 'Project Overview' stat button is displayed.

Expected Behavior:
=================
This stat button should not be displayed while the quotation is not
confirmed to become a sales order.

task-2697063

closes odoo/odoo#80305

Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

Steps to reproduce the bug:
- install `”purchase_product_matrix”`
- Go to the purchase settings and enable “Warnings” option
- Create a product with variants
- Add purchase warning
- Create a PO and add the product

Problem:
The warning message is not appearing

Solution:
the `”_product_id_change()”` function has no return.
To trigger the warning message, we have to call the `”onchange_product_id_warning”` manually because it is not triggered automatically in the grid case

opw-2696007

closes odoo/odoo#80275

Signed-off-by: Arnold Moyaux <arm@odoo.com>

The fields of the FEC export must be sanitized.
All tabs, carriage returns and newlines must be excised.

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



opw-2672261

closes odoo/odoo#80288

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

Steps to reproduce the bug:

- Let's consider two companies C1 and C2 where C1 is the parent of C2
- Let's consider an expense product P with T1 as tax in C1 and T2 as tax in C2
- Let's consider an expense alias A defned for C1 and C2
- Let's consider an employee E in C2 with work email address W
- Send from W to A an email with subject [internal reference of P] Test Expense 1000€

Bug:

An expense is created in C2 with T1 and T2 as supplier taxes instead of only T2

Inspired from function _compute_tax_id defined in model sale.order and purchase.order

opw:2507162

closes odoo/odoo#71586

X-original-commit: 436b8fcf6a10485acb1a6f47b9b81860ae1c243b
Signed-off-by: Laurent Smet <las@openerp.com>

Current behavior :
If we click on the icon rather than the label we got a crash

Steps to reproduce :
- Enable Online Payment and configure an acquirer and add the possibility to save the card
- Go to the Website and Log in (e.g. as `Marc Demo`)
- Go to your account (from dropdown menu > `My Account`)
- Manage you payment methods and add a new one
- Try to delete the newly added payment method by clicking on the trash icon in the button

Reason :
Currently, we rely on the `target` property of the event (triggered after clicking on the button). 
The problem is that, as in this case, if a button has an HTML element as a child and we click on this child, `target` property will target the child whereas in this case we want to retrieve the button and not the child. 

Using `currentTarget` property instead of `target` allows us to retrieve the button no matter what since `currentTarget` always refers to the element to which the event handler has been attached.

OPW-2660186

closes odoo/odoo#80189

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

Some countries, such as Portugal, persons also have VAT-like tax
numbers, that can be used in invoices, just like company VAT numbers
can.

However, the VIES service does not work for these person VAT numbers,
only for companies.

This fix ensures that VIES validation is only used for companies.

closes odoo/odoo#79779

Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Daniel Reis <dreis.pt@hotmail.com>
Co-authored-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>

Part-of: odoo/odoo#79779

- On “Manually create a write-off on clicked button.” type models, change counterpart value
  journal domain to show only journal with type general.
- Add domain to journal_id in manual create writeoff form to only show "general" type journals
- Add "label" to parameters that force tax recompute when changed on a line update.
  Needed because setting the label can change the "invalid" value of a proposition.
  If that is the case, taxes related to this proposition must also have their "invalid" updated.

closes odoo/odoo#80165

Task: 2611348
X-original-commit: beaf7821012c46602bf5135e57b8793a60891120
Signed-off-by: Laurent Smet <las@openerp.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>

This is a backport of https://github.com/odoo/odoo/pull/76046

.

closes odoo/odoo#80193

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

REF:https://www.xe.com/currency/ang-dutch-guilder/



opw:2690166-

closes odoo/odoo#79768

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Steps to reproduce:

-In a database with french accounting,
- The fields cash_basis_transition_account_id and invoice_repartition_line_ids are not well configured

opw-2669061

closes odoo/odoo#80136

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

The use-case that motivated this fix is the deletion of a project task
with many subtasks.  The field 'project_id' on tasks is recursively
computed, and some automated action must be executed when its value
corresponds to a given project.

The issue occurs when the domain of automated actions is evaluated by
method search(), because the latter flushes the fields to search on,
which are also the ones being recomputed.  Combined with the fact that
recursive fields are not computed in batch, this leads to a huge amount
of recursive calls between the automated action and flush().

The execution of task.unlink() looks like this:
- mark 'project_id' to compute on subtasks
- delete task
- flush()
  - recompute 'project_id' on subtask1
    - call compute on subtask1
    - in action, search([('id', 'in', subtask1.ids), ('project_id', '=', pid)])
      - flush(['id', 'project_id'])
        - recompute 'project_id' on subtask2
          - call compute on subtask2
          - in action, search([('id', 'in', subtask2.ids), ('project_id', '=', pid)])
            - flush(['id', 'project_id'])
              - recompute 'project_id' on subtask3
                - call compute on subtask3
                - in action, search([('id', 'in', subtask3.ids), ('project_id', '=', pid)])
                  - flush(['id', 'project_id'])
                    - recompute 'project_id' on subtask4
                      ...

closes odoo/odoo#80114

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Steps to reproduce the bug:
- Create a BOM:
    - set the quantity of the finished product and component as more than 1
    - save > print > BOM Structure

Problem:
The report generated shows the qty and cost for production of 1 unit of product, regardless of the BOM quantity

opw-2691632

closes odoo/odoo#80093

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

Unlinking a workorder which was in the middle of a chain of workorder created two subchains which both created a product when reaching their new respective ends.
The issue was solve by assuring that when we a link is remove from a workorder chain, their adjacent workorders are linked together using next_workorder_id

opw-2669514

closes odoo/odoo#79251

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

Cash flow tags were supplemented and useless and empty tax_ids removed.
Additionally account 7990 had a wrongly tag which was corrected.

closes odoo/odoo#80034

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

closes odoo/odoo#79989

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

In some cases, it is not possible to print the order changes

To reproduce the issue:
(Use demo data)
1. Point of Sale > Configuration > Order Printers, edit Kitchen Printer:
    - Printed Product Categories: Food
2. Edit the POS Bar:
    - Enable Order Printer
3. Start a session of POS Bar
4. Open table T1
5. Select a Food product and add a note
6. Submit the order to the kitchen
7. Select again the same product without any note

Error: The order button isn't green, it is not possible to sent the
second order line to the kitchen

The issue comes from the logic used in `computeChanges`:
https://github.com/odoo/odoo/blob/75fb0aa6e9c314b61b30d49b5c463fa126dfc835/addons/pos_restaurant/static/src/js/multiprint.js#L215-L222


`old_res` contains the products already sent to the kitchen
As a result, since the line from step 5 and the one from step 7 have the
same product, we consider that the new line (step 7) was already
present. Then, when comparing the quantities, both lines have their
quantity equal to 1, so we consider there isn't any information that
should be sent to the kitchen

OPW-2557518

closes odoo/odoo#79526

Signed-off-by: Masereel Pierre <pim@odoo.com>

Steps to reproduce the issue:

- Install "eCommerce" module
- Create 2 attributes with 'Variants Creation Mode' is Never and
  one of them should have at least 2 values.
- Create a product and add the two attributes as variants and
  one of them should have at least one value
- Go to configure variant and select the first attribute and
  exclude one or more values from the second variant
- Go to the website and change the variant to a value from the one
  you excluded and add to the cart directly (you should be fast).

Issue:

  Product with a not possible combination is added to cart.

Cause:

  Not checking if the combination is possible before adding to cart.

Solution:

  When adding product to cart, if element with class
  ".js_add_cart_variants" is present and have children,
  trigger _getCombinationInfo to retrieve last combination info,
  then add it only if the combination is possible.

opw-2569109

closes odoo/odoo#79780

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

A wrong company was used in the Kiosk mode, preventing users to check in
/ out.

closes odoo/odoo#79853

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

The packages reservations are not correctly done in case of a backorder

To reproduce the issue:
(Use demo data)
1. In Settings, enable:
    - Delivery Packages
    - Multi-Step Routes
2. Edit the warehouse:
    - Outgoing Shipments: 2 steps
3. In Operations Types > Delivery Order, enable:
    - Show Detailed Operations
    - Move Entire Packages
4. Create a Pick P:
    - 1 x [DESK0004] Desk
    - 1 x Large Cabinet
5. Put each product in a separate pack
6. Validate P
7. Create a Delivery Order (Planned Transfer):
    - 1 x [DESK0004] Desk
    - 1 x Large Cabinet
8. Mark as TODO, Check Availability
9. In Detailed Operations, mark one of the packs as Done
10. Validate the DO, Create a backorder

Error: The not-yet-done pack is still on the delivery order and its
status is "Reserved". This line shouldn't be present anymore. Moreover,
the backorder has a line for this pack, its state is "Draft" (instead of
"Reserved") and the state of the BO is Ready.

When creating the backorder, the packages levels of the not-yet-done
moves are transferred to the new picking (i.e., the backorder) However,
these moves does not have a package level defined (due to
9d758fa2). Therefore, when checking the
packs:
https://github.com/odoo/odoo/blob/e7450bee8f018a5334d9628235824f2fc6f32cec/addons/stock/models/stock_picking.py#L822-L832


`package_level_ids` is empty, so a new `stock.package_level` is created
(instead of using the one of the initial delivery order). And
`move_lines_to_pack` is empty too, so the new `stock.package_level`
won't have any move lines and its state will be "Draft"

We should rather transfer the package levels of the moves' lines.

OPW-2659176
closes #77509

closes odoo/odoo#79953

Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>

Before this fix, lines of 'entry' type moves on sale journals would have had their
tax audit string sign reversed.

closes odoo/odoo#79556

Task: 2687215
Related: odoo/enterprise#22216
Signed-off-by: Olivier Colson <oco@odoo.com>

Before this fix, all moves of type “entry“ were considered as misc operations in regard to repartition tags and the tax report. And only moves of type “out_refund” and “in_refund” were considered refunds.
Now reverse entries with sale/purchase taxes get their tags set accordingly to repartition lines.

Account                                    D      C      Tax   Tax Grids
700000 Ventes en Belgique (marchandises)   0      1000   21%   -03
451000 T.V.A. à payer                      0      210          -54
400000 Clients                             1210   0

Was reversed to:
Account                                    D      C      Tax   Tax Grids
700000 Ventes en Belgique (marchandises)   1000   0      21%   -03
451000 T.V.A. à payer                      210    0            -54
400000 Clients                             0      1210

Is now reversed to:
Account                                    D      C      Tax   Tax Grids
700000 Ventes en Belgique (marchandises)   1000   0      21%   +49
451000 T.V.A. à payer                      210    0            +64
400000 Clients                             0      1210

Task: 2687215
Part-of: odoo/odoo#79556

Task: 2687215
Part-of: odoo/odoo#79556

[FIX] sale_timesheet : fixed Credit Notes for Vendor Bills not taken into account in project overview profitability

Reproduce :

- Install modules Purchase, Accounting, Project, Sales Timesheet
- In Accounting settings, activate option Analytic Account
- Create a Project and link it with an Analytic Account
- Create a PO then Vendor Bill with this Analytic Account
- Check the Overview for the Project associated with that Analytic Account
- The amount of the bill will show in the "Other Costs" field of the Profitability section
- Go back and add a Credit Note for the vendor bill

Issue :

- The amount of the PO still shows in the "Other Costs" section, where it is expected to be balanced (zeroed) by the Credit Note.

Solution :

- Don't take into account the Vendor Bills for whioch a Credit Note exists.

opw-2527655

closes odoo/odoo#79390

Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>