Part-of: odoo/odoo#110669

closes odoo/odoo#111293

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

Part-of: odoo/odoo#111293

Starting the Odoo server with more than one worker results in repeated
"Bus unavailable" exceptions in the server log.

This seems related to the change made at
https://github.com/odoo/odoo/commit/a2ed3d3d5bdb6025a1ba14ad557a115a86413e65



 Investigation shows the the bus model file is loaded before gevented
 mode is started, and thus the wroker won't have the ImDispach
 available.

closes odoo/odoo#111352

Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>

Before this commit conditions based on `_handle_visibility` and
`_get_cached_visibility` did work only by relying on the cache of the
`menu.page_id` being populated when accessing `is_visible` in sudo.
This does not work if the cache is cleared between the calls.

This commit makes sure all 3 conditions have access the record.

The actual issue has not been reproduced locally yet.
The various workers, crons, websocket work on distinct envs - even
through code they cannot impact the cache of another local env outside
the `check_signaling` system which is only used between requests.
For the problem to occur, some intra-request multithreading is needed
but it could not be located so far.

task-3149270

closes odoo/odoo#111217

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

__Description of the issue:__

When something goes wrong while downloading a report file, a 500 error
is sent as JSON. However the frontend interprets this response as HTML
and then try to parse the text content as JSON.

Most of the time this works, but if the response contains any HTML tags,
like `<lambda>` from a Python stacktrace, the JSON response will get
misinterpreted as HTML instead of regular text, causing the subsequent
JSON interpretation to fail.

The end result for the user is that empty tracebacks will be displayed
instead of User Errors or actual tracebacks.

__Desired behavior:__

The JSON response is HTML escaped before being sent and will therefore
be correctly parsed and displayed to the user.

This basically restore what was done prior of #104594.

closes odoo/odoo#111433

Enterprise: odoo/enterprise#36523
Signed-off-by: Julien Castiaux <juc@odoo.com>

Very similar to the usecase in commit dafe732e6874fbdd15dfd213b5c5c0cde93e534e

Steps to reproduce:

- Install Accounting, Sales, Stock
- Create a product category PC:
	- Costing method: FIFO
	- Inventory Valuation: Automated
- Create a product P:
    - Type: Storable
    - Product Category: PC
- Create a Sales Order SO with 1 x P at cost 10
- Confirm delivery
- SO > Create Invoice > Post
- SO > Return the delivery
- Change product price from 10 to 6
- SO > Create Invoice (!!)
- The invoice will be marked as a credit note automatically
- Post the invoice

Issue:

The product is listed in the journal items, which is correct,
but its value is 6 while it should be 10.

If we create the invoice from the Sales Order instead of adding a
credit note, then the move lines will not be considered reversed,
since they do not have an associated invoice.

Solution:

Consider the move type when deciding if the move line is reversed or not.

opw-3077772

closes odoo/odoo#111035

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

Current behavior:
The internal product reference is not added to the invoice when the
invoice is created from the POS.

Steps to reproduce:
- Create an order in the POS
- Validate the order and print the invoice
- Open the invoice, the internal product reference is not written on the
  invoice

opw-3119678

closes odoo/odoo#111371

Signed-off-by: Engels Robin (roen) <roen@odoo.com>

Before this commit: it was possible to create two PoS terminals in two
companies with the same `adyen_terminal_identifier`. So it's possible,
after each payment, it would add the response to the wrong payment
method's `adyen_latest_response`.

The solution is to bypass multi-company record rule in
`_check_adyen_terminal_identifier`.

opw-3131814

closes odoo/odoo#111320

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Purpose
=======
Allow to customize the Outlook endpoint to be able to use single
tenant apps.

Task-3053447

closes odoo/odoo#104795

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Before this commit, on accessing the validation queue in the website forum,
the user image shown in the sidebar is different from the logged in user image.

