The `copy` method must return the wrapper of the original
`CryptContext` class.

Prevent developers to use these attributes on the registry
instances, as they are supposed to be called from the class itself
only

closes odoo#82718

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

The ability to filter by domain was introduced in
d79678f but as the commit states,
the feature was purely technical and only added the possibility
to filter by domain. It itself did not use it.

Afterwards this feature was moved to the portal module in commit
3cfd64f .

There is no way in the front end to filter by domain, the way messages
are fetched is simply by the model and it's res_id. This feature has
been dead code since it's implementation and doesn't need to be there.

In order not to change any RPC calls, I simply removed the logic server
side. However in master I will fully remove this feature.

closes odoo#33816

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

The dateutil API, available attributes, depends from one version to
another.

Restrict the attributes developers/customers can use in their server
actions to prevent compatibility issues according to different
Linux distribution or PIP installations.

The list is built following what customers actually use
in their server actions, and what we consider useful to
be used in server actions.

closes odoo#93314

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

Prevent keys from several business flows from being misused or detected,
leading to unexpected behaviour.

task-3817669

Prevent keys from several business flows from being misused or detected,
leading to unexpected behaviour.

task-3817669

Prevent keys from several business flows from being misused or detected,
leading to unexpected behaviour.

task-3817669

When printing the gift card report the text saying "Card expires" would
show despite there being no expiration date.

Added a t-if to check if the field is populated before displaying that
text.

Backport of odoo@ec4d3f0

opw-4016994

closes odoo#171447

Signed-off-by: Morgane Demesmaeker <edm@odoo.com>

Before this commit:
-Resized column widths were lost when moving the top row down or the second
 row up.
-This happened because the new widths after resizing were only applied to the
 <td> elements of the first <tr>.

After this commit:
-When moving the top row down or second row up, column widths are copied from
 the first row to the second row.
-Tables don't lose resizing after moving the first row up or down.

task-4019025

closes odoo#171695

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

…voices

Steps to reproduce:
- Install the 'l10n_sa' module and switch to a saudi company
- In the Settings of Accounting, tick the option "Default Terms & Conditions" and select "Add a Note"
- Write something in for the Terms & Conditions
- In the Accounting app create a new invoice, confirm and preview
- At the bottom of the preview, the Terms & Conditions are duplicated

Cause:
The report is trying to print the Arabic and English translation of the Term & Conditions, but only one of the two exists so they appear duplicated.

Solution:
There is already a way to translate manually the Terms & Conditions (Have the 2 languages installed and a button appear near the text). So the fix is simply to display only the Arabic language when there are no translations.

opw-4043175

closes odoo#172781

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

Issue:
======
Image changes aren't auto saved.

Steps to reproduce the issue:
=============================
- Add cover snippet and text-image snipets
- Change cover image or the image in the text-image snippet
- Don't click anywhere after that
- Switch tab to A/B testing for example
- Go back to mail body
- The image changes aren't saved

Origin of the issue and solution:
=================================

When we choose an image from the media dialog, we loose the focus from
the editable which means `onWysiwygBlur` is not called and as
consequence `commitChanges` isn't called too.

Since the flow of the destroy and the `commitChanges` in `onWysiwygBlur`
are in parallel, the following happens:
- We don't update the value in the blur flow because we will wait for
  some promises which may take some time and the component gets
  destroyed and we never call the `updateValue` at the end of the
  function.
- Now in the `commitChanges` coming from `onWillUnmount` we need to pass
  the `urgent` flag in mass_mailing too.

opw-3947516

closes odoo#172312

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Check if the user selected the carrier for storable/consumable products
before proceeding to payment.

Backport of [35ea9bf](odoo@35ea9bfb)

opw-3861697

closes odoo#174248

X-original-commit: 188f019
Signed-off-by: Julien Launois (jula) <jula@odoo.com>

Backport of commit 2b27e1b

closes odoo#174367

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

In no-demo tests, there is no link tracker, so
the expected length is not max+1 but 3.

Follow up of e5b88d3

Task-3502174

closes odoo#174371

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

When you click on the Time-off smart-button on an employee's tab, you define a context that must be maintained

Similar to 15.0: https://github.com/odoo/odoo/blob/15.0/addons/web/static/src/legacy/js/views/calendar/calendar_controller.js#L160

TT49839

[IMP] hr_holidays: Use the context employee or the user's employee

TT50253

closes odoo#172380

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

Steps to reproduce:
	- Install eCommerce and Loyalty module
	- Create a Discount that is applied using code
	- Generate coupon codes
	- Modify the balance of the codes to be more than 1
	- Go to website and create an order
	- Proceed to checkout and apply one of the codes

Current behavior before PR:
The reward will be shown as claimable even after we already applied
its code. This will lead that the user can be able to claim it more
than once in the same order. This is happening becuase when getting
the claimable rewards we are fetching the rewards that already got applied.
https://github.com/odoo/odoo/blob/16.0/addons/sale_loyalty/models/sale_order.py#L655

Desired behavior after PR is merged:
We are excluding the already-applied discounts on the order to avoid
using them more than once in the same order.

opw-4018909

closes odoo#173555

Signed-off-by: Morgane Demesmaeker <edm@odoo.com>

ammending 50c9c3d
to take into account env.company instead of companies

closes odoo#174329

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

Currently when importing an order from sale to pos, if the price was set
manually, changing the partner associated with the order will set back the
price to the original product sale price.

Steps to reproduce:
-------------------
* Make a new quotation in **sales**
* Change the unit price of a product
* Confirm quotation
* Open the pos shop session
* Import the newly created quotation to be settled
* Change the partner
> Observation: The price set manually changes to the product sale price

Why the fix:
------------
When changing the partner of a sale order we compute all the line that have
to recompute their prices:
https://github.com/odoo/odoo/blob/57f1b0bd502938a6d50244896e71df73705584b5/addons/point_of_sale/static/src/js/models.js#L2918-L2920

We see that when we settle an order, `price_manually_set` is set to false.
In this example, if we set it to true it would solve the issue but we cannot use it,
see with odoo@70668ee .

Instead what we can do is to use `price_automatically_set` and set it to true.
This does not undo the previously mentionned commit and fixes this current issue.
This variable was created in odoo@0672995

opw-4001497

closes odoo#172205

Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>

Prior to this commit, enabling limited product loading could result in
the discount product not being loaded.

