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>

Before this commit, when exporting the FEC report, we were using the account journal
name in the initial language set. As it could be confusing for the French administration
to see names in a foreign language, we should use the user language instead to allow the
export of FEC report in French even if another default language was used.

closes odoo/odoo#79679

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

closes odoo/odoo#79143

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

In multi steps configurations, the additional products of a MO could be
missing in the associated picking

To reproduce the issue:
(Use demo data)
1. In Settings, enable "Multi-Step Routes"
2. Update the current warehouse:
    - Manufacture: 2 steps
3. Create a MO for product "Table Top"
4. Edit the MO:
    - Add 1 x Screw in the components
5. Confirm the MO
6. Open the generated Picking

Error: The operations only contains one line for "Wood Panel". There
should be a second line for the "Screw"

When adding the new component, a new stock move is created but the
latter does not have any `group_id` defined. This is the reason why the
generated picking does not include this stock move.

OPW-2671995

closes odoo/odoo#79759

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

- Get a database with millions of files in the checklist (do not ask how
  this happened)
- Set a cron timeout low enough so that `autovacuum_job` times out

The file GC will endlessly timeout without being able to delete any
file.

This is due to how the `_file_gc` method is built: we first build the
whole whitelist, then we perform the deletion. With millions of
checklist files, the loop which builds the `whitelist` takes ages. It
ultimately leads to a timeout of the scheduled action, and therefore no
file is deleted.

To avoid this, we delete the files progressively. The checklist is split
in chunks, and we check which files must be GC'd in a given checklist
chunk. This way the files are removed even in case of timeout, meaning
that there will be less files to check during the next run. Eventually
the GC won't timeout anymore.

closes odoo/odoo#79247

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

When changing any option in Settings, the option "Show Detailed
Operations" of almost all operations types will be enabled

To reproduce the issue:
(Use demo data)
1. Open the Operation Type "YourCompany: Delivery Orders" and ensure
"Show Detailed Operations" is unchecked
2. In Settings, enable an option (e.g., "Default Access Rights")
3. Go back to the form of "YourCompany: Delivery Orders"

Error: "Show Detailed Operations" is checked for no reason

With this commit, "Show Detailed Operations" of almost all operations
types will be directly enabled only if one of the three options (Lots &
Serial Numbers, Storage Locations or Packages) is enabled and none of
these options was enabled before.

OPW-2514993

closes odoo/odoo#79632

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

closes odoo/odoo#79720

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

When detecting if the assets where already preprocessed, the method
only the last asset type matching was returned and deleted.
In standard, it should not have any impact as all assets are of the
same type but it may be possible to mix it with external modules.

Sign CLA

closes odoo/odoo#79458

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

closes odoo/odoo#79672

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

Before this commit, when comparing a period P of reference to another one,
some rows with only data comming from P would not always be presented
in the table. The problem used to manifest only when loading at least to
level at the same time (starting from Total or any header via expand all).

The reason is the following:
- the data comming from P are processed first: starting from somewhere
  in the trees of headers, some nodes linked to the data comming from P
  are progressively created with no children at first, then the children
  (if any) are added later and so on progressively.
- the data comming from the other period is processed and nodes are
  created with no children and so on in the same way, clearing possibly
  all the node children comming from P.

For example, with
  a row groupby = [field_a, field_b],
  a group [v, v1] from P
  a group [v, v2] from the other period,
a node corresponding to v would be added, then a node child for v1.
Then the node for v would be recreated with no children, then a node child
for v2 would be created. leading to a tree of row headers of the form
Total > v > v2.

Note that it was not affecting the measure values for the displayed rows
since those measures are stored separately from the tree and are linked
to the nodes via some ids.

We fix the problem by avoiding the recreation of a node if it already
exists.

opw-2635113

closes odoo/odoo#79580

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Andrea Grazioso <agr@odoo.com>

The flow has been broken multiple times across the years. Let's add a
test in all stable versions. In 14.0 and 15.0, bugs in that flow have
been reintroduced in multiple ways, those will be fixed during the
forward-port of this test.

closes odoo/odoo#79579

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

Backport of 7475bcbe.

closes odoo/odoo#79575

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

Problem : Free Shipping is not translated in delivery
New Behaviour : Free shipping will now be translated

opw-2679727

closes odoo/odoo#79305

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

This commit fixes an issue of the webclient where the tab
was missing the name of the action in the title after a
fresh load of the page.
e.g. after a reload or when duplicating a tab in sales, the
title was 'Odoo' instead of 'S00001 - Odoo'.

closes odoo/odoo#79412

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

Steps to reproduce:

