This fix ensures that new payments created through online account synchronization use the correct company together with the selected journal. It prevents payment records from being created with missing or mismatched company information, reducing accounting inconsistencies.

When creating a new payment, we need to specify the company along with the journal.
Even if the company is normally computed, it isn't the case here because of protection of fields with the `_inherits` feature, along with a de-normalized field.

This update cleans up how several business areas retrieve grouped data, without changing the visible features users rely on. It helps keep payroll, subscriptions, accounting settings, and localization processes easier to maintain and aligned with the main Odoo platform changes.

https://github.com/odoo/odoo/pull/163317

This update simplifies how embedded views are configured in Knowledge, making the underlying code easier to maintain and extend. There is no expected change for end users, but it reduces future development friction and avoids duplicated configuration data.

The function `_insertEmbeddedView` accepts 7 parameters to set up an embedded view. Some of these parameters are optional or incompatible with each other. For example: it makes no sense to pass the xml id of an action and an actual action object. To insert an embedded view, the developer has to pass many null, undefined or falsy values to the function, making the code difficult to read and maintain.

To improve this, the function will accepts a single object containing all the props of the embedded views. This object will directly be encoded in the blueprint of the behavior. The caller will now be responsible for providing a valid configuration with the required values.

The advantage of directly passing the props of the embedded view to the `_insertEmbeddedView` function is that we will not have to update the API of the function in the future whenever we define a new prop to the embedded view behavior.

The `_insertEmbeddedView` function will also no longer copy the action helper of the action to the behavior props of the embedded view. Doing the copy was duplicating data and was not necessary as the action helper is, by default, loaded from the loaded action unless a custom one is defined in the behavior props.

task-3847699

That field is not required, so it is possible to make it empty. The behavior should then be equivalent to the 'disabled' option. Before this fix, it wasn't, and instead restrained the considered accounts to payable and receivable accounts. We'll make it required in master. Forward-Port-Of: odoo/enterprise#60847

That field is not required, so it is possible to make it empty. The behavior should then be equivalent to the 'disabled' option. Before this fix, it wasn't, and instead restrained the considered accounts to payable and receivable accounts.

We'll make it required in master.

Forward-Port-Of: odoo/enterprise#60847

Currently, when creating a task from the calendar view in the field service app, the start date that was set by the user is not registered. Steps to reproduce: ------------------- * Go to the **Field Service** App * Switch to the calendar view * Select "Tomorrow" (x+1) * For the new task, set the `Planned Date` as follows: * Start date : The day after tomorrow at 3PM (x+2 3PM) * End date: Three days after the start at 4PM (x+5 4PM) * Fill anything for the other required fields > *

Currently, when creating a task from the calendar view in the field service app, the start date that was set by the user is not registered.

Steps to reproduce:
-------------------
* Go to the **Field Service** App
* Switch to the calendar view
* Select "Tomorrow" (x+1)
* For the new task, set the `Planned Date` as follows:
  * Start date : The day after tomorrow at 3PM (x+2 3PM)
  * End date: Three days after the start at 4PM (x+5 4PM)
* Fill anything for the other required fields > **Save & Close**
* Switch to the kanban view and select the task created
> Observation: the start date of `Planned Date` is set at Tomorrow 7AM instead of the day after at 3PM

Why the fix:
------------
This behavior was introduced after this commit: https://github.com/odoo/enterprise/commit/39b9362d0469d71b59d47e9d66d5e73b9a46520b.

This commit added an inverse method to the field `planned_date_start` to enable drag and droping tasks in the calendar view. And `planned_date_start` is a field that exists purely for calendar displaying of tasks.

https://github.com/odoo/enterprise/blob/c8c4a52b508621b45239332273832de26a085931/project_enterprise/models/project_task.py#L299-L305

When creating a task in the calendar view, the context contains `default_planned_date_start` and its value depends on the first day you selected in the calendar. At task creation, `default_planned_date_start` triggers a write in `planned_date_start` which triggers its inverse method.

This removes the `default_planned_date_start` from the context which won't trigger the inverse method. We don't have to worry about the line `default_planned_date_begin: default_planned_date_start,` as if we have selected a start date in the form, it will be present inside `vals_list` in the create function and will use that value instead of the one in the context.

