It is not possible for a user to add a carrier directly on a picking if
the invoicing policy of that carrier is set to "Real Cost"

To reproduce the issue:
1. Enable a carrier C
2. Setup a shipping method SM:
    - Carrier: C
    - Invoicing Policy: Real Cost
3. Create and confirm a SO with a product
4. Edit the related picking P:
    - Carrier: SM
5. Validate P

Error: a Validation error is raised "The operation cannot be completed
[...] Model: Sales Order Line (sale.order.line), Field: Description
(name)"

When validating the delivery, we try to create a new SOL with the
shipping cost. We then update its description with the carrier name.
However, since the carrier has been directly added on the picking, the
sale order does not have that information. We should rather get this
information from the delivery.

OPW-2862306

closes odoo/odoo#103764

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

When creating a recipient from composer_suggested_recipient the user
is free to modify the partner form however they want.

This can lead to them inputing data which will create a partner
that does not match the suggested partner data.
In that case the box acts as if the partner was not created.

This aims to remove the partner in such cases and warn the user.

task #3016112

closes odoo/odoo#103596

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

Before this commit: if you use the lot/serial number for the products, it
won't load correctly through the UI.

closes odoo/odoo#103815

Issue: https://github.com/odoo/odoo/issues/100888


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

Necessary improvement to the snailmail invoice layout for snailmail to work since Pingen has deprecated their v1 API with the plan to shut it down at the end of 2022 + their v2 API's validation is stricter.

closes odoo/odoo#103379

Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

Pingen's v2 API does not offer an endpoint to generate a Cover Page automatically with an API call anymore, thus the need to generate it and append it to the invoice from the client-side beforehand.

Part-of: odoo/odoo#103379

When writing a workorder start or end date from its manufacturing order
(and if the MO is unplanned), an error is thrown

Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Open an MO with Work Orders
4. Unplan the MO
5. Add a Scheduled End Date to one of the Work Orders
6. Save
7. An error is thrown

Solution:
Compute the new duration only if both `start_date` and `end_date` are
set (and one of `date_planned_start` and `date_planned_finished` is
passed in values)

Problem:
When only one of `date_planned_start` or `date_planned_finished` is
written on an `mrp_workorder` (and the other is not set), the method
`_calculate_duration_expected` is called but it fails because it passes
a False value instead of a datetime which will raise the error `'bool'
object has no attribute 'tzinfo'`

opw-3004280

closes odoo/odoo#101961

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

New phones go up to 48MP (Samsung Galaxy A22).
Also the error message was saying 4.5 instead of 45.

opw-3020614, opw-3020502

closes odoo/odoo#103603

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

This commit restores the possibility to control the height of the
image gallery snippet. This was indeed possible in <= 11.0 for all
snippets but it was removed in 12.0 as controlling the height via inner
paddings seemed enough and better (as responsive). For the image gallery
snippet however, this was a big regression as the height is forced to
70% of the current screen height on drop and the images inside are
displayed depending on that forced height. Trying to control via
paddings was not leading to the wanted effect.

This restores the possibility in 14.0 as 12.0 and 13.0 are now
deprecated. This is following a customer issue where not having the
ability to control the height is actually confusing as the user edits
its website across different screens and the height is forced to 70%
height of the screen used at the time of edition. With an height input
in the panel, the confusion is gone.

