Daily updates from Odoo
Wednesday, April 8, 2026
42 changes · saas-19.2
Resolved issues and error corrections
This update fixes an issue where the helpdesk website displayed all published knowledge articles, regardless of which team they were linked to. Now, the website only shows articles connected to the specific helpdesk team, improving the user experience and ensuring relevant information is presented. This change was driven by a bug fix (opw-5913355).
Original PR description
To reproduce: ============= - create multiple published knowledge articles - link one of them to a helpdesk team - check the help page on website -> all public articles are listed Problem: ======== when fetching the articles to list, we don't take into account the team configuration and we list all the published articles. Solution: ========= fetch only the article linked to the team or its children. opw-5913355 Forward-Port-Of: odoo/enterprise#113025 Forward-Port-Of: odoo/enterprise#109361
This update resolves a crash issue that occurred when opening Gantt views on days with Daylight Saving Time transitions. Specifically, the change addresses a calculation error related to time zones, preventing the Gantt view from freezing during these transitions. This ensures a more reliable experience for users across different time zones.
Original PR description
Steps to reproduce 1. Set your timezone to Asia/Beirut 2. Open a Gantt view (e.g. Planning) in week scale on the last Sunday of March (DST spring-forward day) Issue Beirut's DST spring-forward makes that day only 23 hours long. luxon's .diff() works in absolute time, so diffColumn() returned a float (e.g. 6.958 instead of 7 for a full week). Array(6.958) throws RangeError: Invalid array length, crashing the entire gantt view. Forward-Port-Of: odoo/enterprise#112840
This update resolves an error that occurred during the registration of super payments in the Australian payroll system. By initializing the error message to an empty string, the system now correctly handles data and avoids returning NULL values. Associated tests have been added to ensure this fix is reliable.
Original PR description
. Initialize the error message with an empty string to avoid returning NULL. . Add corresponding tests task-6091444 Forward-Port-Of: odoo/enterprise#112930
This update ensures that account moves are automatically created when closing a POS session containing Urban Piper future orders (orders with a delivery date). Previously, these orders were excluded, preventing proper accounting record generation. This change improves financial reporting accuracy for orders processed through the Urban Piper integration.
Original PR description
Before this commit, when all orders coming from Urban Piper in a POS session are paid future orders (i.e. have a delivery_datetime), closing the session would not generate an account move. The cause was that the code was excluding future orders when creating the account move. The fix is to exclude only unpaid orders instead. How to reproduce: - Set up Urban Piper (a test account needed). - Place an order from the Urban Piper platform. - Receive the order, accept it, and mark it as ready. - Close the session. - The session will not have an account move. opw-5995985 Forward-Port-Of: odoo/enterprise#113078 Forward-Port-Of: odoo/enterprise#111137
This update fixes an issue where chart links didn't correctly direct users to the appropriate view for each data source (e.g., a list view for a list datasource). Previously, users were directed to a default action view, which was confusing. This change ensures links within charts now consistently navigate to the correct data source view type.
Original PR description
Currently, if the user clicks on a datasource link (inside a chart) they will be directed to the default view of the action realted to the datasource model but it will not go to the corresponding type of view (e.g. a list datasource should direct to a list view). Task-5957004 Forward-Port-Of: odoo/enterprise#108158
This update fixes an issue related to how dates and times are displayed, specifically the inclusion of seconds. The change restores the original behavior of showing seconds when requested, and clarifies the datetime format system. This ensures consistent and accurate time representation across the Odoo Enterprise platform.
Original PR description
In this [commit] the short format has been removed from misc methods because there was no more _short format fields in res.lang. But the short format was used to remove seconds from the res.lang format. Now, this behaviour has been restored with the new datetime format system and the unused format 'long' and 'full' has been removed from the doc string to avoid misunderstanding. The formatDateTime from the JS use the format from the res.lang too. So the same behaviour has been implemented there to be able to show seconds through the option 'showSeconds'. It's also fix the fact that this option didn't have any effect when the datetime was shown in numeric mode. [commit]: odoo/odoo@062b140 opw-6030342 Forward-Port-Of: odoo/enterprise#112505
This update resolves an issue where the system incorrectly identified employees as eligible for late hours reporting when they hadn't recorded a check-in time. The fix ensures that late hours visibility is only calculated for employees with a valid check-in record, preventing errors and improving data accuracy.
Original PR description
_compute_l10n_sa_late_hours_visible, calling min() on the mapped check_in values and then .date() would crash with an AttributeError when check_in is False (e.g. during an onchange triggered by clearing the check_in field in the form view). Filter out records without a check_in before computing the date range, and mark them as not visible since late hours cannot apply without a check-in time. task-6067640 Forward-Port-Of: odoo/enterprise#111935
This update fixes an issue where users couldn't validate delivery orders when using the 'To Pickup' button. The fix removes a technical restriction that prevented opening the form view from the list, now enabling users to properly complete the delivery order process. This improves efficiency and accuracy in order fulfillment.
Original PR description
Steps to reproduce: - Install `industry_fsm_stock` - Create a task and add a product - Click on the "Sale Order" button - Add another product with the Invoicing Policy set to "Delivered quantities" - Click on the "To Pickup" button Issue: Users are unable to validate the delivery order from the products pick up button. Cause: In pr https://github.com/odoo/odoo/pull/227630 the parent view is set with `editable="bottom"`, which prevents opening the form view from the list. Fix: Allow opening the form view from the list view so users can validate the delivery order. Task-5969303 Forward-Port-Of: odoo/enterprise#110125
This change adjusts the VAT number used in the 'L10nThaiTaxReportTest' test case to align with recent updates in how companies and individuals are created within the Odoo system. This ensures the reports accurately reflect current Thai tax regulations and avoids potential discrepancies.
Original PR description
in this commit:- - We're changing partner's vat in 'L10nThaiTaxReportTest' and adopting new vat as per new way of creating company and individual. as `branch name` is depend upon 'is_company'. - see https://github.com/odoo/odoo/commit/f6e431c813787958897526a4d6570124048b428a task-6002111 Forward-Port-Of: odoo/enterprise#112434
This update corrects a bug where discounts were applied twice to service tasks, resulting in incorrect pricing. The fix ensures discounts are applied correctly based on sales order settings, preventing overcharging and improving accuracy for service order calculations. This impacts how discounts are applied to field service tasks.
Original PR description
Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service. <h2>Steps to produce:</h2> * Install `industry_fsm_sale` and enable…
Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service. <h2>Steps to produce:</h2> * Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings. * Create a pricelist with a price rule of type discount that applies 10 percent discount to every product. * Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist. * Go to Field Service > Create a Task, and set `Customer` to Acme Corporation. * Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order <h2>Observed behavior:</h2> The discount is applied twice to the product on SO: **Product**: Service on Timesheets **Unit Price**: `$40` (excluding tax) **First discount:** The 10 percent discount on the unit price of the product. Product unit price is set from `$40 -> $36 ` **Second discount:** The 10 percent discount on the SO line itself. `$36 -> $32.4 ` The untaxed amount is: `$32.40` which should be `$36.00` <h2>Root cause:</h2> This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice. <h2>Solution:</h2> When creating the sales order: * **Discount setting is on:** use list price so the discount is applied from the sales order. * **Discount setting is off:** set the product unit price to the discounted price. [1]- https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 [2]- https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788 opw-5432088 Forward-Port-Of: odoo/enterprise#112948 Forward-Port-Of: odoo/enterprise#103950
This update resolves an issue where the breadcrumb navigation within the Barcode app was sometimes showing blank entries instead of the originating document's name. Now, when navigating from Barcode actions to related records, the breadcrumb correctly displays the document name, improving user clarity and ease of navigation. This ensures users can quickly identify the source document when working within the Barcode interface.
Original PR description
*: stock_barcode_mrp, stock_barcode_picking_batch ## Issue Before This PR: When navigating from the Barcode client action (e.g. picking, inventory, etc.) to related form views (such as lot, product,…
*: stock_barcode_mrp, stock_barcode_picking_batch
## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.
## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
- Delivery Orders.
- Manufacturing Orders
- Batch Pickings
- Inventory Count
- From any of these open a record
(e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.
## Cause of the Issue:
- When switching views inside the Barcode client action,
the FormController calls `setDisplayName(this.displayName())`.
In some cases, this returns an empty string, overwriting the
previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
preventing the controller from retrieving a proper name.
## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.
TaskID: 4978997
Forward-Port-Of: odoo/enterprise#112988
Forward-Port-Of: odoo/enterprise#99165This update fixes a layout issue in the Italian Libro Giornale PDF report. When accounts with long names are used, the report's formatting was broken, causing excessive column expansion and gaps. The fix adds a CSS class to handle these long account names, resulting in a cleaner and more readable PDF report.
Original PR description
When generating the Libro Giornale (IT) PDF report with an account that has a very long name, the column expands excessively and break the layout. Steps to reproduce: - With an IT company setup - Have an account with a very long name - Create an invoice using the account - Open Accounting / Reporting / Audit Reports / Journal Audit - Select variant "Libro Giornale (IT)" - Print PDF Issue: The long account name makes the column excessively large. As a result, the font shrinks to fit the page width, leaving wide gaps between lines. **before patch** <img width="794" height="493" alt="screenshot_047" src="https://github.com/user-attachments/assets/6faa5b57-9c60-41cb-9200-003a50019180" /> **after patch** <img width="793" height="553" alt="screenshot_046" src="https://github.com/user-attachments/assets/e97c8948-410b-4201-83c3-04173220d9ce" /> opw-5457103 Forward-Port-Of: odoo/enterprise#112743
This update corrects a technical issue that prevented users from accessing the timesheet assistant. A duplicate file was identified and removed during the update process, resolving an error related to duplicate keys within the configuration. This ensures a smoother experience for users managing their timesheets.
Original PR description
In PR: https://github.com/odoo/enterprise/pull/108360/changes `aw_local_config.js` was replaced by `frequency_viewer_local_config.js` but in the Forward from saas-19.1 to saas-19.2, both files were maintained https://github.com/odoo/enterprise/commit/3ced9cf68affd973c570e92627361cd0db8eb518
This update resolves an issue preventing the download of Intrastat reports for businesses using commas as decimal separators instead of periods. The fix also addresses a previous error related to product weights, improving overall report generation reliability. A clearer error message has been added to assist users.
Original PR description
Before this commit, in 19.0+, languages that use commas instead of periods for decimals could not download the intrastat report. Simply attempting to change a string to a float was not enough. Also, when a product had a NoneType weight assigned to it another trace back would occur. This also adds a more descriptive and helpful error message. opw-6026730 Forward-Port-Of: odoo/enterprise#112627
This update fixes how default customer partners are assigned when creating orders in our Point of Sale (POS) system for specific countries (Chile, Colombia, Ecuador, and Guatemala). The change centralizes partner assignment, ensuring more consistent and accurate order creation across these localized versions of Odoo Enterprise. This improves the reliability of POS transactions.
Original PR description
Replace the `createNewOrder()` override with `getDefaultPartnerId()` in l10n_cl_edi_pos, l10n_co_edi_pos, l10n_ec_edi_pos and l10n_gt_edi_pos. The default partner assignment is now handled centrally in `point_of_sale`'s `createNewOrder()`. opw-6077656 Forward-Port-Of: odoo/enterprise#112467
This update adds a required field to Milestone actions within Odoo to ensure database upgrades run smoothly. Specifically, it addresses a technical constraint that prevents both an action ID and a Python method from being defined simultaneously. This change is a necessary maintenance update to maintain system stability.
Original PR description
Add an empty `python_method` field to the Milestones embedded actions. This is necessary to satisfy the `_check_only_one_action_defined` constraint during database upgrades. The `ir.embedded.actions` model enforces an XOR constraint between `action_id` and `python_method`, preventing both fields from being set simultaneously. Related PR: https://github.com/odoo/odoo/pull/254102 task-5993183 Forward-Port-Of: odoo/odoo#254106
A minor bug causing a traceback when deleting a toggle list item has been resolved. The fix prevents an error when there isn't a subsequent item in the toggle list, ensuring the delete function works correctly. This improves the stability and reliability of the To-Do module.
Original PR description
Steps to Reproduce: - Go to To-Do → Create New - Create a toggle list - Type something in the title - Press the delete button Description of the issue: - A traceback occurs. Cause: - In `handleDeleteForwardTitleEnd`, there is a check to verify whether the toggle title’s next sibling matches the toggle selector. However, when there is no next sibling, calling `matches()` results in a traceback. Solution: - Only check `matches()` if the next sibling exists. task-6040479 Forward-Port-Of: odoo/odoo#257157 Forward-Port-Of: odoo/odoo#254557
This update corrects a problem where incorrect timezone selections in event creation led to website rendering errors. The fix removes unsupported timezones like 'localtime' from the available options, ensuring event displays are accurate and reliable. This prevents disruptions to the user experience.
Original PR description
### Issue before this commit: When creating an event, the timezone selection dropdown could include values such as localtime or Factory. If one of these values was selected and the event was later…
### Issue before this commit: When creating an event, the timezone selection dropdown could include values such as localtime or Factory. If one of these values was selected and the event was later displayed on the website, it will led to a traceback error such as: Unknown timezone localtime. As a result, the event page will fail to render correctly or trigger runtime errors related to timezone handling. ### Steps to reproduce the issue: 1. Install Ecommerce and Events apps 2. Go to Ecommerce > Site > Events 3. Create a new test event 4. Activate the Unpublished button 5. Click on the button "Events" 6. Set the display timezone as localtime 7. Click the button "Go to website" 8. Traceback will appear saying: Unknown timezone localtime ### Cause of the issue: The issue was caused by the way the list of available timezones was generated. Timezones are retrieved using the system-provided timezone database through Python’s zoneinfo module. This list includes certain special or internal entries such as localtime and Factory. These entries are not meant to be used as real timezones but were still included in the selection field used by the event model. Since the code responsible for formatting event dates expects valid IANA timezone identifiers, selecting one of these special entries could cause failures. ### Reason to introduce the fix: The fix ensures that unsupported or special timezone entries are excluded from the list of selectable timezones. By filtering out values such as localtime and Factory, the system prevents users from selecting timezones that cannot be safely used in event date computations. opw-5994939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252476
This update fixes an issue where clicking links within charts directed users to the wrong views related to data sources. Now, chart links will correctly navigate users to the appropriate view type – for example, a list datasource will open a list view, ensuring a smoother and more accurate user experience.
Original PR description
Currently, if the user clicks on a datasource link (inside a chart) they will be directed to the default view of the action realted to the datasource model but it will not go to the corresponding type of view (e.g. a list datasource should direct to a list view). Task-5957004 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#249883
This update fixes an issue with how dates and times are displayed in Odoo. Specifically, the display of seconds was restored, aligning with the new datetime format system. This ensures consistent time formatting across the application, regardless of the display mode.
Original PR description
In this [commit] the short format has been removed from misc methods because there was no more _short format fields in res.lang. But the short format was used to remove seconds from the res.lang format. Now, this behaviour has been restored with the new datetime format system and the unused format 'long' and 'full' has been removed from the doc string to avoid misunderstanding. The formatDateTime from the JS use the format from the res.lang too. So the same behaviour has been implemented there to be able to show seconds through the option 'showSeconds'. It's also fix the fact that this option didn't have any effect when the datetime was shown in numeric mode. [commit]: odoo@062b140#diff-61162ac65633a1c7b054fc83ce1813f1a7984e3169ff36021713ef441f62a208 opw-6030342 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255004
This update resolves an issue where invoice generation would fail if a line item lacked tax information. The fix adds a check to prevent the system from attempting to calculate tax values when none are defined, ensuring invoices are generated correctly. This improves invoice accuracy and prevents potential errors.
Original PR description
Issue: Attempting to generate facturae document for an invoice without a tax set on one or more line resulted in an IndexError. Solution: adding a check that prevents the function from trying to build tax values when there is no tax on the line. task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256819
This update resolves an issue where multi-day 'Half Day' time off requests were incorrectly generating a single timesheet entry instead of individual daily entries. The fix ensures that time off requests are accurately reflected in timesheets, regardless of the duration, improving the accuracy of employee time tracking.
Original PR description
Steps to reproduce: ------------------- 1. Install Timesheets and Time Off. 2. Create a new Time Off type with duration type "Half Day" (disable "Require allocation" to skip allocations). 3. Enable…
Steps to reproduce: ------------------- 1. Install Timesheets and Time Off. 2. Create a new Time Off type with duration type "Half Day" (disable "Require allocation" to skip allocations). 3. Enable "Timesheets" in Timesheets > Configuration. 4. Ensure the employee is configured with a "Flexible" working schedule. 5. Create a multi-day Time Off request (2 days) using this type and approve it. 6. Check the timesheet entries for the employee. Issue: ------ When a multi-day time off request is submitted for a "Half Day" time off type, the system fails to generate individual daily timesheet entries. Instead, it generates a single timesheet entry with a duration calculated as leave_version_sudo.hours_per_day / 2, regardless of the actual number of days requested. (e.g., if hours_per_day is 8, it generates one entry of 4 hours for a 2-day leave), Cause: ------ After this commit 9512832, multi-day requests were allowed for time off types where the **request_unit** is "half day" or "hours". However, the logic in `_generate_timesheets` for flexible calendars was not updated to account for this. if `work_entry_type_request_unit == 'half_day'`, the following condition in `_generate_timesheets`: https://github.com/odoo/odoo/blob/6ec97349d998701373920b883a95be7132648e03/addons/project_timesheet_holidays/models/hr_leave.py#L45 always evaluates to True. This traps multi-day requests in the "single-day" logic, preventing the code from reaching `_list_work_time_per_day`. Solution: --------- Update the condition to strictly check if the request is a single day before applying the simplified single-entry logic. If the request spans multiple days, it will now correctly fall into the else block, utilizing `_list_work_time_per_day` to generate one timesheet entry per day of the leave. opw-5715197 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257456 Forward-Port-Of: odoo/odoo#248605
This update resolves a visual bug where applying solid text colors in the HTML editor resulted in a persistent gradient background. The fix ensures that the gradient is correctly removed regardless of how the text color is applied (inline style or class-based), improving the consistency and appearance of text within the editor.
Original PR description
Steps to reproduce: - Go to a To-do note - Select a word - Apply a gradient as the text color - Re-open the color picker - From the Solid tab, select the primary color (o-color-1) Description of the issue: - The gradient is not removed and ends up being displayed as a background color Cause: - In the `colorElement` method, the gradient is removed when applying a text color via inline styles. However, when applying a color via class (e.g., text-*), the gradient is not properly cleared. Only the text-gradient class is replaced, while the gradient style remains, causing it to appear as a background color. Solution: Ensure the gradient is removed in both cases: - when applying a color via class and when applying a color via inline styles in `colorElement`. task-6045533 Forward-Port-Of: odoo/odoo#257045 Forward-Port-Of: odoo/odoo#254654
This update fixes a reporting issue in Point of Sale orders using different currencies. Previously, the margin calculation didn't account for the currency rate, leading to incorrect margin values in the reports. Now, the margin calculation correctly incorporates the currency rate, ensuring accurate reporting for all PoS transactions.
Original PR description
When making a pos order in a PoS that uses a different currency, the margin in the pos order report would not take the currency into account Steps to reproduce: ------------------- * Create a product with a price of 100€ and cost 0€ (margin = 100€) * Setup a PoS to use a different currency with a rate of 2 (so 1€=>0.5) * Create a PoS order for this product and validate it * Go to the pos order report and select the order you just made > Observation: The value of the margin is 200 expressed in the different currency, when the rest of the report is using the company currency. Why the fix: ------------ The currency was only applied on the product cost, we now apply it on the whole margin. opw-5927473 Forward-Port-Of: odoo/odoo#257642 Forward-Port-Of: odoo/odoo#255344
This update resolves an issue where the animation intensity slider disappeared after switching animation modes on the website. The fix prevents a redundant class from being added, ensuring the slider remains visible when changing animation effects. This improves the user experience for website editors.
Original PR description
Steps to reproduce: 1. Go to the website and enter edit mode. 2. Click any text in the footer. 3. Change the animation mode from _none_ to _on appearance._ 4. Select the _zoom out_ effect; the intensity slider is visible. 5. Change the animation mode to _on scroll_. Issue: The animation intensity slider is no longer visible. It only reappears after reselecting the same effect. Reason: The `apply` method of `SetAnimationModeAction` always adds the "**o_anim_fade_in**" class, even when an animation effect is already selected. When switching the animation mode, this additional class prevents the intensity slider from being displayed. task-5896549 Forward-Port-Of: odoo/odoo#257887 Forward-Port-Of: odoo/odoo#246921
This update reduces the size of images within chat bubbles and discussion threads to improve visual appearance. The change was necessary due to a previous design where image sizes were linked, resulting in oversized IM status elements. This update ensures a cleaner and more consistent look.
Original PR description
Before this commit, the size of IM status in ChatBubble and Mobile Discuss were too big. This happens because the `DiscussAvatar` component, which groups the img and IM status, is made from SVG, so…
Before this commit, the size of IM status in ChatBubble and Mobile Discuss were too big. This happens because the `DiscussAvatar` component, which groups the img and IM status, is made from SVG, so that there's mask of image around the IM status. Size of the IM status is coupled with size of the img, so for example if the IMG is twice as big as the default size, then the IM status is also twice as big, which is roughly what chat bubble and mobile discuss have. This commit reduces the size of IM status of chat bubble and mobile discuss to 75%, so that this looks better. This is made possible by providing `iconExtraTransform`, some extra `transform` that are applied on the image mask related to icon and the icon itself. This allows the scale down the IM status in addition to the mask, and offset the position with the new scaling. Before / After <img width="63" height="393" alt="Screenshot 2026-03-06 at 14 15 40" src="https://github.com/user-attachments/assets/6ef2ae3d-d54c-461e-9688-91c69d5631ff" /> <img width="64" height="401" alt="Screenshot 2026-03-06 at 14 15 12" src="https://github.com/user-attachments/assets/edeb2175-698c-4734-8e98-d0b373e7aabc" />
This update addresses a technical issue within the web editor by preventing direct modifications to its history. Removing this functionality also resolves a related problem with data copying, ensuring stability. This change improves the reliability of the web editor.
Original PR description
This commit prevent direct write to history, also, removes it from copy_data as it would fail anyway when trying to write the history Forward-Port-Of: odoo/odoo#220239 Forward-Port-Of: odoo/odoo#217167
This update fixes an issue where invoices created with the 'pay later' payment method in Switzerland didn't generate QR codes for payment. The fix ensures that the invoice correctly identifies a bank partner, resolving this problem and enabling proper payment QR code generation. This improves the user experience for customers using this payment option.
Original PR description
Step to reproduce: - Install l10n_ch_pos and make sure swiss company has tax id filled - Create a swiss customer with an email address and vat, add full address - Open a pos session, and make an invoice for a product with tax, - select payment method, which allows `pay_later`, i.e. payment without journal_id Observation: - the invoiced order, do not have qr for payment, because the invoice do not have `bank_partner_id` Cause: - `_get_partner_bank_id` is recently updated in commit[1], which do not considered `pay_later` option [1] https://github.com/odoo/odoo/commit/7e63991dceb6e443b950e6a1b94454a82d5668c7 Fix: - Fixed the fallback logic for `_get_partner_bank_id` opw-6023060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255678 Forward-Port-Of: odoo/odoo#254117
This update allows administrators to remove outdated or incomplete zero-value account move lines. Previously, these lines couldn't be deleted, leading to potential data clutter. This change streamlines account management by allowing the removal of unnecessary entries, improving data accuracy and efficiency.
Original PR description
-added some conditions to allow the user to remove some zero move lines as they may have been created and do not have good information. task-4590580 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#257148 Forward-Port-Of: odoo/odoo#202272
This update resolves an issue where the width of avatar names was incorrectly set to zero, resulting in a small display. The fix adjusts the width to the correct size, ensuring avatars display properly. This improves the visual consistency and usability of the system.
Original PR description
This commit fix the width of the displayName option of the Avatar component which was fixed to zero (bootstrap class 'w-0') Task-5122979 Forward-Port-Of: odoo/odoo#257869 Forward-Port-Of: odoo/odoo#257587
This update fixes a misleading error message users received when adding property fields to records without a parent. The message has been replaced with a clearer instruction: "A <parentFieldLabel> is needed to add property fields." This improves usability and guides users correctly when setting up property fields.
Original PR description
Issue: ------------------------------------------ - When using property fields (e.g., products since 18.1 where categories are optional), users trying to add a property field without a parent…
Issue: ------------------------------------------ - When using property fields (e.g., products since 18.1 where categories are optional), users trying to add a property field without a parent document receive a generic warning: "You need edit access on the parent document to update these property fields". - This message is misleading and does not explain the actual dependency. How to reproduce: ------------------------------------------ 1. Create or edit a record (e.g., product) without setting its parent (e.g., category). 2. Try to add a property field. Cause of the issue: ------------------------------------------ - In `checkDefinitionWriteAccess`, when `definitionRecordId` is missing, the method returns `false`, triggering a generic access-rights warning. Solution: ------------------------------------------ - Added a check at the beginning of `onPropertyCreate` verify if `definitionRecordId` exists. - If missing, following error is raised using the parent field label: "You must set the '%s' field to create a property field." task-4589393 Forward-Port-Of: odoo/odoo#257954 Forward-Port-Of: odoo/odoo#205107
This update fixes a usability issue in the subthread list within Odoo, making it easier to read and understand conversations. The list has been widened and now displays the last message's full body on hover, resolving truncation problems and improving clarity.
Original PR description
Before this commit, the sub thread list had two issues: - It was too small, making it hard to grasp the content of the thread. The last message of the thread was shown, but due to limited space, it was often truncated so much that displaying it was not useful. This commit slightly increases the width of the sub thread list and adds the last message body as a title, displayed on hover. |Before|After| |--|-| |<img width="396" height="627" alt="image" src="https://github.com/user-attachments/assets/f329cbe2-07d7-48d5-a114-0b2528a77848" />|<img width="512" height="637" alt="image" src="https://github.com/user-attachments/assets/cf08d099-6fb5-4b62-97f2-39660014c5f2" />|
This update resolves an issue where some printer drivers weren't properly initializing due to missing key information. The PR adds the ability for these keys to be absent, ensuring broader printer compatibility and stability. This prevents potential disruptions in printing functionality.
Original PR description
After the PR https://github.com/odoo/odoo/pull/247032 for some printers the keys 'device-id' and 'device-make-and-model' are missing which leads to the drivers not being initialized This PR adds the possibility of these keys missing 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 a visual issue where the toolbar in the HTML editor wasn't appearing correctly when selecting individual columns within a table. The fix ensures the toolbar accurately aligns with the selected cell, improving the user experience when working with tables. This resolves a minor but noticeable UI inconsistency.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a 3 x 3 table. - Select 3rd column and wait for toolbar. Currently, the toolbar is positioned at the start of the table even when the last column is selected. This happens because selecting cells in the 3rd column creates a DOM selection range that starts at the first cell and ends at the last cell of the column, traversing all intermediate elements. As a result, browser's range rectangle does not match the actual custom-selection rect. **Desired behavior after PR is merged:** Now, Toolbar is positioned correctly above the custom selected cells. task-5935587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257879 Forward-Port-Of: odoo/odoo#248964
This update resolves a display error that appeared in the search panel when dealing with large datasets. Specifically, a limit was added to the 'partner_id' field in a search view, preventing the 'Too many items to display' error and ensuring all data is correctly shown. This improves the user experience when searching through extensive customer lists.
Original PR description
Have a search view with searchpanel having a filter or a category with a limit. For exemple in sale.order:
```
<searchpanel>
<field name="partner_id" icon="fa-filter" groupby="parent_id" limit="80" enable_counters="True"/>
</searchpanel>
```
On a database with a lot of data, in the category partner of search panel, there is an error 'Too many items to display.'.
Now in the search view, add a filter to restrict the number of records, and hence the number of partners in the search panel below the limit.
Before this commit, the error was still displayed. Now, it isn't, and the data are properly displayed.
Closes #257749
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#257998
Forward-Port-Of: odoo/odoo#257821This update resolves an issue where the placeholder text wasn't displayed in the emoji picker when using the newer Owl3 template. The fix ensures the placeholder is correctly rendered, improving the user experience for selecting emojis. This change aligns the emoji picker with recent template updates.
Original PR description
Before this commit, using owl 3 on current template of emoji picker would not have the placeholder shown. This happens because `placeholder` is defined in JS component while `placeholder` is being used as if defined as a template variable. In owl2 this is not a problem because context of template has the component's context in the prototype chain, however that's not the case in owl3. This commit fixes the issue to match with recent changes in template to prepare for owl3. Before / After (with owl3): <img width="302" height="371" alt="Screenshot 2026-04-08 at 15 08 48" src="https://github.com/user-attachments/assets/c232d533-0d86-473c-b14b-2e7f406158a8" /> <img width="302" height="371" alt="Screenshot 2026-04-08 at 15 09 33" src="https://github.com/user-attachments/assets/84171fd2-0e54-4874-ac72-181fb27873f5" />
This update corrects a technical bug impacting the ability to accurately identify fiscal data module drivers (FDMs) within the Odoo IoT system. The fix removes an unnecessary restriction on the driver class, ensuring proper functionality and data reporting. This resolves a previously undetected issue.
Original PR description
This PR fixes a bug introduced in https://github.com/odoo/odoo/pull/221948/changes#diff-2ff0ee6ef17f1cbd35afdf07878383c136c6900df361c520083d7608c1266db2R35 Since the SerialDriver class is a child of ABC class and has an abstract method decorator used + take_measure is not implemented for fiscal data module drivers, the check lead to 'supported' method never being called for fdm This PR adds the removes the abstract property for SerialDriver class to allow fingerpringting of fdms again
This update fixes an issue where combo orders in the self-order mode were calculating prices incorrectly in the backend. The fix ensures accurate pricing for combos with multiple quantities, resolving a discrepancy between the frontend and backend displays. This improves the reliability of self-order transactions.
Original PR description
**Steps to reproduce:** - Create 2 products, set their price to 0 - Create a combo product, set it's price to 10 - The combo choices should be the 2 products created before - Go to the self order,…
**Steps to reproduce:** - Create 2 products, set their price to 0 - Create a combo product, set it's price to 10 - The combo choices should be the 2 products created before - Go to the self order, order the combo and change the qty to 3 - The price is 30, correct in the frontend - Go to the order in the backend, the price is 0 **Why the fix:** In the backend, during the price recomputation, we did not account for the fact that we could have a parent line with multiple quantity during the split between the free and the extra lines. This means that we counted too many lines, and had to put some in the extra lines. We then override the price_unit with the total_price in this code https://github.com/odoo/odoo/blob/f73c32960721b046076b91e4bc017ddb924e0837/addons/pos_self_order/models/pos_order.py#L341-L342 But the total price has been computed to zero, so the previously computed price_unit is overriden and set to zero. We now divide the line's qty by the parent line's qty to get the qty per parent line, allowing us to have a qty of more than 1 for the parent line. The same is done for the computation of the remaining amount to pay, as **child.qty** is the number of time the item is selected in the combo * the number of combo ordered, meaning it was messing up the computation. opw-6032408 Forward-Port-Of: odoo/odoo#254443
This update resolves a small typographical error within the Odoo testing framework. The fix ensures the accuracy of test results and maintains the stability of the base module. This change has no impact on Odoo's functionality.
Original PR description
A typo was introduced in #163714 Forward-Port-Of: odoo/odoo#256756 Forward-Port-Of: odoo/odoo#228977
This update fixes a bug that caused duplicate orders to be created when a default customer was assigned. The change ensures that orders are correctly identified as empty, even with a default partner, preventing the creation of redundant orders. This improves order processing efficiency and data accuracy.
Original PR description
When a default partner is assigned to new orders, `getEmptyOrder()` failed to find the existing empty order because it filtered on `!order.partner_id`, causing a duplicate order to be created after each validation. Add a `getDefaultPartnerId()` hook returning `null` by default. `createNewOrder()` uses it to assign the default partner centrally, and `getEmptyOrder()` uses it to correctly identify orders still considered empty despite having a default partner set. Also update l10n_ar_pos and l10n_pe_pos to override `getDefaultPartnerId()` instead of `createNewOrder()`. opw-6077656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256618
This update corrects an issue where Point of Sale emails were incorrectly displaying times in UTC for users outside of the store. The fix ensures that email timestamps accurately reflect the store's local timezone, regardless of who sends the email. This improves the clarity and accuracy of communications related to Point of Sale orders.
Original PR description
The tz variable in POS email templates was set using object.env.user.tz, which resolves to UTC when emails are sent by the Public User. Fix by using `object.company_id.partner_id.tz` instead, which reliably reflects the store's timezone regardless of which user triggers the email. opw-6052244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257822
This update fixes a potential crash in the Point of Sale module. Previously, if the Epson printer IP wasn't configured, the system would encounter an error. This change adds a safeguard to ensure the 'isPrivateIp' function handles missing or invalid IP addresses gracefully, preventing the application from crashing.
Original PR description
When `epson_printer_ip` is not set, `isPrivateIp` would crash with "ip.split is not a function" because the value is undefined/null. Add an early return of false when the argument is falsy or not a string. opw-6067382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256028