Issue ---- Demo data company data contains a phone number of a real person, who receives phone calls from people asking to buy stuff :) note: extension of 05f344b6a0b4cd71b4d0f0abcb4825856fdf4edc after finding the number is in other views as well. Steps ---- Number is available on website footer. Cause ---- A real number is used in demo data. opw-3853066 Forward-Port-Of: odoo/odoo#172942 Forward-Port-Of: odoo/odoo#171192

Issue
----

Demo data company data contains a phone number of a real person, who receives phone calls from people asking to buy stuff :)
note: extension of 05f344b6a0b4cd71b4d0f0abcb4825856fdf4edc after finding the number is in other views as well.

Steps
----

Number is available on website footer.

Cause
----

A real number is used in demo data.

opw-3853066

Forward-Port-Of: odoo/odoo#172942
Forward-Port-Of: odoo/odoo#171192

To reproduce the bug: 1. On Runbot, set the decimal accuracy of "Product Unit of Measure" to 5. 2. Go to the website and add a product to the cart. 3. Go to the cart and click on the "+" button. Some decimals may appear due to issues related to floating-point numbers. This issue is being addressed and will be fixed in the future (see: https://github.com/odoo/odoo/pull/152709). In the meantime, we can apply a fix on the frontend. opw-3990565 Forward-Port-Of: odoo/odoo#171104

To reproduce the bug:
1. On Runbot, set the decimal accuracy of "Product Unit of Measure" to 5.
2. Go to the website and add a product to the cart.
3. Go to the cart and click on the "+" button.

Some decimals may appear due to issues related to floating-point numbers. This issue is being addressed and will be fixed in the future (see: https://github.com/odoo/odoo/pull/152709). In the meantime, we can apply a fix on the frontend.

opw-3990565

Forward-Port-Of: odoo/odoo#171104

Specification: The automation name and ID are not visible. Additionally, the 'Disable Automation Rule' and 'Edit Automation Rule' buttons are not working in the error dialog. Expected behavior: The automation rule ID and name are visible, and both buttons work as expected. Task-3959044 Forward-Port-Of: odoo/odoo#171486

Specification:
The automation name and ID are not visible. Additionally, the 'Disable Automation Rule' and 'Edit Automation Rule' buttons are not working in the error dialog.

Expected behavior:
The automation rule ID and name are visible, and both buttons work as expected.

Task-3959044

Forward-Port-Of: odoo/odoo#171486

You can't run the `populate` odoo-bin command more than once if `product.product` is part of the models to be populated. This is because it will always generate a kind of fixed barcode pattern in the form of `BARCODE-PP-{counter}`. This commit simply performs a quick raw SQL check to ensure no previous populate run was done, and if it was it simply retrieves the barcode of the last product created through a previous populate command. If that barcode exists, is then used as prefix itself.

You can't run the `populate` odoo-bin command more than once if `product.product` is part of the models to be populated. This is because it will always generate a kind of fixed barcode pattern in the form of `BARCODE-PP-{counter}`.

This commit simply performs a quick raw SQL check to ensure  no previous populate run was done, and if it was it simply retrieves the barcode of the last product created through a previous populate command. If that barcode exists, is then used as prefix itself.

Running the populate command 4 times in a row will produce the following results:
```
select id,default_code, barcode from product_product order by id desc;

 id  | default_code |          barcode
-----+--------------+----------------------------
 639 | PP-150       | BARCODE-PP-150-150-150-150
 638 | PP-149       | BARCODE-PP-150-150-150-149
              ...
```

Another option would have been to use a fully randomized string, but avoiding randomness is preferable, especially when considering the case of running the populate command only once.

Note that the `product.product` model is the only problematic one when
running back to back `populate` on all models used by accounting:
- account.move
- account.journal
- account.bank.statement
- account.bank.statement.line
- account.payment
- account.reconcile.model
- account.reconcile.model.line
- res.company
- res.partner
- res.partner.industry
- product.product
- product.category
- ...probably more through `_populate_dependencies`...

task-3821088

Forward-Port-Of: odoo/odoo#166365

This commit normalize the breakpoint used to set the justification of the dialog footer's buttons. The issue is that the breakpoint used in the utility classes didn't match the css used for nested footer's children, resulting into discrepancy in in-between viewport sizes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173112 Forward-Port-Of: odoo/odoo#172413

This commit normalize the breakpoint used to set the justification of the dialog footer's buttons. The issue is that the breakpoint used in the utility classes didn't match the css used for nested footer's children, resulting into discrepancy in in-between viewport sizes.


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

Forward-Port-Of: odoo/odoo#173112
Forward-Port-Of: odoo/odoo#172413

Description of the issue/feature this PR addresses: This commit introduces system parameter to skip the creation of bank account in the reconciliation of bank statements. The issue it can solve happens when 2 different commercial entities use the same paying partner (ie a partner that is not a subcontact) to pay their invoices. When an invoice is paid by the paying partner, Odoo will store the account number that was used for the transfer on account.bank.statement.line. When this statem

Description of the issue/feature this PR addresses:

This commit introduces system parameter to skip the creation of bank account in the reconciliation of bank statements.

The issue it can solve happens when 2 different commercial entities use the same paying partner (ie a partner that is not a subcontact) to pay their invoices.

When an invoice is paid by the paying partner, Odoo will store the account number that was used for the transfer on account.bank.statement.line. When this statement line is reconciled with an invoice, if the bank account was not stored on the partner previously, a res.partner.bank will be created automatically.
When another payment is coming from the same bank account, Odoo will then select the partner linked to the bank account that it did store previously, even if the payment was for an invoice linked to another partner, and it will not propose the proper invoice in the reconciliation widget, even if it uses an exact match on the payment reference number.

Having a parameter allowing to skip creation of the bank account in Odoo will allow the reconciliation to be based striclty on the reference number.

Current behavior before PR:

Bank account is stored and wrong invoices are proposed by the reconciliation widget

Desired behavior after PR is merged:

Allow to avoid storing bank account and having wrong invoices are proposed by the reconciliation widget


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

Forward-Port-Of: odoo/odoo#172605
Forward-Port-Of: odoo/odoo#168029

Description of the issue/feature this PR addresses: Translations added with https://github.com/odoo/odoo/commit/e76453bf869f0a5bc2edfe861d3628b6695a205b contains unicode \u00a0 which are rendered as \u00a0 on PDF Current behavior before PR: PDF show the unicode characters  Desired behavior after PR is merged: no more unicode characters --- I confirm I have signed the CLA and read the PR

Description of the issue/feature this PR addresses: Translations added with https://github.com/odoo/odoo/commit/e76453bf869f0a5bc2edfe861d3628b6695a205b contains unicode \u00a0 which are rendered as \u00a0 on PDF

Current behavior before PR: PDF show the unicode characters
![image](https://github.com/odoo/odoo/assets/30716308/73f3b03a-0ccc-4ca4-bc51-dab7c9f557b6)


Desired behavior after PR is merged: no more unicode characters




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

Forward-Port-Of: odoo/odoo#172490

### Steps to reproduce #### Use case 1: 1. Create a PO with 2 lines having different "expected arrival". 2. Change the "expected arrival" of one of the lines so that the earliest date of all the lines is modified. 3. This will change the "expected arrival" of the PO (intended) but also the "expected arrival" of all PO lines. #### > the date is changed on all the lines #### Use case 2: 1. Create a PO with 1 line and change its date planned to tomorrow 2. Save the PO 3. Add a new li

### Steps to reproduce

#### Use case 1:

1. Create a PO with 2 lines having different "expected arrival".
2. Change the "expected arrival" of one of the lines so that the earliest date of all the lines is modified.
3. This will change the "expected arrival" of the PO (intended) but also the "expected arrival" of all PO lines.
#### > the date is changed on all the lines

#### Use case 2:
1. Create a PO with 1 line and change its date planned to tomorrow
2. Save the PO
3. Add a new line on the SO and set a product
#### > the date is changed on all the lines

#### Use case 3:
1. Create a PO with 1 line and change its date planned to tomorrow
2. Save the PO
3. Add a new line for a product with at least 2 product variant and complete his grid for quantities
#### > the date is changed on all the lines

### Cause of the issue:

The `date_planned` fields of the `purchase.order` and `purchase.order.line` are both computed and stored.  When the `date_planned` of a line (new or already existing) is changed, it triggers the compute method of the `date_planned` of the purchase order and changes it: https://github.com/odoo/odoo/blob/5d8c8f3d01c3c633bcacbdb9e42419e11eb802d9/addons/purchase/models/purchase_order.py#L184-L190 
This will in turn trigger the `onchange_date_planned` of the purchase order since we are in the Form view of that model and will update the "planned_date" of every other existing line accordingly:
https://github.com/odoo/odoo/blob/5d8c8f3d01c3c633bcacbdb9e42419e11eb802d9/addons/purchase/models/purchase_order.py#L229-L232

### Fix

We add back the override of the onchange that was present in previous versions and removed in the onchange refactoring made in commit https://github.com/odoo/odoo/commit/109935dbc10256bebb1f5ee0d76a23df7ea91e9f. The purpose of this override being to remove any update of the 'date_planned' of the POL's from the onchange call if this one was triggered by a change of an POL.

#### Note: 
The third use case was fixed by commit 387e9a4 by adding the `_must_delete_date_planned` method but this fix becomes ineffective without the onchange override.

opw-4000019
opw-4012390
opw-4028100
---

Forward-Port-Of: odoo/odoo#171769

The index definition that supports the implementation of `_search_phone_mobile_search` defined in the `PhoneMixin` is created in an `_auto_init` in `crm_lead` of the `crm` module. This means that other models that use the mixin (for ex: `res_partner`) will not get the indexes for it's table, leading to Seq.Scans when searching for a phone number on those models. By hoisting the index definition to an `init` in the mixin, all models that inherit from the mixin will have the supporting index.

The index definition that supports the implementation of `_search_phone_mobile_search` defined in the `PhoneMixin` is created in an `_auto_init` in `crm_lead` of the `crm` module. This means that other models that use the mixin (for ex: `res_partner`) will not get the indexes for it's table, leading to Seq.Scans when searching for a phone number on those models.

By hoisting the index definition to an `init` in the mixin, all models that inherit from the mixin will have the supporting index.

Also add the same custom `trigram` index to support `like/ilike` operators in domains.

task-3942852

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

Forward-Port-Of: odoo/odoo#166698

…ecordset Steps to reproduce: install hr_expense with demo data try to make a jsonrpc or any search on product.product with no domain ->key error Before PR: When the compute for standard_price_update_warning is triggered, if the recordset contains products that have unpaid expenses and some that do not have any unpaid expense, you get a traceback because some product keys are not in the mapp keys opw-3741337 Forward-Port-Of: odoo/odoo#170300 Forward-Port-Of: odoo/odoo#154760

…ecordset

Steps to reproduce:
install hr_expense with demo data
try to make a jsonrpc or any search on product.product with no domain ->key error

Before PR:
When the compute for standard_price_update_warning is triggered, if the recordset contains products that have unpaid expenses and some that do not have any unpaid expense, you get a traceback because some product keys are not in the mapp keys

opw-3741337

Forward-Port-Of: odoo/odoo#170300
Forward-Port-Of: odoo/odoo#154760

Fix of the COA: There was a bad assignation in the account rate difference profit/loss. As these are minor changes, we make this together with changes in the F29 report VAT base https://github.com/odoo/enterprise/pull/55365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170301 Forward-Port-Of: odoo/odoo#151611

Fix of the COA:
There was a bad assignation in the account rate difference profit/loss.

As these are minor changes, we make this together with changes in the F29 report VAT base

https://github.com/odoo/enterprise/pull/55365





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

Forward-Port-Of: odoo/odoo#170301
Forward-Port-Of: odoo/odoo#151611

### Steps to reproduce: - Install Calendar module - Create a new event - Change the organzier to Marc Demo and then add him as attendee - Save the event ### Current behavior before PR: When changing the organizer of an event that you are creating and then add a new attendee and save the event the organizer will not be saved and will be back to the default user. This is happening because when getting the changed values to use it in the create operation it will check if the organizer

### Steps to reproduce:
	- Install Calendar module
	- Create a new event
	- Change the organzier to Marc Demo and then add him as attendee
	- Save the event

### Current behavior before PR:
When changing the organizer of an event that you are creating and then add a new attendee and save the event the organizer will not be saved and will be back to the default user.
This is happening because when getting the changed values to use it in the create operation it will check if the organizer field is readonly https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/model/relational_model/record.js#L592:L597 It will be true and it is readonly because of the computed field in the calendar.event 'user_can_edit' where when it checks who can edit the event before creating it the 'partner_ids' will be found as 'NewId' not yet 'res.partner'
https://github.com/odoo/odoo/blob/17.0/addons/calendar/models/calendar_event.py#L296

### Desired behavior after PR is merged:
We can change the organizer of the event before assign the attendees or creating the event. As we are now checking the ids itself not the whole object of the partner_ids

opw-3908333

Forward-Port-Of: odoo/odoo#172680

Accounts 471000 to 475000 can be used as suspense accounts. 471000, 472000 & 473000 have been chosen since they're the 1st ones Expected deferred accounts: - Expense: 486000 - Revenue: 487000 task-383985 Forward-Port-Of: odoo/odoo#171416

Accounts 471000 to 475000 can be used as suspense accounts. 471000, 472000 & 473000 have been chosen since they're the 1st ones

Expected deferred accounts:
- Expense: 486000
- Revenue: 487000

task-383985

Forward-Port-Of: odoo/odoo#171416

Before this commit, the self order was created with the user of the current session. This is not the expected behavior, as the self order is always accessed by a public user. This commit fixes this by always using the self user for the self order. Forward-Port-Of: odoo/odoo#173292

Before this commit, the self order was created with the user of the
current session. This is not the expected behavior, as the self order
is always accessed by a public user.

This commit fixes this by always using the self user for the self order.

Forward-Port-Of: odoo/odoo#173292

We get a singleton error in multicompany setup when opening the accounting dashboard Steps: - Have at least two companies, one with l10n_fr_reports installed - Select the two companies in the caompany selector - Go to accounting dashboard -> singleton error opw-4053554 Forward-Port-Of: odoo/enterprise#66757

We get a singleton error in multicompany setup when opening the
accounting dashboard

Steps:

- Have at least two companies, one with l10n_fr_reports installed
- Select the two companies in the caompany selector
- Go to accounting dashboard
-> singleton error

opw-4053554

Forward-Port-Of: odoo/enterprise#66757

[IMP] account_online_synchronization: disable auto sync on interactive connection 1- Some providers have bank institutions that are "interactive". In a general way, interactive institution means that users have to refresh their connection with the provider to ensure that they can still have an access to the bank. 2- It's a nightmare for users and for support as the connections keep failing in error. - Disable the automatic synchronization flow on bank sync connections with an interact

[IMP] account_online_synchronization: disable auto sync on interactive connection

1- Some providers have bank institutions that are "interactive".
In a general way, interactive institution means that users have to refresh their connection with the provider
to ensure that they can still have an access to the bank.

2- It's a nightmare for users and for support as the connections keep failing in error.

- Disable the automatic synchronization flow on bank sync connections with an interactive providers and a message should be displayed explaining the situation to users.

task-id#3887751

odoofin-pr#https://github.com/odoo/odoofin/pull/297

Forward-Port-Of: odoo/enterprise#63926

Fixes a commit e3d7b06 Should look at the `self.order_id` creator instead of `self`. opw-3933511 Forward-Port-Of: odoo/enterprise#66748

Fixes a commit e3d7b06

Should look at the `self.order_id` creator instead of `self`.

opw-3933511

Forward-Port-Of: odoo/enterprise#66748

To reproduce: - install l10n_be_intrastat and sale_management, switch to the company BE company CoA - Settings > Sales > Product Catalog, activate the "Unit of Measure" setting - Go to Sales/Configuration/Units of Measure/Units of Measure menu - Create a new units of measure; set the category to "Weight" as Reference Unit of Measure, uncheck the Active checkbox to archive it - Create an invoice for the contact having country Germany and with a product having commodity code, weight, etc se

To reproduce:

- install l10n_be_intrastat and sale_management, switch to the company BE company CoA
- Settings > Sales > Product Catalog, activate the "Unit of Measure" setting
- Go to Sales/Configuration/Units of Measure/Units of Measure menu
- Create a new units of measure; set the category to "Weight" as Reference Unit of Measure, uncheck the Active checkbox to archive it
- Create an invoice for the contact having country Germany and with a product having commodity code, weight, etc set for the intrastate report
- Validate the invoice and check the intrastate report for "This Fiscal Year"

Result -  The report lines appear twice

Expected - The report shouldn't consider archived UoM, lines should appear only once

OPW - 3915784

Additional info:
This behavior happened because in the following refactor PR,
https://github.com/odoo/enterprise/pull/31893/files#diff-7b1b123893744b02df76c7fa971ebb68b9f59e26f619e3a7d8f290c0f45ed037L368
We forgot to re-add the following line as a condition in the where clause:
`ref_weight_uom.active`

Forward-Port-Of: odoo/enterprise#66223
Forward-Port-Of: odoo/enterprise#64500

Before this commit, when clicking on the action with the hierarchy enabled, the parent line were not unfolded which cause the purpose of the action to be useless. task-3839845 Forward-Port-Of: odoo/enterprise#63965

Before this commit, when clicking on the action with the hierarchy enabled, the parent line were not unfolded which cause the purpose of the action to be useless.

task-3839845

Forward-Port-Of: odoo/enterprise#63965

The model 347 report is adding a partner exclusion domain in the search call. It is done by firstly retrieving those partner IDs to then add that list of IDs into a `not in` domain leaf. The issue is that the list of IDs can be gigantic, leading to performance issues. Before odoo/enterprise#61452, it was a blocking issue as if the list was too long (100,000 IDs raise the issue), it would simply make the code crash when loading the report. That PR then simply bypassed the issue by passing t

The model 347 report is adding a partner exclusion domain in the search call.
It is done by firstly retrieving those partner IDs to then add that list of IDs into a `not in` domain leaf.
The issue is that the list of IDs can be gigantic, leading to performance issues.

Before odoo/enterprise#61452, it was a blocking issue as if the list was too long (100,000 IDs raise the issue), it would simply make the code crash when loading the report.
That PR then simply bypassed the issue by passing the domain as `forced_domain` so it would not go through the `literal_eval()` call (which is the one crashing when the list is too long).

But even after that fix, we still provide the list of IDs into the domain and so ultimately in the SQL request, which can still be an issue if there are too many.

This commit improves that by passing the SQL subquery (the one fetching the partners to exclude) directly into the domain, so the SQL query won't contain any list of IDs but just a sub-select. It does have better performance within PostgreSQL for big lists.

Note that the `SQL()` query is surrounded by parentheses on purpose, as it doesn't work otherwise. This might be improved at the ORM level in the future with odoo/odoo#163560.

Task [link](https://www.odoo.com/web#model=project.task&id=3895983)
task-3895983

Forward-Port-Of: odoo/enterprise#62866

In [1], a limit was introduced to the amount of records that can be displayed at the same time in the shop floor app. However, it was not always very clear to the user that they may only be viewing a subset of the available records. It was also impossible to show any records beyond the first 40 that conform to the filter criteria. In this commit, we introduce a pager to resolve these issues. The pager will only be displayed when relevant (ie when not all available records are displayed). Usin

In [1], a limit was introduced to the amount of records that can be displayed at the same time in the shop floor app. However, it was not always very clear to the user that they may only be viewing a subset of the available records. It was also impossible to show any records beyond the first 40 that conform to the filter criteria.

In this commit, we introduce a pager to resolve these issues. The pager will only be displayed when relevant (ie when not all available records are displayed). Using this new pager it is also possible for the user to dynamically increase or decrease the default limit of 40, which was not possible before.

[1] https://github.com/odoo/enterprise/pull/64551 (and forward ports)

Forward-Port-Of: odoo/enterprise#65995

Steps to reproduce: - Install "Field Service" - Open "Project" - Open the settings of a random project - Then click on the "Settings" tab - Disable "Field Service" and enable "Worksheets" - Create a new task with a worksheet - Click on start then stop and save - Click on "Sign Report" Issues: The sign button is not displayed due to the condition in the template which required previously to have `is_fsm` enabled. https://github.com/odoo/enterprise/blob/4d0a467220fba5253fb4a6f388448

Steps to reproduce:
- Install "Field Service"
- Open "Project"
- Open the settings of a random project
- Then click on the "Settings" tab
- Disable "Field Service" and enable "Worksheets"
- Create a new task with a worksheet
- Click on start then stop and save
- Click on "Sign Report"

Issues:
The sign button is not displayed due to the condition in the template which required previously to have `is_fsm` enabled.

https://github.com/odoo/enterprise/blob/4d0a467220fba5253fb4a6f38844861d9ed4e442/industry_fsm/views/project_portal_templates.xml?plain=1#L42

opw-4032692

Forward-Port-Of: odoo/enterprise#66599
Forward-Port-Of: odoo/enterprise#66057

Steps to reproduce: - Install "Field Service" - Open a random task - Click on "Navigate To" Issues: The link is constructed using the coordinates, however Google will convert those coordinates back to an address which will cause a potential discrepancy between the two. opw-4004846 Forward-Port-Of: odoo/enterprise#66611 Forward-Port-Of: odoo/enterprise#65893

Steps to reproduce:
- Install "Field Service"
- Open a random task
- Click on "Navigate To"

Issues:
The link is constructed using the coordinates, however Google will convert those coordinates back to an address which will cause a potential discrepancy between the two.

opw-4004846

Forward-Port-Of: odoo/enterprise#66611
Forward-Port-Of: odoo/enterprise#65893

**Steps to reproduce**: - Create an MO for Stool - In the shop floor, open the "assembly" step of the created WO **Currently**: scanning barcode for back/skip does not do anything. **After this commit**: scanning the barcode executes the expected command. task-4047193 Forward-Port-Of: odoo/enterprise#66579

**Steps to reproduce**:
- Create an MO for Stool
- In the shop floor, open the "assembly" step of the created WO

**Currently**: scanning barcode for back/skip does not do anything.
**After this commit**: scanning the barcode executes the expected command.

task-4047193

Forward-Port-Of: odoo/enterprise#66579

vat base and change exempt base to exports account. Forward-Port-Of: odoo/enterprise#66086

vat base and change exempt base to exports account.

Forward-Port-Of: odoo/enterprise#66086

When we search for the stock moves to report to eTIMS, we need to ensure that the ordering is deterministic so that tests don't randomly fail. runbot-71136 Forward-Port-Of: odoo/enterprise#66739

When we search for the stock moves to report to eTIMS, we need to ensure that the ordering is deterministic so that tests don't randomly fail.

runbot-71136

Forward-Port-Of: odoo/enterprise#66739

…d warning Steps to reproduce: - Go to Accounting/Reporting/Tax Report; - Make sure there is a negative amount in the tax report; - Click on PDF/EDI VAT/Test Interchange (available in debug) not to send the tax report to the government for real, and "Send VAT Report"; - Go to Reporting/EDI exports > it should have the "Rejected" status because of the negative amount(s); Issue: On the Accounting Dashboard: the error "Export(s) de taxes rejeté(s)" is appearing on several journals Sol

…d warning

Steps to reproduce:
- Go to Accounting/Reporting/Tax Report;
- Make sure there is a negative amount in the tax report;
- Click on PDF/EDI VAT/Test Interchange (available in debug) not to send the tax report to the government for real, and "Send VAT Report";
- Go to Reporting/EDI exports > it should have the "Rejected" status because of the negative amount(s);

Issue:
On the Accounting Dashboard: the error "Export(s) de taxes rejeté(s)" is appearing on several journals

Solution:
We get the journal defined for the Tax Return Periodicity. If no journal defined;
We keep only the first Misc journal that is found

This way, we let the user have custom misc journals (fec import or custom coa)

opw-4004375

Forward-Port-Of: odoo/enterprise#66346

…dated on template change" This causes issues as composer computed value is now always forced and user value is ignored. A better fix will come soon. This reverts commit 8b7829469907b39d048a328dd3a939f1c3e1d21c. Task-3996935 Forward-Port-Of: odoo/enterprise#66727

…dated on template change"

This causes issues as composer computed value is now always forced and user value is ignored. A better fix will come soon.

This reverts commit 8b7829469907b39d048a328dd3a939f1c3e1d21c.

Task-3996935

Forward-Port-Of: odoo/enterprise#66727

Currently, an error occurs when the payment status is failed, expired, or failed. Steps to produce an error: - Install `sale_subscription` and `payment_mollie` - setup `mollie` payment provider in testing - Create an invoice for the subscription and confirm it - Click preview of the invoice and click Pay Now. - fill card details, and on the on the next page, select failed or expired in payment status - Confirm error:  `PaymentTransaction._set_canceled() takes 1 positional argument b

Currently, an error occurs when the payment status is failed, expired, or failed.

Steps to produce an error:
- Install `sale_subscription` and `payment_mollie`
- setup `mollie` payment provider in testing
- Create an invoice for the subscription and confirm it
- Click preview of the invoice and click Pay Now.
- fill card details, and on the on the next page, select failed or expired in payment status
- Confirm

error: 
`PaymentTransaction._set_canceled() takes 1 positional argument but 2 were given`

This is because at code [1], we have passed `**kwargs` as arguments in super call, and as a result, it sets all arguments of kwargs in agruments, e.g., 2 of super call, but method call requires one positional argument.

This commit will fix the above issue by passing a positional argument with kwargs in the super call.

[1]-https://github.com/odoo/enterprise/blob/43621084d0cf95970eb6e45cf67bcb20ec14b8b3/sale_subscription/models/payment_transaction.py#L186

sentry-5606090812

Forward-Port-Of: odoo/enterprise#66664

Currently, accounts `7632/9` are not taken into account in the Belgian profit and loss report. opw-4037481 Forward-Port-Of: odoo/enterprise#66666 Forward-Port-Of: odoo/enterprise#66343

Currently, accounts `7632/9` are not taken into account in the Belgian profit and loss report.

opw-4037481

Forward-Port-Of: odoo/enterprise#66666
Forward-Port-Of: odoo/enterprise#66343

Before, the default user assigned to the self order was a standard pos user. This commit changes the default user to pos_manager to avoid any access rights issues. RB error: 70391 Forward-Port-Of: odoo/odoo#173102

Before, the default user assigned to the self order was a standard pos user.

This commit changes the default user to pos_manager to avoid any access rights issues.

RB error: 70391

Forward-Port-Of: odoo/odoo#173102

Before this commit, opening a record from the list view triggered field validity checks, resulting in unnecessary notifications. This commit optimizes the process by bypassing the _checkValidity function when no changes to the record have been made. opw-3987849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173282

Before this commit, opening a record from the list view triggered field validity checks, resulting in unnecessary notifications. This commit optimizes the process by bypassing the _checkValidity function when no changes to the record have been made.

opw-3987849

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

Forward-Port-Of: odoo/odoo#173282