The website editor's snippets modal has been adjusted so it appears correctly for right-to-left languages. This improves usability for teams working in languages such as Arabic or Hebrew when building or editing website pages.

This commit adapts CSS code to correctly display the snippets modal for RTL languages.
The snippets modal was introduced in this commit [1].

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

task-4072655

The POS HR dashboard now checks point-of-sale activity instead of sales orders when deciding whether to show sample data. This prevents the dashboard from making the wrong decision based on unrelated sales information, improving accuracy for businesses using POS with HR data.

We recently added some model dependencies to determine if a dashboard should display its sample data if the database did not have enough information worth showing.

The pos_hr dashboard was depending on sale orders by mistake. It's supposed to depend on `pos.order` and to a certain extent `report.pos.order`.

Task-4220370

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

Fixes minor display issues in kanban cards where long titles or translated badge labels could cause amounts and footer details to overlap or appear misaligned. This improves readability and consistency for users working with expenses, sales orders, purchase orders, and POS orders.

This commit fixes small UI issues in expense, pos, purchase and sale kanban views, introduced by the conversion to the API [1][2][3][4]. They had similar issues. The amount displayed on the right of the title row sometimes overflowed, when the title was too long. And the left part of the footer was weirdly displayed when the label of the badge displayed next to it was too long (which might easily happen with translations).

[1] https://github.com/odoo/odoo/pull/171214
[2] https://github.com/odoo/odoo/pull/173466
[3] https://github.com/odoo/odoo/pull/174308
[4] https://github.com/odoo/odoo/pull/174134

Task~4215979

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

This update corrects visual layout issues in kanban cards after the recent kanban view update. Project, task, and timesheet cards should now display more consistently, improving readability for users managing work and time entries.

Task 4215979

This update restores the correct layout for the e-learning Courses kanban view after a recent technical change. It helps users browse and manage course cards with the expected visual structure, including when sales-related course features are installed.

This commit fixes the layout of the Courses (e-learning) kanban view, following the conversion to the new kanban API [1]

[1] https://github.com/odoo/odoo/pull/180256

Task~4215979

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

The website editor toolbar now shows the correct name for each selected font style, including Header 1. This prevents confusion when users format content and helps ensure the chosen style is clearly reflected in the dropdown.

Before this commit:

Selecting header 1 in the font dropdown will show header 1 display 1 which is wrong. They are 2 different fonts.

After this commit: Now every selected font show its corresponding name.

Added a test to check the flow for all possible fonts.

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

Spreadsheet list views now keep boolean values as true or false instead of turning them into text. This prevents formulas and evaluations from misreading checkbox-style data, improving accuracy in spreadsheet-based reporting.

The method returning a list field value based on its type did not properly handle the boolean fields. It would return the string "TRUE" and "FALSE" which are interpreted as strings by the evaluation process.

task-4182574

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

This fix makes table column changes in the HTML editor properly recorded in the editing history. Users can now undo or redo adding, moving, or deleting table columns, reducing frustration and accidental content loss.

Before this commit, adding / moving / deleting a table column does not add a step. It is therefore not possible to undo/redo.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

This update fixes an automated website shop test so it more accurately confirms product variant selections inside a modal window. It helps reduce false test failures and supports smoother quality checks for the online checkout experience.

In this commit, we remove unuseful click action, we use check action instead of click (to ensure the input is checked after clicking on it) and we precise some step trigger by adding .modal to check the element is well in a modal before proceed to checkout (in the tour).

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

eCommerce category images uploaded in the backend are now automatically converted to WebP. This helps reduce image file sizes and can improve storefront loading performance without changing the user's workflow.

A new option to convert images to webp was added in 1a978183001e0503104285f4bd5bed983beb0efb. This commit adds this option to eCommerce categories' form view image field so categories images uploaded from the backend benefit from webp improvements too.

This fixes leftover view definitions so repair manufacturing and website collection settings use the current list format consistently. It helps prevent configuration or display issues caused by older view naming during upgrades or use of these screens.

before this commit, few tree tags are left over without changing into list tag in this commit: https://github.com/odoo/odoo/commit/4ca79b1549eec988a31b80aa0e9f03e6420e84df#diff-e8da39382dbb141dfbfcec84a5a4365734015a25cd3ed94004f7eb7daa7e7ab0R12

after this commit, all tree tag will be converted into list tag

Related EE: https://github.com/odoo/enterprise/pull/71002

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

The editor now recognizes inserted media, such as document icons, as real content instead of treating the paragraph as empty. This prevents placeholder hints like “Type here” or command prompts from appearing on top of media, improving the editing experience.

Steps:
1. In an empty editable, insert a document with /image -> Documents
2. Move the cursor to before or after the document icon.

-> The 'Type "/" for commands' hint is displayed over the icon.

3. Now click outside the editable.

-> The "Type here" hint is displayed over the icon.

Both hints display are undesirable, as the content of the first (and only) paragraph is not empty.

This commit makes sure media elements are considered as visible content when checking if a block is empty.

This fixes a small usability issue in the HTML editor where hovering over the disabled remove formatting button did not show its explanatory tooltip. Users now get clearer feedback about the unavailable action, while the button still looks and behaves disabled.

Issue:
======
hover over remove format button when disabled
doesn't show tooltip.

Origin of the issue:
====================
Since the disabled button will have the class .disabled which will add
`pointer-events:none` to the button so when hovering nothing happens.

Solution:
=========
- Add `pointer-events:auto` to show the tooltip on hover.
- Add `cursor:auto` to show the usual cursor and not the pointer when
  hover.
- Style the `.disabled:active` button the same as the `.disabled` so
  that clicking on the button doesn't change the style which gives the
  impressions that something happened.

This fix stops users from dragging selected table cells out of a table in the HTML editor, which previously could cause an error. It improves editing stability by preventing an unsupported action that led to a crash.

Before this commit: in a table, select last two cells of first row and
drag drop it to a p element out of the table, a traceback is raised

After this commit: the dragging on the table cells is disabled



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

This fix makes a banner editor test run consistently by ensuring needed resources are loaded before the test action continues. It reduces random test failures, helping keep development and release checks more dependable without changing customer-facing behavior.

This commits fix an indeterministic test error. The indeterministic error was made by a getBundle triggered by a click, the solution is get the bundle ourself and await it.

This fixes an issue where website test helpers could fail when used outside a full HTTP test environment. The change makes tests fall back to the configured web port when no running server is available, improving reliability for internal testing without affecting normal users.

`MockRequest` calls `HttpCase.base_url()` even though it can be used outside of http cases. odoo/odoo#180461 made consistency a requirement as it retrieves the actually bound port from a running server.

Make `http_port()` return `None` if no server is running (rather than error), and have `MockRequest` fallback on ~the old behaviour (of just retrieving the http_port from the config) in that case. Technically we could probably hardcode `8069` to limit e.g. issues when running with `http_port=0`, but odds are none of that is really relevant.

Duplicating embedded actions now avoids saving two conflicting action targets at the same time. This prevents errors for users when copying embedded actions that use a predefined Python method.

Before this commit, when the user tries to duplicate a embedded action containing the field `python_method` set, the `action_id` should not given otherwise an error will be raised because the `check_only_one_action_defined` constraint will not be respected because we will have 2 actions to call for a same embedded action.

This commit makes sure the `action_id` field is not set if `python_method` is given.

task-4191101

When staff book a restaurant table and return to the floor plan, the table now correctly appears as occupied. This helps avoid seating confusion and gives staff an accurate view of table availability.

