This fix prevents an error when opening or customizing the manufacturing work order planning view without selected records. It skips an availability check when there is no relevant data, making the view more reliable for users working with Odoo Studio.

Traceback happens because it doesn't require records and call the function without row records. The code doesn't handle that case.

Don't try to find unavailabilities in that case and just skip this part of code

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

This update adjusts parts of Payroll and Knowledge so they continue to work correctly after a change in how new records are created behind the scenes. It prevents failures in related screens and keeps automated checks passing.

The PR https://github.com/odoo/odoo/pull/111965 has as a side effect to
change the value returned by the create method of the orm service. Here
we adapt the code that uses it and make the test pass.

Using the web_editor html field in the Record component causes crashes. Why does this happen? The fields used in the Record component do not always have modifiers. Solution: Use the isReadonly function of the record to know if the field is readonly or not. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-P

Using the web_editor html field in the Record component causes crashes.

Why does this happen?
The fields used in the Record component do not always have modifiers.

Solution:
Use the isReadonly function of the record to know if the field is readonly or not.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#113025

For performance reasons, the grouped kanban view automatically folds groups when they are to many, s.t. at most 10 groups are open by default (because for each one of them, we must perform a web_search_read rpc to fetch their records) [1]. However, during the convertion to owl, we broke half of this logic. The qunit test introduced by [1] simulates a read_group that only sets the __fold key to true in folded groups, but doesn't define it in other groups. This test passed. But the logic

For performance reasons, the grouped kanban view automatically
folds groups when they are to many, s.t. at most 10 groups are open
by default (because for each one of them, we must perform a
web_search_read rpc to fetch their records) [1].

However, during the convertion to owl, we broke half of this logic.
The qunit test introduced by [1] simulates a read_group that only
sets the __fold key to true in folded groups, but doesn't define it
in other groups. This test passed. But the logic in the model
didn't correctly handle the case where the __fold key was given for
all groups, even when its value was set to false. This happens for
instance in the project task kanban view.

This commit fixes the issue.

[1] https://github.com/odoo/odoo/commit/fa4c650b01dc184041c61d9d52299b0b740a83bd

Task 3191948

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#112954

Before this commit, name_get of the res.partner model could return the partner's name + its address but with empty lines if some address elements were not set. Now, these empty line are removed which makes the address cleaner. task: 2759019 Forward-Port-Of: odoo/odoo#112207

Before this commit, name_get of the res.partner model could return
the partner's name + its address but with empty lines if some address
elements were not set.
Now, these empty line are removed which makes the address cleaner.

task: 2759019

Forward-Port-Of: odoo/odoo#112207

Steps to reproduce the bug: - Enable “multi routes” and “wave transfer in the settings - Go to warehouse: - Incoming shipments: - Select 3 steps - Create two storable products “P1” and “P2”: - update their qty - Create a purchase order: - Add “P1” and “P2” - Confirm - Go to the picking: - Set qty done only for “P1” - Validate the picking and create a backorder - Go to inventory > Operations > Transfers: - Select the internal transfer from input

Steps to reproduce the bug:
- Enable “multi routes” and “wave transfer in the settings
- Go to warehouse:
    - Incoming shipments:
        - Select 3 steps
- Create two storable products “P1” and “P2”:
    - update their qty
- Create a purchase order:
    - Add “P1” and “P2”
    - Confirm
- Go to the picking:
    - Set qty done only for “P1”
    - Validate the picking and create a backorder
- Go to inventory > Operations > Transfers:
     - Select the internal transfer from input to quality control
     - Action > Add to wave
     - A new wave transfer > select the move for “P1”
     - Add to wave

Problem:
The operation type is not set on the wave transfer

opw-3112142

Forward-Port-Of: odoo/odoo#112976
Forward-Port-Of: odoo/odoo#112716

Before this commit: If we do a payment in COP (Colombian currency) with a 2 decimal price, For example: $ 1.23 The signature generated by Odoo to PayULatam will be wrong. This will lead to an Internal Server Error caused by the `ValidationError`: `PayU Latam: Invalid sign: received %(sign)s, computed %(check)s.` Note that the issue does not happen on version 14. By cross comparing with the version 14, the issue don't happen there as the signature sent by Odoo at the beginning of the transac