opw-4057657

closes odoo#173600

Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>

Problem
---
The `sequence` field of product attributes has no default,
This causes ordering bugs in the frontend when using handles.

Steps
---
* go to product attributes list view
* move the last element to the top (to ensure a full reordering)
* create a new product attribute *PA* > go back to the list view
        * it appears at the bottom of the list
        * its sequence appears to be 0 to the frontend but is actually
          NULL
* move it one place up
        * *PA* and the item after it now have the sequence numbers 0, 1
* refresh
        * the two last items move to the top, crisscrossing with the
          previous 2 first items which also have sequence 0, 1

Cause
---
The frontend always assume click-and-drag sortable lists are already
sorted, but this assumption is wrong when we have a record with a NULL
`sequence`, because it will appears at the end of the ORDERBY SQL query
but be converted to 0 frontend-side.

opw-3937263

closes odoo#174397

Signed-off-by: Nathaniel Jacques (naja) <naja@odoo.com>

Steps to reproduce:
- Edit any product's 'Description for delivery orders' (inventory tab)
- Create a delivery for this product (or confirm sale order to create one automatically)
- Print delivery slip (Correct formatting)
- Validate delivery
- Print delivery slip once more (Description loses linebreaks)

This is only for looks, but it's a document the end user will see so there are concerns about it looking unprofessional.

This formatting error is due to us not being able to use a field element after remaking the order lines to group related products in python.

opw-4040127

closes odoo#174531

X-original-commit: a5e9820
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Yoann Baron (bary) <bary@odoo.com>

This is a complement to previous fix:
odoo@649a7f1
in which the use case where both companies have "Round Globally" set as
"Rounding Method" was not handled.

Steps to reproduce:
- Install Sales & Accounting
- Create a second company with a different currency (e.g. AED) than the first one (e.g. USD)
- Configure the rounding factor of the currency of the second company to 1.000000
- Configure the default company of the current user to the second company
- Switch to the second company
- In Accounting settings, set "Rounding Method" to "Round Globally"
- Switch to the first company
- In Accounting settings, set "Rounding Method" to "Round Globally"
- Create a SO:
  * Customer: [any]
  * Order Lines: [any line with a tax]
- Save the SO
- Edit the SO by changing the price unit of the product
  !!! Make sure that the tax amount has a decimal part
- Save the SO

Issue:
In the chatter, the note about the new value of the tracked field Total
is different from the Total value shown in the SO.
Also, in Customer Preview, the total to pay shown on the upper-left of
the page is different than the total shown in the SO details.

opw-3814058

closes odoo#174560

Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>

version - 16.0

Steps:
-Install rental app.
-Activate the date picker from the web-editor.
-Add the start date and end date from that.
-Select some attribute of the product.

Issue:
-When any user adds the start date and end date from the date picker and
after that, the user adds the other attribute(filter) of the product, that s>

Cause:
-The selected rental period (start and end dates) is not persisted when the
 page refreshes or updates due to attribute selection.

Fix:
Get the value of 'start_date' and 'end_date'.
Update the hidden input fields for 'start_date' and 'end_date' with the
values before applying the attribute changes.

opw-3774060

closes odoo#165068

Related: odoo/enterprise#64962
Signed-off-by: Valentin Chevalier <vcr@odoo.com>

…es description.

closes odoo#174511

Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>

Was always failing because of an invalid signature

closes odoo#174555

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

Before this commit, when performing the Google Calendar account reset
in Odoo, some events and recurrences were disappearing from Odoo when
they shouldn't. This was happening because we were not removing the
'google_id' information of deleted recurrences or even unlinking
events incorrectly in Odoo side. Additionally, the synchronization of
only 'new' or 'all existing' events were not correctly being handled
because the 'need_sync' write should change according with the selected
'sync_policy'.

After this commit, we correctly remove the 'google_id' of recurrences
when the deleting them and we now consider correctly the 'sync_policy'
of synchronizing only 'new' or 'all existing' events by updating the
'need_sync' status of all existing synchronized events.

task-3731683

closes odoo#167299

Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>

Issue:
The `_get_weight` method is called for each location
to compute the weight and it sums up all the incoming
and outgoing lines for forecasted weight. Using filtered
for each record is compute intensive and gets slower overtime.

While returning a delivery with 30 stock moves the
_create_return took 7:41 minutes most of which were
on `_get_weight`.

Solution:
Optimized the `_get_weight` method to use `read_group`
to get the sum of incoming and outgoing lines.

closes odoo#170675

Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>

Update the OWL lib.

Release notes:
https://github.com/odoo/owl/releases/tag/v2.3.0

These releases contain small improvements

* v2.3.0
[IMP] compiler: add support for the .translate suffix

closes odoo#174621

Signed-off-by: Géry Debongnie <ged@odoo.com>

Current behaviour:
When sending an email through Email Marketing,
the icon is right in the preview, but wrong in
the received email.

Steps to reproduce:
1. Install mass_mailing
2. Create a new mailing
3. Select a template with a twitter icon
4. The icon is the new one
5. Click on Test
6. Open the email
7. Wrong icon

Cause of the issue:
Twitter icons have been overriden in fontawesome_overridden.scss
However this css is not loaded when writing the src
in fontToImg in convert_inline.js

Fix:
Same fix as for tiktok, forcing a custom font
and changing the icon code to match the font
(ie: one icon is F099 in FA but E800 in the custom font)

opw-3963437

closes odoo#173874

X-original-commit: 5b463f7
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>

Current behavior:
Israeli mobile phone numbers are composed as such:
+972 55-295-1235
+972 country code, 5X mobile number indicator,
X5-29 phone operator
Only operators up to 5-28 were supported, recent
library changes now support up to 5-29
(the next operator being 5-32)

Steps to reproduce:
parsed = phonenumbers.parse('055 294 1234', 'IL')
is_valid = phonenumbers.is_valid_number(parsed)
is_valid == False

Cause of the issue:
Old versions of phonenumbers (external library) are not
up to date with the latest israeli phone system changes

Fix:
Monkey patched the library
Similar as: odoo@b787803

opw-3942014

closes odoo#174570

X-original-commit: 5fe431a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>

When the user adds a Kenyan phone number, it is not correctly parsed by
the phonenumbers library, resulting in a user error while sending a WhatsApp
message to that number.

