Use case: the eco-taxes (recupel, auvibel, etc) are fixed taxes in Odoo,
which apply before the "regular" (percentage) tax on an invoice line. We
can have one or more fixed taxes and 1 regular tax.

In EN16931, there can only be 1 tax per invoice line. Thus, the fixed
taxes are encoded as charge on the invoice lines (with reason code
`AEO`: "Collection and recycling"). The tags `AllowanceCharge` (in UBL)
and `SpecifiedTradeAllowanceCharge` (in CII) are used. Then a serie of
tax related infos need to be changed: the taxes in UBL/CII should not
contain the fixed ones and the total untaxed amount needs to be adapted,
as well as the total tax amount (since the fixed taxes were removed).

To be able to import the fixed taxes back in Odoo, the charges on the
invoice lines are read and their names and amounts are used to search on
the existing taxes.

task-3274208

closes odoo/odoo#122955

X-original-commit: 49ba394a
Signed-off-by: Laurent Smet <las@odoo.com>

Currently, when we create a draft move in an empty period, a sequence
number (name) gets generated and set on the move. This is fine.

When subsequently we change the date of that move to a period that
already has entries in it, the sequence number (name) for our draft move
is recalculated according to the new period.

When we post a new move in this same period afterwards, and then
delete our previous draft move, we are left with a gap in the sequence.

Example: We already have a move on 2023-01-01 with name `2023/01/0001`.
We add two new moves `A` and `B` as follows.

| Step | Move | Action      | Date       | Name           |
| ---- | ---- | ----------- | ---------- | -------------- |
| 1    | `A`  | Add         | 2023-02-01 | `2023/02/0001` |
| 2    | `A`  | Change date | 2023-01-10 | `2023/01/0002` |
| 3    | `B`  | Add         | 2023-01-15 | `/`            |
| 4    | `B`  | Post        | 2023-01-15 | `2023/01/0003` |
| 5    | `A`  | Delete      |            |                |

A gap is now created, since we have `2023/01/0001` and `2023/01/0003`,
but `2023/01/0002` was deleted (possible since it was in draft).

To solve this issue, we now make sure that when a draft entry is moved
to a period that already has entries in it, we reset the name to `/`,
to not consume a sequence number and prevent possible gaps in the
sequence later on.

task-3326834

closes odoo/odoo#121958

X-original-commit: 7ea521a2
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>

Steps to reproduce:

- Install Attendances app and Employee app
- Setup an employee with a contract which work entry source is from
attendance
- Change the working schedule to different timezone, for example
Asia/Hong_Kong
- By default the working schedule should be start to work from 0800 to 1700
- Now create an attendance in the first day of the contract, i.e.
1st May 2023, check in time 0700, check out time 2000
- The total work hours should be 13
- However, in the work entry, the genearted work entry is 0800-2000, only
12 work hours.

Current behaviour:
The generated work entry mismatches the value of the attendance

Expected behaviour:
The work entry should match the attendance

Explanation:
This issue is casued by the timezone issue. When the system generate
the work entry, it will calculate the date_from datetime and date_to datetime.
Then it will compare between the attendance and the date_from datetime to choose
the larger datetime to put inside the work entry as start time.

However, the date_from datetime didn't consider the timezone of the working schedule.
In the above example, Asia/Hong Kong time is UTC+8 time. Therefore if we convert
the attendance time back to UTC time. It is check in time 30 April 2023, 2300 to
check out time 1 May 2023, 1200. In the mean time, if we compare between the date_from
datetime (1 May 2023, 0000) and the attendance check in time (30 April 2023, 2300).
The system will take the date_from time and therefore the generated work entry time
is incorrect.

closes odoo/odoo#121233

Related: odoo/enterprise#40976
Signed-off-by: Kevin Baptiste <kba@odoo.com>

Steps to reproduce:

- Install industry_fsm_report, website
- Create Project P, add column/stage PC.
- Edit stage, Email Template = Task: Intervention Schduled.
- Edit the template > Advanced Settings > Optional report to print and
  attach = Worksheet Report (PDF). Save everything.
- Go to website, "contact us" page > Edit the form, Action = Create a
  task, Project = P > Save

Issue:

When you first submit the form, it will fail, but the task will be
created and visible in project P. By instinct, the user will submit the
form again, so the task will be duplicated. The second form submit will
return a success message.