Before this commit:
===
- After booking a table and returning to the floor plan, the table was not marked as full.

After this commit:
===
- After booking a table and returning to the floor plan, the table is now correctly marked as full.

Task-4210770

Deleting some Point of Sale demo orders could fail because related order lines and payments were missing default identifiers. This fix adds default UUID values so demo POS records can be removed cleanly, improving reliability for testing and demonstrations.

In this commit:
=================
Fix traceback when deleting demo records in POS.
When deleting some demo orders in the POS, a traceback was
raised because the lines of the orders did not had an order
linked to it. This was because they did not have an uuid.
We now have default uuid values for orders, order lines and
pos payments.

Task: 4212901

Related: https://github.com/odoo/enterprise/pull/70925

Duplicating a bill no longer carries over payments matched to the original bill. This prevents the same payment from appearing linked to both the original and copied bill, reducing accounting confusion.

The matched_payment_ids field value is being copied when duplicating a bill. This causes the payment from the original bill to get linked to the new bill as well, which is unexpected.

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

This fixes an issue in the HTML editor where creating a table in an empty column could show repeated column hints in every table cell. The hint now appears only in the intended first paragraph, making the editing experience cleaner and less confusing.

Before this commit: creating a table in an empty column, all the table cells have the column hint

After this commit: only the first p node under the col div has the column hint



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

The replenishment view now keeps the horizon value selected by the user when they leave and return to the view. This prevents repeated manual re-entry and makes stock planning workflows more consistent.

To reproduce:
- Open replenishment view
- Change horizon value in the panel to 5
- Open any other view and reopen replenishment view

Current behavior:
Horizon is reset back to 0.

Expected behavior:
Horizon will remember the last value (5 in this example).

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

Several website building blocks now use the correct grid settings, so their layouts display more consistently across screen sizes. This helps pages built with these snippets look as intended and reduces manual layout adjustments for website editors.

Website building blocks with multiple buttons now display with proper spacing on smaller screens. This prevents buttons from appearing cramped or misaligned, improving the mobile presentation of affected website sections.

This commit introduces a fix for the snippets that include at least two
buttons in their layout.

Prior to this commit, the buttons were simply defined within the `<p>`
tag, due to a lack of testing corner case scenarios. This implementation
was actually wrong, because as soon as you add `n+1` button within the
editor, it'll apply a `mb-2` on each button to space them correctly on
smaller devices.

To fix this issue, we simply replicate the behaviour of the editor by
adding the class on the snippets that match this scenario.

task-4210852
part of task-4077427

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

This fix adjusts several website building blocks so their grid layouts use the right row, column, and spacing settings. It helps pages built from these snippets display more consistently and avoids layout issues for website editors and visitors.

This commit fixes several issues related toin grid options:
- `s_cta_mockups`: wrong column count
- `s_image_punchy`: wrong row count and column count
- `s_numbers_grid`: `g-col-md-3` was used instead of `g-col-lg-3`
- `s_sidegrid`: distinct sizes were used for `g-col-lg` and `col-lg`
                padding classes were used

task-4213996

This update ensures copied databases with the Monster recruitment integration are neutralized so they do not contact external systems or affect live customer data. It helps support teams investigate issues on database duplicates safely without risking unintended changes in production-related services.

This commit adds the missing neutralization necessary for the
hr_recruitment_integration_monster module introduced in [1]

The purpose of the standard neutralization framework is to allow us to
create database copies that will not interact with external systems in
ways that could impact the production database (or if it is not possible
to prevent the interactions, make sure that they are benign or won't
result in actual changes), or impact the customers of the operator of
the production database.

This is mainly useful to allow safe support investigation on database
duplicates.

[1] https://github.com/odoo/enterprise/pull/70213

This fix updates the Knowledge migration so embedded file links keep their access information after a field name change. It helps ensure existing Knowledge articles with embedded files continue to work correctly after upgrading.

Purpose:
--------
In commit [1], the field holding the access token inside the file model has been renamed from accessToken to access_token.

This commit adds the renaming of the related accessToken prop of the embedded file component during the migration of the file behavior.

[1]: https://github.com/odoo/odoo/commit/448c9791dd1980d1aa3c244a9f85828424c7e10b

Task-4221554

This change adds test coverage for inter-company purchase and sales flows where goods are delivered before the related purchase order is confirmed. It helps ensure reservations work correctly through inter-company transit locations, reducing the risk of stock flow errors between companies.

In the community-side, we allow the reservation on all transit locations (i.e. Inter-Company transit as well).
Adds a test where an interco PO is generated in draft then confirmed after the delivery was done in the other company, as it can now reserve on the already delivered quantities.

Task-4207078

Attachments added to Knowledge comments now display at the proper size without awkward scrollbars or cramped layouts. This keeps comment threads easier to read while avoiding broader styling changes that affected the comment appearance.

This commit aims at fixing an issue with message containing attachments. Those attachments can be displayed too small resulting in scrollbars and weird displays.

In e8df9ed4a92e we tried to fix this by using the environment variable inChatWindow, but this changed the styling of comments drastically. So in this commit we remove this option and directly apply the correct style to the attachment cards.

task-4221276

The payroll test suite now uses a fixed date instead of a date based on the current day. This prevents occasional test failures caused by changing calendar dates, helping keep payroll quality checks stable.

Before this commit, the test `test_ytd_02_reset_date` was using a date relative to today's date; however this can bring errors. This commit sets a fixed date for the test in order to avoid that.

The purchase manufacturing work order quality module can now be installed with demo data without hitting an employee-link error. This prevents setup interruptions caused by the system installation user not being tied to an employee record.

Installing this module with demo data gives an error "You need to link this user to an employee of this company to process the work order"
As the installation user is "__system__" there is no linked employee.

This update keeps Uruguay electronic invoicing screens compatible with the latest Odoo view naming rules. It prevents affected list-style pages from failing to load after the platform stopped accepting the older view name.

Since odoo/odoo#159909 we no longer accept `tree` as a synonym for `list` views.

This fixes layout issues in Kanban views used for field service, projects, helpdesk timesheets, and timesheet grids. Users should see cleaner, more consistent task and timesheet cards, making daily work easier to scan and manage.

Task~4215979

This fixes payroll contract setup so worker compensation is only required when the contract is with a US company. It prevents unnecessary validation blockers for non-US companies and reduces confusion during HR contract management.

The worker compensation could be required even though the contract is not with a
 US company.

Minor visual issues in the Helpdesk team dashboard have been corrected after a recent interface update. This helps teams view their dashboard cards and information more consistently without changing business workflows.

This commit fixes small UI issues introduced by the conversion of kanban archs to the new API [1], in the helpdesk team dashboards.

[1] https://github.com/odoo/enterprise/pull/70127

Task~4215979

This fix completes a technical naming update by replacing remaining outdated view tags with the current list format. It helps keep these modules aligned with the latest Odoo standards and reduces the risk of display or compatibility issues.

*documents_account, documents_hr_recruitment,
l10_in_hr_payroll,l10n_uy_edi

before this commit, few tree tags are left over without changing into list tag in this commit: 4ca79b1#diff-e8da39382dbb141dfbfcec84a5a4365734015a25cd3ed94004f7eb7daa7e7ab0R12

after this commit, all tree tag will be converted 'into list tag

The loan management test has been updated to use fixed dates, preventing failures caused by the date when the test is run. This helps keep automated checks stable and reduces false alarms during development.