Steps to produce:
- Add a Kenyan phone number (e.g., '+254114627044').
- Try to send WhatsApp messages using this phone number.
- This will throw an Invalid number error.

Problem:
when `phonenumbers` python library is used in odoo for parsing phone numbers,
versions below `8.13.31` have problem with parsing some Kenyian numbers because
they aren't updated, therefore they can't identify prefix and throw an error.

task-3994165

closes odoo#174636

X-original-commit: 39e16a5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Dato Nefaridze (dane) <dane@odoo.com>

Some valid URLs were not working before because since [1], we were only
supporting 15-16 digits facebook page ID, but some have less numbers. We
now check IDs between 12 and 16 numbers.

We also add a feedback notification for users if their link did not work
for some reason.

[1]: odoo@82c4393

task-3995431

closes odoo#174596

X-original-commit: e4e9a14
Signed-off-by: Robin Lejeune (role) <role@odoo.com>

The signature of `_get_additional_shop_values` was wrongly changed in
6957035.

closes odoo#174680

Related: odoo/enterprise#67452
Signed-off-by: Valentin Chevalier <vcr@odoo.com>

Updates the partner demo data for the chilean localization. One of the demo companies had real information which was dangerous to have in databases.

[FIX] l10n_cl: Eliminate partner demo logo

Eliminates a partner demo data logo since it was the official logo of the company, and we received complaints from the company.

closes odoo#174589

X-original-commit: 88160a7
Signed-off-by: Laurent Smet (las) <las@odoo.com>

v2.3.0 of Owl added the .translate modifier to props, allowing them to
be translated. This commit updates the script that generates the .pot
files (the list of source terms to translate) in order to take into
account props with the .translate modifier.

Task-3980675

closes odoo#174697

Signed-off-by: Vincent Larcin (vila) <vila@odoo.com>

Before this commit, no API version was given to StripeJS. This could
lead to discrepancies between the APIs.

Now, the API version used will be the same client-side and server-side.

closes odoo#174713

X-original-commit: 330746d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>

63a80c1 added support for safe_eval
in python 3.12. However this added RETURN_CONST in _SAFE_OPCODES
instead of _CONST_OPCODES. This stopped const_eval from returning const
values.

closes odoo#174045

Task-4067772

closes odoo#174689

X-original-commit: 11f9c11
Signed-off-by: Florian Vranckx (flvr) <flvr@odoo.com>
Signed-off-by: Bram Van Gaal (brvg) <brvg@odoo.com>

Description of the issues this commit addresses:

As from the first of september 2024, Finland will raise 24% taxes to 25.5%,
those rates are currently not available in Odoo.

Desired behavior after this commit is merged:

New 25.5% taxes are available in Finland
OSS tax mapping is done for other countries to Finland
The mapping from Finland to other countries is deliberately left for later
as we don't want the mapping to 25.5% to tkae place before the 09/01/24.

task-4010731

closes odoo#174421

X-original-commit: 4a077e2
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Signed-off-by: Thomas Becquevort (thbe) <thbe@odoo.com>

Steps to reproduce
==================

In 17.2:
- Install calendar,hr_homeworking
- Use the emulated mobile view from the devtools
- Go to calendar
- Swipe horizontally to change the displayed week

=> A crash occurs here

https://github.com/odoo/odoo/blob/saas-17.2/addons/hr_homeworking/static/src/calendar/common/calendar_common_renderer.js#L108

Cause of the issue
==================

The `AttendeeCalendarCommonRenderer` is rendered before the data for the
next week has been loaded.

This means that `this.props.model.worklocations` has no entry for the
`parsedDate`.

Solution
========

Await the action before modifying the ActionSwiper state

opw-4047632

closes odoo#173305

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

Currently, when buying a gift card through the website and choosing the
options to pick up in store and pay in store, the quantity set when settling
the order is zero.

Steps to reproduce (initial):
-----------------------------
* Go to the **website** app
* Select **configuration** > **Payment Providers**
* Make sure `Pay in store` is published and enabled/or in test mode
* Select **configuration** > **Shipping methods**
* Make sure that a shipping method `Pick in store` is set up and published
  for your shop
* Now make an order on the website for a gift card and any storable product
* Choose the options to pick and pay in store
* Go to the **Point of sale** app
* Open shop session
* Settle the order just created
> Observation: The quantity for the gift card is 0

Steps to reproduce (alternative):
---------------------------------
* Go to **Sale** App
* Create a quotation for a gift card and any storable product
* Save the quotation (not confirm)
* Go to the **Point of sale** app
* Open shop session
* Settle the order just created

Why the fix:
------------
The issue is not specific to the gift card product, it affects all `'service'`
products.
https://github.com/odoo/odoo/blob/7be2770f2a8dc26f7aa0c539b878b258e94592c8/addons/pos_sale/static/src/js/models.js#L85-L91

We notice that, if the order was paid instead of choosing the option to pay
in store, the quantity on the pos order when settling it is 1. This is because
the order not yet paid is still considered as a quotation. While if it is
paid through the website it is considered as a sale order and thus `qty_to_invoice`
has been computed.

The same behaviors can be replicated through the **Sale** app. If a quotation
is only saved we also have a quantity of 0. If it is confirmed, the quantity is 1.

As discussed with DALA, using `qty_to_invoice` to set up the quantity in POS
only makes sense when we deal with sale orders. When dealing with quotations we
should set the quantities in the shop order depending on the quantities of
the quotation.

opw-4003749

closes odoo#174703

X-original-commit: 6341769
Signed-off-by: Sarah Bellefroid (sbel) <sbel@odoo.com>

task-no

closes odoo#174789

X-original-commit: ec106bf
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>

Before Commit:

On switching the checkbox direction from left to right and pressing tab,
the checkbox would shift to the left while the text appeared on the right,
and vice versa for RTL languages.

After Commit:

Commit [1] added the positioning of checklists in Right-to-Left (RTL) languages.
Previously, only the direct child li elements of ul were styled because of
the use of the child combinator selector (>), as the dir attribute was only
applied to the outermost ul element. This commit ensures uniform styling
across various languages, including RTL languages.

[1]: bb9c4b3

task-3828737

closes odoo#174066

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

