Problem: When the customer invoice journal uses the l10n_sg electronic invoicing and the user creates an invoice, a traceback error will occur. The traceback error details a key error since 'tax_exemption_reason' is not a key in the dict from _get_invoice_line_item_vals. Purpose: Only if the key 'tax_exemption_reason' exists in the dict, then it should get popped. Steps to Reproduce on Runbot: 1. Install l10n_sg 2. Switch to SG Company 3. Go to the “Customer Invoices” Journal and check

Problem: When the customer invoice journal uses the l10n_sg electronic invoicing and the user creates an invoice, a traceback error will occur. The traceback error details a key error since 'tax_exemption_reason' is not a key in the dict from _get_invoice_line_item_vals.

Purpose: Only if the key 'tax_exemption_reason' exists in the dict, then it should get popped.

Steps to Reproduce on Runbot:
1. Install l10n_sg
2. Switch to SG Company
3. Go to the “Customer Invoices” Journal and check the “SG BIS Billing 3.0” option for the “Electronic Invoicing” field
4. Create an invoice with a product
5. Confirming the invoice will throw the error.

opw-3984143

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

Forward-Port-Of: odoo/odoo#172600
Forward-Port-Of: odoo/odoo#171687

Issue: ====== Traceback occurs when you select more than one table cell Steps to reproduce the issue: ============================= - Go to to-do - Add a table 1row x 3cols - Add some content with somewhat big length for example "abcde" in the first cell - Add anything in the second cell - Start the selection from the last character of the first cell - Move the cursor to add selection from the second cell - Traceback Origin of the issue: ==================== When we have table

Issue:
======
Traceback occurs when you select more than one table cell

Steps to reproduce the issue:
=============================
- Go to to-do
- Add a table 1row x 3cols
- Add some content with somewhat big length for example "abcde" in the first cell
- Add anything in the second cell
- Start the selection from the last character of the first cell
- Move the cursor to add selection from the second cell
- Traceback

Origin of the issue:
====================
When we have table cells selected, the first while loop stops at the `td` element and not the startContainer so we shouldn't enter in the if condition that handles the `br` elements

task-4043879

Forward-Port-Of: odoo/odoo#172517

Before this commit, the POS loyalty program allowed the partial rewards which was inconsistent with the sale module's behavior. This change aligns the POS module with the sale module's behavior as updated in the following commit: https://github.com/odoo/odoo/commit/5188566444df102561b9d3e58f6671f60c61ffc3 opw-4000589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172675 Forward-Port-Of: odoo/odoo#171746

Before this commit, the POS loyalty program allowed the partial rewards which was inconsistent with the sale module's behavior.

This change aligns the POS module with the sale module's behavior as updated in the following commit: https://github.com/odoo/odoo/commit/5188566444df102561b9d3e58f6671f60c61ffc3

opw-4000589

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

Forward-Port-Of: odoo/odoo#172675
Forward-Port-Of: odoo/odoo#171746

## [FIX] project: let project user to set a project as favorite Before this commit, since the project user cannot edit a project and a recent fix (https://github.com/odoo/odoo/pull/168464) ensures the boolean_favorite widget is readonly is the field is readonly or if the record is readonly then the project user can no longer mark a project in favorite. This commit overrides the standard widget `boolean_favorite` for project to make sure the widget is always editable if the field is not

## [FIX] project: let project user to set a project as favorite