When submitting a form, we first generate a savepoint (added in
commit [1]).
Since this is the first interaction with the report system, during the
handling of the form, the assetsbundle will be generated (see keyword
'commit_assetsbundle'), which will cause a commit.
Finally, assuming no other error is raised, we try to delete the
savepoint.
However, since a commit was executed, then the savepoint will no longer
exist, which will cause an error status to be returned.

Solution:

When submitting a form, pass `commit_assetsbundle=False` to the record
creation, which prevents the commit from happening.

This solution has a downside; creating the record also sends an email
and the report attached to that email will have broken styling. This is
still an improvement to the current behaviour, which doesn't send the
first email at all.

[1]: https://github.com/odoo-dev/odoo/commit/5a499ecf113f08c11d2b33b47680dd00ec1b297b



opw-3183912

closes odoo/odoo#122581

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

Currently if a customer makes an order with a new loyalty card, the
Balance on the PartnerListScreen does not show the balance for the new
loyalty card
We need to refresh the page

Now, the Balance will show the new loyalty card balance without
refreshing the page

opw-3332436

closes odoo/odoo#122221

Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>

Set "Cash Discount Tax Reduction" to "Always"
Have Tax A and Tax B
Create an invoice with a payment term having a discount (example: 2/7 Net 30)
Add the following lines
1) Any prod, Tax A
2) Any prod, Tax B
In journal items tab we will see 2 line for the product,
2 for tax, 3 for epd, 2 for epd tax discount, 1 for payment
Delete line 2)
Check journal items

Issue: epd discount for tax B is still there
This occurs because:
- When calculating the epd vals we don't actually
issue a clear command
- Due to a `_sync_dynamic_line` optimization
we may write on a line scheduled for delete instead of creating a new
one
As result an old tax may be left in the overwritten line

opw-3285534

closes odoo/odoo#123050

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

Backport of ea939f6 for earlier versions.
When creating an alternative RFQ, set the source document of the
original RFQ as source document of the newly created alternative.

opw-3293564

closes odoo/odoo#123034

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

When the value of fields is getting None. And no value is assigned to the
`field`. So the traceback will be generated.

In this commit, we will assign a default value to the field if the field gets a
None value. So that it won't get a None value in any case.

sentry-4211843089

closes odoo/odoo#123005

Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

The missing 15A tax report line was added in odoo/odoo#90369 but it was not included in the VAT Payable/ Refundable Total line.
With this commit, we add codes to TotalA and TotalB and modify the final total to use these codes instead.

Bug report directly to me

closes odoo/odoo#122979

X-original-commit: 897024c097f117c130ce83502bca24f940a083fd
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>

Steps to reproduce the bug (before the commits of this PR):
- Drop a Cover snippet on the website.
- Change the parallax to "None".
- Save and edit.
- Modify an option (for example, add a filter) to add the
`o_modified_image_to_save` class to the image.
- Change the parallax to "Fixed".
- Save.
- Inspect the Cover snippet.
=> The `span` element has the attributes `data-snippet="s_cover"` and
`data-name="Cover"`. Note that this could lead to problem during the
migration process.

Let's analyze the process  in order to better understand the problem:
- At the change of the parallax to "None", there is a change of the
target thanks to the call to `setTarget()`. The new target is now the
`section` element.
- At the save and edit, there is a call to `_loadImageInfo()`. All the
dataset (including `data-snippet` and `data-name`) of the new target is
copied in `this.img`.
- At the modify of an option, the `o_modified_image_to_save` class is
added to `this.img`.
- At the change of the parallax to "Fixed", there is a change of the
target thanks to the call to `setTarget()`. The new target is now the
`span` element.
- At the save, `cleanForSave()` is called and because there is the
`o_modified_image_to_save` on `this.img`, all the dataset of `this.img`
(including `data-snippet` and `data-name`) is copied on the new target
(the `span` element).

Note that this problem is resolved by the second commit of this PR.
Indeed, the dataset of the target is first filtered by
`_whiteListAttributes` before being copied into `this.img`. However,
databases that already have the problem will not be fixed by. The goal
of this commit is to remove the `data-snippet="s_cover"` and the
`data-name="Cover"` from the `span` elements in those existing
databases.

