Monday, May 18, 2026
31 changes · saas-19.3
Resolved issues and error corrections
This update simplifies the process of retrieving transactions from Codabox. Previously, a write access check was required, even with an established connection. This change removes that unnecessary check, streamlining the process and improving efficiency.
Original PR description
Currently, we use the `_l10n_be_codabox_verify_prerequisites` method before trying to fetch transactions. This method checks if the user has write access rights on res.company model which should not be mandatory to fetch transactions from codabox when the connexion is already created. opw-6108811 Forward-Port-Of: odoo/enterprise#117097
This update resolves an issue where pressing Enter after a styled heading created a new paragraph that incorrectly inherited the heading's formatting (like color). The fix ensures that newly created paragraphs are empty and without inherited styles, aligning with the expected behavior. This improves the consistency and predictability of the HTML editor.
Original PR description
Problem: Pressing Enter at the end of a styled heading (e.g., with a color) creates a new paragraph that inherits the heading styles. This is no longer the expected behavior. The new paragraph should be empty and without inherited styles. Solution: When splitting a heading at its boundaries and creating a base container, fill it with a `br` instead of carrying over styles. Steps to reproduce: - Add a heading. - Apply a style (e.g., color). - Place the caret at the end of the heading. - Press Enter. - Observe that the new paragraph still has the heading color. task-6147897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264624 Forward-Port-Of: odoo/odoo#262150
This update resolves an issue where test emails sent through the Email Marketing app would leave a related attachment visible in the chatter of contact records. The fix ensures that test messages are properly removed from the Chatter after sending, preventing clutter and improving the user experience. This improves the clarity of communication within the system.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a mailing campaign - Set its recipients to Contact - Upload a file in Settings > Attach a file - Click on the test button to send a test mail to any mail - Go to the first contact record - Related attachment appears in the chatter **Issue:** Before 18.2, messages created for testing were ignored by the Chatter as they were empty (and not unlinked). But if an attachment was provided, it was linked to the test message and not deleted afterwards (which means it shows up in the record chatter). **Fix:** Ensure the related messages are unlinked at the same time as the test mail in `send_mail_test` by setting `is_notification` to False to trigger the `unlink` logic and remove the related attachments at the same time. backport of: https://github.com/odoo/odoo/commit/526b3d73886558315f2435714b2ed82fec313e78 opw-6168632 Forward-Port-Of: odoo/odoo#263139 Forward-Port-Of: odoo/odoo#262152
This update fixes a visual issue in the project timesheet reporting. Previously, the 'Time Remaining' value wasn't highlighted in red when it was a negative number, which could be confusing for users. The fix ensures the value is correctly colored red when negative, improving clarity and accuracy of time tracking data.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** - Adjusted the logic to ensure the Time Remaining value is highlighted in red when value is negative **Task-id: 5404009** Forward-Port-Of: odoo/odoo#260996 Forward-Port-Of: odoo/odoo#240489
This update corrects a visual inconsistency in the project timesheet interface. Previously, the 'Time Remaining' value wasn't highlighted in red when the time was negative. This fix ensures that negative time values are correctly displayed with a red warning indicator, improving clarity and accuracy for users managing project time.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** In hr_timesheet, the remaining_hours field has a decoration-danger applied In sale_timesheet_enterprise, this field is overridden as portal_remaining_hours So, Added the corresponding decoration-danger on portal_remaining_hours. task-5404009 Forward-Port-Of: odoo/enterprise#114836 Forward-Port-Of: odoo/enterprise#113632
This update fixes an issue where the FEC file parser would fail due to empty lines. The change now automatically skips these empty lines, ensuring all valid FEC files are processed correctly and preventing errors. This improves the reliability of the French localization import process.
Original PR description
It could happens that we have some empty lines in the fec files, the parser was returning an error when that happened. We still want to process the file so we will just skip the empty lines. task-6169168 Forward-Port-Of: odoo/enterprise#115758
A recent test for live chat duration was unreliable due to a race condition in how the system handled agent state changes. This fix addresses this issue by splitting the test to avoid the problematic state transitions, ensuring the test runs consistently. This improves the overall reliability of our live chat monitoring.
Original PR description
The `show looking for help duration in the sidebar` test has been flaky since [1]. The root cause is that the agent joins at the final step, resetting the state to in_progress, then immediately…
The `show looking for help duration in the sidebar` test has been flaky since [1]. The root cause is that the agent joins at the final step, resetting the state to in_progress, then immediately switches it back to `looking_for_help`. This creates several race conditions: - Bus notifications from `join_livechat_need_help`, new message events, and any other notification carrying stale state data. - Channel state fetched after the user joins via `/mail/data`. The mock server makes these races hard to guard against: notifications arrive one by one, and there's no UI signal that guarantees all stale data has been processed. This commit splits the test to preserve coverage while avoiding the problematic rapid state transition. runbot-242278 [1]: https://github.com/odoo/odoo/pull/252738 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#264666
A recent change in the Odoo system caused the remaining time for sales projects linked to orders to no longer be displayed correctly. This PR restores a key setting that ensures the remaining time is shown, resolving this visual issue for users managing sales projects. It's a minor fix impacting the display of project timelines.
Original PR description
Steps to Reproduce: - Open any project linked with a sales order - Open task and click on Sale Oder Item dropdown. Issue: - You can see that SOL's with time remaining don't show the amount of time left Reason: - In this PR https://github.com/odoo/odoo/pull/193079 a record (view_task_form2_inherit_sale_timesheet) has been removed. - So the context key `with_remaining_hours` required to show remaining time is missing. Fix: - Add the record back which updates context task-6170953 Forward-Port-Of: odoo/odoo#262746
This update resolves an issue where the Microsoft SwiftKey keyboard caused incorrect selection updates within the HTML editor, leading to unexpected focus shifts. By caching the selection on each change, the system now accurately reflects the user's intended selection, improving the editor's stability and usability.
Original PR description
Problem: When using the Microsoft SwiftKey keyboard, placing the caret at the beginning of a table cell and triggering a `beforeinput` event can result in `getSelection()` returning an incorrect selection. Notably, the selection immediately before the event is correct, but it changes unexpectedly without firing a `selection_change` event. Solution: Cache the selection whenever a `selection_change` event fires, ensuring we keep the last correct selection set by the user or editor. Steps to reproduce: - Edit a table with an empty cell. - Place the caret inside the empty cell. - Press Backspace. - Observe that the focus moves to the previous cell unexpectedly. task-6150731 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264769 Forward-Port-Of: odoo/odoo#259798
This update fixes an issue where the rental report was displaying incorrect dates. The fix ensures that each row in the report accurately reflects the start and return dates of the rental order, providing more reliable reporting data. This improves the accuracy of rental tracking and analysis.
Original PR description
The rental report is a daily report with x rows by rental order, with x the days between the start and return dates. With generate_series inside the select, the query was creating x rows with the same id, resulting in the date field not being correctly displayed (one unique date, the start date). This fix corrects the generation of the report to display the real date on each row. opw-5266525 Forward-Port-Of: odoo/enterprise#106235 Forward-Port-Of: odoo/enterprise#104764
This update corrects a display issue with the Folder report layout when using Right-to-Left (RTL) languages like Arabic. The change involves adjusting the report's image styling to ensure it aligns correctly within the RTL layout, improving readability and presentation for users in those languages. This resolves a visual bug impacting invoice printing.
Original PR description
Steps: - Enable rtlcss - Install an RTL language (e.g Arabic or change english direction to rtl) - Enable RTL language - Go to settings - Configure report layout document - Select Folder type - Try to print an invoice - The header title style is broken the svg image used in the title should be mirrored to be displayed correctly on RTL opw-6140277 Forward-Port-Of: odoo/odoo#263115 Forward-Port-Of: odoo/odoo#262830
This update corrects a technical issue that prevented accurate payroll calculations when a payrun had no associated payslips. The fix ensures the system functions correctly regardless of the number of payslips processed, improving payroll accuracy and reliability. This resolves a potential disruption to payroll processing.
Original PR description
If the payrun does not have any payslips, the _get_payslip_stp is called on an empty recordset, which causes the compute to fail. This commit fixes the _get_payslip_stp compute for empty recordset. task-6215823 Forward-Port-Of: odoo/enterprise#117198
This update corrects a technical error in the 'my department' holiday reporting test. The test was incorrectly creating duplicate employee records, which could have caused data inconsistencies. The fix ensures the test uses the existing employee record for the demo user, preventing this issue and maintaining data integrity.
Original PR description
Issue: The test was creating a new employee linked to the demo user, but if the demo user already had an employee, it would violate the (user_id, company_id) uniqueness constraint. Fix: Before creating a new employee, we check if the demo user already has one. If not, we create it, otherwise we use the existing one. task-6050719 Forward-Port-Of: odoo/odoo#263224
This update resolves an issue where a warning message persisted after canceling a payslip in the payroll system. The change ensures that the warning is cleared, providing a cleaner and more intuitive user experience. This improves the reliability and usability of the payroll module.
Original PR description
. Clear payslip warning after cancelling the payslip . Add corresponding tests task-6199148 Forward-Port-Of: odoo/enterprise#117418 Forward-Port-Of: odoo/enterprise#116859
This update ensures that all employee groups, regardless of their type, receive the correct employer-paid rent posting account in payroll. Previously, this setup was limited to a single group, leading to inconsistencies. This change maintains accurate and predictable payroll accounting.
Original PR description
Before this commit, the employer-paid rent setup was only applied to one employee group. This could leave other employee groups without the expected rent posting account. After this commit, the same rent posting setup is applied for each available employee group. This keeps payroll accounting behavior consistent. Task-6175007
A test was failing due to inconsistencies in how account reports were loaded during automated testing. This update ensures the test accurately reflects the system's behavior by generating the necessary account reports within the test itself. This resolves a runbot error and maintains the stability of the account reporting functionality.
Original PR description
Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report,…
Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report, specifically, the account report corresponding to the audit report's company (see: odoo/enterprise#101377). In version 19.1, a test was added to validate account report options. However, this test assumed that embedded account reports would always load the global account report (i.e., `account_reports.balance_sheet`). When tests run on runbot, demo data is not loaded. In that context, no report variants exist in the database, so the system falls back to the global account report, causing the test to pass. In environments where demo data is loaded, a report variant does exist, and the system correctly selects it instead of the global report. As a result, the test assertions are no longer valid and fail, leading to runbot errors. To address the issue, we will generate the account reports within the `setup` method of the test. This ensures that the assertions remain consistent, regardless of whether demo data is present. runbot-error-id~242235 Forward-Port-Of: odoo/enterprise#117075 Forward-Port-Of: odoo/enterprise#112486
This update resolves an issue where the chatbot restart button on the feedback panel could fail, leaving the live chat in an error state. Now, the button is disabled when the chatbot hasn't completed its process, preventing errors and ensuring a smoother user experience. This improves chatbot reliability.
Original PR description
Before this commit, it was possible to restart the chatbot on the feedback panel when closing the chat window. This was actually failing when the chatbot was stopped before the last step was completed and left the livechat state in error. Now, the button is simply disabled on feedback when we did not reach the end of the chatbot to avoid any issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258601 Forward-Port-Of: odoo/odoo#257891
This update corrects a minor visual glitch where overlays (like dialog boxes) sometimes appeared twice when initially displayed. The change improves the stability and reliability of the user interface by preventing unnecessary re-renders, resulting in a smoother user experience.
Original PR description
Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount. This comes from implementation details for detecting whether the overlay comes from shadow DOM or…
Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount. This comes from implementation details for detecting whether the overlay comes from shadow DOM or website, to determine which overlay container should decide to display the overlay [1]. The code relies on presence of the root id in the DOM and overlay container was relying on presence of `ref.el` to get the root id from DOM. This was motivated by `isVisible(overlay)` whose computation was also relying on the ref [2] but this has the drawback that `ref.el` was sometimes not yet available immediately on 1st rendering. Solution of [1] was to re-renderer whenever `ref.el` is set, but another solution that prevents a re-render is to have the root id in the `env`. This commit changes the solution of [1] by instead `rootId` in the `env`. The new solution has the benefit to not require a re-render of the overlay container, which prevents undesirable flickers that may happen on mounting an overlay for the 1st time. [1]: odoo#169264 [2]: odoo#154349 Forward-Port-Of: odoo/odoo#263860
This update fixes an issue where the average inventory cost calculation in the 'Inventory at Date' report was inaccurate. Specifically, when using the AVCO cost method, the calculation was incorrectly influenced by the standard price instead of actual costs, leading to incorrect reported values. This ensures accurate inventory valuation reports.
Original PR description
When we open the Stock report at date, we filter out moves anterior to that date and, if the cost method is AVCO, Odoo recompute the `avg_cost` up to that point of time with `_run_average_batch`. However, when iterating over the moves, `move._get_value(at_date)` might return a value calculated from the current standard_price if the move is not associated with any accounting entry or PO/SO. Steps to reproduce the issue: 1. Create a new product with AVCO cost method 2. On the product form, set the cost to 5$ 3. Manually adjust the inventory to 5 units 4. Create a PO and receive 5 products at a unit cost of 10$ > Total value: 75$ > Total quantity: 10 units > avg_cost: 7.5$ 5. Navigate to Stock report and run "Inventory at Date" at current time 6. avg_cost is 8.75$ instead of 7.5$ Ticket: opw-5951072 Forward-Port-Of: odoo/odoo#257705 Forward-Port-Of: odoo/odoo#253659
This update resolves an issue where livechat conversations wouldn't automatically mark as read after ending. Now, the system correctly triggers the 'read' state when a conversation is in focus, ensuring agents see accurate read statuses for closed chats. This improves agent efficiency and provides a clearer view of ongoing interactions.
Original PR description
**Description of the issue this PR addresses:** Previously, when a livechat conversation ended, it was never automatically marked as read. The existing `mark_as_read` mechanism depends on the…
**Description of the issue this PR addresses:** Previously, when a livechat conversation ended, it was never automatically marked as read. The existing `mark_as_read` mechanism depends on the composer being focused, but ended livechat conversations hides the composer, and the chat window does not focus the thread automatically (focus only happens on explicit click). This made it impossible for the read state to be triggered through the normal path, leaving agents with persistent unread indicators on closed livechat conversations. **Desired behavior after PR is merged:** - Focus the composer when present. - Focus the conversation otherwise. This ensures the read state is correctly triggered when the conversation is effectively in focus. task-[5900038](https://www.odoo.com/odoo/project/1519/tasks/5900038) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263607 Forward-Port-Of: odoo/odoo#253609
This update fixes a technical issue related to how Point of Sale orders are created. Specifically, it allows for the inclusion of important data during order generation, streamlining the process and ensuring more complete order information. This change is related to a larger effort to improve the Enterprise version of Odoo.
Original PR description
In this commit: ================ This commit allows `getEmptyOrder()` to receive `data` and apply it when creating an order. Task-6217580 Related Ent PR-https://github.com/odoo/enterprise/pull/117378
This update resolves an issue where depositing money in Point of Sale orders incorrectly triggered a preset selection popup. The change ensures that deposit orders are immediately identified as 'settling accounts,' preventing the popup and streamlining the deposit process. This improves the user experience for cash transactions.
Original PR description
Before this commit: ==================== depositing money for a partner in PoS with presets enabled could incorrectly trigger the preset selection popup. This happened because the order was not marked as is_settling_account early enough, so the preset selection logic did not ignore deposit orders. After this commit: ===================== is_settling_account is initialized during order setup and seeded immediately when the deposit order is fetched or created. As a result, deposit orders correctly bypass the preset selection flow. Task-6217580 Related Comm. PR-https://github.com/odoo/odoo/pull/264572
This update fixes an issue where Colorado state income tax calculations resulted in a positive value on payslips, which is incorrect. The fix aligns with established payroll tax principles, ensuring that taxes are always withheld from employee paychecks, not reported as refunds. This ensures accurate payroll reporting.
Original PR description
## Issue When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive. ## Steps to reproduce 1. Install *United States - Payroll*…
## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.
## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
- Wage: $0
- (Set the contract's status to *Running*)
- (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
- Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**
## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:
> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*
## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).
opw-5999856
Forward-Port-Of: odoo/enterprise#117232
Forward-Port-Of: odoo/enterprise#112724This update fixes a potential issue where multiple payslips for the same month (specifically for employees not on contract) could incorrectly double-count worked hours when calculating the employment bonus. The change ensures accurate bonus calculations by only considering worked hours once, improving payroll accuracy for this employee group.
Original PR description
In the case of out of contract payslips, we might have multiple payslips with worked day lines for the same month. In that case, we need to be careful to not count these hours twice when computing the employment bonus, which depends on the total "workable" hours for the month. task-6208125
This update corrects a technical error that caused the LNA (Long Polling Acknowledgement) feature to be enabled consistently for all IoT polling requests, regardless of the action being performed. Removing a mistakenly reintroduced parameter ensures the correct number of arguments are passed to the function, resolving this issue and restoring proper LNA behavior.
Original PR description
In odoo/enterprise#104157, the `headers` parameter was accidentally reintroduced to the `rpc` function of the longpolling class. This was causing `post` to be called with the wrong number of arguments, and a side-effect of this is that LNA was being enabled always for poll requests and never for action requests. This commit removes the headers parameter so that the function is called with the correct number of arguments.
This update corrects a visual issue where the 'Attendance' bubble incorrectly appeared on payruns. The fix ensures that payrun bubbles accurately reflect employee status changes, improving the user experience when navigating payrun details. It addresses inconsistencies in how payrun data is cached and displayed.
Original PR description
Two bugs stem from the payrun "step bubble" bar (Employees → Time [→ Attendance] → Payslips): 1. When a payrun not containing attendance-tracked employees is opened first and I change one of the…
Two bugs stem from the payrun "step bubble" bar (Employees → Time [→ Attendance] → Payslips): 1. When a payrun not containing attendance-tracked employees is opened first and I change one of the employee's tracking method to attendance, going back via breadcrumb I'd see that the Attendance bubble incorrectly appears for the latter. The root cause is that cachePayRunSteps is a Map iterated in insertion order: "attendance" is appended after "payslip" the first time it is encountered, so it always renders last regardless of the server-defined canonical order. Fixed by turning it into an array overridden at every data fetch. 2. When navigating back to the payrun list via breadcrumb after changing the last of an employee's work_entry_source (e.g. removing the last attendance-tracked employee from a payrun), the bubble still shows the previous state. Fixed by marking the payrun as fresh when following specific flow, preventing the reload of the bubbles using instead the previously cached ones. task-5959087
This update corrects a technical issue where an approval rule was being applied incorrectly due to a duplicate XML ID. The change ensures that approval rules are applied correctly based on user and manager roles, improving the reliability of approval workflows. This resolves a potential inconsistency in how approvals were handled.
Original PR description
The XMLID `approval_approver_manager` was defined twice, causing the rule to be applied with the last evaluated access configuration for both `group_approval_user` and `group_approval_manager`. This commit renames the first occurrence of the duplicated XMLID to `approval_approver_user` to restore the intended separation between user-level and manager-level approval access rules. task-6095010 Forward-Port-Of: odoo/enterprise#113480
This update fixes a discrepancy in how invoiced quantities are calculated for sales orders, specifically when dealing with packaged products. Previously, rounding differences led to a slight mismatch between the delivered and invoiced quantities. This change ensures consistent rounding, accurately reflecting the quantity invoiced.
Original PR description
Steps to reproduce: --- - Install the `Sales and Inventory` modules. - Enable `Units of Measure & Packagings` from Settings. - Go to `Sales > Configuration > Products > Units & Packagings.` - Create…
Steps to reproduce: --- - Install the `Sales and Inventory` modules. - Enable `Units of Measure & Packagings` from Settings. - Go to `Sales > Configuration > Products > Units & Packagings.` - Create a new unit > Pack of 12 with quantity 12 and unit Units. - Create a new product > enable Track Inventory, set Quantity On Hand to 100, and in the `sales` tab, under `Upsell & Cross-Sell`, set `packaging` as` Pack of 12`. - Create a Sales Order > add the product and set the quantity to 3, with a unit Pack of 12. - Confirm the order and validate the delivery. - Create and confirm the invoice. - Return `1 unit` from the delivery and validate it. - From the invoice, create a `credit note` with quantity 1 unit and confirm it. - Go back to the Sales Order. Issue: --- - On the Sales Order: `Delivered Quantity` shows` 2.92` while `Invoiced Quantity` shows `2.91`. Root cause: --- - At [1] & [2], in `_compute_qty_invoiced`, the `_compute_quantity` method is called without specifying a `rounding_method`, so it defaults to `UP` (1/12 rounded to 0.09), while `_compute_qty_delivered` explicitly uses `HALF-UP` (1/12 rounded to 0.08), leading to inconsistent rounding. Solution: --- - In this PR, the same rounding method (HALF-UP) is applied when computing the invoiced quantity to ensure consistency with the delivered quantity. [1]https://github.com/odoo/odoo/blob/64c1f1a7d3b24ca613d0b29a2412f1094fea08d9/addons/sale/models/sale_order_line.py#L896-L912 [2]https://github.com/odoo/odoo/blob/64c1f1a7d3b24ca613d0b29a2412f1094fea08d9/addons/sale_stock/models/sale_order_line.py#L193-L209 opw-6073690 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263300 Forward-Port-Of: odoo/odoo#258024
This update removes a confusing button on Sale Orders for products handled through subcontracting. By hiding the Manufacturing Order (MO) button, we prevent users from navigating to unnecessary back-end manufacturing documents and streamline the process managed through Purchase Orders and Subcontracting Receipts.
Original PR description
The Manufacturing Order (MO) smart button on a Sale Order is confusing when the product is subcontracted. In a subcontracting flow, the user manages the process via the Purchase Order and the Subcontracting Receipt. This commit ensures the MO smart button is hidden when the fulfillment is handled through subcontracting to prevent user confusion and unnecessary navigation to back-end manufacturing documents. Task-id: 6173877 Forward-Port-Of: odoo/odoo#263105
This update corrects a UI issue where changes to cloned website snippets weren't properly reflected. The fix ensures that duplicated snippets are marked as 'dirty' when their content is updated, maintaining accurate state visibility within the website editor. This prevents outdated content and improves the user experience.
Original PR description
Steps to reproduce: 1. Open the website editor 2. Add a snippet containing text content 3. Clone the snippet 4. Change the website language 5. Switch to translation mode 6. Modify the content of the original snippet => The cloned snippet reflects updates from the original snippet due to shared content, but is not marked as `o_dirty` and remains in a clean (yellow) state. Expected behavior: Cloned snippets should be marked as `o_dirty` when their content changes indirectly, ensuring the UI accurately reflects the modified state. This fix ensures duplicated snippets are flagged as `o_dirty` on indirect updates, preventing silent UI inconsistencies and improving state visibility. task-6176337 Forward-Port-Of: odoo/odoo#261916
This update resolves an issue where Point of Sale orders would fail if a product used an archived Unit of Measure. We've now implemented a fix to load archived UOMs within the POS, ensuring order creation works smoothly regardless of UOM status. This improves the reliability of the POS system for all users.
Original PR description
If a product uses an archived UOM and an order is then created in the POS with this product, an error would occur because it could result in trying to use a UOM that wasn't loaded in the POS since it was archived. To fix this issue, we now load archived UOMs in the POS. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6197465 Forward-Port-Of: odoo/odoo#264837 Forward-Port-Of: odoo/odoo#263838