The cause of issue was the variable passed from the controller and the
variable used for iterating the for loop who are the same, aka user. Thus
the value for 'user' is getting changed. resolved by storing the user value
to a temporary variable and restoring it after the loop.

After this commit, in the validation queue it will show the same logged in
user image in sidebar.

closes odoo/odoo#110904

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Release notes: https://github.com/odoo/owl/releases/tag/v1.4.11.1



This fixes an issue with refs in iframes in firefox 109+

closes odoo/odoo#111344

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

Before this commit, if a link to a page was not correct because of a
case mismatch, it would simply land on a 404 page.
While it's correct, as URL are case sensitive, it leads to a few bad UX
flow at the admin/editor level:
- Create a link in your page (on a text or a button eg), type an URL
  which does not exists (to create it after) like /Page
- Click on the link/button you just made, you are redirected to /Page
  which display a 404 with the "Create page" option (correct)
- When you click on that button, it will actually create a page with
  /page URL, leading to a mismatch between the URL you created and the
  page URL.
  Your link/button will still lead to a 404 URL as it points to /Page.

Since it's just a fallback when an exact URL match is not found, it
should not break anything and should not have bad impact at any level
(seo/speed etc).
Indeed:
- It's done through a 302 redirect
- `_serve_page()` is already a fallback case, so it will only make
  the `website.redirect` and 404 cases a bit slower due to the extra
  search query.

The only possible scenario seems to be if the user (mind the uppercase):
- Created a /Page page
- Created a redirect from /page to /another-page

In this case, /page won't land on /another-page but on /Page.
This flow seems unlikely and is not actually wrong either way.
At least, it certainly is less important than ensuring a case
insensitive fallback.

Finally, note that another solution would have been to either:
- Force page URL to lower case.
  -> This is not stable friendly, people might be relying on this to
     create pages with different casing:
     `/Batman-VII-The-Dark-Knight-Whatevers`, while not recommended,
     doesn't sounds idiot.
     On top of not being stable friendly, we probably want to keep
     offering this possibility
- Redirect all URLs to lowercase endpoints.
  -> This is obviously not stable and not Odoo's jobs. It should be
     something decided by the sysadmin and done at nginx (etc) level.

task-3110294
opw-3104030

closes odoo/odoo#109812

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

Steps to reproduce (Using Chromium-based browser > v. 108):

  - Install Survey module
  - Open 'Feedback Form' survey
  - Click on 'See Results' button
  - Try to print the 'results' of 'Feedback Form'

Issues:

  - Hundreds of empty pages added when printing.
  - Chart not fully displayed.

Cause:

  - The chartjs library add some HTML elements not displayed (inside div
  with class `chartjs-size-monitor`) to handle the resizing of the
  chart canvas.
  One of the element has a width and height of 1000000px with an
  overflow:hidden, but the overflow does not work properly when printing.
  (Issue introduced in Chrome v. 108, working fine in v. 107 or on any
  Firefox version)

  - The chart canvas is not resized to 100% of its parent container and
  therefore not fully displayed. (Not working in all Chrome and Firefox
  versions)

Solution:

  Add CSS (with print media rule):
  - Set style to `display: none` on `chartjs-size-monitor` HTML element.
  - Set the width and height of the chart canvas to 100%.

opw-3109523

closes odoo/odoo#110874

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

opw-3073678

closes odoo/odoo#111330

Related: odoo/enterprise#36448
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>

task - 3142380

closes odoo/odoo#110687

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

When sending the same survey to the same partner, the system detects it and
allows the user to choose between sending a new invitation or resending the
old one so that the user can continue the survey that might already be ongoing.
The detection was not working anymore and this fixes the problem.

Technical note: _compute_existing_partner_ids was intersecting record set
partner_ids (the one currently added) and a record set of partner for which an
invitation has already been sent. The intersection didn't work because
partner_ids relation was not completely set and instead of id, had "origin" id.
Comparing id using a filter solves the problem (using the trick that .ids,
return also the origin ids).

Task-3087702