task-3287330

closes odoo/odoo#122924

X-original-commit: https://github.com/odoo/odoo/commit/a4b96962a1b4b3d06bad7a61474430151e93367d


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

*: web_editor, website

Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Put a "Blur" filter on the background image.
- Save.
- Change the parallax from "Fixed" to "None".
- Save and edit.
=> The "Filter" option displays "None" but should display "Blur".

When changing the parallax, `setTarget()` is called. The goal of this
function is to transfer the `background-image` from the old target to
the new one. The commit modifies this function by adding the transfer of
the dataset information relative to the background image from the old
target to the new one. It also transfers the `o_modified_image_to_save`
class from the old target to the new one if needed.

task-3287330

X-original-commit: https://github.com/odoo/odoo/commit/a9c194f06e1772a899cc795906e6d7cfaf33bf56
Part-of: odoo/odoo#122924

For background images, modifying options such as "Filter" does not
directly lead to the modification of their corresponding data attributes
in the DOM as those modifications are done at the save request. This
should not be the case. The goal of this commit is to, as for regular
images, modify their corresponding DOM data attributes at the option
update.

Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Replace the background image by one of your own.
- Add a filter to the background image.
- Inspect the Cover snippet.
=> The `data-gl-filter` attribute has not been added in the DOM and you
have to click on "Save" for it to be actually added.

task-3287330

X-original-commit: https://github.com/odoo/odoo/commit/4a797f51ec9d3d378fc30033e4fda2bc1e73586c
Part-of: odoo/odoo#122924

Steps to reproduce the bug:
- Add a cover snippet on the website.
- Change the background image with one of your own.
- Save and edit again.
=> Options such as "Filter", "Width" and "Quality" do not appear
anymore.

The problem is that the `src` attribute of the background image is not
correctly updated when initializing the image. This is because the
target used to recover the URL of the background image is the snippet
and not the image itself. This problem is resolved by ensuring that the
argument of the function `getBgImageURL` is the background image. Now
that the `src` attribute is correctly updated, the `computeVisibility`
function of the the `BackgroundOptimize` option works properly and the
options "Filter", "Width" and "Quality" are displayed as wanted.

Note that now, the dataset of the target is filtered with a "white list"
(BACKGROUND_IMAGE_ATTRIBUTES) before being copied in the dataset of
`this.img`. Indeed, if the parallax is set to "None" for example, we do
not want data attributes such as `data-snippet` to be copied in the
dataset of `this.img`.

task-3287330

X-original-commit: https://github.com/odoo/odoo/commit/9b11abda493500cc79ce6f6f8df3f2e3855900b0
Part-of: odoo/odoo#122924

[FIX] hr : Hide field department in launch plan wizard if multiple employees from different departments are selected

task - 3279067

closes odoo/odoo#119948

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

Forward port: https://github.com/odoo/odoo/pull/120965 added in a check
to prevent setting a reserved qty when using an import file.
Unfortunately this field was renamed in saas-15.2 during
https://github.com/odoo/odoo/pull/80434/



Therefore this fix ensures that we check the new field name.

closes odoo/odoo#122892

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

A new validation was recently added to prevent importing
reserved quantities on stock move lines, to prevent inventory
discrepancies [1]. However, such validation inadvertently introduced
another issue, which is now, if the reserved quantity is not filled with
0, the new validation is triggered.

This commit fixes the above issue by not requiring the reserved quantity
to be provided.

In addition, a typo is fixed in the error message:
"it is not allow" -> "allowed"

[1] odoo/odoo#119201

X-original-commit: 76ad7b7d
Part-of: odoo/odoo#122892

In this commit,
1. Adding a safeguard to ensure date_from is not empty before calculating the
time delta in the wizard.date_to.
2. Both classes disabled="1" and disabled="true" are not working so we add
a disabled class on the button. I don't know why disabled="1" is not working.

task-3328601

closes odoo/odoo#121750

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

To comply with the requirements asked by the Belgian government for
the PoS certification, some changes had to be made to the reports.
As we have to show the turnover of the session on the session report,
we decided to show this for everyone, as this is a useful information
for every user.

closes odoo/odoo#119319

Related: odoo/enterprise#40119
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>