- On a company with multi currency
- Set the company currency rate to 1, and the foreign currency
  to 0.273748
- Create a vendor bill
- Set first the foreign currency, then select a product with a
  tax to 21% and a price unit of 155.32
- Go to 'Journal Items', the 'tax paid' line debit is computed to 119.15
- Reselect the foreign currency on form.
- Now the 'tax paid' line debit is computed to 119.16

The total is also impacted as the tax changed.

Explanation:

Before this commit, the taxes was both computed in foreign currency and company currency. However, when setting a new currency or changing the date, the taxes wasn't recomputed but the new conversion rate was applied.
This commit is fixing the issue by applying the same logic as in 14.0: the taxes are always computed only the foreign currency, then the conversion rate is applied to get the accounting balance.

opw-2569668

closes odoo/odoo#79065

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

Currently, when user open the question from helpdesk ticket and
user clicks on the back button of the forum page,
it redirects the user to the app switcher. It happens because the
back button contains the homepage URL as httprequest.referrer
does not support the fragment url with hash(#).

so this commit fixes the issue by binding the onclick event on the
back button so clicking on the back button redirects the user
to the helpdesk ticket.

task-2602604

closes odoo/odoo#75585

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

closes odoo/odoo#79294

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

As it was confusing to have some autogenerated sum on the parent model we show the proper tax value of the report

Part-of: odoo/odoo#79294

This commit reverts [1]. Otherwise, the same order lines may be
submitted several times.

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. Select table T1
5. Add a Bacon Burger and submit the order
6. Open another table
7. Reopen table T1
8. Add a Cheese Burger and submit the order

Error: The ticket sent to the kitchen has the bacon burger and the
cheese burger. Only the last one should be sent to the kitchen

When selecting a table, a RPC call gets all information about the
current order. In the server response, the orderlines are sent as new
records:
https://github.com/odoo/odoo/blob/629a4f34ea66f10a981f4b25d5d69281f62853b6/addons/pos_restaurant/models/pos_order.py#L88


Therefore, the orderlines will have a new ID. However, since [1], the
lines identifiers are used to know which lines have changed. This
explains why the bacon burger is sent twice.

[1] 8159e5ac

OPW-2678701

closes odoo/odoo#79397

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

Steps to reproduce the bug:
- Install sale_management and sale_mrp
- Create a product with BOM, which is a KIT and add any product in BOM line
- Create a SO for the product > Confirm
- Validate the delivery
- Cancel the SO >  Set to Quotation > Reconfirm

Problem:
A new delivery order is generated while the ordered quantity = delivered quantity
This is because `_get_qty_procurement` wrongly computed the product quantity based on the moves quantities in the kit case.

opw-2647856

closes odoo/odoo#79387

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

A bug currently makes the carousel snippet collapse/disappear when its
active contents are removed. This happens because after the removal,
the carousel no longer has an active item.

The solution that was chosen was to not allow the removal of slides
unless using the dedicated option which is there for that. This solution
has to advantage to also allow users to create empty slides (using a
background image for example) by simply removing the columns inside.

task-2506165

closes odoo/odoo#77033

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

Current behavior:
If you have 2 time the same product in the agreement and you confirm an order with just one line of this item
the 2 lines in the agreement will have the quantity.

Expected behavior:
Only the ordered item should have the quantity applied. In this case the products are compared with the price and
product ID. If you modify the price in the PO the first line of the agreement will have the quantity by default.

Steps to reproduce:
1. Create a new Purchase Agreement
-Add two lines with the same product
- First line has a scheduled date and price that are different from the second line
2. Generate RFQ and confirm PO with only the first product line and a set quantity
3. Once the PO has been confirmed, going back to the Purchase Agreement, the ordered quantities on both lines will be the same, although the PO was generated for only the first line.

opw-2627898

closes odoo/odoo#78779

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

For status images

closes odoo/odoo#79263

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

Steps to reproduce :

  - Install Sales
  - Modify the report, use the theme "Clean" and the font "Open Sans"
  - Modify the company phone to: +41 26 322 01 02
  - Print a quotation

Issue :

  Company phone is on 2 lines

Cause :

  CSS (`display: inline-block;`) issue with wkhtmltopdf.

Solution :

  Remove custom CSS for `span.o_force_ltr` since by default a
  span has `display: inline;`.

cherry-pick of: https://github.com/odoo/odoo/commit/d462f13e0c1c04e792895bba9f2edfb35d9ee9d3

ref commit: https://github.com/odoo/odoo/commit/5b022f433a44e627541d30ae21d7a867f4a3a6ff


opw-2567836

closes odoo/odoo#78927

Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>