`test_loan_import_amortization_schedule` was failing because of a missing `freeze_time` which has now been added along with hard-coded dates instead of relative dates which are more prone to errors.

runbot errors: 100079 100342

The automated test for preparation displays has been corrected so it reflects a real point-of-sale order flow. This helps prevent false confidence in testing and improves reliability for restaurant and preparation display workflows.

This commit fix a test that was not testing a real flow due to a lack of uuid on the order lines. It is now re-written.

Community PR: https://github.com/odoo/odoo/pull/180731

The update rewrites preparation display tests so they better reflect real point-of-sale order flows. This helps prevent false confidence from tests that previously missed important order line details, reducing the risk of future issues reaching restaurant workflows.

This commit fix a test that was not testing a real flow due to a lack of uuid on the order lines. It is now re-written.

Related: https://github.com/odoo/odoo/pull/181858

Opening unpinned document folders now keeps them under the Company section, so users see expected navigation and management options. This restores items like breadcrumbs and the settings menu, making folder browsing more consistent and easier to use.

When you double-click on an unpinned folder, like "Support", to inspect its content, you notice the absence of some important tools in the UI: the cogwheel menu, a proper breadcrumb...

Parenting the unpinned folders to the "Company" section solves the issues.

task-4216195

This update removes an obsolete receipt reprint screen from the Point of Sale module. It has no expected impact on daily use, but helps keep the system cleaner and easier to maintain.

In this commit we remove the `ReprintReceiptScreen` component, which became unused in 405d90981ed734e1ca0f6ead07e25a1f9811ba6e

Task 4204436



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

The partner autocomplete app will no longer be installed automatically as part of other setup flows. This gives businesses more control over whether to enable the feature and avoids adding it unless it is explicitly needed.

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

Before this commit, in a scenario with multiple ongoing orders in a restaurant, attempting to invoice one of the orders could lead to an error. This was due to the fact that syncOrderResult[0] might correspond to a draft order. This commit addresses the issue by using the currentOrder, which is updated upon receiving data from the server, ensuring the correct order is invoiced. opw-4189363 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Po

Before this commit, in a scenario with multiple ongoing orders in a restaurant, attempting to invoice one of the orders could lead to an error. This was due to the fact that syncOrderResult[0] might correspond to a draft order. This commit addresses the issue by using the currentOrder, which is updated upon receiving data from the server, ensuring the correct order is invoiced.

opw-4189363

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

Forward-Port-Of: odoo/odoo#182107

Versions -------- - saas-17.4+ Steps ----- 1. Create an invoice; 2. enter a product; 3. hit enter to add a label; 4. hit enter to add newlines to the label; 5. confirm. Issue ----- On Firefox, the added newlines don't show in the invoice lines tab, but do show in the journal items tabs. On Chrome, they show in the journal items tab, as well as invoice lines tab until they become uneditable by confirming the invoice. Cause ----- Bootstrap's `text-wrap` class added in 4f325

Versions
--------
- saas-17.4+

Steps
-----
1. Create an invoice;
2. enter a product;
3. hit enter to add a label;
4. hit enter to add newlines to the label;
5. confirm.

Issue
-----
On Firefox, the added newlines don't show in the invoice lines tab, but do show in the journal items tabs.

On Chrome, they show in the journal items tab, as well as invoice lines tab until they become uneditable by confirming the invoice.

Cause
-----
Bootstrap's `text-wrap` class added in 4f325ef62026 collapses sequential whitespace into a single space, wrapping text if necessary.

For `input` and `div` elements, this makes sense.

For `textarea`, wrapping is standard, and unlike `input`, it allows pressing Enter to start a new line, but because of `text-wrap`, these get collapsed into a single space, making it difficult for the user to see the actual layout of what they're editing.

Solution
--------
Remove the `text-wrap` class from `textarea` elements to keep line breaks visible regardless of invoice state.

opw-4126094

Forward-Port-Of: odoo/odoo#180488

Before this commit, when only one payment method was available, an additional payment line with a value of zero would be automatically added, even if a payment line already existed. opw-4186191 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181863

Before this commit, when only one payment method was available, an additional payment line with a value of zero would be automatically added, even if a payment line already existed.

opw-4186191

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

Forward-Port-Of: odoo/odoo#181863

* Before this commit: the monetary value is always fix with 2 decimal and no thousand separator at all like 1000000 instead of 1.000.000 * After this commit correctly display thousand separator and of course the decimal and currency symbol simply using formatMonetary method 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

* Before this commit: the monetary value is always fix with 2 decimal and no thousand separator at all like 1000000 instead of 1.000.000
* After this commit correctly display thousand separator and of course the decimal and currency symbol simply using formatMonetary method

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#181917
Forward-Port-Of: odoo/odoo#180388

When there are multiple missing records for the same relation across different models, only one was being retained. This fix ensures that missing records are merged correctly and no data is overwritten, preventing potential data loss during recursive loading. opw-4183904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181671

When there are multiple missing records for the same relation across different models, only one was being retained. This fix ensures that missing records are merged correctly and no data is overwritten, preventing potential data loss during recursive loading.

opw-4183904

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

Forward-Port-Of: odoo/odoo#181671

Steps: --------- - Install the Point of Sale module with demo data. - Set up online payment provider (e.g. Razorpay) for the Indian company. - Enable online payment method in Point of sale app configuration - Add the payment method in Point of sale shop configuration. - Make a successful online payment in the Point of sale app. Issue: --------- - Error occurs after successful payment, preventing the payment from being processed and confirmed in POS module and the payment entry from

Steps:
---------
- Install the Point of Sale module with demo data.
- Set up online payment provider (e.g. Razorpay) for the Indian company.
- Enable online payment method in Point of sale app configuration
- Add the payment method in Point of sale shop configuration.
- Make a successful online payment in the Point of sale app.

Issue:
---------
- Error occurs after successful payment, preventing the payment from being
  processed and confirmed in POS module and the payment entry from being posted.

Cause:
---------
- Payment transactions status were failing due to company mismatch between the
  partner(admin)'s company and the pos order's company.

FIX:
---------
- If customer is not selected in pos order, we consider the order and payment
  from public user not from the admin user.

Improvement:
---------
- env is not accessible with self in controller for self.env.ref('base.public_user')
  fixed with request.env.ref('base.public_user')
- Unused code removed from `_get_partner_sudo` method

task-3989409

Forward-Port-Of: odoo/odoo#173268

Before this commit, adding the same attribute to multiple products caused the attribute values to appear multiple times in the mobile/kiosk. Moreover, attributes with the variant creation mode were incorrectly displayed as configurable options, despite being intended to represent separate products and not to be shown as options for configuration. opw-4163858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179529

Before this commit, adding the same attribute to multiple products caused the attribute values to appear multiple times in the mobile/kiosk. Moreover, attributes with the variant creation mode were incorrectly displayed as configurable options, despite being intended to represent separate products and not to be shown as options for configuration.

opw-4163858

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

Forward-Port-Of: odoo/odoo#179529

In systems with a non-English locale (e.g., "ar-001"), the `date_order` field could not be parsed correctly, leading to improper sorting of paid orders. opw-4181429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181894

In systems with a non-English locale (e.g., "ar-001"), the `date_order` field could not be parsed correctly, leading to improper sorting of paid orders.

opw-4181429

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

Forward-Port-Of: odoo/odoo#181894

Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.4.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182059

Update the OWL lib.

Release notes:
https://github.com/odoo/owl/releases/tag/v2.4.0

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

Forward-Port-Of: odoo/odoo#182059