Postgfresql functions can only take a max of 100 arguments by default,
when using 'jsonb_build_object' to update translations in jsonb menus
each lang adds 2 args as key value pairs. The languages should be added
in batches of 50.

closes odoo/odoo#121973

Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>

Steps to reproduce:
- install l10n_be (company B)
- stay on Company A and create a cash rounding
- Go to Company B and create an invoice
- In Other Infos > Cash Rouding Method, set it to the earlier created one
- Save

Issue:
You won't be able to save. But the message is too generic to know what is the cause of it
"Missing required account on accountable invoice line."

Cause:
The field `profit_account_id` is company_dependent. Therefore, the same cash rounding record will be accessible in both companies but in Company B the `profit_account_id` won't be set.
When Saving, we compute a cash difference (rounding) and try to create a new line for it. But since there is no account set, the sql constraint will be raised.

Solution:
The less dirty solution is to have an onchange that check that whenever we want to set a cash rounding method, it has all the required fields set

opw-3185950

closes odoo/odoo#122949

X-original-commit: 2092e8a76024ee1a818cc58e5675f5b0fa3037b6
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>

On this situation:
* P1 consumable product, kit, with components P2 and P3 in its BoM using
  1 of each
* P2 comsumable product, kit, with component P3 using 1 in the BoM
* P3 storable product, 10 units in stock

Before:
The qyt_available for P1 is 10. That's incorrect: to assemble one P1 we
need precisely two of P3s, one for P2 BoM then an extra for P1 BoM.

After:
The qyt_available for P1 is 5.

closes odoo/odoo#122899

X-original-commit: b3255432
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>

Issue:
------
In a multi-company context, the creation of a public holiday
in one company will affect leaves in other companies.
We cancel leaves that have the same time slot as the
public holiday, regardless of the company.

Solution:
---------
Take account of the company in which
the public holiday is created and compare
it with the company of the employee who has leave.

opw-3339973

closes odoo/odoo#122896

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

According to Singapore IRD documentation, Box 13 should only involve accounts of type "Income",
Currently, Box 13 calculation is based "Net Profit" which is the combination of Operating incomes, Income, Cost of Revenue, Expenses and Depreciation.

2860997

closes odoo/odoo#113087

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

When an invoice is issued in Thailand, the Revenue department will make a note that taxes need to be paid. This is important for both corporate tax and VAT purposes. A tax invoice is important to be generated and should contain the title "Tax Invoice".
On top of that, the tax invoice should also contain the information on supplier's tax id number (headquarters or branch number). In this case, we set the original Odoo invoice to be labelled Tax Invoice and create another invoice called commercial invoice.

2879718

closes odoo/odoo#113334

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

When invoicing the first time to a customer, the user can choose a style layout for the invoice.
The 'Striped' laoyout is a little bit different when we configure it and preview the pdf than when using it in an actual invoice.
This commit make the layout preview more accurate in relation to the real invoices.

Comment that led to the task : https://www.odoo.com/web#id=3232301&menu_id=4720&cids=1&action=333&active_id=809&model=project.task&view_type=form



closes odoo/odoo#115979

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

In a Kanban View, the container in which elements are dragged is a `d-flex`
element, and as such it has the `overflow: visible` css property by default.
This means that if there are more groups than the current dimensions of the
viewport allows for, those groups will overflow outside the dimensions of the
container, preventing elements from being dragged outside.

Therefore the dimensions of the draggable area should consider the container
`scrollWidth` and `scrollHeight`, as these values take into account the
dimension of overflowing elements.

task-3339978

closes odoo/odoo#122576

Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

False

closes odoo/odoo#122375

X-original-commit: 8754284f
Signed-off-by: William André (wan) <wan@odoo.com>

AssertionError: convert amount from unknown date
The problem occurred when removing the default value of 'Order Deadline' and
selecting a product before saving the record.

After applying this commit will fix this issue.

sentry-4175826548

closes odoo/odoo#121592

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

Before 16.0 and https://github.com/odoo/odoo/pull/78857 the session
cookie duration was set to 3 months, but the server-side garbage
collection of inactive session was reaping them after 7 days of
inactivity. The cookie lifetime was essentially superseded by the
server-side GC.

After https://github.com/odoo/odoo/pull/78857

 these limits were made
consistent with each other, but the lifetime value was kept at 3 months,
which is a bit too long as a default.