closes odoo/odoo#108448

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

Usecase to reproduce:
- Set product as FIFO and a cost of 10$
- Sell 5 units
- Modify the cost method to average

We expect the value of the stock to remain -50$.
However it went to -150$

It happens because the change of cost method is not supported
with negative quantity of stock. It's not really a huge bug because
it will be reconcile to the real value in the next in and when the
stock will be positive again but at least it gives a proper valuation
of the inventory.

opw-3100717

closes odoo/odoo#108692

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

Steps to reproduce:
- In settings, activate "Free sign up" option;
- Go to "Sign in" page;
- Click on "Don't have an account?";
- Create an account.

Issue:
No confirmation email is sent.

Cause:
The `qcontext.get('token')` variable does not exist
in the case of a "Free sign up".
And therefore, we do not respect the condition to send an email.

opw-3103867

closes odoo/odoo#108888

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

Taxes in Luxembourg have been reduced until the end of 2023: 17% -> 16%, 14% -> 13% and 8% to 7%.

This change remaps the OSS tax mappings for Luxembourg to the new tax rates.

task-3159138

closes odoo/odoo#111234

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

The fields user_ids on res.partner can be slow on large database, because there no index.
Before on large database 100ms after 1ms.

closes odoo/odoo#111228

Signed-off-by: Rémy Voet <ryv@odoo.com>

backport of 4ff2d0ad

Before this commit, if two or more lines in sale_report had the same value as price_total, they were group together in _compute_kpi_sale_total_value and included in output sum only once. That leads to incorrect values in digest mail.

This commit fixes that issue by changing grouping column from price_total to company_id.

Steps to reproduce the issue:
----------------------------

1. Send Digest Mail for database and check values in it (assume we have both All Sales KPI and PoS KPI).
2. Create several sale_order_line and/or pos_order_line with exactly the same price_total (for example: 5 PoS transaction, each one for one product of value 10000).
2. Send Digest Mail again and check values in it.

Current behavior:
-----------------

The All Sales KPI will increase by value of only one of lines (in our example: PoS KPI will increase by 50000 = 5*10000, All Sales KPI will increase by 10000)

Expected behavior:
-----------------

All Sales KPI should include all transactions from sale_report in given period of time (all sale_order_line and pos_order_line).

opw-3116707

closes odoo/odoo#111225

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

To reproduce the issue:

1. Install [Accounting] on Apps
2. On [Settings],
- [Users & Companies]>[Companies]: add a company with country Belgium
- Set the company to the Belgian one
- add French, set the language to it
- [General Settings] - check the [Companies] section

Desired behavior: Correction of VAT label

Impacted versions: 14.0 up to master

opw-3104416

closes odoo/odoo#110925

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

Confirming a sale order with lots of lines (> 300) with
route_id = Dropship is currently quite slow. This is because
a recompute happens for the fields 'account_analytic_id'
and 'analytic_tag_ids' of purchase.order.line, among other fields.

These two compute methods have been overriden in the
purchase_requisition module. Both child's methods have the
same structure, a for rec in self loop calling super inside of it.
However, since super is called with self and not rec, the super
compute function will be called on self len(self) times.
This produces lots of queries (for an SO with 976 lines, 1.9M queries
on account_analytic_default are produced).

This commit replaces the for loop by a call to super and by passing
a filtered recordset instead of self. This speeds up the confirmation
of sale orders by multiple orders of magnitude.

opw-3067893

closes odoo/odoo#111135

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

There was previously no check that the ticket id belong to the selected event.

For better data integrity, this should be the case

closes odoo/odoo#109784

Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

Steps to reproduce the bug:
- Create a product category “Fifo”:
    - set the costing method to Fifo
- Create a storable product “P1”:
    - category: All (costing method = standard)
    - Update the qty to 10 units

- Go to inventory → Product variant → “P1”
- Change the category from “All” to “Fifo”
- Go to inventory → Reporting → stock valuation
- Add “reaming_qty” field in the list view