Note: this also introduces a `forceStyle` parameter for the
`selectStyle` option to be able to force the inline style a widget
controls. Indeed, without it, the system is "smart" and tries not to
force inline style when it is not needed (if you try to force red on
something that is naturally red (thanks to a CSS rule for example), it
won't be forced). Here, this was leading to an issue when trying to set
the height:

- Current height is 700px
- There is some code that forces a min-height on all carousel items so
  that they are the same height. As the gallery image dimensions depend
  on the block forced height (this is how the snippet work), the forced
  min-height are related to that forced height (something like 680px).
- You focus the height input and type 800px
- The same code forces new min-height on all carousel item (something
  like 780px).
- You un-focus the height input, the system tries to re-set 800px (which
  is already set)... it ends up removing it as it thinks that setting
  that height is not needed as the snippet is now "naturally" 800px tall
  thanks to the carousel items' min-heights.

opw-2838774

closes odoo/odoo#103694

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

This join is a leftover from https://github.com/odoo/odoo/pull/28248


and is not needed anymore since currency_rate is now stored on purchase.order.
Removing it allows to greatly speedup purchase.report queries.

On a database with 7000 purchase order and 1100 res_currency_rate:

From:
Planning Time: 4.411 ms
Execution Time: 19815.754 ms

To:
Planning Time: 16.914 ms
Execution Time: 77.433 ms

opw-2973044

closes odoo/odoo#101002

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

Current behavior:
If you try to edit the form view of pos.order in studio, you get a
traceback.

Steps to reproduce:
- Install point_of_sale
- Go to PoS order
- Click on studio
- Click on the button to edit the form view
- You get a traceback

opw-3008565

closes odoo/odoo#103403

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

Method `consume` is called at the end of a tour. Tour can be started via debug
menu by any admin with "Access rights", however the method requires `Settings`
access level.

Fix it by adding `sudo()`. This issue could be reviewed in master.

STEPS:

* change Administration access level to "Access rights"
* start tour `sale_quote_tour`
* follow the tour steps

opw-2965772

closes odoo/odoo#99378

Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>

The liquidity line of a statement line is always expressed in journal currency.
The counterpart lines (invoice lines most of the time) are expressed in the transaction currency.
When reconciling the statement line with an invoice line, the current code sums the amounts in foreign currency to detect if there is a rounding issue or not.
However, the considered amount for the liquidity line is not expressed in the right currency (journal currency instead of the transaction one).

Note: The current test is working even without the fix in 14.0 but is failing on the next version because the code has changed.

co-author: ushyme (sesn) <sesn@odoo.com>
opw-2991183

closes odoo/odoo#103676

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

Steps to reproduce:
- Edit
- Add a snippet with columns
- Save
- HTML editor
- Set up a border on one column of the snippet with different colors for
  the top/right/bottom/left sides
- Edit
- Click on the column => crash

This is only an example, but if a colorpicker widget is linked to a
SnippetOption instance's `selectStyle` method designed to handle the
"border-color" property of an element, the value received can be split
if the item uses different colors for its top/right/bottom/left borders.
For instance, you could receive "red blue" if the item has red top and
bottom borders and blue left and right borders. In that case, the
colorpicker widget code would try to add the class "bg-red blue" on its
preview item which would crash because of the space inside).

After this commit, we simply do not show any color for this case.

opw-2803311

closes odoo/odoo#103654

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

We are spammed by some accounts that don't have credits anymore.

With this commit, when we try to send letters from the cron, whenever we
meet the CREDIT_ERROR error_code, we stop trying to send the letter.

task-2930455

closes odoo/odoo#103489

X-original-commit: f1fed40e
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

Steps to reproduce:

 - Install Sales,Inventory
 - Set delivery methods
 - Set customer language in French have the user in English
 - Create sale order with at least one item
 - Add a delivery Method, Free Delivery Method

Issue:

  Sale order line related to delivery product is in both
  the customer language and user language.
  If you print and invoice, the delivery method line
  will be in two different languages

Cause:

  Partner language wasn't being applied to context
  and therefore translations were not in partner's
  language.

Solution:

  A local variable context was defined and assigned
  the partner language to in the local scope. This induces translations
  to occur in partner's language.

https://github.com/odoo/odoo/blob/cff91c6acbb7ef6a884d4dc4170574b83ff6e4cb/odoo/tools/translate.py#L416-L417



Backport of 863537b9

opw-3000159

closes odoo/odoo#103663

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