Before this commit:
If we do a payment in COP (Colombian currency) with a 2 decimal price, For example: $ 1.23
The signature generated by Odoo to PayULatam will be wrong. This will lead to an Internal Server Error caused by the `ValidationError`: `PayU Latam: Invalid sign: received %(sign)s, computed %(check)s.`

Note that the issue does not happen on version 14. By cross comparing with the version 14, the issue don't happen there as the signature sent by Odoo at the beginning of the transaction is different.
For some unknown reason the code was changed in version 15 to round it to the first decimal and this looks to be the cause of the issue. So, in fact the signature that Odoo send at the beginning of the transaction looks to be wrong and this ends up modifying the signature that should be generated on the return of the transaction

Version 14 code to compare with:
https://github.com/odoo/odoo/blob/bbb987edff769a825f7617d24314ec7d79e29c40/addons/payment_payulatam/models/payment.py#L41

After this commit
No internal server error and the transaction is validated correctly

opw-3018628

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#112990

[FIX] delivery: wrong delivery price for real cost in so Steps to reproduce the bug: - Install FedEx delivery - Go to the shipping method > FedEx: - Select Real cost and margin on rate 10% - Create a storable Product “P1” and update its qty - Create a SO: - Add the product “P1” - Click on add shipping - Select FedEx and get the rate - Imagine the price is $10 and with margin it's $11 - Confirm the SO and process the delivery Probelm: The shipping price will

[FIX] delivery: wrong delivery price for real cost in so

Steps to reproduce the bug:
- Install FedEx delivery
- Go to the shipping method > FedEx:
    - Select Real cost and margin on rate 10%
- Create a storable Product “P1” and update its qty
- Create a SO:
    - Add the product “P1”
    - Click on add shipping
    - Select FedEx and get the rate
    - Imagine the price is $10 and with margin it's $11

- Confirm the SO and process the delivery

Probelm:
The shipping price will be $12 instead of $11 in the SO

Because the estimated price is calculated the first time with margin and added in the picking when sending to the shipper: https://github.com/odoo/odoo/blob/afed7db30042e2ea91cdae292dadb7b6f742e33d/addons/delivery/models/stock_picking.py#L226

Then, the delivery cost is added to the SO, but the margin is applied a second time:

https://github.com/odoo/odoo/blob/afed7db30042e2ea91cdae292dadb7b6f742e33d/addons/delivery/models/stock_picking.py#L246

https://github.com/odoo/odoo/blob/afed7db30042e2ea91cdae292dadb7b6f742e33d/addons/delivery/models/stock_picking.py#L262

so this commit is useless:
https://github.com/odoo/odoo/commit/632767d83e0f42acc5b486bde02dd1d9c2533911
because the `_add_delivery_cost_to_so` function is called only when sending to the shipper

opw-3184482

Forward-Port-Of: odoo/odoo#112996
Forward-Port-Of: odoo/odoo#112910

For the Knowledge module, we would like to allow the user to fully customize a graph view and let the user insert the graph they see in an article. When loading the graph view from an article, the system can not currently restore the following settings: 1. For the bar chart and the line chart: The system will not able to restore the "sorting order" and the "stack option" set by the user. 2. For the line chart: The system will not be able to restore the "cumulative option" set by the user.

For the Knowledge module, we would like to allow the user to fully customize a graph view and let the user insert the graph they see in an article. When loading the graph view from an article, the system can not currently restore the following settings:

1. For the bar chart and the line chart: The system will not able to restore the "sorting order" and the "stack option" set by the user.
2. For the line chart: The system will not be able to restore the "cumulative option" set by the user.

This PR will ensure that these options can be specified from the context of the view. The context configuration will have a higher precedence than the configuration stored in the metadata of the model.

When the user will open an article containing a graph view, the graph view will automatically load the options that have been set by the user when inserting the view. The user can thus create their own dashboards by customizing the graphs and inserting them in an article.

This PR will also fix some inconsistencies with the standard view props definition:
1. To check the type of each element in an array, the prop definition has to include an "element" entry. In the standard view props definition, we included an "elements" entry which will completely be ignored by the schema validator of owl in debug mode.
2. The "element" entry is only used when the `type` entry of the prop definition is `Array`. We will therefore simplify the property definition and remove the "element" entry for the props that are not arrays.
3. The `orderBy` definition of the standard view props mismatch with the `orderBy` definition of the `WithSearch` component and the search model.