opw-3850455

Forward-Port-Of: odoo/enterprise#62232
Forward-Port-Of: odoo/enterprise#61351

We should not rely on the `type_name` field (which is a translated) to determine if an order is a confirmed subscription. To reproduce: - Active a second language (for. ex French) and enable it as well for the current website - Create a subscription, set a customer reference to 'CUST-REF' then confirm it - Click on "Preview" => In English, the 'CUST-REF' is visible in the subscription header, in other languages it was not visible. Forward-Port-Of: odoo/enterprise#62093

We should not rely on the `type_name` field (which is a translated) to determine if an order is a confirmed subscription.

To reproduce:
- Active a second language (for. ex French) and enable it as well for the current website
- Create a subscription, set a customer reference to 'CUST-REF' then confirm it
- Click on "Preview"

=> In English, the 'CUST-REF' is visible in the subscription header, in
  other languages it was not visible.

Forward-Port-Of: odoo/enterprise#62093

This commit converts all the tests that rely on mail test utils and helpers into hoot. **part of task**-[3818666](https://www.odoo.com/web#id=3818666&cids=2&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#61927

This commit converts all the tests that rely on mail test utils and helpers into hoot.

**part of task**-[3818666](https://www.odoo.com/web#id=3818666&cids=2&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#61927

When receiving emails, the attachments of the email may be made directly into a document. This will not make a copy, meaning restrictions on message attachments apply on these attachments. By extension this means the related fields on documents cannot be used properly. We now do a second check, filtering documents, if the access rights check fails because of message attachment restrictions. The reason to do two checks is that we do not want to add querries in the most common cases where th

When receiving emails, the attachments of the email may be made directly into a document. This will not make a copy, meaning restrictions on message attachments apply on these attachments. By extension this means the related fields on documents cannot be used properly.

We now do a second check, filtering documents, if the access rights check fails because of message attachment restrictions.

The reason to do two checks is that we do not want to add querries in the most common cases where the check will succeed regardless of filtering.

issue introduced in odoo/odoo@4c4e63f01aefa01c2377f15f2020485cb0f7e4da

task-3519815

Forward-Port-Of: odoo/enterprise#62338
Forward-Port-Of: odoo/enterprise#62174

The SUN number is normally mandatory to generate such a file, and is repeated at multiple places within it. However, HSBC bank diverges from the others, and allows putting 'HSBC' at a normally unused position of the file; in such case, all the fields supposed to contain the SUN can be left blank. UHL1 records of the file also use the SUN to build an identifier. HSBC's doc is unclear about what should go there, but ING says here https://www.ingwb.com/binaries/content/assets/support-content/pay

The SUN number is normally mandatory to generate such a file, and is repeated at multiple places within it. However, HSBC bank diverges from the others, and allows putting 'HSBC' at a normally unused position of the file; in such case, all the fields supposed to contain the SUN can be left blank.

UHL1 records of the file also use the SUN to build an identifier. HSBC's doc is unclear about what should go there, but ING says here https://www.ingwb.com/binaries/content/assets/support-content/payments-and-reporting/insidebusiness-payments/domestic-uk-file-format-description-february-2024.pdf that this identifier should be 999999 + 4 blanks or SUN + 4 blanks, so we make the choice to use 999999 if we have no SUN, for HSBC.

We don't want to make the SUN field optional for everyone just because of that one use case. Instead, we ask people to write 'HSBC' as their SUN number in the settings if they don't have any, and this considers the field as blank for the file generation.

(HSBC's doc can be found on the related ticket)
opw-3863262

Forward-Port-Of: odoo/enterprise#62323
Forward-Port-Of: odoo/enterprise#62111

When sending a negative amount of stock, Amazon can't process the inventory update availibility feed. opw-3905455 Forward-Port-Of: odoo/enterprise#62185

When sending a negative amount of stock, Amazon can't process the inventory update availibility feed.

opw-3905455

Forward-Port-Of: odoo/enterprise#62185

…atable Those fields are just counting stuff, and their labels are never displayed. So it's useless having them in the .pot file Forward-Port-Of: odoo/enterprise#61019

…atable

Those fields are just counting stuff, and their labels are never displayed. So it's useless having them in the .pot file

Forward-Port-Of: odoo/enterprise#61019

Before this PR, the sign_request record was browsed but we did not checked if the record was correct. Before this PR, when the sign_document_from_mail controller was called without timestamp parameter, it would redirect to the sign.sign_request_expired template because current_request_item._validate_expiry(post.get('timestamp'), post.get('exp')) would return False. For human triggered interaction, it is not an issue. Some customer complained of massive email sent. One of the signer

Before this PR, the sign_request record was browsed but we did not checked if the record was correct.

Before this PR, when the sign_document_from_mail controller was
called without timestamp parameter, it would redirect to the
sign.sign_request_expired template because
current_request_item._validate_expiry(post.get('timestamp'),
post.get('exp')) would return False.

For human triggered interaction, it is not an issue.

Some customer complained of massive email sent. One of the signer is
probably relying on MS Defender. This is system is known to click on
links in email and cleaning the GET parameters of the URL.

In that case, the bot will get the sign.sign_request_expired which has a
button that allows to resend the sign request. If the bot click on that
button, it will send an email, that will be analyzed by the bot. it will
clean the parameters, get the sign.sign_request_expired template etc
etc.

Forward-Port-Of: odoo/enterprise#61853

This commit extends tax reports added in l10n_ng to show warnings and hide the Closing Entry button on Withholding tax report. Also adds tax report tests. Odoo PR: https://github.com/odoo/odoo/pull/148370 Task [link](https://www.odoo.com/web#model=project.task&id=3607459) task-3607459 Forward-Port-Of: odoo/enterprise#62147 Forward-Port-Of: odoo/enterprise#58603

This commit extends tax reports added in l10n_ng to show warnings and hide the Closing Entry button on Withholding tax report. Also adds tax report tests.

Odoo PR: https://github.com/odoo/odoo/pull/148370
Task [link](https://www.odoo.com/web#model=project.task&id=3607459)
task-3607459

Forward-Port-Of: odoo/enterprise#62147
Forward-Port-Of: odoo/enterprise#58603

Previous to this commit, in demo, when installing CodaBox, if a Belgian company already had an accounting firm set, it was overriden by a new one. This commit fixes this by checking if the Belgian company already has an accounting firm set. If so, we do not modify it. task-id: none Forward-Port-Of: odoo/enterprise#62227 Forward-Port-Of: odoo/enterprise#60822

Previous to this commit, in demo, when installing CodaBox, if a Belgian company already had an accounting firm set, it was overriden by a new one.

This commit fixes this by checking if the Belgian company already has an accounting firm set. If so, we do not modify it.

task-id: none

Forward-Port-Of: odoo/enterprise#62227
Forward-Port-Of: odoo/enterprise#60822

Reproducing: 1. Use a folder with one `binary` and one `url`-type documents. 2. Add a tag on the `binary` one. 3. Check the tag in the search panel 4. Share the folder Problem: You are warned about having included a link in the share, but you had not. Note that this domain is not the one used to identify the records that will be included in the share (stored in `domain`). Task-3806121 Forward-Port-Of: odoo/enterprise#58650

Reproducing:
1. Use a folder with one `binary` and one `url`-type documents.
2. Add a tag on the `binary` one.
3. Check the tag in the search panel
4. Share the folder

Problem:
You are warned about having included a link in the share, but you had not.

Note that this domain is not the one used to identify the records that will be included in the share (stored in `domain`).

Task-3806121

Forward-Port-Of: odoo/enterprise#58650

Before this commit, the open shifts without any SOL set are not fetched during the auto plan process because the following condition is falsy for them inside the domain used: `('sale_line_id.state', '!=', False)`. This commit changes the domain to check if the SOL is false or if the state of the SOL set is different than 'cancel'. runbot-61465 Forward-Port-Of: odoo/enterprise#62026

Before this commit, the open shifts without any SOL set are not fetched during the auto plan process because the following condition is falsy for them inside the domain used: `('sale_line_id.state', '!=', False)`.

This commit changes the domain to check if the SOL is false or if the state of the SOL set is different than 'cancel'.

runbot-61465

Forward-Port-Of: odoo/enterprise#62026