Before this commit there was an issue with the header effects (except
the 'Scroll') if the page did not have much scroll height when the
header decreases in height when scrolling down. When this issue appeared
it was impossible to reach the bottom of the page.

This was due to the fact that when the header size is smaller when
scrolled (e.g. height scrolled logo option), the padding-top of the
`main` is decreased and therefore the scroll height of the page too..
Which meant that, during the transition that changes the height of the
header, this decrease in scroll height immediately increase the height
of the header, then decrease, etc. in an endless loop.

This commit fixes that by no longer triggering an animation that changes
the height of the header if the scroll height is too short.

This commit also fixes an issue with the standard effect which was not
properly destroyed and left a 'translate transform -100%' on the header
when changing the "standard" effect to a "scroll" effect and the page
was scrolled.

opw-2812482

closes odoo/odoo#87757

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

- Steps to reproduce:
- Install Stock/MRP
- Create a custom view where you use move_finished_ids, for ex:

<data>
<xpath expr='//form[1]/sheet[1]/group[1]' position='inside'>
<field name='move_finished_ids'/>
</xpath>
</data>

- Create a new MO
- Traceback with keyerror byproduct_id

To solve the problem we use get() instead of accessing the key directly

- Task id: #3008264

closes odoo/odoo#102302

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

To reproduce:
1. Create a (incorrect) view manually. For example, inherit from
`res.config.settings.view.form` and do add the following view architecture:
```xml
<data>
  <xpath expr="//div[hasclass('settings')]" position="inside">
    <field name="field-dont-exist" widget="upgrade_boolean"/>
  </xpath>
</data>
```
( In practice, Odoo will refuse to let us save the view if it is incorrect
(we can bypass that by pushing directly in the database for testing) )

-> When trying to open the settings app, you will have a cryptic JS error:
`TypeError: field_utils.format[(formatType || this.formatType)] is not a function`
The goal of this PR is to improve the error to ease its correction.

Note: This issue can happen in practice after an upgrade or a failed
uninstallation of a module.

OPW-2952309

closes odoo/odoo#98189

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

Because of an issue with converting bool values, read_progress_bar didn't work
on grouping by bool fields (e.g. Active).

Related tests worked fine because mocked server responses were different from
real server responsed. So, we need to adjust mocked server too.

opw-2870937

closes odoo/odoo#103617

X-original-commit: 73a7f4e4
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

Before this commit: the "no-store" was overridden in developer mode.

'no-cache' does not require that the response must not be stored in the
cache. It only specifies that the cached response must not be reused to
serve a subsequent request without re-validating.
It is up to the browser what to qualify as a subsequent request. In
Chrome, using the back button and duplicating the tab does not. So I
agree that it's better to use 'no-store' in dev mode.

The solution is to prevent changing the "Cache-Control" if it's "no-store".

opw-2855802

closes odoo/odoo#103608

X-original-commit: 397e9179
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Before this fix, when reconciling an invoice with a refund (both using cash basis taxes) in a multicurrency setup, the two cash basis entries that got created were made so that the invoice's used the refund's rate, and the refund's used the invoice's one.

This caused confustion, and forced Odoo to always add cash basis adjustment journal items in the exchange difference move, in order to balance the accounts properly.

By not swapping the rates anymore, we avoid the creation of these journal items.

OPW 2888592

closes odoo/odoo#103554

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

When reconciling an invoice using cash basis taxes with multiple payments, it is possible that some base or tax amount falls victim of rounding errors (for example, a tax amount of 9.99 would become 4,49 when paying the invoice with two payments of half its amount, hence loosing one cent).

In this case, when the invoice gets fully paid, we fix that by using adjustment lines in an exchange difference entry (even in monocurrency).

The bug we fix here is that the lines added into this exchange difference entry were never considered as tax exigible, and hence never appeared in the tax report, even though they should. This was due to the fact tax exigibility is recomputed automatically when creating the entry, so the value needs to be set afterwards.