This commit changes the default SESSION_LIFETIME back to 7 days for both
limits.

In addition, since the server-side GC is now implemented by a
database-specific cron job, this commit introduces an optional system
parameter `sessions.max_inactivity_seconds` that can be set to override
the default server-side GC threshold, to make it shorter.

Note 1: the ICP does not modify the cookie lifetime which will remain set
to the default 7 days. This means normal browser sessions won't stay
alive for longer than 7 days of inactivity. So `sessions.max_inactivity_seconds`
can't be effectively set to a longer expiration time.
This seems like a reasonably safe default.

Note 2: the session GC happens during the execution of the autovacuum
cron job ("Base: Auto-vacuum internal data") which is scheduled once per
day by default. When setting a small `sessions.max_inactivity_seconds`
value, it may be necessary to increase the frequency of that cron job
accordingly.

closes odoo/odoo#122888

Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

Steps to reproduce:
- set up a header with company logo
- print 20 sale orders in arabic

Bug:
header disapears on most pages

Fix:
add a setting to allow users to increase the delay before printing

opw-3217155

closes odoo/odoo#122850

X-original-commit: 5d18944b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

Group the res_partners in self by placeholder_path value before
calling __setitem__ on each group. Because placeholders are
independent from the recordset, we can set the value
of res_partner[avatar_field] to a placeholder for a recordset
of partners. When self contains lots of partners without
image_field value, this speeds up the _compute_avatar function
noticeably. This in turn speeds up stuff like loading
the Contacts KanbanView (search_read on res_partner).

Example speedup: In a database without any image for the partners,
search_read for avatar_128 with limit=80: 609ms -> 64ms.

opw-3128771

closes odoo/odoo#122840

X-original-commit: 34e97b4c65b7392576d94b870e22e74df14f9dd2
Signed-off-by: Rémy Voet <ryv@odoo.com>

When moving a package, the quant at source location is not
automatically removed

To reproduce the issue:
1. In Settings, enable
   - Packages
   - Storage Locations
2. Create a storable product P
3. Update the on hand quantity
   - 1 x P at WH/Stock in package PK
4. Create a planned delivery D with 1 x P
5. Confirm and reserve D
   - PK should be reserved
6. Validate
7. Open the package
   - Its location is "Partner Locations/Customers", which make sense
8. Inventory > Configuration > ... > Locations, open WH/Stock
9. Current Stock

Error: There is a line with PK. The quantity is 0 but still, it
create some confusion for the user who could believe that the package
is still in WH/Stock

This issue does not occur if the user goes through the product form
and click on the on hand quantity. The "incorrect" quant will not be
there. This is because, when loading the action, we call
`_quant_tasks`:
https://github.com/odoo/odoo/blob/05a7f5c04804423cfc3a833a1b3f0b5eec3fc147/addons/stock/models/stock_quant.py#L296-L300
This method will clean the quants (merge & unlink)

However, in the above case (step 9), the action is defined on XML side:
https://github.com/odoo/odoo/blob/7d4dfeb0e26b387dee312897264a68963f90267f/addons/stock/views/stock_location_views.xml#L24-L26
https://github.com/odoo/odoo/blob/d956e719d43c68abe6210e3136db576aaa6f60b8/addons/stock/views/stock_quant_views.xml#L190-L196


So, we can't make it behave as it does from the product form,
unfortunatly.

As alternative, we can try to call `_unlink_zero_quants` when we are
moving a package (and not `_quant_tasks` for perf matters as, so far,
we will not have any quant to merge)

OPW-3292238

closes odoo/odoo#122768

X-original-commit: 5fb84ba5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

A raw query is not necessary to produce the desired result, found
activities need to be kept only if the corresponding record can be found
with standard search (which includes multi-company check).

Part of task-3266643

closes odoo/odoo#122698

X-original-commit: 815bc803
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Before this commit, the reversal of a passed exchange
move was not created on the correct date:

- If sequence is reset by month, the reversal should
  be created at the end of the month of the exchange
  move, and if sequence is reset by year, at the end
  of the year.

Steps:

- With a foreign currency X activated and two different
  rates few months in the past.
- Create and confirm an invoice with currency X at the
  date of the first rate.
- Register a payment at the date of the second rate
  (an exchange move is created).