Problem:
The empty_stock layer (the layer created to empty the product) has `remaining_qty` of -10 instead of 0 whereas we change from standard to Fifo

The write method of `product.product` is triggered,  leading to Product Variant having another category than Product Template when the write method of `product.template` is triggered

opw-3138061

closes odoo/odoo#110982

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

Don't limit on the first directory found in the upgrade-path.

It follow the same behavior regarding scripts found in the `maintenance`
directory and the ones in the local `upgrades` directory of modules.

opw-2868713

closes odoo/odoo#110997

X-original-commit: d2e6c9d5
Signed-off-by: Christophe Simonis <chs@odoo.com>

Backport of: https://github.com/odoo/odoo/commit/1e550be1cc968940dd5c263160b8cc38e9d4e72b



Steps to reproduce the bug:
- Enable Multi-step Routes in inventory settings
- Go to Inventory > Warehouses> San francisco > Set Incoming Shipments
   to 2 steps
- Create a Test Product:
    - Route: Buy
    -  vendors Azure Interior and Gemini Furniture in this exact order
- Create a Replenishment Rule for the “Test Product”:
    - route: Buy
    - Vendor: “Gemini Furniture”
    - min and max quantity to 0
    - To Order: 1
    --> Click Order Once

Problem:
Check the purchase order, it will have “Azure Interior” as the vendor
and not “Gemini Furniture”

opw-3099958

closes odoo/odoo#110449

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

Update of taxes could create name collision due to uniqueness of
(name, company, scope, type) on taxes.
We add "[old]" before the tax name to avoid this problem.

closes odoo/odoo#110815

Related: #108571
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

Before this commit "parallax" animation was not working in modals.

This commit adds a parameter to the animation effects to enable
animations (triggered by the scroll) in the modals.

Note that for the "Newsletter" popup we have hidden the "parallax"
options. To make them work, it would be necessary to review the
structure of the "Newsletter" popup so that the vertical scrollbar is in
the same location as the "s_popup" snippet (on the ".modal" element).

task-2971402

closes odoo/odoo#99894

Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>

Added countries which have ports defined in aduana.cl but were not in the list.

closes odoo/odoo#109123

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

After unlock a picking/MO, it's possible to change the qty_done of a
cancelled move. This change won't have any result on product's stock.
In this commit, we raise an error when user changing cancelled moves.
We advise user to create a new line instead.

Task-3116125

closes odoo/odoo#110083

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

Currently the Spanish address format does not include the province/state.

This change adds the province between parentheses after the zip code and city.

task-3147965

closes odoo/odoo#110918

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

Steps to reproduce the bug:
- Create a storable product “P1”
    - costing method: avco
- Create a PO:
    - Add the product “P1”:
        - Line 1: Qty= 10, price= $50
        - Line 2: Qty=1, price= $10
    - Confirm the PO and receive the product

- Go to purchase → Reporting → Purchase Analysis

Problem:
The average price is incorrect, the current calculation is:

(50 + 10) / 2 = 30

The average should take into account the quantities purchased in each
line, And not simply the number of line, so the correct calculation
should be:

((10 * 50) + (10 * 1)) / 11 = 46.36

The SQL query is correct, it is when applying the read_group that the
calculation is incorrect, we should override it to make a personalized
calculation of the average.

opw-3136406

closes odoo/odoo#110740

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

Current behaviour:
When checking out a shopping cart in the ecommerce, if there are
no payment acquirers available for the billing address (for ex:
billing address in Canada but payment acquirers available only in
the US), there is no indication/msg about it during checkout.

Expected behaviour:
A message should be displayed when no payment acquirers are
available to the customer. Such message was added in 15.0.

Steps to reproduce:
- Install Ecommerce, delivery module, Test Payment acquirer
- Setup a shipping method restricted to US
- Setup payment method restricted to US
- Visit shop from an incognito
- Put in Canada address for Billing and Shipping method when
  checking out