- one2many field: * On a dirty form view with an one2many filed; * Click the one2many field; * Open load more; * Create a new record; * Change the visibility (change tab on the browser). Before this commit, the form view will save and close the load more and the new record dialog. - many2many field: * On a new record form view with a many2many field; * Click the `add` button on the kanban of the many2many field; * Complete the dialog form view; * Change the visibility;

- one2many field:
 * On a dirty form view with an one2many filed;
 * Click the one2many field;
 * Open load more;
 * Create a new record;
 * Change the visibility (change tab on the browser).

 Before this commit, the form view will save and close the load more and
 the new record dialog.

- many2many field:
 * On a new record form view with a many2many field;
 * Click the `add` button on the kanban of the many2many field;
 * Complete the dialog form view;
 * Change the visibility;
 * Save the dialog form view.

 Before this commit, because when changing the visibility, the
 background form view will save the new record, and the dialog form view
 (the one opened when clicking the button `add`) will lose the
 references to it's parent record.

- settings:
 * Open the settings view;
 * Made a change on a setting;
 * Change visibility.

 Before this commit, the settings will be saved without calling the
 `execute` function. Furthermore, settings should never be saved if it's
 not an implicit action from the user.

The autosave feature really doesn't make sense in any of these cases.

opw-[4141005](https://www.odoo.com/web#id=4141005&view_type=form&model=project.task)
opw-[4143092](https://www.odoo.com/web#id=4143092&view_type=form&model=project.task)
opw-[4177698](https://www.odoo.com/web#id=4177698&view_type=form&model=project.task)
opw-[4151462](https://www.odoo.com/web#id=4151462&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#181220

Suppose the following structure: ---------------------------------------------- BoM of Main kit: - BoM Type: Kit - Quantity: 4 - Components: * 1 x Sub kit A * 1 x Sub kit B BoM of Subkit A: - BoM Type: Kit - Quantity: 1 - Components: * 2 x Component A (Cost: $10, Storable) BoM of Subkit B: - BoM Type: Kit - Quantity: 1 - Components: * 2 x Component B (Cost: $6, Storable) When creating a sale order for 1 Main Kit, delivering the components

Suppose the following structure:
----------------------------------------------
BoM of Main kit:
  - BoM Type: Kit
  - Quantity: 4
  - Components:
    * 1 x Sub kit A
    * 1 x Sub kit B

BoM of Subkit A:
  - BoM Type: Kit
  - Quantity: 1
  - Components:
    * 2 x Component A (Cost: $10, Storable)

BoM of Subkit B:
  - BoM Type: Kit
  - Quantity: 1
  - Components:
    * 2 x Component B (Cost: $6, Storable)

When creating a sale order for 1 Main Kit, delivering the components and posting the invoice, the Cost Of Goods Sold computed by the _stock_account_get_anglo_saxon_price_unit method was ignoring the COGS for the Subkit B.
This is due to the commit https://github.com/odoo/odoo/commit/31e1352df686d8a23628ade83d321929c49d6f4e which fetches the BOMs from the stock moves linked to the Sale Order. As no component is present directly in the bom lines of the Main Kit BOM, the bom was omitted.

Now, if the product's bom is not present in the stock move's bom, we'll fetch one the old way.

opw-4033293

Forward-Port-Of: odoo/odoo#179206
Forward-Port-Of: odoo/odoo#174853

Button to close conversation and start a call are too small and close to each other. This means attempt to close the conversation can lead to accidentally starting a call, which scare all members of the conversation. This commit increases the size of these buttons and show borders so that it is less likely to click on start a call when the intent is to close the conversation. Before / After <img width="365" alt="Screenshot 2024-09-29 at 22 22 17" src="https://github.com/user-attachments/a

Button to close conversation and start a call are too small and close to each other. This means attempt to close the conversation can lead to accidentally starting a call, which scare all members of the conversation.

This commit increases the size of these buttons and show borders so that it is less likely to click on start a call when the intent is to close the conversation.

Before / After
<img width="365" alt="Screenshot 2024-09-29 at 22 22 17" src="https://github.com/user-attachments/assets/7781eb6f-20e4-4ef2-ac0a-be50b39869ee">
<img width="366" alt="Screenshot 2024-09-29 at 22 21 56" src="https://github.com/user-attachments/assets/eede8d9c-891a-4cda-8dca-853b155ed6c3">

Forward-Port-Of: odoo/odoo#182017

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

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

Since https://github.com/odoo/odoo/pull/121963, there are tooltips on search panel items when the user hovers them. However, it is not very convenient since the user needs to hover precisely the span which contains the item name for the tooltip to pop up. This commit simply moves up the data-tooltip attribute in the elements hierarchy so that it will show for the whole button instead of only the title. This also fixes a bug with the tooltip position in the charts of account search panel as a sid

Since https://github.com/odoo/odoo/pull/121963, there are tooltips on search panel items when the user hovers them. However, it is not very convenient since the user needs to hover precisely the span which contains the item name for the tooltip to pop up. This commit simply moves up the data-tooltip attribute in the elements hierarchy so that it will show for the whole button instead of only the title. This also fixes a bug with the tooltip position in the charts of account search panel as a side effect.

task-3917084

Forward-Port-Of: odoo/odoo#181721
Forward-Port-Of: odoo/odoo#180776

Before: All event from last year to the next 2 years were fetched. This might cause timeout depending on the amount of events. After this commit: Reuse the system parameter to allow limiting to a set value Note: This does not need to be done on google as the fetch limit is already present, see: https://github.com/odoo/odoo/pull/66250/files#diff-f1bbd37c3355f798d3f2d89ccc00c778aa4faa4c6709b6d66cc9650ad0d553b6 opw-4077113 Forward-Port-Of: odoo/odoo#181613

Before:
All event from last year to the next 2 years were fetched. This might cause timeout depending on the amount of events.

After this commit:
Reuse the system parameter to allow limiting to a set value

Note: This does not need to be done on google as the fetch limit is already present, see:
https://github.com/odoo/odoo/pull/66250/files#diff-f1bbd37c3355f798d3f2d89ccc00c778aa4faa4c6709b6d66cc9650ad0d553b6

opw-4077113

Forward-Port-Of: odoo/odoo#181613

### Steps to reproduce: - Create a project - Create a task in this project and add a subtask for this task - Navigate to the kanban view for projects - Notice that the count of tasks shows 2 but you will just see only one task when clicking on this project ### Current behavior before PR: This is happening because when calculating the count of tasks we are just considering the tasks that has that project_id without checking anything else. https://github.com/odoo/odoo/blob/17.0/addo

### Steps to reproduce:
	- Create a project
	- Create a task in this project and add a subtask for this task
	- Navigate to the kanban view for projects
	- Notice that the count of tasks shows 2 but you will just see only one task when clicking on this project

### Current behavior before PR:
This is happening because when calculating the count of tasks we are just considering the tasks that has that project_id without checking anything else.

https://github.com/odoo/odoo/blob/17.0/addons/project/models/project_project.py#L56:L62

But when showing the tasks we are just showing the main tasks not the sub-tasks.

### Desired behavior after PR is merged:
We are now checking if this task should be displayed or not and if it won't be displayed we don't count it.

This is a backport of [commit](https://github.com/odoo/odoo/pull/160476/commits/1fc1f6f54ebadcda1ef090e1f73a05be85373c03)

opw-4201309

Forward-Port-Of: odoo/odoo#181892
Forward-Port-Of: odoo/odoo#181410

Instead of only allowing selection by limited account type, the system allows selection by group. 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#181370 Forward-Port-Of: odoo/odoo#181327

Instead of only allowing selection by limited account type, the system allows selection by group.

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#181370
Forward-Port-Of: odoo/odoo#181327

Load taxes in an end script when all modules are loaded ``` Traceback (most recent call last): File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1313, in preload_registries registry = Registry.new(dbname, update_module=update_module) File "<decorator-gen-16>", line 2, in new File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked return func(inst, *args, **kwargs) File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 114, in new o

Load taxes in an end script when all modules are loaded

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1313, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-16>", line 2, in new
  File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 114, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 476, in load_modules
    processed_modules += load_marked_modules(env, graph,
  File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 364, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 232, in load_module_graph
    migrations.migrate_module(package, 'post')
  File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 240, in migrate_module
    migrate(self.cr, installed_version)
  File "/home/odoo/src/odoo/17.0/addons/l10n_uk/migrations/1.1/post-migrate.py", line 7, in migrate
    env['account.chart.template'].try_loading('uk', company)
  File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 153, in try_loading
    return self._load(template_code, company, install_demo)
  File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 212, in _load
    self._post_load_data(template_code, company, template_data)
  File "/home/odoo/src/odoo/17.0/addons/l10n_uk/models/template_uk.py", line 38, in _post_load_data
    result = super()._post_load_data(template_code, company, template_data)
  File "/home/odoo/src/enterprise/17.0/account_reports/models/chart_template.py", line 31, in _post_load_data
    company._get_and_update_tax_closing_moves(fields.Date.today(), include_domestic=True)
  File "/home/odoo/src/enterprise/17.0/account_reports/models/res_company.py", line 163, in _get_and_update_tax_closing_moves
    report, tax_closing_options = tax_closing_move._get_report_options_from_tax_closing_entry()
  File "/home/odoo/src/enterprise/17.0/account_reports/models/account_move.py", line 264, in _get_report_options_from_tax_closing_entry
    report_options = tax_report.with_context(allowed_company_ids=company_ids).get_options(previous_options=options)
  File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 1670, in get_options
    initializer(options, previous_options=previous_options)
  File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 1619, in _init_options_custom
    self.env[custom_handler_model]._custom_options_initializer(self, options, previous_options)
  File "/home/odoo/src/odoo/17.0/odoo/api.py", line 534, in __getitem__
    return self.registry[model_name](self, (), ())
  File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 213, in __getitem__
    return self.models[model_name]
KeyError: 'l10n_uk.tax.report.handler'
```

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

Currently, we only check delivered quantities in a Sale Order based on the `usage` of the destination location of the related delivery. This means that in the case of Inter-company transactions, we won't consider them as deliveries, as its delivery location will be 'Inter-Company Transit', which itself is a 'transit' location. Test in odoo/enterprise#70663 Task-4207132 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1

Currently, we only check delivered quantities in a Sale Order based on the `usage` of the destination location of the related delivery. This means that in the case of Inter-company transactions, we won't consider them as deliveries, as its delivery location will be 'Inter-Company Transit', which itself is a 'transit' location.

Test in odoo/enterprise#70663

Task-4207132

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

Forward-Port-Of: odoo/odoo#181857
Forward-Port-Of: odoo/odoo#181412

This commit removes unnecessary whitespace in the localization files. No functional changes have been introduced, only whitespace adjustments. #169577 Forward-Port-Of: odoo/odoo#181767 Forward-Port-Of: odoo/odoo#179975

This commit removes unnecessary whitespace in the localization files.

No functional changes have been introduced, only whitespace adjustments.

#169577

Forward-Port-Of: odoo/odoo#181767
Forward-Port-Of: odoo/odoo#179975

Issue: ===== Written html code inside the forum post gets rendered in the readonly view. Steps to reproduce the issue: ============================= - Create a new forum post - Write `<p>abc</p>` - Save - The `p` element disappears (it got rendered, you can check it by inspecting the element). Origin of the issue and solution: ================================= Let's first name the `p` element added by the editor as `pe` to differenciate between them. The issue is divided

Issue:
=====
Written html code inside the forum post gets rendered in the readonly
view.

Steps to reproduce the issue:
=============================
- Create a new forum post
- Write `<p>abc</p>`
- Save
- The `p` element disappears (it got rendered, you can check it by
  inspecting the element).

Origin of the issue and solution:
=================================

Let's first name the `p` element added by the editor as `pe` to
differenciate between them.

The issue is divided into 2 subproblems:

- We need to save the correct value: currently if we have written in the
  editor `<p>abc</p>`, it will save the value `<pe><p>abc</p></pe>`
  which means that the two `p` element will be handled the same either
  both will appear as a string in the readonly view or will be rendered
  which is not right. To solve the issue, we need to override the
  `value` of the text area and not the html before the submit. By
  doing this the textarea.value will be equal to
  `<pe>&lt;p&gt;abcdef&lt;/p&gt;</pe>` which is the correct value.

- Now the second problem is when we edit the post , it will render again
  the `p` element that we wrote. The fetched template actually have the
  correct value inside the textarea, but seems like the browser when
  rendering it, it will convert the value to `<pe><p>abd</p></pe>` which
  is not right, and if we use textarea.html it will encode the `<pe>`
  element which is wrong too. To get the original value, we fetch if
  again and use it in the options of the wysiwyg.

  opw-4148163

Forward-Port-Of: odoo/odoo#181626
Forward-Port-Of: odoo/odoo#179854

The task description of a task generated after receiving an email from an email alias should be the body of the email (from the message thread). We differentiate this case from the case where the task is generated in another way (e.g. manually or triggered by another module), in which we should not populate the task description. related-https://github.com/odoo/odoo/pull/108360 task-4207145 version-16.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/subm

The task description of a task generated after receiving an email from an email alias should be the body of the email (from the message thread). We differentiate this case from the case where the task is generated in another way (e.g. manually or triggered by another module), in which we should not populate the task description.

related-https://github.com/odoo/odoo/pull/108360

task-4207145
version-16.0

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

Forward-Port-Of: odoo/odoo#181806
Forward-Port-Of: odoo/odoo#181572

Prevent tip product from being taxed rb error: 76973, 76972, 77055, 77054 Forward-Port-Of: odoo/odoo#181771

Prevent tip product from being taxed

rb error: 76973, 76972, 77055, 77054

Forward-Port-Of: odoo/odoo#181771

While the requirements contain `geoip2`, it's used as an optional dependency e.g. `http.py` imports it conditionally and as long as `request.geoip` is not accessed it causes no trouble. However `website` does exactly this right in the `_frontend_pre_dispatch`, it's technically conditional but the conditions are: - a frontend page (not an explicit route and not an attachment) - no tz in the context (which is very likely for new frontend session) Forward-Port-Of: odoo/odoo#176617

While the requirements contain `geoip2`, it's used as an optional dependency e.g. `http.py` imports it conditionally and as long as `request.geoip` is not accessed it causes no trouble.

However `website` does exactly this right in the `_frontend_pre_dispatch`, it's technically conditional but the conditions are:

- a frontend page (not an explicit route and not an attachment)
- no tz in the context (which is very likely for new frontend session)

Forward-Port-Of: odoo/odoo#176617

# Context: The `create` method in the `mail.alias.domain` model currently tries to make the created alias domain record the default for all companies and `mail.alias` records if it's the first of it's kind to be created. But in it's current form it fails to accound for grandfathered databases (pre 17.0) or miss confgurations by a user, where we have archived companies attached to `mail.alias` where the `alias_domain_id` field is False. In such a edge case, it is impossible to create a a

# Context:

The `create` method in the `mail.alias.domain` model currently tries to make the created alias domain record the default for all companies and `mail.alias` records if it's the first of it's kind to be created.

But in it's current form it fails to accound for grandfathered databases (pre 17.0) or miss confgurations by a user, where we have archived companies attached to `mail.alias` where the `alias_domain_id` field is False.

In such a edge case, it is impossible to create a alias domain record, because during the save (create), the user is faced with a Validation Error produce by the checks in the `_check_alias_domain_id_mc` in the `mail.alias` model.

Example error message:
```
"We could not create alias archived-company-alias@example.com because
domain example.com belongs to company ActiveCompany while the owner
document belongs to company ArchivedCompany."
```

It follow that the user is blocked from setting up an alias domain unless they temporarily unarchive a company.

# Proposed solution:

Assuming that the objective is to initialize all current mail aliases in the DB with the "first" alias domain record to be created, we should force the `company_ids` field in the just created `mail_alias_domain` record to contain ALL companies (active or not).

# Reproduction steps:

One way to reproduce the issue on a fresh DB is:
- install mail
- define a domain alias in the general settings
- create a second company
- install Accounting
- make sure a localization pack is loaded for each company (the idea is to create default sale and purchase accounting journals with their email alias)
- archive second company
- in Technical > Aliases menu, clear alias domain from aliases (set `alias_domain_id` = False)
- delete alias domain
- create a new alias domain

--> Validation Error

OPW-3955936

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

Forward-Port-Of: odoo/odoo#169613

Steps to reproduce: - (16.0 only) Project > Configuration > Settings > Enable 'Sub-tasks' - Project > New > Add 2 Stages and a Task - Click the task > Sub-tasks tab > Create a subtask - Go back to the project's task view - Delete the 2nd stage The sub-tasks are now visbile when they should not be. This is because we reload the view after stage deletion, with an action that does not contain display_project_id (16.0) / display_in_project (>= 17.0) in its domain. opw-4191732 --- I co

Steps to reproduce:
- (16.0 only) Project > Configuration > Settings > Enable 'Sub-tasks'
- Project > New > Add 2 Stages and a Task
- Click the task > Sub-tasks tab > Create a subtask
- Go back to the project's task view
- Delete the 2nd stage

The sub-tasks are now visbile when they should not be. This is because we reload the view after stage deletion, with an action that does not contain display_project_id (16.0) / display_in_project (>= 17.0) in its domain.

opw-4191732

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

Forward-Port-Of: odoo/odoo#181789
Forward-Port-Of: odoo/odoo#180753

# Context: A pesky bug has been flying under the radar since at least Odoo 15.0. When passing `email_from=False` to the _find_mail_server, we will always have an early return at: https://github.com/odoo/odoo/blob/f05626e14264cf3bb477c86ad82439726d778c8f/odoo/addons/base/models/ir_mail_server.py#L668C1-L676C1 This comes from the fact that we can generate False == False => True comparisons while filtering the `ir.mail.server` records, by : * `email_from_normalize` is False (since `email_f

# Context:
A pesky bug has been flying under the radar since at least Odoo 15.0. When passing `email_from=False` to the _find_mail_server, we will always have an early return at: 
https://github.com/odoo/odoo/blob/f05626e14264cf3bb477c86ad82439726d778c8f/odoo/addons/base/models/ir_mail_server.py#L668C1-L676C1


This comes from the fact that we can generate False == False => True comparisons while filtering the `ir.mail.server` records, by :
* `email_from_normalize` is False (since `email_from` was also False) and mail server has no from_filter = > email_normalize(m.from_filter) == email_from_normalized => False == False
* `email_from_domain` is False (since `email_from` was also False)  and mail server has a full email address in the from_filter field => email_domain_normalize(m.from_filter) == email_from_domain => False == False

Both edge-cases leads to the first email server config to always be selected for the SMTP connection, even if a valid mail server exist matching for example the default notification email (i.e. notifications@custom.domain).

This can lead to notification emails failing on DB having multiple outgoing email servers setup, where the SMTP server does sender verification (Outlook, Gmail – you can only send as a specific sender email).
Should impact Odoo versions 15 and later.

# Proposed fix:
We wrap the first checkpoint in an if block with email_from. Logically if email_from is already False, we should skip to the second checkpoint (matching notifications default email) and only later try to fall back to the first `ir.mail.server`  record (while also triggering the warning log).

# How to reproduce:
Any workflow triggering an automatic notification email as Odoobot, while having the `email` field set to `False`.

1) Setup DB with website_sale installed
2) Set `email` field of Odoobot `res.partner` (by default id = 2) to False 
3) Setup at least two outgoing email servers (`ir.mail.server`) with the first having no `from_filter` and the second one matching the default notifications email address (default = notifications@mycompany.example.com) 
4) So to the Ecommerce shop and buy any random product and finalizing the transaction. → Triggered notification email will always be sent by mail server id = 1, even if it should match id = 2 in this case

OPW-4140192


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

Forward-Port-Of: odoo/odoo#181872
Forward-Port-Of: odoo/odoo#178340

The taxes on Peru localization no not have the percentage added by default on the invoice_label field. Currently, the tax name is simply IGV (for the 18% tax) which makes the invoice PDF feel incomplete. This Pr adds the percentage on the invoice label. task: 4114767 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181283 Forward-Port-Of: odoo/odoo#179132

The taxes on Peru localization no not have the percentage added by default on the invoice_label field. Currently, the tax name is simply IGV (for the 18% tax) which makes the invoice PDF feel incomplete.
This Pr adds the percentage on the invoice label.

task: 4114767




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

Forward-Port-Of: odoo/odoo#181283
Forward-Port-Of: odoo/odoo#179132

When a snippet is in grid mode, the grid items horizontal padding can be modified with the "Padding (Y, X)" option. When we are in mobile view, the display is back to `flex`, in order for the layout to look like the snippets in normal mode. However, while the normal mode columns all have the same padding, which depends on the `--gutter-x` CSS variable, the grid items still keep the horizontal grid padding, making them misaligned with the other contents. An other inconsistency in grid mode

When a snippet is in grid mode, the grid items horizontal padding can be modified with the "Padding (Y, X)" option. When we are in mobile view, the display is back to `flex`, in order for the layout to look like the snippets in normal mode.

However, while the normal mode columns all have the same padding, which depends on the `--gutter-x` CSS variable, the grid items still keep the horizontal grid padding, making them misaligned with the other contents.

An other inconsistency in grid mode is the `--gutter-x` variable: in order for the container to be well aligned with the header, it was set to 0 (except when the container is full-width, where it is 30px). The issue is that this rule is applied on mobile too, making the container inconsistent with the normal snippets.

This commit fixes these issues by blocking the horizontal grid padding in mobile view, and by setting the `--gutter-x` variable rule only for the desktop view.

This commit also moves the rule added in commit [1], which is used to compensate the margins of the rows that are direct children of grid items. Indeed, now that the padding is not variable in mobile view, this rule is only needed in desktop view.

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

task-4194685

Forward-Port-Of: odoo/odoo#180665
Forward-Port-Of: odoo/odoo#180649

After [this refactoring] a regression occurred on the search for taxes on invoices/bills/journal entries. Before, there was a custom search function that allowed to search with a term like "21M" and get the taxes "21% M ...". After the refactoring this was broken. This commit fixes that again. [this refactoring]: https://github.com/odoo/odoo/commit/7fc8794655840961dab1bd80a4bfad3b30953448 Forward-Port-Of: odoo/odoo#181478

After [this refactoring] a regression occurred on the search for taxes on invoices/bills/journal entries. Before, there was a custom search function that allowed to search with a term like "21M" and get the taxes "21% M ...". After the refactoring this was broken.

This commit fixes that again.

[this refactoring]: https://github.com/odoo/odoo/commit/7fc8794655840961dab1bd80a4bfad3b30953448

Forward-Port-Of: odoo/odoo#181478

In the payment report, a space was missing between the VAT label and the span "Emitter Acc. Ben.". In order to don't rely on spaces, a ps-1 class was added in both "Emitter Acc. Ben." and "Emitter Acc. Ord.". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#69259 Forward-Port-Of: odoo/enterprise#53722

In the payment report, a space was missing between the VAT label and
the span "Emitter Acc. Ben.". In order to don't rely on spaces, a ps-1
class was added in both "Emitter Acc. Ben." and "Emitter Acc. Ord.".

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

Forward-Port-Of: odoo/enterprise#69259
Forward-Port-Of: odoo/enterprise#53722

Steps: - create a bom for Product A with the following component: Semifinished B, ratio 1.0 - create a bom for Semifinished B with the following component: Raw C, ratio 1.0 - add A with its bom, B should be created automatically after adding A - add B (even if already present) with its bom, C should be created automatically after adding B - input a forecasted demand of 1 for A (the period doesn't matter) - there should be an indirect demand of 1 for B and C - input a forecasted demand of

Steps:
- create a bom for Product A with the following component: Semifinished B, ratio 1.0
- create a bom for Semifinished B with the following component: Raw C, ratio 1.0
- add A with its bom, B should be created automatically after adding A
- add B (even if already present) with its bom, C should be created automatically after adding B
- input a forecasted demand of 1 for A (the period doesn't matter)
- there should be an indirect demand of 1 for B and C
- input a forecasted demand of 4 for B in the same period
- there should now be an indirect demand of 5 for C

Issue:
The indirect demand of C stays at 1 because the code bypasses the intermediate forecasted demand if there's an indirect demand from a level above

Fix:
Store the indirect demand at ratio in `subproduct_indirect_demand`
If `subproduct_indirect_demand` is different from `ratio * forecast_values['replenish_qty']`, substract it from the entire `replenish_qty` for the corresponding period when adding to `indirect_demand_qty`.

Cases:
`subproduct_indirect_demand` == `ratio * forecast_values['replenish_qty']`:
- base case, there's only indirect demand for B, skip
- there's forecasted demand on B and an equal reduction on the manual replenish qty, skip => the demand is reported to the next period as normal
- there's forecasted demand on B and a max to replenish qty that nullifies it, skip => same as above

`subproduct_indirect_demand` < `ratio * forecast_values['replenish_qty']`:
- base case, there's no indirect demand, proceed
- there's additional forecasted demand for B, proceed => add `(ratio * forecast_values['replenish_qty']) - subproduct_indirect_demand` to the `indirect_demand_qty` dict
- there's additional replenish qty for B, proceed => the additional qty is set on the first day of the period

`subproduct_indirect_demand` > `ratio * forecast_values['replenish_qty']`:
- there's a manually input `replenish_qty` that is inferior to the indirect demand, proceed => the parent_date is set at the end of the current period in case of lead time to prevent negative replenish qty on the period before

Forward-Port-Of: odoo/enterprise#70232

The PR https://github.com/odoo/enterprise/pull/66908 has introduced some problems in the way the studio navbar is styled in dark mode: mainly its menu items are not visible. Here we adapt some variables to have them visible again and have a suitable style on on hover. Forward-Port-Of: odoo/enterprise#71029

The PR https://github.com/odoo/enterprise/pull/66908 has introduced some problems in the way the studio navbar is styled in dark mode: mainly its menu items are not visible.
Here we adapt some variables to have them visible again and have a suitable style on on hover.

Forward-Port-Of: odoo/enterprise#71029

Steps to reproduce: - Install Timesheet when on Time Off - Timesheet > Start > Input a project in the header - Try to input a task Unlike in previous versions, the tasks are not filtered to only show the belonging to the selected project. This happens because timesheet_grid_holidays adds a value to the fieldInfo domain, having a non empty domain means it is picked over field.domain, which contains the necessary filters otherwised used on tasks. opw-4204658 Forward-Port-Of: odoo/enterpr

Steps to reproduce:
- Install Timesheet when on Time Off
- Timesheet > Start > Input a project in the header
- Try to input a task

Unlike in previous versions, the tasks are not filtered to only show the belonging to the selected project. This happens because timesheet_grid_holidays adds a value to the fieldInfo domain, having a non empty domain means it is picked over field.domain, which contains the necessary filters otherwised used on tasks.

opw-4204658

Forward-Port-Of: odoo/enterprise#70749

When a visitor clicks on a view link, they are redirected to the login page to authenticate and gain access to the view. This is necessary to ensure the user has the appropriate permissions to open the view and access the records. Current problem: When clicking on a view link, the users are redirected to an error page after successfully logging in. This happens because the system generates a faulty redirection URL (`/knowledge/article/undefined`) for the login page. This occurs because the

When a visitor clicks on a view link, they are redirected to the login page to authenticate and gain access to the view. This is necessary to ensure the user has the appropriate permissions to open the view and access the records.

Current problem:

When clicking on a view link, the users are redirected to an error page after successfully logging in. This happens because the system generates a faulty redirection URL (`/knowledge/article/undefined`) for the login page. This occurs because the `KnowledgeWidget` widget generates the URL using `this.resId` (`/knowledge/article/{this.resId}`) and the widget does not have any `resId` property set.

Steps to reproduce:
1. Open any list or kanban view
2. In the view's cog menu: "Knowledge" > "Insert link in article"
3. Click the "New" button to create a new article
4. After being redirected to the article, click on the "Share" button
5. Publish the article
6. Copy the generated article URL
7. Open a private window and paste the URL
8. Click the view link
9. Enter valid credentials

=> After logging in, the user is redirected to an error page.

TO BE: After logging in, the user should be redirected to the backend view of the article. The user should then be able to open the view by clicking on the view link.

Solution:

To solve this issue, we will use `this.$id` instead of `this.resId` to get the current article id.

Reference: https://github.com/odoo/enterprise/pull/57346

task-4210743

Forward-Port-Of: odoo/enterprise#70651

**Version:** - saas-17.4 **Steps to reproduce:** - activate debug mode - go to template with no sign record - click on the "signed document" state button or option from the template kanban **Issue:** - it was giving traceback when clicking on "signed documents". **Cause:** - an UncaughtPromiseError was triggered due to an undefined 'noContentHelp' prop in the SignActionHelper component. **Solution:** - removed the 'noContentHelp' prop from the SignActionHelper component to pre

**Version:**
- saas-17.4

**Steps to reproduce:**
- activate debug mode
- go to template with no sign record
- click on the "signed document" state button or option from the template kanban

**Issue:**
- it was giving traceback when clicking on "signed documents".

**Cause:**
- an UncaughtPromiseError was triggered due to an undefined 'noContentHelp' prop in the SignActionHelper component.

**Solution:**
- removed the 'noContentHelp' prop from the SignActionHelper component to prevent the validation error as it is not used at anywhere.

task-4098729

Forward-Port-Of: odoo/enterprise#68021

The problem was that the date picker was disabled when we have Use Existing ones only enabled, but it should be enabled when "Use Existing ones" is checked or "Create New" in the config of "Lots/Serial Numbers". Steps to reproduce: - add a product tracked by lots and have also enabled expiration dates - inventory Receipts configuration - in general, check both options "Use Existing ones" and "Create New" under "Lots/Serial Numbers" - now if you receive product in barcode app, you

The problem was that the date picker was disabled when we have Use Existing ones only enabled, but it should be enabled when "Use Existing ones" is checked or "Create New" in the config of "Lots/Serial Numbers".

Steps to reproduce:

- add a product tracked by lots and have also enabled expiration dates

- inventory Receipts configuration

- in general, check both options "Use Existing ones" and "Create New" under "Lots/Serial Numbers"

- now if you receive product in barcode app, you will see expiration date of the lots disbaled

opw-4086325

Forward-Port-Of: odoo/enterprise#70913
Forward-Port-Of: odoo/enterprise#68008

**Steps to reproduce:** - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * CFDI to public: [Checked] * Invoice Date: [Today] * Payment terms: [the following month] (e.g. 30 Days) - Confirm the invoice - Register a payment **Issues:** 1) "Payment Policy" is PUE no matter what the dates are because "CFDI to public" has been checked. 2) It is not possible to sign the p

**Steps to reproduce:**
- Install l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Create an invoice:
  * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
  * CFDI to public: [Checked]
  * Invoice Date: [Today]
  * Payment terms: [the following month] (e.g. 30 Days)
- Confirm the invoice
- Register a payment

**Issues:**
1) "Payment Policy" is PUE no matter what the dates are because "CFDI to public" has been checked.
2) It is not possible to sign the payment when the generic rfc (i.e. XAXX010101000) is used.