- Unreconcile the payment from the invoice.
-> A reversal of the exchange move is created, but the
   date is wrong (set to today's date).

opw-2856385

closes odoo/odoo#122167

X-original-commit: d47cf44f
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>

Previous commit (https://github.com/odoo/odoo/pull/116570

) renamed
this method _get_subtasks_recursively.
But instead of calling itself in the return statment, the
method _get_all_subtasks was called resulting in a non-recursive
function and to potential undesired behavior as _get_all_subtasks calls
_get_subtask_ids_per_task_id that calls _get_subtasks_recursively in
some cases.

With this commit, we just call _get_subtasks_recursively on the children
to make it actually recursive, like it was in the first place.

closes odoo/odoo#122331

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

before this commit, in the payment transaction form
the field state_message(Message) is showing value
 too compactly

* accounting -> configuration -> payments ->
payment transactions

after this commit, the field will display value
properly utilizing the full width

closes odoo/odoo#122821

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

Steps to reproduce the bug:
- Drop the "Form" snippet on the website.
- Add a new field.
- Replace the field label by two quotation marks (`""`).
=> Traceback appears.

Since [1], it is possible for the user to create forms whose fields can
have a conditional visibility, meaning that the field is only visible if
another field in the form meets certain conditions. Due to that, there
is a mechanism that verifies if a condition on a field should be updated
when the user modifies the label of a field. To do so, a `querySelector`
is searching for an element that has a `data-visibility-dependency` set
to the previous field name by doing a querySelector of type
`querySelectorAll('.s_website_form_field[data-visibility-dependency="${previousInputName}"]')`.
Because `previousInputName` is set to `"`, it is not considered as a
character and an error is thrown.
To resolve this problem, strings that are stored in `name`, `data-name`
and `data-visibility-dependency` are encoded: All the occurrences of `"`
are replaced by `"`, all the occurrences of `'` are replaced by
`'` and all the occurrences of ``` ` ``` are replaced by `‘`.

[1]: https://github.com/odoo/odoo/commit/2dcbfecf3c10687a2cd3af36335d5be70c904fce



opw-3246341

closes odoo/odoo#122769

X-original-commit: ccaf4f1e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>

The goal of this commit is to be able to use the `addCustomField`
function with a `type` argument that is different of `checkbox`,
`radio` or `select`.

opw-3246341

X-original-commit: 34b3770a
Part-of: odoo/odoo#122769

When processing several SMLs at once, the 'same product' policy of a
storage category is not respected

To reproduce the issue:
1. In Settings, enable:
   - Multi-Step Routes
   - Storage Categories
   - Packages
2. Create a Storage Category SC:
   - Allow New Product: same
3. Create two locations L1, L2:
   - Parent: WH/Stock
   - Type: Internal
   - Storage Category: SC
4. Create a putaway rule:
   - When in: WH/Stock
   - Package type: Pallet
   - Store to: WH/Stock
   - Having Category: SC
5. Edit the warehouse:
   - Incoming Shipments: 2 steps
6. Create two products P01, P02:
   - Type: Storable
7. Create a planned receipt R:
   - To: WH/Input
   - Operations:
     - 1 x P01
     - 1 x P02
8. Mark R as Todo
9. Create two packages:
   - 1 x P01 in PK01 (! PK01 must be a Pallet)
   - 1 x P02 in PK02 (! PK02 must be a Pallet)
10. Validate R
11. Open the related internal transfer

Error: Both packages are redirected to L1. Considering the product
policy of SC, one line should be redirected to L1 and the second one
to L2

To apply the product policy, the code looks at the quants of each
location. But it does not consider the incoming SMLs. Therefore, when
applying the putaway rule to the first SML, it selects L1 (which
makes sense). Then, for the second SML, because it does not see the
first one, it considers that L1 is empty and can be selected, hence
the error.

OPW-3204924

closes odoo/odoo#122742

X-original-commit: 8bde894638838b449d097e7d75092aa15c646c74
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

Since https://github.com/odoo/odoo/pull/121355

,
add_to_compute on no-store compute field, lead to recompute the field
at the end of request and it can lead to some non deterministic bug
(compute with a bad context by example).
Avoid to add_to_compute no-store or no-compute fields.

closes odoo/odoo#122496

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