OPW 2888592

Part-of: odoo/odoo#103554

Steps to reproduce the bug:
- Create a storable product “P1” with BOM:
    - Type: Kit
    - Quantity: 3
    - Components:
        - product “C1”, QTY: 5

- Update the quantity of “C1” to have 10 in stock
- Go to “P1” product form

Problem:
- The on-hand quantity is 2 instead of 6 →
  10 (available qty of c1) / (5 / 3) = 6

In the `_compute_quantities_dict` function, the `explode` function is
called to have the qty of the component necessary:
https://github.com/odoo/odoo/blob/ef4ae7f62d6b690b4745b4145ce25ff02b6b29f6/addons/mrp/models/product.py#L151
but it is the qty necessary for 3 kit according to what is indicated
in the BOM, so we will have 5 qty needed of “C1” as a result:
https://github.com/odoo/odoo/blob/49234be3418169c8f3c928493b86a1a67ab55914/addons/mrp/models/mrp_bom.py#L289
Then the quantity available in stock of the “C1” (10) is reduced by
the quantity needed (5), so 2:
https://github.com/odoo/odoo/blob/ef4ae7f62d6b690b4745b4145ce25ff02b6b29f6/addons/mrp/models/product.py#L188


But this result must be multiplied at
the end by the quantity set in the BOM (3), to get the quantity per kit
→ (10/5)* 3 = 6

opw-3010175

closes odoo/odoo#103325

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

If the credential of Adyen are not correct and refresh POS after a payment
The cashier are unable to cancel or remove the payment line
Because the longpollong continue to reach Adyen to try to get a response.
This issue come from the last on POS_adyen commit:
262e50e2

With this commit we stop the polling if we can't reach Adyen server
So the correct status is setted at the payment line and the cashier
can delete it.

closes odoo/odoo#103281

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

Current behavior:
When the product name is too long and the language is a right to left
language, the background gradients is flipped.

Steps to reproduce:
- Create a PoS product with a long name in Arabic (عر باب
الحرم المدني الفاخر عليقة باب الحرم ريال شاملا الضريبة)
- Set DB language to Arabic
- Open PoS session
- The background gradient is flipped.

opw-3011393

closes odoo/odoo#103310

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

Take a (py.extras) datetime representing the moment "2022-10-17 00:00:00"
in the timezone of Brussels. Trying to get the related utc moment through
to_utc gives wrongly "2022-10-16 23:00:00". This happens because the
months are not numbered in the same way in Date or datetime, so that in
October for example, the offset applied was that of November which is
-60 instead of -120 (summer/winter change). We fix that problem.

closes odoo/odoo#103367

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

Issue:
The stripe idempotency keys do not allow the same key for
different endpoints hence we modify the key for refunds.

opw-2662964

closes odoo/odoo#103482

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

Current behaviour:
When installing Sales, then PoS, we get an error when loading the modules.

Expected behaviour:
No error should be present when installing PoS just after the Sales app.

Steps to reproduce:
(With demo data)
- Install Sales
- Install PoS
- Get Error

Reason for the problem:
When installing Sales, there is the Product dependency that creates a product variant,
named product_product_4d.
Then in the Sales demo data there is the addition of an "exclude_for"
record (basically an exclusivity rule for variant attributes, for ex: A AND B cannot be together).
In our case it happens to be the attributes which product_product_4d was based of. Therefor the ORM
deletes said record (from the database).
Then when installing PoS, it installs Stock as a dependency, which demo data references product_product_4d,
which is not present anymore in the database.

Fix:
Remove the creation of product_product_4d and all the records that reference it.

Affected versions:
- 14.0 (separate PR)
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master

opw-2999180

closes odoo/odoo#101920

Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>

Current behaviour:
When an indonesian customer buys from the POS and generates an invoice,
we get an error of missing kode_transaksi of the customer,
even tough it it correctly set on the invoice details of the contact.