This PR will fix that inconsistency for all those components and update the tests and the JSDoc accordingly. It will then be possible to set the `orderBy` value from the props of the `View` component without getting an error in debug mode.

task-3056268
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#105167

This commit fixes the appearance of the select element in dark mode. Since the background color is set with transparency, a white background was set on the options dropdown by desktop (Chromium/Firefox) browsers, which made the text difficult to read. By adding a color to the options, we can fix the appearance without the need to put a color without transparency on the select elements. task #3147138 The fix don't deteriorate the light mode, but allows the dark mode to have visible options

This commit fixes the appearance of the select element in dark mode. Since the background color is set with transparency, a white background was set on the options dropdown by desktop (Chromium/Firefox) browsers, which made the text difficult to read. By adding a color to the options, we can fix the appearance without the need to put a color without transparency on the select elements.

task #3147138

The fix don't deteriorate the light mode, but allows the dark mode to have visible options : 
<img width="215" alt="image" src="https://user-images.githubusercontent.com/35101914/217781775-13804b92-3247-4160-aa07-6fa312385da8.png">
<img width="272" alt="image" src="https://user-images.githubusercontent.com/35101914/217781859-cf76e0c7-66dc-46b2-9465-b1b5f80cedf8.png">

Forward-Port-Of: odoo/odoo#112274

The field email_from is a computed stored field. Let it compute for the email_from instead of taking the one from the orginal task This affects 14+ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113086 Forward-Port-Of: odoo/odoo#112603

The field email_from is a computed stored field. Let it compute for the email_from instead of taking the one from the orginal task

This affects 14+




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#113086
Forward-Port-Of: odoo/odoo#112603

The current connection works greedily regarding the number of connections opened. Once a new connection is needed, it is added to the pool and never closed unless the maximum number of connections is reached. We introduce 2 changes. First, we do not cycle on the available connections anymore. We take the first one available and let it at its position in the list. It opens the possibility to use `idle_session_timeout` introduced in PostgreSQL 14. Moreover, we introduce a garbage collection

The current connection works greedily regarding the number of connections opened. Once a new connection is needed, it is added to the pool and never closed unless the maximum number of connections is reached.

We introduce 2 changes. First, we do not cycle on the available connections anymore. We take the first one available and let it at its position in the list. It opens the possibility to use `idle_session_timeout` introduced in PostgreSQL 14.

Moreover, we introduce a garbage collection of the unused connections. If the connection has been unused for more than `MAX_IDLE_TIMEOUT` seconds, it is closed and removed from the pool.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#112859

The field is updated in SQL but not in cache. Also remove hacks in the business code to prevent potential issues from this behavior. Forward-Port-Of: odoo/odoo#113094

The field is updated in SQL but not in cache.  Also remove hacks in the business code to prevent potential issues from this behavior.

Forward-Port-Of: odoo/odoo#113094

This commit adapts the translation tests for non-English Numbering system to rely on the month's numbers instead of names, as the goal of those tests is to verify that the correct Numbering System has been applied instead of this specific datetime format. This is due to Chrome 110+ modifying/fixing month's name translation in the Intl API, and more specifically the bengalese's test breaking since this update. Note: Firefox and Webkit browsers applied similar fixes in their recent versions.

This commit adapts the translation tests for non-English Numbering system to rely on the month's numbers instead of names, as the goal of those tests is to verify that the correct Numbering System has been applied instead of this specific datetime format.

This is due to Chrome 110+ modifying/fixing month's name translation in the Intl API, and more specifically the bengalese's test breaking since this update.

Note: Firefox and Webkit browsers applied similar fixes in their recent versions.


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#113096

An IndexError `list index out of range` trace back that occurs in point_of_sale /RecieptScreen :async _sendReceiptToCustomer was caught by sentry. `order_server_id` is undefined because it is not properly sync with the server see : https://drive.google.com/file/d/1ahmRI99sIQrf99DIfowVexWWek7ML15G/view?usp=share_link `Step to reproduce:` 1. First of all start the session in point_of_sale to produce error we have to be in offline mode and generate product order. 2. Add customer