opw-4145716
opw-4127870

Forward-Port-Of: odoo/enterprise#70470

Steps to reproduce: - Download 'Project' and 'Subscription' - Create a product with: -- Product type: 'Service' -- Create on order: 'Task' -- Project: Pick any -- Recurring checkbox must not be ticked - Subscription > New > Add any recurring product > Confirm - Create invoice > Confirm invoice > Back to subscription - Upsell > Add your task creation product > Confirm - The project is linked but no task is created The ability to create tasks from upsell orders was disabled in cbbc70f7

Steps to reproduce:
- Download 'Project' and 'Subscription'
- Create a product with: -- Product type: 'Service'
-- Create on order: 'Task'
-- Project: Pick any
-- Recurring checkbox must not be ticked
- Subscription > New > Add any recurring product > Confirm
- Create invoice > Confirm invoice > Back to subscription
- Upsell > Add your task creation product > Confirm
- The project is linked but no task is created

The ability to create tasks from upsell orders was disabled in cbbc70f73e6fe9e29e27dea4415e20a262bbdf82.
According to the commit message, this was done because upsell orders prorate the price of subscriptions accoding to the time until next invoice relative to the subscription's recurrence (i.e. if the upsell is created halfway through the recurrence it is discounted by 50% etc...). Since we do not have a way to prorate tasks it is marked as a technical limitation.