Before this commit, since the project user cannot edit a project and a
recent fix (https://github.com/odoo/odoo/pull/168464) ensures the boolean_favorite widget is readonly is the field
is readonly or if the record is readonly then the project user can no
longer mark a project in favorite.

This commit overrides the standard widget `boolean_favorite` for project
to make sure the widget is always editable if the field is not in
readonly.

task-4041969

## [FIX] lunch: allow employee to save as favorite a product in lunch

Before this commit, the current user could have no access to lunch app
to add/edit product, etc. Since the user cannot edit `lunch.product`
model, he can no longer save as favorite a product since a recent bug
fix (https://github.com/odoo/odoo/pull/168464) to ensure the button is in readonly when the field or the record is
in readonly.

This commit makes sure the user can always save as favorite even if the
record is readonly for the user since the user just has to choose what
he would like to eat during lunch break and so he just needs to select
and save as favorite.

task-4041969

Forward-Port-Of: odoo/odoo#172840
Forward-Port-Of: odoo/odoo#172464

To reproduce the bug: 1- Enable margins in project app 2- Create a billable project 3- Affect to the project billable hours or a sale order 4- go in project update -> new -> profitability section We can see that the profitability is empty. This is because of a condition that checked if a analitic_line was existant in analytic_account_id. Witch is not needed. The check on analytic_account_id is enough. opw-3992550 Forward-Port-Of: odoo/odoo#172234 Forward-Port-Of: odoo/odoo#169995

To reproduce the bug:
1- Enable margins in project app
2- Create a billable project
3- Affect to the project billable hours or a sale order 4- go in project update -> new -> profitability section

We can see that the profitability is empty. This is because of a condition that checked if a analitic_line was existant in analytic_account_id. Witch is not needed. The check on analytic_account_id is enough.

opw-3992550

Forward-Port-Of: odoo/odoo#172234
Forward-Port-Of: odoo/odoo#169995

With the version 3.3, the 3bl tax tag has been removed and so the 3.2 script is throwing an error since that tag doesn't exist anymore The fix is that we remove the 3.2 script and change 3b tag to 3bg or 3bs in the 3.3 script along with the replacement of the 3bl tag Task: 4032184 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172443 Forward-Port-Of: odoo/odoo#171737

With the version 3.3, the 3bl tax tag has been removed and so the 3.2 script is throwing an error since that tag doesn't exist anymore

The fix is that we remove the 3.2 script and change 3b tag to 3bg or 3bs in the 3.3 script along with the replacement of the 3bl tag

Task: 4032184

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

Forward-Port-Of: odoo/odoo#172443
Forward-Port-Of: odoo/odoo#171737

View validation has been improved to take into account groups and access rights (during create and write). see: https://github.com/odoo/odoo/commit/6f06420e4a9443c52dc0cb427f8f55eb4aecabce Issue: When an administrator modifies the involvement of groups, access rights or during migration, certain views trigger errors (because there are inconsistencies and the view will not work for certain users). This error is triggered when modifying views and not when modifying groups. Furthermore, errors c

View validation has been improved to take into account groups and access rights (during create and write). see: https://github.com/odoo/odoo/commit/6f06420e4a9443c52dc0cb427f8f55eb4aecabce

Issue: When an administrator modifies the involvement of groups, access rights or during migration, certain views trigger errors (because there are inconsistencies and the view will not work for certain users). This error is triggered when modifying views and not when modifying groups. Furthermore, errors can be complicated to understand (for example a person activating a view ends up with the group inconsistency error).

From this commit, non-critical errors (the view can be used for some users) no longer trigger an error but trigger a warning, this warning is also displayed in the interface.

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

Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin. To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin. Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale. This PR provides a helper to

Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin.

To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin.

Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale.

This PR provides a helper to convert the locales from the Python side for use on the JavaScript side.

*: payment_adyen

Task-4014022

Forward-Port-Of: odoo/odoo#172373
Forward-Port-Of: odoo/odoo#171176

Steps to reproduce: - Create a serial tracked storable product. - Create a receipt picking for this product with quantity > 2. - Confirm the picking and assign serial numbers. - Click on "Detailed Operations" smart button. - Change the destination location of one or more move line. - Select some move lines with different destination location. - Click on "Put in Pack" button. Expected behavior: `stock.package.destination` wizard opens with only the selected move lines. Current behav

Steps to reproduce:
- Create a serial tracked storable product.
- Create a receipt picking for this product with quantity > 2.
- Confirm the picking and assign serial numbers.
- Click on "Detailed Operations" smart button.
- Change the destination location of one or more move line.
- Select some move lines with different destination location.
- Click on "Put in Pack" button.

Expected behavior:
`stock.package.destination` wizard opens with only the selected move lines.

Current behavior:
The wizard opens with all the move lines in the picking.

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

Forward-Port-Of: odoo/odoo#172542
Forward-Port-Of: odoo/odoo#172218

It prevents the removal of a cron at module uninstall for example. If the cron is being removed it makes sense to drop their associated progress entries. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172770

It prevents the removal of a cron at module uninstall for example. If the cron is being removed it makes sense to drop their associated progress entries.


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

Forward-Port-Of: odoo/odoo#172770

For records such as blogs, no specific rights exists. Customizations could decide to give access to specific records based on their own rules. They are limited by the fact that the check for edition is not overridable. This commit makes it possible to implement specific checks for restricted editors to edit records from the website builder. Steps to reproduce: - Install `website_blog`. - Setup a restricted editor user. - Override `website._check_user_can_modify` to allow access for a gi

For records such as blogs, no specific rights exists. Customizations could decide to give access to specific records based on their own rules. They are limited by the fact that the check for edition is not overridable.

This commit makes it possible to implement specific checks for restricted editors to edit records from the website builder.

Steps to reproduce:
- Install `website_blog`.
- Setup a restricted editor user.
- Override `website._check_user_can_modify` to allow access for a given user to a given blog post record.
- Edit that blog post with that user from the website builder.

=> Blog post could not be edited.

Forward-Port-Of: odoo/odoo#172385

[IMP] l10n_tr: Add tax and tax report translation Add tax and tax report translation in turkish language for the new tr improvements task-id#3924220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172713

[IMP] l10n_tr: Add tax and tax report translation

Add tax and tax report translation in turkish language for the new tr improvements

task-id#3924220

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

Forward-Port-Of: odoo/odoo#172713

Create an analytic plan [TEST] with default optional availability Add an applicability line with: - Domain: Expense - Product Category: [CATEG] - Applicability: Mandatory Create an expense with an expense product having categoy [CATEG] Create Report, submit and approve Issue: No message is raised, the action should have been blocked by the mandatory applicability opw-3955683 Forward-Port-Of: odoo/odoo#172549 Forward-Port-Of: odoo/odoo#168312

Create an analytic plan [TEST] with default optional availability 
Add an applicability line with:
- Domain: Expense
- Product Category: [CATEG]
- Applicability: Mandatory 

Create an expense with an expense product having categoy [CATEG]
Create Report, submit and approve

Issue: No message is raised, the action should have been blocked by the mandatory applicability

opw-3955683

Forward-Port-Of: odoo/odoo#172549
Forward-Port-Of: odoo/odoo#168312

Steps to reproduce the bug: - Create a storable product “P1” - Create a delivery for P1 - Click on “Detailed operation” smart button - select the move line - click on “put in pack” Problem: Nothing happens because the `put_in_pack` function of the 'stock.move.line' model always returns true after calling the same function of the 'stock.picking' model instead of returning the result. Note that this function cannot handle multiple move lines with different pickings. opw-4029393 For

Steps to reproduce the bug:
- Create a storable product “P1”
- Create a delivery for P1
- Click on “Detailed operation” smart button
- select the move line
- click on “put in pack”

Problem:
Nothing happens because the `put_in_pack` function of the 'stock.move.line' model always returns true after calling the same function of the 'stock.picking' model instead of returning the result.

Note that this function cannot handle multiple move lines with different pickings.

opw-4029393

Forward-Port-Of: odoo/odoo#172235
Forward-Port-Of: odoo/odoo#172068

Before this commit, extra fields that begin by `_` were not correctly handled in the `related_models.js` file. This commit fixes this issue by adding a condition to prevent extra fields that begin by `_` from being overridden. Forward-Port-Of: odoo/odoo#172774

Before this commit, extra fields that begin by `_` were not correctly handled in the `related_models.js` file.

This commit fixes this issue by adding a condition to prevent extra fields that begin by `_` from being overridden.

Forward-Port-Of: odoo/odoo#172774

Previously, in the self_order data demos, there was no button on the home page. Now there are. Another fix in this PR: images were no longer loaded since refactoring. This has now been fixed. taskId: 4023864 Forward-Port-Of: odoo/odoo#172629

Previously, in the self_order data demos, there was no button on the home page.

Now there are.

Another fix in this PR: images were no longer loaded since refactoring. This has now been fixed.

taskId: 4023864

Forward-Port-Of: odoo/odoo#172629

Description of the issue/feature this PR addresses: Current behavior before PR: - In the onboarding tour, a step guides users in creating sub-tasks. Desired behavior after PR is merged: - Launch the sub-task steps only when the tour is automatically started. task-3990244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172700 Forward-Port-Of: odoo/odoo#169796

Description of the issue/feature this PR addresses:

Current behavior before PR:
- In the onboarding tour, a step guides users in creating sub-tasks.

Desired behavior after PR is merged:
- Launch the sub-task steps only when the tour is automatically started.

task-3990244

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

Forward-Port-Of: odoo/odoo#172700
Forward-Port-Of: odoo/odoo#169796

A few translation issues are fixed with this: - The title of the report was not translating the type of leave - The title was not correctly formatting the dates accroding to the locale of the user. - The months were not translated - The days were not translated Cleaning of the title's English will be done in master --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172692 Forward-Port-Of: odoo/odoo#171976

A few translation issues are fixed with this:
- The title of the report was not translating the type of leave
- The title was not correctly formatting the dates accroding to the locale of the user.
- The months were not translated
- The days were not translated

Cleaning of the title's English will be done in master

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

Forward-Port-Of: odoo/odoo#172692
Forward-Port-Of: odoo/odoo#171976

**Current behavior:** Lines in an invoice may display a product name incorrectly if they mix arabic/latin characters. **Expected behavior:** These types of product names should respect the RTL syntax if being sent to an Arabic lang partner. **Steps to reproduce:** *Ensure the rtlcss node package is installed and in PATH* 1. Create a Saudi company / switch to a demo one, switch to Arabic language 2. Create a product with the name: `دفتر سلكي بهوية الهيئة A4 - شد 50 ورقة

**Current behavior:**
Lines in an invoice may display a product name incorrectly if
they mix arabic/latin characters.

**Expected behavior:**
These types of product names should respect the RTL syntax if
being sent to an Arabic lang partner.

**Steps to reproduce:**
*Ensure the rtlcss node package is installed and in PATH*

1. Create a Saudi company / switch to a demo one, switch to
     Arabic language

2. Create a product with the name:
   `دفتر سلكي بهوية الهيئة A4 - شد 50 ورقة`

3. Create an invoice to a partner with Arabic set as their lang

4. Confirm the invoice -> print it

5. The product name on the PDF has a mal-ordered name

**Cause of the issue:**
The right-to-left rule of the Arabic language is not getting
enforced.

There is a secondary bug where certain whitespace-delimited
substrings get displayed in a broken, overlapping way. From my
no-comprehensive testing, it seems to only happen when there is
a sequence in the string where you have some substring ending in
a numeral (0-9) followed by a single-space, then another
substring that begins with an Arabic alphabet character.

**Fix:**
When printing an invoice with an arabic partner:
1. Use right-aligned text instead of left

2. Pad single-space breaks between substrings in a product name
     where the first substring ends with a numeral and the
     second begins with an alpha char.

3. Add explicit `dir="rtl"` attribute to the display node

opw-3971541

Forward-Port-Of: odoo/odoo#172179
Forward-Port-Of: odoo/odoo#169267

The aim of this commit is to fix an issue in the sql query generated by the `account_disallowed_expenses` module that was covered by the `account_disallowed_expenses_fleet` during the runbot testing. runbot-71011 Forward-Port-Of: odoo/enterprise#66567

The aim of this commit is to fix an issue in the sql query generated by the `account_disallowed_expenses` module that was covered by the `account_disallowed_expenses_fleet` during the runbot testing.

runbot-71011

Forward-Port-Of: odoo/enterprise#66567

Before this commit, if one of the product's categories was not included in the preparation display, it would lead to an error. opw-4012616 Forward-Port-Of: odoo/enterprise#66534 Forward-Port-Of: odoo/enterprise#66479

Before this commit, if one of the product's categories was not included in the preparation display, it would lead to an error.

opw-4012616

Forward-Port-Of: odoo/enterprise#66534
Forward-Port-Of: odoo/enterprise#66479

Steps to reproduce ================== - Install web_studio,calendar - Go to calendar - Open studio => In the sidebar, Quick Create is disabled but should be enabled Toggling it does nothing Cause of the issue ================== The value was incorrectly read from `archInfo.hasQuickCreate` Solution ======== `hasQuickCreate` -> `quickCreate` This shows a second issue: Now that it's enabled, we can't disable it. This is because we remove the attribute instead of se

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

- Install web_studio,calendar
- Go to calendar
- Open studio

=> In the sidebar, Quick Create is disabled but should be enabled
   Toggling it does nothing

Cause of the issue
==================

The value was incorrectly read from `archInfo.hasQuickCreate`

Solution
========

`hasQuickCreate` -> `quickCreate`

This shows a second issue:

Now that it's enabled, we can't disable it.
This is because we remove the attribute instead of setting it to false

If we don't pass the attribute, it will keep it's default value (true)

https://github.com/odoo/odoo/blob/2afce223268c4ee1ac3c98a6108b1390be82716b/addons/web/static/src/views/calendar/calendar_arch_parser.js#L34

opw-4023026

Forward-Port-Of: odoo/enterprise#66253

Tag updates were causing reload of the domain, while updating tag counts, With this commit all contextual values are preserved during tag updates [Reproduce] - Install documents,contacts- Open a contact - Open its documents - Go to "internal" - Upload a document - Add a tag to it (or remove it) - BUG: all documents visible (instead of documents for that particular client) opw-3967799 Forward-Port-Of: odoo/enterprise#65299

Tag updates were causing reload of the domain, while updating tag counts, With this commit all contextual values are preserved during tag updates

[Reproduce]
- Install documents,contacts- Open a contact
- Open its documents
- Go to "internal"
- Upload a document
- Add a tag to it (or remove it)
- BUG: all documents visible  (instead of documents for that particular client)

opw-3967799

Forward-Port-Of: odoo/enterprise#65299

Steps to reproduce: 1. Create an event with an appointment-type set. 2. In the Calendar module, open the event you created for the appointment. 3. Navigate to the 'Appointment Details' page. Before This Commit: The 'Appointment Details' page is displayed even if no resources have been set. After This Commit: Appointment resource records will only be shown if resources are set. Task:3918574 Forward-Port-Of: odoo/enterprise#66415 Forward-Port-Of: odoo/enterprise#63885

Steps to reproduce:
1. Create an event with an appointment-type set.
2. In the Calendar module, open the event you created for the appointment.
3. Navigate to the 'Appointment Details' page.

Before This Commit:
The 'Appointment Details' page is displayed even if no resources have been set.

After This Commit:
Appointment resource records will only be shown if resources are set.

Task:3918574

Forward-Port-Of: odoo/enterprise#66415
Forward-Port-Of: odoo/enterprise#63885

The config parameter `stock_barcode.mute_sound_notifications`, who allows to mute all sounds in the Barcode app, is not used on the MainMenu, which means scanning a barcode on the main menu will always play a sound regardless the configuration. This commit fixes that. Forward-Port-Of: odoo/enterprise#66227

The config parameter `stock_barcode.mute_sound_notifications`, who allows to mute all sounds in the Barcode app, is not used on the MainMenu, which means scanning a barcode on the main menu will always play a sound regardless the configuration.
This commit fixes that.

Forward-Port-Of: odoo/enterprise#66227

### Steps to reproduce the issue: 1. Create a Product with "Service" as Product Type and "Based on Timesheets" as Invoicing Policy 2. Go to _Field Service > Configuration > Projects_ and choose a Project 3. In the _Invoicing_ section, add a line with an Employee and the Service Product you created 4. Create a Task for the Project 5. Add in the _Timesheets_ section a line with the Employee and a duration of one hour 6. Click on "Mark as done", then "Sales Order" 7. The Delivered Quantiti

### Steps to reproduce the issue:

1. Create a Product with "Service" as Product Type and "Based on Timesheets" as Invoicing Policy
2. Go to _Field Service > Configuration > Projects_ and choose a Project
3. In the _Invoicing_ section, add a line with an Employee and the Service Product you created
4. Create a Task for the Project
5. Add in the _Timesheets_ section a line with the Employee and a duration of one hour
6. Click on "Mark as done", then "Sales Order"
7. The Delivered Quantities have a correct value but the Ordered Quantities do not

### Explanation:

An uom conversion is performed in `_get_delivered_quantity_by_analytic` to compute `qty_delivered` but is missing in `_fsm_create_sale_order_line` for `product_uom_qty`.
https://github.com/odoo/odoo/blob/18e03c73691d9efa82cbf82b5e084172fe74665e/addons/sale/models/sale_order_line.py#L386-L392

### Suggested Fix:

To prevent unintended behaviours, any product that is currently used in a Field Service Project will have `invoice_policy`, `service_type` and `detailed_type` locked to match the domain of `timesheet_product_id` for every model using it.

opw-3858530

Forward-Port-Of: odoo/enterprise#66252
Forward-Port-Of: odoo/enterprise#63337

Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin. To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin. Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale. This PR provides a helper to

Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin.

To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin.

Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale.

This PR provides a helper to convert the locales from the Python side for use on the JavaScript side.

Task-4014022

Community: https://github.com/odoo/odoo/pull/171837

Forward-Port-Of: odoo/enterprise#66287
Forward-Port-Of: odoo/enterprise#66061

Belgium now asks the pro rata deduction for the VAT export. Mandatory if the business is concerned. Added new module to be able to add fields to the wizard. task-3916995 Forward-Port-Of: odoo/enterprise#66456 Forward-Port-Of: odoo/enterprise#65442

Belgium now asks the pro rata deduction for the VAT export. 
Mandatory if the business is concerned.
Added new module to be able to add fields to the wizard.

task-3916995

Forward-Port-Of: odoo/enterprise#66456
Forward-Port-Of: odoo/enterprise#65442

Steps to reproduce ------------------- - create a commission plan with: product category: "All" rate: R capped: True max commission: >>> - create a partner level with the created commission plan - create a partner with the created partner level - create a product in the correct category with price P - create a quotation template with the created product - create a sale order with the partner as referrer - add the quotation template (the product is added automatically)

Steps to reproduce
-------------------
- create a commission plan with:
    product category: "All"
    rate: R capped: True
    max commission: >>>
- create a partner level with the created commission plan
- create a partner with the created partner level

- create a product in the correct category with price P
- create a quotation template with the created product

- create a sale order with the partner as referrer
- add the quotation template (the product is added automatically)
- confirm
- create the invoice, confirm it and register the payment

At this moment, a purchase order is created (the commission) If we repeat these steps with a new sale order,
the amount of the purchase order will increase as expected.

- add a quotation template on the commission plan (in the rules)
- repeat the creation of a sale order.

No commission is added (purchase order line).

Cause:
------
We have no template when calling `_match_rules`.
However, our plan has a default template.
The result is that no rules are found.

Solution:
---------
Fallback on the sale order's template
if it is not a subscription.

opw-3933323

Forward-Port-Of: odoo/enterprise#64884

## [FIX] account_disallowed_expenses_fleet: query is mixing apple and pear The aim of this commit is to make the report behaves correctly when facing a DB with a lot of vehicles and a lot of accounts by making the query `group by` and `order by` more robust. Context: - 1 account and 1 vehicle share the same number for the id - the account is tagged with disallowed expense tag - 1 `account.move.line` without vehicle in that account - 1 `account.move.line` with a vehicle (with a dna ra

## [FIX] account_disallowed_expenses_fleet: query is mixing apple and pear

The aim of this commit is to make the report behaves correctly when
facing a DB with a lot of vehicles and a lot of accounts by making the
query `group by` and `order by` more robust.

Context:
- 1 account and 1 vehicle share the same number for the id
- the account is tagged with disallowed expense tag
- 1 `account.move.line` without vehicle in that account
- 1 `account.move.line` with a vehicle (with a dna rate) in the same
  account

Before the commit:
- The computation is giving wrong result in the report: 2 `account.move.line`
  were aggregated together under the hierarchy of the account without vehicle
  and the vehicle doesn't appear in the report at all.
  cause: the `CASE WHEN` could return, for example `92` as a `vehicle_id` and
  then `92` as an `account_id` and thus have them regrouped together.

- 2 lines of the report were sharing the same "line_id" (the id given by
  report framework id, see method `_build_line_id`) which are used in a
  t-key property in an OWL loop resulting in a crash for the front-end.

After the commit:
- The 2 lines are aggregated seperatly: The line without `vehicle_id` is under
  the hierarchy of the account and the line with `vehicle_id` is under the
  hierachy of the concerned vehicle.
- The line doesn't share any line_id anymore

task-id: None (issue discovered in our own prod)

## [IMP] account_reports: ensure line_id is uniq in tests

Moved to https://github.com/odoo/enterprise/pull/66216

Forward-Port-Of: odoo/enterprise#66462
Forward-Port-Of: odoo/enterprise#64166

Issue ===== When a GS1 barcode contains both a packaging and a weight, the quantity is wrong because we use the weight as the quantity and multiply it by the packaging quantity. How to reproduce ================ - Enable "Product Packagings" and "Units of Measure"; - Select GS1 nomenclature as the Barcode Nomenclature; - Create a product with a packaging for multiple quantity (e.g.: 4 Units) and with a valid GTIN (e.g.: 12345600012349); - In the Barcode app, create a new receipt;

Issue
=====

When a GS1 barcode contains both a packaging and a weight, the quantity is wrong because we use the weight as the quantity and multiply it by the packaging quantity.

How to reproduce
================

- Enable "Product Packagings" and "Units of Measure";
- Select GS1 nomenclature as the Barcode Nomenclature;
- Create a product with a packaging for multiple quantity (e.g.: 4 Units) and with a valid GTIN (e.g.: 12345600012349);
- In the Barcode app, create a new receipt;
- Scan a GS1 barcode containing both the packaging barcode and a weight (e.g.: 10123456000123493103001500) => The scanned weight is used as the quantity and is multiplied by the packaging quantity (in this example, the quantity will be 6, because 4 units x 1.5 kg = 6 units)

Expected Behavior
=================

Since the associated product uses Units as UoM, the scanned weight can't be converted into quantity (we can't convert g or kg into units), so this information should be ignored and the packaging quantity should be used alone instead.

Note that the packaging quantity will still multiply the scanned quantity if the share the same UoM category. This behavior is still supported to be able to scan multiple packagings at once. That said, this use case make sense for products using Units only.

[OPW-3988826](https://www.odoo.com/odoo/11258/tasks/3988826?cids=1)

Forward-Port-Of: odoo/enterprise#66375
Forward-Port-Of: odoo/enterprise#65073

Steps to reproduce: - create a spreadsheet document - insert an image in the spreadsheet - hit the Share button - open the link in an incognito window => the image is not displayed Task: 4037385 opw-4035835 Forward-Port-Of: odoo/enterprise#66427 Forward-Port-Of: odoo/enterprise#66152

Steps to reproduce:
- create a spreadsheet document
- insert an image in the spreadsheet
- hit the Share button
- open the link in an incognito window

=> the image is not displayed

Task: 4037385
opw-4035835

Forward-Port-Of: odoo/enterprise#66427
Forward-Port-Of: odoo/enterprise#66152

After this commit: Traceback will not occur when searching for tickets on the portal task-3959379 Forward-Port-Of: odoo/enterprise#63556

After this commit:
Traceback will not occur when searching for tickets on the portal

task-3959379

Forward-Port-Of: odoo/enterprise#63556

The Company Identification field was incorrectly formatted as a numeric field. It is specified as numeric by some banks [^1], but the official specification is alphanumeric [^2]. On top of that the alphanumeric Company Discretionary Data field was right-justified. A minority of banks don't handle this correctly. There's no official specification on how to align alphanumeric fields [^1]. The decision to left-justify is based on the following: - Chase specifies to left-justify them [^3]

The Company Identification field was incorrectly formatted as a numeric field. It is specified as numeric by some banks [^1], but the official specification is alphanumeric [^2].

On top of that the alphanumeric Company Discretionary Data field was right-justified. A minority of banks don't handle this correctly.

There's no official specification on how to align alphanumeric fields [^1]. The decision to left-justify is based on the following:

- Chase specifies to left-justify them [^3]
- The most extensive open-source ACH library left-justifies them [^4]
- Another Python ACH library left-justifies them too [^5]
- Online images of ACH files seem to left-justify them as well

The only two remaining fields that are right-justified with spaces ({:>...}) are Immediate Destination and Immediate Origin. This is on purpose. Although they are numeric fields and thus right aligned, they are specified to start with a blank space, not a leading 0 [^2].

[^1]: https://web.archive.org/web/20230624090124/https://files.nc.gov/ncosc/documents/eCommerce/bank_of_america_nacha_file_specs.pdf
[^2]: https://achdevguide.nacha.org/ach-file-overview
[^3]: https://www.chase.com/content/dam/chaseonline/en/demos/cbo/pdfs/cbo_nacha_filespecs.pdf
[^4]: https://github.com/moov-io/ach/blob/073d011f811605e1b6051792163159a55feca533/converters.go#L81-L94
[^5]: https://github.com/travishathaway/python-ach/blob/cc8b6448d75f3815c91d3b8a5dadd6731aa96e71/ach/data_types.py#L57-L76

opw-4033830

Forward-Port-Of: odoo/enterprise#66286