Due to the `qty_to_order` field on `stock.orderpoint` being a stored
computed field, it needs to be recalculated every time one or more of
its dependencies could have changed, to keep a consistent record in the
database.
It is, however, dependent on the `qty_forecast` field which is a
non-stored computed field, depending itself on all the stock moves that
are linked to the product set on the orderpoint.
This results in a complete recalculation of the `qty_on_hand`,
`qty_forecast` and `qty_to_order` on ALL the orderpoints linked to a
product every time some `stock.move` has been touched or created with
that product. Even if many of those orderpoints may not even be located
in the concerned warehouse.
This situation can create a performance bottleneck when just processing
pickings, as its constantly (and often pointlessly) recalculating these
field values to store. This becomes a major issue in case the concerned
database contains many warehouses with many different orderpoints.

This issue is remedied in a more permanent way for master in [1], but
due to the stable policy we use a different approach here:
The `qty_to_order` field on `stock.orderpoint` is now no longer
dependent on `qty_forecast`. Instead, when creating `stock.moves` or
writing on its `state`, `product_uom_qty` or `date` fields, we manually
trigger a recalculation of the `qty_to_order` on all the orderpoints on
the relevant product, but only in the relevant warehouses.
In case there is no relevant warehouse for the `stock.move` (none on the
source or destination move), we fall back to the previous behavior of
recalculating `qty_to_order` for all orderpoints linked to the product.

[1] odoo#159432

task-3822497

closes odoo#165637

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

Problem:
For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold

Steps to reproduce:
- Install "point_of_sale" app and "pos_loyalty" module
- Select "Scan existing cards" in the promotions settings
- Generate a gift card with a value of 0.00 $ and copy its code
- Start a shop session
- Select the gift card product and enter the code
- Change the price of the gift card (must be an integer < 10)
- Proceed to the payment
- See the popup error

Cause:
As the gift card has no points, "couponPointChanges" stays empty. But when the price is modified, "couponPointChanges" is updated but has no giftCardId so the error is triggered (see "validateOrder" in PaymentScreen.js).
There is no issue if the price is > 10 or is not an integer because "_updatePrograms" is called after each click on the numpad and "changesPerProgram" gets the values of "couponPointChanges" which are the saved in "oldChanges" which is modified by getting the values of "pointsAdded" which has "giftCardId" so "couponPointChanges" get the "giftCardId"

opw-3909019

closes odoo#174538

Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>

We get an error when trying to validate a dropship
for a product having python tax.

Steps:

- Create a python tax T of type purchase with
  python code being `result = product.weight * 0.1`
- Create a storable product P, with tax T as purchase tax,
  set a vendor and activate dropshipping
- Create and confirme a SO for product P, confirm the related PO
  then try to validate the related dropship
-> We get an User Error (AttributeError: NoneType object has no
attribute weight)

This is because `_compute_all` is called without `product_id` parameter,
leading to the error in `account_tax_python._compute_amount` when trying
to acces the `weight` attribute.

opw-4029025

closes odoo#174850

X-original-commit: 82a7a9c
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>

In this PR: odoo#172760 the check_vat_il function is calling self.company.

It appears it was not a good idea and several things were not done well:
- It could lead to errors as run_vat_test can be called on multiple partners: https://github.com/odoo/odoo/blob/16.0/addons/base_vat/models/res_partner.py#L170.
- The previous PR is also checking the VAT number depending on the field is_company but did not put it as a constraint. This can be fixed, but with more changes than needed.

It has been decided to use the `` check for all Israeli VAT numbers, regardless of the partner type. With this change the VAT check for companies is not complete: it is not tested that they begin by a 5. But it is good enough.

opw-3954674

closes odoo#174817

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

Before this commit, when a reward eligible for multiple products was
claimed, only one product was added to the order regardless of the
reward's configuration.

opw-4066760

closes odoo#174176

Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>

Steps to reproduce:
- Set delivery in 2 steps
- Create a sales
- Validate the transfer from Stock to Output
The delivery status changes from "not delivered" to "partially delivered" even though nothing has been delivered to the customer.

After the fix:
If a picking is validated but nothing was delivered to the customer yet, the delivery status is set to "Started".

closes odoo#169194

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

Steps to reproduce:
- Install l10n_ar and website_sale
- Switch to an Argentinian company
- Create a product with a customer tax (e.g. IVA 21%)
With a public user or a user without "AFIP Responsibility":
- Go to eShop and add the created product to the cart
- Go to the cart

Issue:
No tax is applied.

Cause:
There are some fiscal positions from Argentinian localization that map
IVA 21% to IVA Exento (i.e. 0%).
These fiscal positions are linked to specific "AFIP Responsibility" types
and should only be applied for users having these "AFIP Responsibility"
types configured on their contact form.
However, when this field is not set, it is ignored in the domain computing
the fiscal position and one of these Argentinian fiscal positions satisfies
the resulting domain.

Solution:
Filter on "AFIP Responsibility" in the domain computing the fiscal position
if "l10n_ar_afip_responsibility_type_id" key is present in the context, no
matter what its value.

opw-3943108

closes odoo#171923

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

In list views, the label of a field, displayed in the thead, is
sometimes truncated (especially as we apply our own column widths
logic). Moreover, fields might sometimes be unclear to the user,
and in the list view we don't benefit from the "help" that might
be defined on the field.

This commit helps with those two issues. In non debug mode, there's
now a tooltip on the field's label. This tooltip contains the
(never truncated) label and the help when there's one.

Note that in debug, nothing changes: we still display a big tooltip
with a lot more information.

task 4049882

closes odoo#173177

Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>

The migrations folder was put in the data folder instead of the module folder
which would block the upgrade system from finding the scripts.

no-task

closes odoo#174958

Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>

closes odoo#174972

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

Before this commit, scanning a barcode on the payment screen would
mistakenly capture the barcode value as the payment amount. This could
lead to incorrect payment amounts being recorded if not noticed by the
cashier.

opw-4079147

closes odoo#174992

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

Behaviour before this change
-----
In the "My time off" dashboard, an user belonging to "Administrator" or "Officer"
groups will see a list of all public holidays regardless of which working hours
they are defined for.
Confirmed to be unintended behaviour by HR PO (gmf).

Behaviour after this change
-----
The list of public holidays displayed on the time off dashboard is the same for
all users. The same change is also applied to stress days.

opw-4019868

closes odoo#173205

Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>

Steps to reproduce:
1. Login to an internal user who does not have Livechat application access
2. Go to the website, do some interactions with chatbot
3. Go back to the backoffice, click on the Messages systray menu