This however does not need to extend to non-recurring products on subscription sale orders as they are not prorated.

opw-4114049

Forward-Port-Of: odoo/enterprise#69794

This commit adapts documents tests to changes made in https://github.com/odoo/odoo/pull/180776 Forward-Port-Of: odoo/enterprise#70831 Forward-Port-Of: odoo/enterprise#70795

This commit adapts documents tests to changes made in https://github.com/odoo/odoo/pull/180776

Forward-Port-Of: odoo/enterprise#70831
Forward-Port-Of: odoo/enterprise#70795

Adds a test for the counterpart in community side. Checks that a delivery in the 'Inter-Company transit' location is properly shown as "delivered quantity" in the SO form. See odoo/odoo#181412 Task-4207132 Forward-Port-Of: odoo/enterprise#70903 Forward-Port-Of: odoo/enterprise#70663

Adds a test for the counterpart in community side. Checks that a delivery in the 'Inter-Company transit' location is properly shown as "delivered quantity" in the SO form.

See odoo/odoo#181412

Task-4207132

Forward-Port-Of: odoo/enterprise#70903
Forward-Port-Of: odoo/enterprise#70663

Steps to reproduce: - Install the helpdesk_sale_timesheet module. - Create two helpdesk teams (e.g. VIP Support and Customer Care). - Enable time billing and timesheets for the VIP Support team only. - In the portal view of tickets observe that the "Time Spent" label is missing Issue: - In the portal view you will see the 'Time Spent' label missing. Cause: - In the portal view of tickets the 'Time Spent' label is missing because when data is grouped (e.g. by stage, assignee, or t

Steps to reproduce:
- Install the helpdesk_sale_timesheet module.
- Create two helpdesk teams (e.g. VIP Support and Customer Care).
- Enable time billing and timesheets for the VIP Support team only.
- In the portal view of tickets observe that the "Time Spent" label is missing

Issue:
- In the portal view you will see the 'Time Spent' label missing.

Cause:
- In the portal view of tickets the 'Time Spent' label is missing because when data is grouped (e.g. by stage, assignee, 
  or team) it will check for the first group of tickets. It evaluates group in ascending order and if `use_helpdesk_sale_timesheet` is set to false for the first group the 'Time Spent' label will disappears even if it's enabled for other group.

Fix:
- In this commit we will check the `use_helpdesk_sale_timesheet` field for every ticket in the list. If it is set to true for any ticket the "Time Spent" label will be displayed; otherwise it will remain hidden.

task-4058210

Forward-Port-Of: odoo/enterprise#69331

When validation an order in a Chilean shop, the date is not show on the receipt. Steps to reproduce: ------------------- * Change the company for the Chilean one **CL Company** * Go to the **Point of sale** App * Open shop session * Make and order and validate it > Observation: The date is not reported on the receipt Why the fix: ------------ Commit https://github.com/odoo/enterprise/commit/1ce4eaa025426354c640e6e6c69269b1e6b2c7d1 moved the date on receipt in the header for the chi

When validation an order in a Chilean shop, the date is not show on the receipt.

Steps to reproduce:
-------------------
* Change the company for the Chilean one **CL Company**
* Go to the **Point of sale** App
* Open shop session
* Make and order and validate it
> Observation: The date is not reported on the receipt

Why the fix:
------------
Commit https://github.com/odoo/enterprise/commit/1ce4eaa025426354c640e6e6c69269b1e6b2c7d1 moved the date on receipt in the header for the chilean localization.

Header uses the data from `props.headerData`
https://github.com/odoo/odoo/blob/5f748c9d5731fe2e7e519ee9625da25e2bb219bc/addons/point_of_sale/static/src/app/navbar/cash_move_popup/cash_move_receipt/cash_move_receipt.xml#L6

The date field in `headerData` is computed in `getReceiptHeaderData` https://github.com/odoo/enterprise/blob/923dfe962b714797ee41e8f7beed2cb2d6df7048/l10n_cl_edi_pos/static/src/overrides/models/pos_store.js#L48

However, this commit https://github.com/odoo/odoo/commit/5cb7639160cef5401ada8cdde5a5522d8d29c9a9 removed the field `receiptDate` on the pos order. We thus use the same logic to set the date in `headerData`.

opw-4136943

Forward-Port-Of: odoo/enterprise#70833
Forward-Port-Of: odoo/enterprise#70131