- Warning will occur stating no valid shipping method found (Correct)
- Go back and change the shipping address to a US address but leave
  billing to Canada
- Checkout will not let you progress but will show no warning message
  as you'd expect

Reason for the problem:
In 14.0 there was no warning message setup when we don't have a valid
payment acquirer.

Fix:
Backport the warning message from 15.0 and up.

Affected versions:
- 14.0

opw-3133810

closes odoo/odoo#110922

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

On tablet view, if the user selects another lot than the one
reserved, we will still keep a reservation for the old one

To reproduce the issue:
(Need mrp_workorder)
1. Create two products P_finished, P_compo:
   - Storable
   - Tracked by SN
2. Update on hand quantity of P_compo:
   - 1 x SN01
   - 1 x SN02
   - 1 x SN03
3. Create a BoM:
   - Product: P_finished
   - Components: 1 x P_compo
   - Operations: 1 x a new operation
4. Create, confirm and assign a MO for 2 x P_finished
5. Start the WO
6. Set a finished lot
7. The consumed lot is SN01, set it to SN03
8. Validate the WO
9. Mark WO as done
   - Do not close the MO
10. Open the detailed operations of the MO

Error: There is a line that consumes SN03, but there is also a line
for SN01's reservation. This is incorrect, while the MO is not
closed, the quant of SN01 has its available quantity equal to 0.

Since we have to create a backorder, we split all SM. Then, we
remove the excess reservation. To do so, we unreserve the raw SM and
then assign it again. Here is the issue: we run the generic assign
process, so it will not consider that there is already a SML with a
done quantity, i.e.: it will ignore the consumed lot and will just
try to reserve the first one it finds (-> SN01)

OPW-3104930

closes odoo/odoo#110400

Related: odoo/enterprise#36033
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

The current VAT check doesn't pass for valid Venezuelan VAT numbers (RIF). Venezuela has a specific method to validate their RIF, very different from the standard VIES check.

This commit adds an implementation of the VAT number validation in Venezuela. The validation is based on
(1) pattern matching
(2) checksum validation

Task id=3094593

closes odoo/odoo#107658

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

In case of subcontracting, it is not straightforward for a user to
select the appropriate MO on the landed costs form.

To reproduce the issue:
(Need stock_landed_costs)
1. Create two products P_compo, P_finished
    - Storable
    - P_finished:
        - Add a vendor V
2. Create a BoM:
   - Product: P_finished
   - Type: Subcontracting
   - Subcontractors: V
   - Components: 1 x P_compo
3. Process a receipt R:
   - From: V
   - Operations: 1 x P
4. Open the form to create a landed cost
5. Set the Apply On to Manufacturing orders
6. Try to find R

Error: There isn't any reference for R. There is actually the
reference of the manufacturing order (for instance WH/SBC/00001) but
the user can't know that this MO is related to R.

A part of the solution is the partial backport of [1]. Thanks to
this commit, the method `name_get` of the MO will include the name
of the associated receipt in case of subcontracting.

[1] 0e26ed69

OPW-3070543

closes odoo/odoo#109431

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

Steps to reproduce the bug:

Here are aliases for the used contacts:
- A: Azure Interior
- B: Gemini Furniture
- C: Gemini Furniture, Edwin Hansen
- D: (delivery address for Edwin Hansen)

1. Login on a runbot.
2. Set VAT of A and B to different values.
3. Open C, and create a delivery address: D
4. Check: VAT of D = VAT of B
5. Change the related company of C from B to A.

Bug:

The VAT of C = VAT of A, however VAT of D did not change.

When syncing the commercial fields of a partner, we also sync his childs.

PS: Due to function _compute_commercial_partner, the commercial partner is always updated for
all the childs.

So the condition child.commercial_partner_id != self.commercial_partner_id
is never satisfied in function _children_sync and the commercial fields were
never updated.

opw:3111493

closes odoo/odoo#109074

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