Issue:
- Security error about user cannot read the chatbot.script.step record.

Cause:
- When formatting the chatbot's message to render, user has to access the current chatbot script step to get some information, but he does not have enough rights to read the record.

Fix:
- Use sudo on the needed part when formatting the message.

closes odoo#174611

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

Prevent keys from several business flows from being misused or detected,
leading to unexpected behaviour.

task-3817669

Issue
----

The german translation for some tax lines for Luxembourg have the wrong format. This makes
the line get ignored when generating a XML report.

Steps
----

 - Install `l10n_lu`.
 - Change the fiscal country to Luxembourg.
 - Go to Accounting -> Tax Report.
 - Choose Tax Report (LU) from the Report button above.
 - Generate a XML report.
 - The XML report doesn't have the `767` & `768` codes.

Cause
----

Corresponding tax lines are mis-formated.

opw-4053595

closes odoo#174223

Signed-off-by: Laurent Smet (las) <las@odoo.com>

return emtpy translations list when the field is not translatable to be
consistent with the api's definition

closes odoo#175110

Signed-off-by: Louis Wicket (wil) <wil@odoo.com>

Before this commit, selecting a product on a vendor bill line would set the product sale uom as the line uom by default.
This behavior was changed to set the product purchase uom as the line uom by default.

The default uom behavior on Vendor Bills lines should be aligned with the default uom behavior on Purchase orders.

task-4012191

closes odoo#175126

X-original-commit: a09e0c6
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Signed-off-by: Hesham Saleh (hsal) <hsal@odoo.com>

Before this commit:
========================
In link tracker form, if there is no campaign/medium/source, 'No matches found'
message is directly displayed and the text-box for input disappears quickly.

Specifications:
========================
We need to keep the input text-box open to be able to create new records on
the fly.

Technical Reason:
========================
defined 'formatNoMatches' as false to keep text-box open.

After this commit:
========================
Text-box for input will remain open and will not disappear.

Task-4065969

closes odoo#175218

X-original-commit: 7209fe3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Nihar Patel (nihp) <nihp@odoo.com>

The pages/links were changed in the documentation. Update the
documentation buttons in the settings to match.

closes odoo#175135

Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Co-authored-by: Felicious <feku@odoo.com>

Previously, there was no clean way to redirect old URLs like /xx.asp?id=xx with
the correct HTTP status code.

This update adds support for such redirects, allowing people to migrate to Odoo
more easily.

fiximp-realife

closes odoo#175188

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

…hat was posted

Version: 15, 16, 17, master

Description of the issue/feature this PR addresses:

Argentinean localization: if a customer invoice with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the partner to one with "Consumidor Final" AFIP Responsibility, then "Document Type" field is changed and this is not the desired behavior because that field is readonly when the invoice was posted. Compute method should not overried the document type if the invoice was posted before. If it does then an incosistency will occurr because the name, document type and sequence will not match. A new sequence non-real will be used. Also the user it is not aware is happening because the field is readonly.

Video showing how to replicate the bug:

https://drive.google.com/file/d/1D4uqNnXMkguS813NiLl9td4_f_TJ35Xf/view

Steps to reproduce:

1. Log in with admin on runbot odoo enterprise 16 instance and install l10n_ar_edi (Argentinean Electronic Invoicing) module.

2. Take position on company "Responsable Inscripto"

3. Go to "Accounting / Customers / Invoices" and create a new customer invoice with customer "ADHOC SA" (this partner has "IVA Responsable Inscripto" AFIP Responsibility), with a sale journal "Pre-printed Invoice" AFIP POS System (i.e Ventas Preimpreso), add an invoice line and confirm it.

4. Reset to draft the invoice mentioned in step 3 (now journal and document type are readonly fields), change customer to "Consumidor Final Anónimo" (this partner has "Consumidor Final" AFIP Responsibility) and save. Check that the document type has changed from "(1) FACTURAS A" to "(6) FACTURAS B" and this is not the desired behavior because is a readonly field now because the invoice was posted before.

Current behavior before PR:

When a customer invoice with customern with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the customer to one with  "Consumidor Final" AFIP Responsibility, then "Document Type" field is changed and this is not the desired behavior because that field is readonly when the invoice was posted.

Desired behavior after PR is merged:

When a customer invoice with customer with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the customer to one with  "Consumidor Final" AFIP Responsibility, then "Document Type" field is not changed.

Ticket Adhoc side: 77058

Task latam: 1235

closes odoo#172003

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

Steps to reproduce:

- In website edit mode.
- Click on the header.
- Select the "Vertical" template in the "Header" options.
- Drag and drop a "Search" block from the inner content section into the
header.
- Click on the header.
- Select "On Hover" for the "Sub Menus" option of the "Navbar".
- Save the page.
- Enter a letter (e.g., "a") in the search input.
- Click outside the page to lose the focus on the input.
- Hover over the search results with the mouse.
- Traceback: "Cannot read properties of null (reading 'blur')"

The bug occurred after commit [1], which didn't account for a dropdown
missing a "dropdown-toggle" element.

[1]: odoo@0f7cbf2

opw-4012850

closes odoo#175309

Signed-off-by: Robin Lejeune (role) <role@odoo.com>

Currently, when a loyalty program has a reward of type product and uses
`reward_product_tag_id` (set up for at least 2 products), the addition of
rewards to the pos order will have mismatched reward lines when adding the
second free product (the first product needed to be added first).

Steps to reproduce:
-------------------
* Go to **Point of Sale** App
* Go to **Products** and add a tag (the same) for two products
* Under **Products** select `Discount & Loyalty`
* Create a new program of type **Buy X Get Y**
* Rule:
  * Min qty: 2 products $0.00
  * Among Products: Put all chairs products for example
* Reward:
  * Type: Free Product
  * Product: None
  * Product tag: The tag put on the products previously
* Open shop session
* Add 2 chairs
* Select reward, add the first one
> Everything ok until now
* Add 2 chairs
* Select reward, add the second one
> Observation: Reward computation is wrong we have the following lines:
```
4 Chairs,
Reward 1,
Reward 2,
Free product reward 1
```
We are missing the free product line related to the second product added
and the button to select reward is still highlighted.

Why the fix:
------------
To explain this fix I will use the example given above.

Here are the steps that have been executed
* Add 2 chairs
* Add the first reward product
* Add 2 chairs