Expected behaviour:
Every indonesian contact with correctly setup up invoice details,
should be able to checkout from POS and generate an invoice without
problems.

Steps to reproduce:
- Install indonesian accounting localisation, the efaktur module, POS and Contacts
- Switch to the Indonesian company
- Create a new Contact, add a VAT, check ID PKP,
and in Invoicing fill the whole "Indonesian Taxes" section
- Add a valid invoice range in the e-fakture general settings
- Setup a POS Session if non is present, it's irrelevant, start a new session
- Try to buy something with the new contact as customer, and generate a new invoice at checkout.
- You should have a pop-up error about the "Kode Transaksi" missing.

Reason for the problem:
The `l10n_id_kode_transaksi` field is not present in the values used
when generating the moves for the invoice.

Fix:
Add a compute that fetches the kode_transaksi from the partner_id linked
to the move.

In the meantime, we needed to inverse the readonly states logic (keeping
the same behaviour) in order to avoid the compute being triggered in the
constraint.

Affected versions:
- 14.0
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master

opw-2993838

closes odoo/odoo#101365

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

Change datev codes in l10n_de_skr03 and 04 for some lines and allow 4 digit codes.

closes odoo/odoo#100289

Doc: https://apps.datev.de/help-center/documents/0907043


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

Apps store menus currently don't work and they are redirected to local Apps
menu. Because the warning message says "Odoo Apps will be available soon", user
may click such menu few times and notice growing breadcrumps, which looks buggy:

Apps / Apps / Apps / Apps / Apps / Apps / Apps / Apps / Apps / Apps / Apps

To reproduce: activate debug mode and click menu Apps / Updates

opw-2985389

closes odoo/odoo#100476

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

When having falsy values, we may end up with 'False' as a string. Better be
defensive when trying to parse res_id.

Task-3025143

closes odoo/odoo#102576

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

When mail_action_view() calls this function, the model may not be a valid
one or even be missing. So we check if the model exists before checking its
type.

We also correctly add kwargs parameters propagation.

Add tests.

Task-3025143

Part-of: odoo/odoo#102576
Co-authored-by: Krzysztof Magusiak <kmagusiak>

Before this commit:
Let's consider project P1 having no stages.
Let's consider project P2 having Stage 1, Stage 2
When importing tasks via csv file:
- Task 1 for project P1 and Stage 1
- Task 2 for project P1 and Stage 2

Stage 1 and Stage 2 are still assigned only to project P1.

After this commit:
Stage 1 and Stage 2 are now assigned to P1 and P2.

Task-2996393

closes odoo/odoo#101783

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

Before this commit, multi clicking quickly on the "Ok" or "Cancel"
buttons of a confirmation dialog would call the confirm callback
multiple times. For instance, in "Mass mailing", create a new
mailing and click "Send". In the confirm dialog, clicking quickly
multiple times on "Ok" would call the "Send" button action multiple
times.

Fixing #74647 (from 14.0 to 15.3)

closes odoo/odoo#103202

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Fix the matrix question type preview display
on small and medium screen size.

Task-3006768

closes odoo/odoo#102191

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

Revert commit 5221fe2a1d77b586495b23f8b57d5e80d08e5b10
Indeed, some localizations are inconsistent.
For instance, for l10n_tr, l10n_pl, l10n_et and l10n_vn, `property_account_expense_categ_id`
is an account of type current_assets.

closes odoo/odoo#102891

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

Currently, if the employee is not linked with the user, then the current user is
set in the timesheet.Now it will be fixed.

  Steps to reproduce:
      1. Install hr_timesheet
      2. Go To Employee
      3. Create employee
      4. Open the timesheets (Click on the 'Timesheets' stat button)
      5. Create the timesheet
      6. Check the user

Task-2924292

closes odoo/odoo#96318

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