An IndexError `list index out of range`  trace back that occurs in point_of_sale
/RecieptScreen :async _sendReceiptToCustomer was caught by sentry.
 `order_server_id` is undefined because it is  not properly sync with the server

see : https://drive.google.com/file/d/1ahmRI99sIQrf99DIfowVexWWek7ML15G/view?usp=share_link

`Step to reproduce:`

1. First of all start the session in point_of_sale to produce error we have to 
   be in offline mode and generate product order.
2. Add customer, select a payment method and validate.
3. After validation send email to customer(failed to send mail.
    because we are in offline mode and `order_server_id` is undefined )
4. Now get back to online mode and again send mail to customer 
5. This time an IndexError 'list index out of range' is trace-backed.


So if order_server_id is null then we throw error to user.

sentry-3824163568

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#112973
Forward-Port-Of: odoo/odoo#112394

This PR fixes two issues related to the pager when the real count is unknown. **[FIX] web: pager: do not fetch count on page next** Since commit [1], we can have list or kanban view with same limit and count_limit (to save a costly search_count), i.e. have a pager like "1-80/80+". Before this commit, when reaching the count limit on page next, we performed the search_count. This was fine before as the count_limit was hardcoded to 10k, so you basically never did page next until the lim

This PR fixes two issues related to the pager when the real count is unknown.

**[FIX] web: pager: do not fetch count on page next**

Since commit [1], we can have list or kanban view with same limit
and count_limit (to save a costly search_count), i.e. have a pager
like "1-80/80+". Before this commit, when reaching the count limit
on page next, we performed the search_count. This was fine before
as the count_limit was hardcoded to 10k, so you basically never did
page next until the limit. However, it's a issue now that the
count_limit can be specified, as in the above example, we don't
want to slow down the loading of the second page records because of
the search_count.

With this commit, we slightly increase the count limit when we
reach it, so for instance doing next when the pager shows 1-80/80+
fetches the records with args offset=80, limit=80, count_limit=160
and the pager then shows 81-160/160+. If the total number of records
is reached, we know the count and display it, for instance, after
another pager next: 161-190/190.

The same logic applies when the pager is manually edited, e.g. when
you write 1-150 in a pager showing 1-80/80+, you'll get 1-150/150+
if there are more than 150 records.

[1] 699215ec9a71b8c9b6a53fe96e924a400d216729

3162026

**[FIX] web: pager: count_limit: fetch count on previous**

For performance reasons, we added a feature that allows to limit
the search_count done when fetching records in list and kanban
views, to display on the right side of the pager [1][2]. However,
the page previous case wasn't correctly handled when we had a
limited count. When doing page, we need to know the total number of
records to compute the offset. Before this commit, we went to the
last page, which wasn't really the last page (because we sent a
wrong offset), which can be misleading for users. With the commit,
we force a search_count when doing page previous on the first page.

[1] 6acfad26513298f57a2edcf40d0f7a2e38a97295
[2] 699215ec9a71b8c9b6a53fe96e924a400d216729

Task 3162026

Forward-Port-Of: odoo/odoo#111301

- prevent a click to open the link dialog - prevent link creation upon discard - make only on step when creating a link --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113056 Forward-Port-Of: odoo/odoo#110963

- prevent a click to open the link dialog
- prevent link creation upon discard
- make only on step when creating a link


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#113056
Forward-Port-Of: odoo/odoo#110963

Current behavior: When using a language with a comma as decimal separator, the cash in/out popup wouldn't allow you to enter a "," in the input field Steps to reproduce: -Install a language with a comma as decimal separator (e.g. French) -Open a POS session -Click on the cash in/out button -Input doesn't allow you to use comma. This is not linked to any ticket, I found it while testing the POS. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Current behavior:
When using a language with a comma as decimal separator, the cash in/out popup wouldn't allow you to enter a "," in the input field

Steps to reproduce:
-Install a language with a comma as decimal separator (e.g. French) -Open a POS session
-Click on the cash in/out button
-Input doesn't allow you to use comma.

This is not linked to any ticket, I found it while testing the POS.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#112997