We are currently in the middle of the step "Add second reward product".
during that process, we end up in the function `_computeUnclaimedFreeProductQty`
while computing values for the reward line. At this very moment in time,
the order has the following lines:
* 4 Chairs
* Product 1
* Free product (related to Product 1)
* Product 2
Where Product 1 and Product 2 are the reward products, having the same tag.

Let's focus on this piece of code, with the current example:
https://github.com/odoo/odoo/blob/76023820c4d725c81677d2bf3e010c8cee1edd19/addons/pos_loyalty/static/src/js/Loyalty.js#L1464-L1475

Where `product` in this case is `Product 2`. What is happening here at the
end is that we have `available = 1` because of line 4 and `claimed = 1`
because of line 3. The program considers that we have already claimed the
quantity and is the reason why it is not adding the reward line.

The first idea to fix this issue was to write the condition:
```
if (reward.reward_product_ids.includes(product.id) && reward.reward_product_ids.includes(line.product.id)) {
```

instead of this one
```
if (line.get_product().id === product.id) {
```

Now both line 2 and 4 are counted toward the `available` quantity. This way
the code knows that we have two availaible free product but only 1 was
claimed.

While this fixed the original issue, a new issue was created. Now, when
we add the second product, the two reward lines were grouped together, using
the price of the first free product added. Why was this happening?

Well, once the fist call to the function `_computeUnclaimedFreeProductQty`
was done and the reward line was added we had the following order (temporarily)
* 4 Chairs
* Product 1
* Free product (related to Product 1)
* Product 2
* Free product (related to Product 2)

Which is what we expect but we face an issue when the loyalty programs are
updated. When the programs update, we go through the function
`_updateRewardLines`. In this function we discard the reward lines from
the order and then for each claimed reward (Product 1 and Product 2) we
re-apply the reward.

While applying the reward for Product 1, we again go through the function
`_computeUnclaimedFreeProductQty`. In this case, the order looks like this:
* 4 Chairs
* Product 1
* Product 2

and the function will say that there are 2 available free product and 0
claimed. Were it is technically true, in this case we want to have the available
quantity to 1. We want the initial condition:
```
if (line.get_product().id === product.id) {
```

In the second passage, for product 2, we have `available = 2` and `claimed = 2`.

opw-3587020

closes odoo#173529

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

Since odoo#169396, the hr_expense_test_tour is failing on community
nightly runs as the "save the new report" step does not succeed without demo.

runbot-70701

closes odoo#174476

Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>

Steps to reproduce:
- Install the 'l10n_sa' module and switch to a saudi company
- Install the Arabic language
- Go in Accounting > Customers > Invoices and create a new one
- Add an internal note with a list (using /)
- Add a translation in arabic with the "EN" button
- Click Preview
- The points of the list appear in the middle of the page

Cause:
The lists are not adapted to be displayed from right to left.

Solution:
Add the option `dir="rtl"` in the span of the Arabic text to make the lists appear the right way.

opw-4043175

closes odoo#175333

Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Signed-off-by: Mathieu Coutant (mcou) <mcou@odoo.com>

Step to reproduce:

- install l10n_in
- create an invoice
- select an Indian customer with GSTIN
- change delivery address to other indian customer without GSTIN
- print report, call it "report 1"
- change delivery address to other indian customer with GSTIN
- print report, call it "report 2"

Current behavior:

For report 1:

- The GSTIN value of the partner_id appear twice on the report

For report 2:

- The GSTIN value of the partner_id appear twice
- The GSTIN value of the delivery partner does not appear

Expected behavior:

- The GSTIN value of partner_id should not appear twice
- If exist, the GSTIN value of delivery partner should be shown

opw-4027540

closes odoo#173655

Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>

Translated text that contains multiple interpolated values should always
use named placeholders. Otherwise, sprintf will always insert the values
in the same order, which may not match the order of the placeholders
after translation in a language with a different syntax.

closes odoo#175332

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

This commit fixes a read access error on the field employee_ids of
hr_leave when a user, who is not in group_hr_holidays_user, tries to
cancel/refuse a timeoff. The bug only appears when the timeoff crosses a
public holidays.

closes odoo#174682

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Steps to reproduce the issue:
- Debug mode > Settings > Technical > Decimal Precision > Product Price
- Set to another number
- Purchase > Any Purchase order
- Mobile view, puchased item has a decimal precision of 2

Why is this a bug:
Kanban view is the only one to disregard Product Price Precision setting

What this fix does:
Update the display with correct decimal precision setting

opw-3984082

closes odoo#172049

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

### Contains the following commits:

odoo/o-spreadsheet@97d415b3e [REL] 16.0.49 Task: 0
odoo/o-spreadsheet@f6efbf465 [FIX] package: update owl to 2.3.0 Task: 0
odoo/o-spreadsheet@ea767a46c [PERF] Borders: Improve bulk border deletion Task: 4084858
odoo/o-spreadsheet@44bd11caa [PERF] SheetPlugin: Faster header addition/deletion Task: 4084858
odoo/o-spreadsheet@9e42a869b [PERF] model: reuse success dispatch result Task: 3741429
odoo/o-spreadsheet@1df6d0914 [FIX] functions: COUNTIF count string dates Task: 4077445
odoo/o-spreadsheet@108007423 [FIX] composer: layout break when composer assistant is opened Task: 4037213
odoo/o-spreadsheet@ead785ebf [IMP] position_hook: include width and height in `useSpreadsheetRect` Task: 4037213

closes odoo#175476

Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Before this commit, it was possible to delete an accrual plan while
it was referenced by an allocation.
This commit introduces an error message if the user tries to delete
an accrual plan in those conditions.

task-4023187

Also updates the `hr_holidays.pot` file

closes odoo#172910

Forward-port-of: odoo#171403
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>

For the sake of simplicity we'd assume 3 days: Mon, Tue, Wed.
Let's also assume that the everything happens in GMT+10

Now if we have a valid leave allocation for Mon and Tue, we should
NOT be able to able to take it on Wed. However, because of the way
Timestamps are casted to dates it is possible. It happens as follow:
user "asking" server for leave on Wed, defines requested day by passing by
the datetimes in the context ranging from Tue 21:00 to Wed 09:00

