[**Problem:** In POS, if a product which has two variants with the same discount is selected, in debug mode an error window appears. If not in debug mode, the selector widget appears even though it should not because it's the same discount **Steps to reproduce:** - Enable the "variants" and the "Discounts" settings - Create a new product, make it available in POS - In the "Attributes & Variants" page, add a color attribute line and give it two values - In the Point of Sale page, give

[**Problem:**
In POS, if a product which has two variants with the same discount is selected, 
in debug mode an error window appears. If not in debug mode, the selector 
widget appears even though it should not because it's the same discount

**Steps to reproduce:**
- Enable the "variants" and the "Discounts" settings
- Create a new product, make it available in POS
- In the "Attributes & Variants" page, add a color attribute line and give it two values
- In the Point of Sale page, give it a category
- Open Point of Sale/Products/Discount & loyalty, and click on New
- Click on the text below "Conditional rules" on the bottom left of the screen
- In the Products field select the two variants of your new product
- Save
- Open a shop in Point of Sale
- Select your product

**Current behavior:**
If in debug mode an error message appears.
If not in debug mode, a selector widget appears, allowing the user to choose 
between two times the same discount

**Expected behavior:**
Because it's the same discount, no window of selection (and no error window) should appear

**Cause of the issue:**
when computing the list of the different discounts available for a product there's 
no mechanism to avoid duplicates. 
So linkedPrograms will be a list of two identical values
https://github.com/odoo/odoo/blob/2e4c704d80812aabe28ae491e28c5faa4c27d693/addons/pos_loyalty/static/src/app/services/pos_store.js#L372-L373 
makeAwataible is then called with "list" containing the two objects with the same id.
https://github.com/odoo/odoo/blob/2e4c704d80812aabe28ae491e28c5faa4c27d693/addons/pos_loyalty/static/src/app/services/pos_store.js#L377-L383

If not in debug mode: this will result in the creation of a SelectionPopup allowing 
to choose between two times the same discount

If in debug mode:
when __render will eventally be called,
https://github.com/odoo/odoo/blob/2e4c704d80812aabe28ae491e28c5faa4c27d693/addons/web/static/lib/owl/owl.js#L3050 
slotScope.this.props.list will be a list of two element with the same id, this will trigger 
an error thanks to this line which is added in debug mode https://github.com/odoo/odoo/blob/2e4c704d80812aabe28ae491e28c5faa4c27d693/addons/web/static/lib/owl/owl.js#L4486

opw-4703868

Forward-Port-Of: odoo/odoo#207885

This commit removes all files related to the session tour for survey. This tour has been maintained for years but sadly keeps breaking as it's very sensitive due to various reasons: - Mix of python code and multiple chained tours - Multiple "timing" components that are part of the session functional flow: - SVG charts animations for question answers - CSS animations when showing the leaderboard - Animations when going from one question to another We have already put a lot of eff

This commit removes all files related to the session tour for survey.

This tour has been maintained for years but sadly keeps breaking as it's very sensitive due to various reasons:
- Mix of python code and multiple chained tours
- Multiple "timing" components that are part of the session functional flow:
  - SVG charts animations for question answers
  - CSS animations when showing the leaderboard
  - Animations when going from one question to another

We have already put a lot of effort into fixing it in various versions, despite never touching the base survey code, only the test was broken, not the feature.

It started failing yet again recently and the cause is (once again) obscure.

Due to all these reasons, and the fact that survey is in "maintenance mode" and rarely modified to a significant degree, we believe it's best to get rid of it to focus on more important matters.

Task-4778379

Side-note: Sorry Florian Charlier <flch@odoo.com> we have tried enough, it's time to let it go now :')

Forward-Port-Of: odoo/odoo#209333
Forward-Port-Of: odoo/odoo#208757

After 18.0, the Product form has changed and the Purchase taxes field was moved on the main tab. By doing so, we removed the "Purchase" checkbox (as the tab would have been empty), but by doing so we lost the ability to tell that a product can be purchased or not. Now when account is installed we make the checkbox visible on the Product form even without the Purchase app, the tab will then only be visible if both the Purchase app is installed and the checkbox is ticked.  task- 4742975 For

After 18.0, the Product form has changed and the Purchase taxes field was moved on the main tab. By doing so, we removed the "Purchase" checkbox (as the tab would have been empty), but by doing so we lost the ability to tell that a product can be purchased or not.

Now when account is installed we make the checkbox visible on the Product form even without the Purchase app, the tab will then only be visible if both the Purchase app is installed and the checkbox is ticked. 

task- 4742975

Forward-Port-Of: odoo/odoo#207089

### Issue In project sharing, tasks in the "Done" and "Approved" stages were not shown with distinct progress in the Kanban progress bar. As a result, users were unable to identify the task status easily. ### Reason: The color class was set incorrectly. ### Fix: We have updated the color class in this commit to correctly reflect the task stages. issue-https://github.com/odoo/odoo/commit/1a44b849970d3e39111a99ea35db5b586b184dd3 ### Steps to Reproduce: - Create a projec

### Issue
   In project sharing, tasks in the "Done" and "Approved" stages were not shown with distinct progress in the Kanban progress bar. As a result, users were unable to identify the task status easily.

### Reason:
   The color class was set incorrectly.

### Fix:
   We have updated the color class in this commit to correctly reflect the  task stages.
  issue-https://github.com/odoo/odoo/commit/1a44b849970d3e39111a99ea35db5b586b184dd3

### Steps to Reproduce:
  - Create a project with 2 tasks:
      - Task 1 in the "Done" stage
      - Task 2 in the "Approved" stage
  - Share the project with a portal user
  - Open the project in the portal
  - Navigate to the project sharing Kanban view and check the progress bar

task-4551177

Forward-Port-Of: odoo/odoo#206031

When the test DB includes all demo data, sometimes the corrected tours took the wrong products This commit makes the selection of products in test tours more precise, just as it is the case for some other selectors. runbot-error-161984 runbot-error-108034 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-Por

When the test DB includes all demo data, sometimes the corrected tours took the wrong products

This commit makes the selection of products in test tours more precise, just as it is the case for some other selectors.

runbot-error-161984
runbot-error-108034

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#210118

__Current behavior before commit:__ The QR code on the payment page is cropped when the Pending Message of the payment provider has a long line. __Description of the fix:__ Set `flex-shrink-0` to the QR code card so it doesn't shrink. __Steps to show the cropped QR code:__ 1. Install sale_management and website 2. Set company currency to EUR 3. Enable QR Codes under Customer Payments in Settings 4. Enable Online Payment (and disable Online Signature) under Quotations & Orders 5. In

__Current behavior before commit:__
The QR code on the payment page is cropped when the Pending Message of the payment provider has a long line.

__Description of the fix:__
Set `flex-shrink-0` to the QR code card so it doesn't shrink.

__Steps to show the cropped QR code:__
1. Install sale_management and website
2. Set company currency to EUR
3. Enable QR Codes under Customer Payments in Settings
4. Enable Online Payment (and disable Online Signature) under Quotations & Orders
5. In Payment Providers, install SEPA Direct Debit. Select Test mode, check Enable QR Codes, and publish it.
6. **In Messages tab, put a very long line as Pending Message**
7. Go to the Journal "Bank" and set a random IBAN as Account number
8. Create a new Quote with a non 0 price and click on Preview and pay the order
9. The QR code is cropped

opw-4735003

Forward-Port-Of: odoo/odoo#209686

For proper provision management we introduce accounts 2350 and 2351 task-4797323 Forward-Port-Of: odoo/odoo#210062

For proper provision management we introduce accounts 2350 and 2351

task-4797323

Forward-Port-Of: odoo/odoo#210062

Before this commit, if a paid order request was sent twice, duplicate records such as pickings or invoices could be created in the system. opw-4788967 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210112 Forward-Port-Of: odoo/odoo#209834

Before this commit, if a paid order request was sent twice, duplicate records such as pickings or invoices could be created in the system.

opw-4788967

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

Forward-Port-Of: odoo/odoo#210112
Forward-Port-Of: odoo/odoo#209834

Fixes an issue when issuing self-billed invoices to the platform. So far we have been using Odoo's bill name as ID, but we should instead use the bill reference (if set) to use the supplier number. task-4777585 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210162 Forward-Port-Of: odoo/odoo#208721

Fixes an issue when issuing self-billed invoices
to the platform.
So far we have been using Odoo's bill name as ID,
but we should instead use the bill reference (if
set) to use the supplier number.

task-4777585

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

Forward-Port-Of: odoo/odoo#210162
Forward-Port-Of: odoo/odoo#208721

- Fix issue where combo price were not recomputed when changing the pricelist of the order. - The issue was due to the fact that in the `pos_order.set_pricelist()` method we were only recopute the combo line that have a `price_type === "original"`, and that the combo line `price_type` was undefined. Now when a adding a combo product to the cart, all of its lines have a `price_type` set to `automatic` initially, and inside `pos_order.set_pricelist()` we now recompute the price of the combo line

- Fix issue where combo price were not recomputed when changing the pricelist of the order.
- The issue was due to the fact that in the `pos_order.set_pricelist()` method we were only recopute the combo line that have a `price_type === "original"`, and that the combo line `price_type` was undefined.
Now when a adding a combo product to the cart, all of its lines have a `price_type` set to `automatic` initially, and inside `pos_order.set_pricelist()` we now recompute the price of the combo line that have a `price_type === "automatic"`.

Steps to reproduct:
- Create pricelists and add it to pos config
- Open PoS
- Add combo product to cart
- Change pricelist
- => Price is not recomputed based on the pricelist as it should

task-id: 4707663



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

Forward-Port-Of: odoo/odoo#208605
Forward-Port-Of: odoo/odoo#204981

The selectionchange event is triggered in the next microtask tick. Any test that relies on the effect of a selectionchange but does not explicitely wait for it before running its step function or checking its expected result is likely to fail non-deterministically on newer versions of Chrome. This is basically a generalized version of the fix at https://github.com/odoo/odoo/pull/206969. Forward-Port-Of: odoo/odoo#209907 Forward-Port-Of: odoo/odoo#209844

The selectionchange event is triggered in the next microtask tick.

Any test that relies on the effect of a selectionchange but does not explicitely wait for it before running its step function or checking its expected result is likely to fail non-deterministically on newer versions of Chrome. This is basically a generalized version of the fix at https://github.com/odoo/odoo/pull/206969.

Forward-Port-Of: odoo/odoo#209907
Forward-Port-Of: odoo/odoo#209844

Before this commit, the connection manager would send the IoT devices to the DB before checking out to the correct git branch. This was intended to give the user a quicker response that the IoT connection was successful. However, due to the change of identifier from MAC address to serial number, connecting an IoT to a DB in master results in the following behaviour: - IoT starts in saas-18.1, connects to DB - It posts to `/iot/setup` before checking out, using its MAC as the identifier

Before this commit, the connection manager would send the IoT devices to the DB before checking out to the correct git branch. This was intended to give the user a quicker response that the IoT connection was successful.

However, due to the change of identifier from MAC address to serial number, connecting an IoT to a DB in master results in the following behaviour:
  - IoT starts in saas-18.1, connects to DB
  - It posts to `/iot/setup` before checking out, using its MAC as the identifier
  - The IoT box appears in the Odoo backend with the MAC identifier and its current devices
  - After checking out, the IoT calls `/iot/setup` again but with the serial number
  - The Odoo backend rejects the call because it thinks it is a new IoT box, but the token doesn't match

The end result is that it is impossible to connect new devices to the Odoo database, unless the IoT is disconnected and re-paired.

To fix this, we will simply stop sending the devices early.

task-4797337

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

Forward-Port-Of: odoo/odoo#210065

Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be synchronized without any organizer in user A's Outlook calendar due to a limitation of Microsoft of not accepting creating events for other users (user B) directly. In the meanwhile, in Odoo, the event ownership will be transferred from user B to user A, which is also wrong. After this commit, when us

Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be synchronized without any organizer in user A's Outlook calendar due to a limitation of Microsoft of not accepting creating events for other users (user B) directly. In the meanwhile, in Odoo, the event ownership will be transferred from user B to user A, which is also wrong.

After this commit, when user A starts or resumes its synchronization with Outlook, previous Odoo events which user A is attendee but not organizer won't be synchronized until the organizer synchronizes its calendar. This will keep the ownership of the event intact in Odoo, and when the organizer synchronizes its calendar with Outlook, it will be correctly synchronized in Outlook as well. This approach will also reduce the possibility of duplicated events in Odoo side (and by transitivity, in Outlook side).

task-4269432

Forward-Port-Of: odoo/odoo#209871
Forward-Port-Of: odoo/odoo#188961

Currently, a console log warning appears when adding a byproduct in the BOM. Additionally, the uom widget doesn't function as expected. Steps to Reproduce ================== - Enable byproducts for the manufacturing operation. - Navigate to Manufacturing > Products > Bill of Materials. - Open an existing demo BOM or create a new BOM product. - Add a byproduct and observe the console log warning. Issue ===== In the mrp_bom view, the byproduct list uses the many2one_uom widget. How

Currently, a console log warning appears when adding a byproduct in 
the BOM. Additionally, the uom widget doesn't function as expected.

Steps to Reproduce
==================
- Enable byproducts for the manufacturing operation.
- Navigate to Manufacturing > Products > Bill of Materials.
- Open an existing demo BOM or create a new BOM product.
- Add a byproduct and observe the console log warning.

Issue
=====
In the mrp_bom view, the byproduct list uses the many2one_uom widget.
However, the quantity_field was not passed, leading to the console
log warning.

This commit ensures the quantity_field is correctly passed and resolves
the warning. Additionally, the uom widget is now properly displayed.

Task: [4714266](https://www.odoo.com/odoo/project.task/4714266)

Forward-Port-Of: odoo/odoo#205353

**Problem:** The problem happens when a product can be sold by a packaging where the UOM of the packaging is not a reference unit (it depends from another unit, for instance a packaging of 33kg where the UOM is kg which depends from g) and the product price is based on the UOM of the packaging (in the exemple: kg). When in the point of sale app, if we scan the barcode of this packaging for the product, the quantity sold will be computed as if it was sold in the reference unit (here a

**Problem:**
The problem happens when a product can be sold by a packaging 
where the UOM of the packaging is not a reference unit (it depends
from another unit, for instance a packaging of 33kg where the UOM
is kg which depends from g) and the product price is based on the 
UOM of the packaging (in the exemple: kg). 
When in the point of sale app, if we scan the barcode of this packaging
for the product, the quantity sold will be computed as if it was sold 
in the reference unit (here as 33kg is 33.000 g, the quantity will be 
33.000, even though we sell the product by kg so we expected a quantity 
of 33).

**Steps to reproduce:**
- Open Sale/Configuration/Products/Units&Packagings
- Create a New record, set the quantity to 33kg and set a name
- Check the "Group Products in POS" option
- Go to Point of Sale/products and create a new product
- Check the Sales and Point of Sale boxes
- In general information in the "Sale Price" field select kg as the unit
- In the Sales tab, in the packagings field select the packaging you just 
created
- click on the tag of this packaging and write a barcode for it.
- Open a shop in point of sale
- Click on the three horizontal lines on the top right of the screen
- Select Debug Window, write the barcode of your packaging
- Click on scan

**Current behavior:**
The quantity of your product in order is 33.000

**Expected behavior:**
The quantity should be 33

**Cause of the issue:**
When the quantity sold is computed it's computed by taking the factor 
of the packaging which is the number of reference unit of this packaging.
https://github.com/odoo/odoo/blob/9354163d9fe45a34e7c3686f2c88cb9e3d4fbfc2/addons/point_of_sale/static/src/app/models/pos_order_line.js#L55
Here the reference unit is g so the factor is 33.000. 
But the product is sold in kg so the quantity should be 33.

**Fix:**
The quantity sold should be the factor of the packaging divided by the 
factor UOM in which the product is sold (here : 33000/1000 = 33)

opw-4652869

Forward-Port-Of: odoo/odoo#208737
Forward-Port-Of: odoo/odoo#205026

**Steps to reproduce:** - Install account - Go to "Invoicing / Configuration / Accounting / Journals" - Create a "Credit Card" type journal - In "Incoming Payments" tab (or "Outgoing Payments"), try to add a line **Issue:** There is no option for "Payment Method" select field. If the default "Manual Payment" line is removed, it's not possible to add it again. **Cause:** The list of available payment methods for credit card journal is empty. The method that is computing the available

**Steps to reproduce:**
- Install account
- Go to "Invoicing / Configuration / Accounting / Journals"
- Create a "Credit Card" type journal
- In "Incoming Payments" tab (or "Outgoing Payments"), try to add a line

**Issue:**
There is no option for "Payment Method" select field. If the default "Manual Payment" line is removed, it's not possible to add it again.

**Cause:**
The list of available payment methods for credit card journal is empty.
The method that is computing the available payment methods is always returning False for credit card journals, but it should not.

**Solution:**
Compute the available payment methods normally as it is the case for bank and cash journals.

opw-4754110




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

Forward-Port-Of: odoo/odoo#209438

To reproduce: ============= - have an employee with a working schedule of night shifts like 18:00 to 00:00 break to 01:00 then continue to 03:00 - create payslip for this employee for January 2025 - print the payslip, the working hours will be 183.9936 The problem: ============ 00:00 is represented as 23:59:59.99999 in python, that missing microsecond impacts the computation of the duration of the work entry. The solution: ============= round the total seconds opw-4702410 ---

To reproduce:
=============
- have an employee with a working schedule of night shifts like 18:00 to 00:00 break to 01:00 then continue to 03:00
- create payslip for this employee for January 2025
- print the payslip, the working hours will be 183.9936

The problem:
============
00:00 is represented as 23:59:59.99999 in python, that missing
microsecond impacts the computation of the duration of the work entry.

The solution:
=============
round the total seconds

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

Forward-Port-Of: odoo/odoo#208811

When no notification was received before bus disconnection, the `has_missed_notifications` route is missing a parameter, leading to an error. This commit fixes the issue. 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#210083 Forward-Port-Of: odoo/odoo#209890

When no notification was received before bus disconnection, the `has_missed_notifications` route is missing a parameter, leading to an error. This commit fixes the issue.

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#210083
Forward-Port-Of: odoo/odoo#209890

Fixes an issue where copying an account report correctly update the formulas of the report but not the subformulas. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209742 Forward-Port-Of: odoo/odoo#208071

Fixes an issue where copying an account report
correctly update the formulas of the report but
not the subformulas.

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

Forward-Port-Of: odoo/odoo#209742
Forward-Port-Of: odoo/odoo#208071

Tests were failing because of smooth scrolling. runbot-103421 Forward-Port-Of: odoo/odoo#210009

Tests were failing because of smooth scrolling.

runbot-103421

Forward-Port-Of: odoo/odoo#210009

This error occurs when a user attempts to send multiple invoices at once. Steps to Reproduce: - Install the `account` module. - Open `Invoices`. - Select multiple invoices and click `Send`. `KeyError: <NewId origin=3>` This error occurs when the wizard tries to compute the summary data of invoices. Since this is a computed field, so we got newId here. This commit will fix the above issue by using _origin.id, ensuring that it always returns the ID of a valid record. Sentry-

This error occurs when a user attempts to send multiple invoices at once.

Steps to Reproduce:

 - Install the `account` module.
 - Open `Invoices`.
 - Select multiple invoices and click `Send`.

`KeyError: <NewId origin=3>`

This error occurs when the wizard tries to compute the summary data of invoices. Since this is a computed field, so we got newId here.

This commit will fix the above issue by using _origin.id, ensuring that it always returns the ID of a valid record.

Sentry-6562659542


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

Forward-Port-Of: odoo/odoo#207241

Steps to reproduce: - Install Discuss, events and contacts app - Set a partner langage to another langage - Open the event app and select an event - Select 'Attendees' in the smart buttons and click on New - In the 'Booked by' field, select the partner with the foreign langage - Save Current Behavior: A registration email is created but the body of the email is not translated to the language of the partner Expected Behavior: The body of the registration email should be translate

Steps to reproduce:

- Install Discuss, events and contacts app
- Set a partner langage to another langage
- Open the event app and select an event
- Select 'Attendees' in the smart buttons and click on New
-  In the 'Booked by' field, select the partner with the foreign langage
- Save

Current Behavior:
A registration email is created but the body of the email is not translated to the language of the partner

Expected Behavior:
The body of the registration email should be translated in the language of the partner

Cause of the issue:

In order for the translation to happen inside _render_field() the variable 'equality' has to be True
Link 1: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L180

Because field is equal to 'body' the value of equality is the value of self.body_has_template_value
Link 2:https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L168

self.body_has_template_value is computed by checking if the 'body' attribute of self (self is an instance of mail.compose.message)
is either equal to self.template_id.body_html or tools.html_sanitize(self.template_id.body_html)
Link3: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L70

In this case, self.body has been computed using html_sanitize(self.template_id_html)
Link4: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/odoo/fields.py#L2231
so self.body_has_template_value shoud be True

The reason it's False is that when computing the value of self.body (Link4) the method html_sanitize is used with an argument (**sanitize_vals)
which is not the case when comparing self.body to html_sanitize(self.template_id.body_html) (Link3)

As a result self.body and html_sanitize(self.template_id.body_html) are not equal
which makes self.body_has_template_value be False
which makes equality be equal to False
which makes the translation not happening

Fix :

Inside _compute_body_has_template_value() I made the method also return True if
self.body is equal to html_sanitize(self.template_id.body_html,**sanitize_vals)
with santize_vals having the same value as when self.body is computed

opw-4349122

Forward-Port-Of: odoo/odoo#200187

For proper provision management we introduce accounts 2350 and 2351 task-4797323 Forward-Port-Of: odoo/enterprise#85574

For proper provision management we introduce accounts 2350 and 2351

task-4797323

Forward-Port-Of: odoo/enterprise#85574

In case of a multi-company enabled database, it was possible to assign a journal to an online account of a different company, which didn't make much sense. Forward-Port-Of: odoo/enterprise#85536 Forward-Port-Of: odoo/enterprise#82080

In case of a multi-company enabled database, it was possible to assign a journal to an online account of a different company, which didn't make much sense.

Forward-Port-Of: odoo/enterprise#85536
Forward-Port-Of: odoo/enterprise#82080

This commit will do a backport of the python change made in this commit: https://github.com/odoo/enterprise/pull/77565/commits/7f26eefa932ec09297fbc4b8256ebe0b2976b231 task-4476707 Forward-Port-Of: odoo/enterprise#84728

This commit will do a backport of the python change made in this commit: https://github.com/odoo/enterprise/pull/77565/commits/7f26eefa932ec09297fbc4b8256ebe0b2976b231

task-4476707

Forward-Port-Of: odoo/enterprise#84728

Currently, an empty partner ref in an FEC line could incorrectly match a partner with an empty ref. This fix ensures that only non-empty refs are considered when processing FEC files. Steps to reproduce: 1. Install the `l10n_fr_fec_import` module. 2. Create a contact and set its ref to an empty string (`""`). 3. Import an FEC file containing lines without `CompAuxNum`. 4. The created contact will be incorrectly assigned to all lines without `CompAuxNum`. opw-4592290 Forward-Port-O

Currently, an empty partner ref in an FEC line could incorrectly match a partner with an empty ref.

This fix ensures that only non-empty refs
are considered when processing FEC files.

Steps to reproduce:
1. Install the `l10n_fr_fec_import` module.
2. Create a contact and set its ref to an empty string (`""`).
3. Import an FEC file containing lines without `CompAuxNum`.
4. The created contact will be incorrectly assigned to all lines without `CompAuxNum`.

opw-4592290

Forward-Port-Of: odoo/enterprise#84855
Forward-Port-Of: odoo/enterprise#81676

This commit fix some tests in account_reports which were failing in nightly on the runbot, see error 134654. First test fails because an account number sequence was changing depending on if the accountant module was installed or not. Fix the test by replacing the hardcoded account name by the used bank journal name. Second test fails because of payment_state computation which is different depending on if the accountant module was installed or not. Fix it by using the _get_invoice_in_p

This commit fix some tests in account_reports which were failing in nightly
on the runbot, see error 134654.

First test fails because an account number sequence was changing depending
on if the accountant module was installed or not. Fix the test by replacing
the hardcoded account name by the used bank journal name.

Second test fails because of payment_state computation which is different
depending on if the accountant module was installed or not. Fix it by using
the _get_invoice_in_payment_state method instead of hardcoded value.

no task

Forward-Port-Of: odoo/enterprise#84417

Fix a bug where account moves paid with cash appears in a line with full 0 in the boe export of mod347 tax report. But it shouldn't create a line at all, so this commit remove the lines in this case. task-4613012 Forward-Port-Of: odoo/enterprise#84317

Fix a bug where account moves paid with cash appears in a line with full 0 in the boe export of mod347 tax report. But it shouldn't create a line at all, so this commit remove the lines in this case.

task-4613012

Forward-Port-Of: odoo/enterprise#84317

When timezone of user is empty and the user clicks on Add Closing Day(s) button, a traceback will appear. Steps to reproduce the error: - Open Profile > Preferences > Select empty in timezone > Save - Install ``Appointments`` - Go to Appointments > Schedule > Resource Bookings > Add Closing Day(s) Traceback: ``` File "/home/odoo/src/enterprise/appointment/wizard/appointment_manage_leaves.py", line 19, in <lambda> leave_start_dt = fields.Datetime('Start Date', required=True, defa

When timezone of user is empty and the user clicks on Add Closing Day(s) button,
a traceback will appear.

Steps to reproduce the error:
- Open Profile > Preferences > Select empty in timezone > Save
- Install ``Appointments``
- Go to Appointments > Schedule > Resource Bookings > Add Closing Day(s)

Traceback:
```
File "/home/odoo/src/enterprise/appointment/wizard/appointment_manage_leaves.py", line 19, in <lambda>
    leave_start_dt = fields.Datetime('Start Date', required=True, default=lambda self: self._default_time(0, 0))
  File "/home/odoo/src/enterprise/appointment/wizard/appointment_manage_leaves.py", line 14, in _default_time
    user_timezone = pytz.timezone(self.env.user.tz or self.env.context.get('tz', 'utc'))
  File "/home/odoo/src/odoo/odoo/_monkeypatches/pytz.py", line 129, in timezone
    return original_pytz_timezone(name)
  File "__init__.py", line 183, in timezone
    if zone.upper() == 'UTC':
AttributeError: 'bool' object has no attribute 'upper'
```

https://github.com/odoo/enterprise/blob/2c938b66fc1b526a360f4b199a47bcc53991bcb9/appointment/wizard/appointment_manage_leaves.py#L14
When the user selects an empty timezone, tz will be False.
So, It will lead to the above traceback.

Forward port https://github.com/odoo/enterprise/pull/64948 was closed in master,
so the issue is still present in saas-17.4 and all later versions.

sentry-6537084290

Forward-Port-Of: odoo/enterprise#83363

Issue: ---------- A user with Sale Manager access is unable to confirm a recurring service type sale order. Root Cause: -------- The Sale Manager lacks write access to task and recurrence records, which are updated during order confirmation. Fix: ------- Used sudo() when updating the recurrence to bypass access restrictions, allowing the Sale Manager to confirm the sale order successfully. Steps to Reproduce: ------------- - Install the project_sale_subscription module

Issue:
----------
  A user with Sale Manager access is unable to confirm a recurring  service type sale order.

Root Cause:
--------
  The Sale Manager lacks write access to task and recurrence records,  which are updated during order confirmation.

Fix:
-------
  Used sudo() when updating the recurrence to bypass access restrictions, allowing the Sale Manager to confirm the sale order successfully.

Steps to Reproduce:
-------------
  - Install the project_sale_subscription module.
  - Create a user with Sale Manager access only.
  - Log in as that user and create a subscription-based sale order.
  - Add a recurring service product to the order line.

Forward-Port-Of: odoo/enterprise#85584
Forward-Port-Of: odoo/enterprise#85489