When a odoo user already exists, the installation of the deb package
fails because the `/var/lib/odoo` directory does not exists.

The reason is that the postinst script is trying to change the
permissions of this directory which is only created if a odoo user does
not already exists.

With this commit, the permission changes only occurs when the directory
is created.

closes odoo/odoo#111814

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

Partner's VAT identification number now is not missing when printing Foregin Invoices.

closes odoo/odoo#110483

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

Current behavior:
When making a refund of an order in the PoS, the cost of good was
computed as if the refund was a classic order.

Steps to reproduce:
- Make sure you are in anglo-saxon accounting
- Create a category that use AVCO and automated valuation
- Create a product with a cost of 10€ that is part of the new category
- Create a PoS order with the product
- Refund the order
- Close the session, and check the accounting entries, the cost of good
  sold is 20€ instead of 0€

Note: this fix needs you to set the return picking type in the Operation
type of the PoS

opw-3149324

closes odoo/odoo#111252

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

Previously, when underconsumption occured, we split the move (in
post_inventory). And if backorder, the moves not done would be linked to
the new backorder MO (when backorder MO is created).
After 8883c06a, we create backorder MOs
before _post_inventory, making it so the moves not done will not be
linked to the backorder MOs and reserved qtys are not released.
To fix, we set cancel_backorder to be true to cancel all the leftover
moves and release the reserved qty.

Task-2697611

closes odoo/odoo#80271

closes odoo/odoo#110990

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

Considering the MO under consumption situation:
  component A, to consume = 2, consumed = 1
Previous, after "mark as done", the MO will have two lines:
  component A, to consume = 1, consumed = 1, state done
  component A, to consume = 0, consumed = 0, state done
Now, after "mark as done", it will be consistent with picking:
  component A, to consume = 1, consumed = 1, state "done"
  component A, to consume = 1, consumed = 0, state "concel"

Task 2446915
PR #66583
ENT PR odoo/enterprise#16554

NOTE: this commit has been backported from [1] and, at that time, the
modified part of the test `test_basic` didn't exist. Then, the part of
the test has been added with the assert value equal to '2' and has been
modified during the FW (see [2]) so it matches with the new behaviour
introduced by [1]
Same with [3]

[1] 729db008
[2] odoo/odoo#75001
[3] odoo/odoo#75443

Part-of: odoo/odoo#110990

The calendar renderer used event.record.allday and not event.allDay
and as such doesn't use the attribute set on the view.
If the model doesn't have a field called 'allday' this can't work.
This commit fixes that.
OPW-2968130

closes odoo/odoo#110669

Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Justine Doutreloux <justine.doutreloux@acsone.eu>

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>