Why such datetime range? Firstly because we have hardcoded devault values
for events that range from 07:00 to 19:00 in local time (ref.1).
Secondly because we're in GMT+10 so this range gets shifted:
 07:00 on Wed becomes 21:00 on Tue
 19:00 on Wed becomes 09:00 also on Wed

Then because allocations ranges are defined by dates not datetimes,
implicit casting is performed that causes cut-off of the time from the datetime
and in the end instead of checking if leave is allowed on Wed we check if
it is allowed on Tue and Wed.

[FIX]
Shifting back into the user's timezone before casting.

[Reproduction of the original issue]
- install hr_holidays
- create employee E
- create & validate new Allocation A  (in TimeOff/Allocations):
	- of type T (creating new type will help identify the issue)
	- for employee E
	- valid from Mon to Tue
- Open E's time off (Employee E -> Time Off)
- Switch your browser TZ that is +10
- Attempt to book time off for E on Wed
- BUG: you are allowed to do so

opw-3850159

(ref.1)
calendarEventToRecord from calendar_model
https://github.com/odoo/odoo/blob/15.0/addons/web/static/src/legacy/js/views/calendar/calendar_model.js#L74-L75

closes odoo#174952

X-original-commit: 27ba460
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>

Before this commit, customers could change their delivery address from
PayPal's checkout page. It created confusion because the change did not
update the selected delivery address in Odoo, if any.

This commit adds the `no_shipping='1'` parameter to the API request to
prevent PayPal from prompting users for a delivery address.

opw-4079193

closes odoo#175547

X-original-commit: 36160c0
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

…ries

Avoid setting default value of zero for Integer/Float fields
or False for Boolean fields (those are already the fields default)

This avoid triggering write on the related models (on multi-companies
database with millions on journal entries this speedup the installation
of modules from ~8-9 minutes to ~15 seconds)

closes odoo#175596

X-original-commit: def96a8
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>

…as more precision than the rounding precision

Current behavior:
When a cashier enter a payment value with more precision than the rounding precision (eg. rounding=0.10 and payment value=1.25), he just cannot proceed to the payment.

Steps to reproduce:
- Install "Point of Sale" app
- Go to the settings and enable the cash rounding
- Go the shop settings and enable the cash rounding and create a down rounding method with a precision of 0.10
- Start a shop session, select a product and go to the payment screen
- Select a payment method and write a number on the numpad so that the value goes up to the cent (eg. 1.25)
- Select another payment method to pay the rest

Solution:
With this commit, an error popup will be displayed explaining why the cashier cannot proceed the payment and what he could change to authorize the payment. This popup should appear when selecting another payment method and when validating the payment.

opw-3992018

closes odoo#174145

Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>

Before this commit, if an order failed to synchronize due to a
concurrent update error, the order would be captured in one process
and saved as an attachment in another process. This fix ensures that
the attachment is removed when capturing an order that already exists
in the database, thereby eliminating unnecessary POS order attachments.

opw-4091844

closes odoo#175551

Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>

Steps to reproduce:
	- Install eCommerce module
	- Go to Website > Cart
	- Click on Edit > Customize > Extra Info
	- Go to Website settings and Check 'Extra Step During Checkout'

Current behavior before PR:
The 'Extra Step During checkout' setting is not synchronized when
turning on and off from website editor or from website settings. This
actually leads sometimes that you might turn it on from website settings
and it won't be visible in the checkout process. This is happening because
in the 'res.config.settings' we are dealing with 'ir.ui.view' that is not
linked to any website but in the website editor we are dealing with 'ir.ui.view'
that is linked to the website you are editing.
https://github.com/odoo/odoo/blob/17.0/addons/website_sale/models/res_config_settings.py#L68
https://github.com/odoo/odoo/blob/17.0/addons/website_sale/models/website.py#L588

Desired behavior after PR is merged:
When turning on/off the setting from the website settings now we are
dealing with the 'ir.ui.view' that is linked to a website. So the setting
is now website dependant.

opw-3992571

closes odoo#170639

Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>

In Luxembourg, the "Société national des chemins de Fer Luxembourgeois"
expects the `PartyLegalEntity/CompanyID` to be filled with the "Registre
de Commerce et des Sociétés" (RCS), which is normally filled on the
`company_registry` of the supplier company.

Before this commit, we filled this tag with the VAT (which is also
filled in the `PartyTaxScheme/CompanyID`).

The peppol official documentation states:

1. `PartyTaxScheme/CompanyID`: "The Seller's VAT identifier (also known
as Seller VAT identification number) or the local identification
(defined by the Seller’s address) of the Seller for tax purposes or a
reference that enables the Seller to state his registered tax status." [1]

2. `PartyLegalEntity/CompanyID`: "An identifier issued by an official
registrar that identifies the Seller as a legal entity or person." [2]

Consequently, it is not certain whether the company_registry should
always be used to fill the element `PartyLegalEntity/CompanyID` or not,
hence we only use it in Luxembourg for now.

[1] https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-AccountingSupplierParty/cac-Party/cac-PartyTaxScheme/cbc-CompanyID/
[2] https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-AccountingSupplierParty/cac-Party/cac-PartyLegalEntity/cbc-CompanyID/

opw-4075457

closes odoo#175379

Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>

Steps to reproduce:
- Install Purchase and Accounting
- Go in Accounting > Configuration > Accounting > Taxes
- Select the line with "Tax Type" equal to "Purchases"
- In advanced options tick "Included in Price"
- In the Purchase app create a new RFQ and add the tax
- Confirm the order and receive the products
- In the Purchase Order form view go in Action > Accrued Expense Entry
- Change the date to a month from now, lines should appear
- These lines have the price including the taxes, it should be without

Cause:
The calculation of the problematic price is quantity * price, which is problematic with included taxes.

Solution:
Instead of calculating the price we use the `price_subtotal` calculated by the `compute_all` method. We can not use `price_subtotal` of the line as it includes the whole quantity and not only the quantity to invoice.

opw-4045737

closes odoo#175711

X-original-commit: 5236a67
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Mathieu Coutant (mcou) <mcou@odoo.com>

Backport of: odoo#168517

Steps to reproduce:
- Planning > Configuration > Shift Templates > Create
- Configure the Shift so that it ends 1 minute into the next day.
==> "(2 days span)" is not displayed in the shift template name.

What happens:
The rounding precision on the number of days computation only goes up to
a 16th of a day, any less was rounded down and show up as 1 day (i.e
1-14 minutes assuming 40h work weeks, ...). This 16th rounding was
removed entirely.