[FIX] web_editor: button links should not use oe-link-color Commit[1] intended to change the color of links in the editor to make them more visible by making them a slightly lighter color. However, it did so in a way that also applied to button links, which already had different colors. In the case of primary buttons, it actually made the links less readable as a result. This commit excludes buttons from the original css rule so that they keep their special style while still maintaining

[FIX] web_editor: button links should not use oe-link-color
Commit[1] intended to change the color of links in the editor to make them more
visible by making them a slightly lighter color. However, it did so in a way
that also applied to button links, which already had different colors. In the
case of primary buttons, it actually made the links less readable as a result.

This commit excludes buttons from the original css rule so that they keep their
special style while still maintaining the intent of the original commit.

[1]: https://github.com/odoo/odoo/commit/47c73c7213c06a5bbb496031707e1ec20e060bf1

task-3131568

Forward-Port-Of: odoo/odoo#112893

The sample server did not create a __range value when grouping by 'date' This resulted in a traceback as it is expected to at least be false. This commit computes it properly. task - 3098681 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110051

The sample server did not create a __range value when grouping by 'date' This resulted in a traceback as it is expected to at least be false.

This commit computes it properly.

task - 3098681

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#110051

In the sample server, we generate random float values between 0 and 100. The faulty assertion expected the value to be strictly less than 100, however, it sometimes failed: when Math.random() generated a value >= 0.99995, it produced 100 as float value. Runbot error 15206 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

In the sample server, we generate random float values between 0 and 100. The faulty assertion expected the value to be strictly less than 100, however, it sometimes failed: when Math.random() generated a value >= 0.99995, it produced 100 as float value.

Runbot error 15206

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#113149

Since we create a google meet link when we create an event, we get an issue with the appoitments that generate their own videocall links. That lead to send a Odoo discuss link to the customer, and then set the google meet link in the sales person calendar. As the insert of google event is done post commit of the transaction, and there is no way to generate a google meet link before the creation of an event, there is no trivial fix to generate the google mette link at the right moment. We just

Since we create a google meet link when we create an event, we get an issue with the appoitments that generate their own videocall links. That lead to send a Odoo discuss link to the customer, and then set the google meet link in the sales person calendar.

As the insert of google event is done post commit of the transaction, and there is no way to generate a google meet link before the creation of an event, there is no trivial fix to generate the google mette link at the right moment. We just don't generate the google link when a Odoo discuss link is already there.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#113173

This draft change updates the French reports module to reproduce a suspected issue in a balance sheet formula. It appears intended to help validate and fix reporting accuracy for French accounting statements before a final correction is made.

## Issue There is a difference between the `allocated_hours` and their contribution to the "total" of the day in the planning demo data. ## Steps to reproduce: - Install Planning, Sale, Timesheet (with demo data) - Go to Planning, filter for "Abigail Peterson" as resource - Notice that for the planning, the allocated hours are 4h@100%, but the contribution for the "total" is 3h. ## Reason for the problem: Since version 16.0, `allocated_hours` are taking into consideration the working

## Issue
There is a difference between the `allocated_hours` and their contribution to the "total" of the day in the planning demo data.

## Steps to reproduce:
- Install Planning, Sale, Timesheet (with demo data)
- Go to Planning, filter for "Abigail Peterson" as resource
- Notice that for the planning, the allocated hours are 4h@100%, but the contribution for the "total" is 3h.

## Reason for the problem:
Since version 16.0, `allocated_hours` are taking into consideration the working calendar of the resource on the planning slot. The `allocated_hours` and the `allocated_percentage` are co-dependant computed fields, so when we set the `allocated_hours` we don't modify the `allocated_percentage` (this is wanted behaviour). The problem arises in the demo data where we set the `allocated_hours` by hand, but the `allocated_percentage` should have been adjusted to the correct %, taking into consideration the working calendar. For example in some slots, we have for a shift of 7AM -> 11AM a manual allocation of 4h, but the `allocated_percentage` is set to 100%, instead of 133.33% it should've been.

## Fix
Remove the manual set of the `allocated_hours` in the demo data, so it can be recomputed correctly, taking into account a default 100% `allocated_percentage`. This way there shouldn't be any difference between the `allocated_hours` on the slot and the contribution to the "total".

## Affected versions
- 16.0
- saas-16.1
- master
---
opw-3184923

Forward-Port-Of: odoo/enterprise#37276