Rounding precision has to be at least 3 decimals for this problem to
stop occuring. 8:02 still rounds to on day on 2 decimals the commit we
are backporting here only has 2, which seems wrong.

opw-3911429

closes odoo#175737

X-original-commit: 9b23860
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Yoann Baron (bary) <bary@odoo.com>

After this commit, the option to hide the YouTube logo is removed from
the video options because the parameter is no longer supported since
August 15, 2023, in the YouTube API.

For more information, see:
https://developers.google.com/youtube/player_parameters#modestbranding

opw-4078086

closes odoo#175738

X-original-commit: f79cde9
Signed-off-by: Robin Lejeune (role) <role@odoo.com>

Chilean customers are not required to provide a Zip Code, as this information is not commonly used in the country.

task-4048931

closes odoo#175736

X-original-commit: 0383c90
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Signed-off-by: Seif Gneedy (segn) <segn@odoo.com>

With an IT company setup
Create a BILL in foreign currency with tax
Go to List view
Activate field VAT (l10n_it_edi_amount_vat_signed)

Issue: VAT amount is in company currency but symbol is in foreign
currency.
This occurs because the field is missing the correct currency_id

opw-4034566

closes odoo#172220

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

Set Company country to India
Create a TAX as follows
- Amount: 15%
- Included in price: False
- Tax repartition line:
  - 100.00% of tax to 100560 Tax Receivable
  - -100.00% of tax to 999999 Undistributed Profits/Losses
Open Bank Reconciliation Widget
Create a statement
Match with Manual operation
Select created tax

Issue: created tax lines have no amount
This occurs because when computing the tax amounts with compute_all
if the configuration of tax is price included (enforced from context)
and the tax is in cache we use the computed amount.
Unfortunately in this particular configuration the amount is 0

opw-3986439

closes odoo#173674

Signed-off-by: Laurent Smet (las) <las@odoo.com>

Currently the amount due of a move was always sent in an email for any
type of move. The condition only checked if there was an
`invoice_date_due` set. This field is set for any kind of move and
default to the creation date of that move.

However it only makes sense to show amounts due for invoices, bills,
receipts and credit notes. Showing these for miscellaneous moves like
the tax closing entry causes users to be confused. The amount displayed
is the total amount of the move and not the amount to be paid to the
authorities.

This fix makes sure we only show the amount due in emails for the right
move types in order not to confuse users.

opw-4042715

closes odoo#174819

Signed-off-by: Laurent Smet (las) <las@odoo.com>

An error occurs when adding a printer with accents in its name.
When trying to print, no error is shown to the user, only an
error log in the console.

The issue is due to the get_identifier() function in the Printer
class, which uses a regex that does not allow accents.

Steps to reproduce:
1. Add a printer with an accent in its name in Cups.
2. Synchronize the IoT box to Odoo.
3. Enable some reports printing on the IoT box for the new device.
4. Try to print a report with the new printer.
5. Then:
   1. No error is displayed for the end user.
   2. An error is logged in the console.

Solution:
Use a different regex approach by disallowing certain characters
instead of allowing only specific ones.

opw-4070003

closes odoo#176020

X-original-commit: a16774b
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Louis Gobert (loug) <loug@odoo.com>

Steps to reproduce:
- Create 2 storable product
- Update the on hand quantity to 100 only for the first one
- Create an confirm an SO 75 units of each
- Set the done qty to 50 on both moves and create a backorder
- Print delivery slip for the original picking
> The Ordered quantity is wrong on the product with no stock on hand
(50 instead of 75).

Cause of the issue:

If there's no on hand qty the backorder move will not be associated to
any `move_line` so that the `qty_ordered` will not be updated by these
lines:
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L785-L791
Furthermore, since they are not cancelled, they are filtered out here
and hence do not update the `qty_ordered` by these lines either:
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L813-L816
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L831

Fix:

We modify the filter meant for empty move lines so that moves that are
not confirmed and are not associated to any `move_line` contribute to
the `qty_ordered` via these:
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L831
However, since we do not want a move that is fully backordered to appear
on the delivery slip we need to filter out all the line keys that will
be created, because they pass our new filtering condition (but
didn't pass the old one), here:
https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L819-L821

opw-3957193

closes odoo#175556

X-original-commit: 2505caf
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
Co-authored-by: waha <waha@odoo.com>

location_menu_ids field domain was set to match a menu_type that doesn't
exist.

[reproduce orginal bug]
- install website_event
- open some event in debug mode
- Edit -> select "Website Submenu" -> Save
- Edit -> select "Website Submenu" -> deselect "Website Submenu" -> Save
- Open Event's page, BUG: location menu duplicated

opw-4049804

closes odoo#175038

X-original-commit: 41a8acd
Signed-off-by: Andrzej Pietrusiak (pian) <pian@odoo.com>

Close odoo#175793

* STEP TO REPRODUCE: go to contact form or perrsonal profile, upload
avatar with image 1.png -> Save -> Delete image uploaded -> Update that
same image 1.png again -> Nothing happen
* SOLUTION: we need to clear ev.target.value just like in v17 does
 odoo#176126

** NOTE: This issue is not exist in v15 and v17

closes odoo#176126

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

Since commit odoo/odoo@adb5357,
we have added a new DIV (`o_form_view_container`) around the form view.

But the CSS selector for the sticky control panel was not adapted so
the feature was not working anymore.

This commit fixes the CSS selector.

Steps to reproduce:
* Open Odoo on small screen
* Open the Contact App
* Select a contact
* Try to scroll down and up into the form view
=> Bug the control panel is not sticky

Note : backport of PR 176015

closes odoo#176164

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

Problem: If there is no company set on the analytic account for a work center, then an error occurs when adding a work order with that work center to a manufacturing order. The error occurs because there is no company assigned to the analytic account, so there is no currency set.

Purpose: Should be able to add a work order to a manufacturing order when the analytic account associated with the work center doesn't have an associated company.

Steps to Reproduce on Runbot:

1. Create a new analytic account and remove the company
2. Navigate to a work center and set the analytic account from the previous step
3. Create a manufacturing order
4. Add a work order with the work center from the previous step and save

opw-4036375

closes odoo#176155

X-original-commit: 1fdccad
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Richard Prosser (prri) <prri@odoo.com>