This commit changes the wording for all the actions linked to the trash as the old one was confusing for users. We reworded "Remove from trash" to "Restore from Trash" in the burger menu and "Remove from Trash" to "Restore" in the banner. We also changed the pot file to include the translations of the reworded sentences. task-3180742 Forward-Port-Of: odoo/enterprise#36948

This commit changes the wording for all the actions linked to the trash as the old one was confusing for users.

We reworded "Remove from trash" to "Restore from Trash" in the burger menu and "Remove from Trash" to "Restore" in the banner.

We also changed the pot file to include the translations of the reworded sentences.

task-3180742

Forward-Port-Of: odoo/enterprise#36948

Steps to reproduce ================== - Go to contacts - Click on a record to go to the form view - Enter studio - Add a new "Lines" fields (one2many) - Rename the fields The one2many field and the related fields are recreated again You can check this by going into debug mode then go to Settings / Technical / Database Structure / Fields and apply the custom filter opw-3055817 Forward-Port-Of: odoo/enterprise#37248 Forward-Port-Of: odoo/enterprise#36963

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

- Go to contacts
- Click on a record to go to the form view
- Enter studio
- Add a new "Lines" fields (one2many)
- Rename the fields

The one2many field and the related fields are recreated again You can check this by going into debug mode then go to Settings / Technical / Database Structure / Fields and apply the custom filter

opw-3055817

Forward-Port-Of: odoo/enterprise#37248
Forward-Port-Of: odoo/enterprise#36963

Before this commit, we could: - Create an asset - Compute the depreciation board - Modify some values like the original value, or the accounts, ... - Confirm the asset => the depreciation board is not recomputed, so the values are inconsistent We will now change the values of the accounts and journal of the entries when changed on the asset. The reason being that when the user wants to see the values of the entries, we write on the asset, so he will see the right values. For other

Before this commit, we could:
- Create an asset
- Compute the depreciation board
- Modify some values like the original value, or the accounts, ...
- Confirm the asset
=> the depreciation board is not recomputed, so the values are inconsistent

We will now change the values of the accounts and journal of
the entries when changed on the asset.
The reason being that when the user wants to see the values of the entries,
we write on the asset, so he will see the right values.

For other fields (the values, dates or type of computation),
we will unlink the depreciation board.
When modifying this field, the user will see that his
depreciation board has disappeared, and won't be surprised.
They can still undo their changes, to have their old depreciation board.

task-2937679

Forward-Port-Of: odoo/enterprise#35211

This pull request was closed because the related issue has already been resolved elsewhere. No additional business-facing change is introduced here, so there is no expected impact for users.

The problem has been solved by odoo/odoo#112095 so this PR is not needed anymore.

Task-2674649

[FIX] knowledge: memorise graph type of embedded view When the users opens a graph view, changes the type of the graph and inserts the graph in an article of Knowledge, the embedded view will always load the first available graph (i.e: the "bar chart"). With this commit, the embedded views will now load by default the graph that was active when inserting the view. This new behavior will allow the user to insert the graph they want. [FIX] knowledge: memorise sorting order of embedded view

[FIX] knowledge: memorise graph type of embedded view

When the users opens a graph view, changes the type of the graph and inserts the graph in an article of Knowledge, the embedded view will always load the first available graph (i.e: the "bar chart"). With this commit, the embedded views will now load by default the graph that was active when inserting the view. This new behavior will allow the user to insert the graph they want.

[FIX] knowledge: memorise sorting order of embedded view

When the users opens a list view, orders the records by clicking on a column and inserts the list view in an article of Knowledge, the embedded view will omit the sorting order set by the user. With this commit, the embedded views will now keep the sorting order set when inserting the view. This new behavior will allow the user to customize the embedded view even more.

task-3056268

Forward-Port-Of: odoo/enterprise#33707

__Current behavior before PR:__ While exporting a XAF report, an error is raised if the report contains partners that are located in countries that are not part of ISO-3166 (like Kosovo). This happens because the report is validated using "data/xml_audit_file_3_2.xsd" which does not contains the country code of Kosovo (XK). __Desired behavior after PR is merged:__ When exporting a XAF report, the valid country codes are parsed from he ".xsd" file mentionned above using lxml. If some

__Current behavior before PR:__
While exporting a XAF report, an error is raised if the report contains partners that are located in 
countries that are not part of ISO-3166 (like Kosovo).
This happens because the report is validated using "data/xml_audit_file_3_2.xsd" which does not 
contains the country code of Kosovo (XK).

__Desired behavior after PR is merged:__
When exporting a XAF report, the valid country codes are parsed from he ".xsd" file mentionned above  using lxml.
If some partners are located in countries forbidden by the dutch tax authorities,
the user is prompted (via a `RedirectWarning`) to change the address of the concerned partners.
The user can also choose to continue and skip the fields `<country>` and `<taxRegistrationCountry>` in the report.

__To test the feature:__
⚠️ This PR https://github.com/odoo/enterprise/pull/36523 must be merged in order for this one to properly work. Indeed there is a bug *when you request __a file__*; if an error/warning is raised, an empty message is shown to the user. (And this code is based on a `RedirectWarning`)

- Intall `l10n_nl_reports`
- Create a partner with Kosovo as country in the address
- Register the payement of an invoice for this partner
- Go to Accounting > Reporting > General Ledger > EXPORT (XAF)

OPW-3085277

Forward-Port-Of: odoo/enterprise#36717
Forward-Port-Of: odoo/enterprise#35308

For usability. Creating a horizontal group without editing it made no sense. Forward-Port-Of: odoo/enterprise#37239

For usability. Creating a horizontal group without editing it made no sense.

Forward-Port-Of: odoo/enterprise#37239

Steps to reproduce: - Create a french partner with a VAT number. - Create and post an invoice with an "EU" tax. - Create and post a credit note to cancel the invoice. - Remove the VAT number from the partner. - Open the EC sales list report. - Export the XML. Current behavior: A UserError is raised because no VAT number is specified. Desired behavior: The export is not blocked, and the partner is skipped. No task/ticket. Internal bug report. Forward-Port-Of: odoo/enterprise#37

Steps to reproduce:
- Create a french partner with a VAT number.
- Create and post an invoice with an "EU" tax.
- Create and post a credit note to cancel the invoice.
- Remove the VAT number from the partner.
- Open the EC sales list report.
- Export the XML.

Current behavior:
A UserError is raised because no VAT number is specified.

Desired behavior:
The export is not blocked, and the partner is skipped.

No task/ticket.
Internal bug report.

Forward-Port-Of: odoo/enterprise#37237

…link The `fields` args was shadowing the fields imported, thus it was crashing. Forward-Port-Of: odoo/enterprise#37241

…link

The `fields` args was shadowing the fields imported, thus it was crashing.

Forward-Port-Of: odoo/enterprise#37241

Balance = debit - credit, not the opposite. In addition, the `amount_residual_currency` should be computed at reconciliation, and not set at import. opw-3166143 Forward-Port-Of: odoo/enterprise#37067

Balance = debit - credit, not the opposite. In addition, the `amount_residual_currency` should be computed at reconciliation, and not set at import.

opw-3166143

Forward-Port-Of: odoo/enterprise#37067

Problem 1: Subscription are not closed if the user never paid the invoice. Problem 2: Nothing prevent a renewal to be confirmed with a start_date before the next_invoice_date of the parent. It leads to concurrent subscriptions... (User portal & backend) # SPECIFICATIONS Prevent renewal to be confirmed if parent next invoice date > renewal start date. cron_subscription_expiration should close contract when the invoice is not paid after (due date + auto close limit) The

Problem 1: Subscription are not closed if the user never paid the invoice.
Problem 2: Nothing prevent a renewal to be confirmed with a start_date before the next_invoice_date of the parent. It leads to concurrent subscriptions... (User portal & backend)


# SPECIFICATIONS

    Prevent renewal to be confirmed if parent next invoice date > renewal start date.
    cron_subscription_expiration should close contract when the invoice is not paid after (due date + auto close limit)
        The tooltip of auto-closing should be adapted to inform about this new feature.
    subscriptions should be closed when the next invoice date is passed for X days where x is the auto_close_limit defined on the quotation template or 15 days.

taskid: 3054994

Forward-Port-Of: odoo/enterprise#36758
Forward-Port-Of: odoo/enterprise#35710