Daily updates from Odoo
Wednesday, April 8, 2026
184 changes
29 changes
Resolved issues and error corrections
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
27 changes
Resolved issues and error corrections
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 consistent and accurate order creation across these localized versions. This improves order processing reliability and data accuracy.
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 empty field to Milestone actions within Odoo. This change ensures the system's database remains stable during upgrades by adhering to a technical constraint that prevents conflicting action definitions. It’s a routine maintenance update to maintain data integrity.
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
This update fixes an issue where the animation intensity slider disappeared after switching animation modes on the website. The problem stemmed from a code change that consistently added a styling class, preventing the slider from reappearing until the same effect was selected again. This ensures a consistent and expected user experience when customizing website animations.
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#246921
A minor bug that caused 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 fixes a misleading error message users saw when trying to add property fields to records without a parent (like categories). The message has been replaced with a clearer instruction: "A <parentFieldLabel> is needed to add property fields." This ensures users understand the requirement and can easily correct the issue.
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#257875 Forward-Port-Of: odoo/odoo#205107
This update resolves an issue with the Windows IoT installer by correcting file paths and adjusting logging levels. The change ensures the installer functions correctly and provides more detailed information for troubleshooting, improving stability and reliability.
Original PR description
this commit fixes incorrect paths for the Windows IoT installer and updates log levels to INFO instead of WARNING.
This update corrects a visual issue where the display name within avatars appeared extremely narrow. The fix adjusts the width of the avatar component, ensuring names are displayed correctly and consistently. This improves the overall user experience and presentation of user profiles.
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 resolves an issue where the search panel displayed an error message ('Too many items to display') when dealing with large datasets. By adding a filter to limit the number of records shown, the search panel now correctly displays data without the error, improving the user experience. This ensures a smoother and more reliable search experience, especially with extensive data.
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#257908
Forward-Port-Of: odoo/odoo#257821This update fixes an issue where kiosk orders were automatically replaced with generic names like 'Table tracker X'. Now, customers can consistently use the custom order name they initially entered, ensuring accurate order tracking and a better customer experience. This change improves order clarity and reduces potential errors.
Original PR description
Before this commit, when a customer placed an order from a kiosk and provided a custom name, it was systematically overwritten by the backend with a generic "Table tracker X" or the tracking number. task-id: 6014281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue with how dates and times were displayed, specifically regarding the inclusion of seconds. The change restores the original behavior of showing seconds when requested, and clarifies documentation to avoid confusion. This ensures consistent and accurate time formatting across Odoo.
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 ensures that stock landed costs accurately reflect the currency rate used when the invoice was created, regardless of subsequent currency rate changes. Previously, the system used the current date's rate, leading to incorrect cost calculations. This fix updates the calculation to use the invoice's currency rate, improving financial accuracy.
Original PR description
**Issue**: Even if the currency rate is changed on the invoice, the today currency rate is used while generating stock landed cost. **Steps to reproduce**: - Enable two currencies (ex: Dollar and…
**Issue**: Even if the currency rate is changed on the invoice, the today currency rate is used while generating stock landed cost. **Steps to reproduce**: - Enable two currencies (ex: Dollar and Euro) - Enable Landed Costs on the settings - Create a service product - Create a bill for that product for 100 dollar and click the Landed Costs check box - Change the currency rating (ex: 1 USD = 0.5 euro) and confirm the bill - Click on "Create Landed Costs" -> The cost is not 200 **Cause**: While creating the landed cost: https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/stock_landed_costs/models/account_move.py#L21 it uses `_convert` from the currency: https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/stock_landed_costs/models/account_move.py#L35 which gets the `conversion_rate` defined on the currency, regardless whether `is_invoicing` is true: https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/odoo/addons/base/models/res_currency.py#L294 https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/account/models/account_move.py#L6350-L6351 **Solution** It is safe to replace the `convert` calls by the `currency_rate` of the `Account.move.line` since: https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/account/models/account_move_line.py#L735-L747 `currency_rate` will be set as `_get_conversion_rate` when not invoicing. Also add rounding since `_convert` is called with `round=True` by default. opw-6047031 Forward-Port-Of: odoo/odoo#256394
This update resolves an issue where invoice generation would fail if a line item didn't have a tax assigned. The fix adds a check to prevent the system from attempting to calculate tax values when none are present, ensuring invoices are generated correctly even for invoices without taxes.
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 a visual glitch that appeared when formatting tables in the To-Do module. Specifically, applying formatting like bold would create unexpected blank lines above the table. The fix prevents styling of system nodes, ensuring proper layout and a consistent user experience.
Original PR description
Steps to Reproduce - Go to To-Do - Add a table - Type content inside the table - Select all using Ctrl + A - Apply formatting (e.g., Bold) Description of the issue: An empty line appears above the table and the layout shifts unexpectedly after applying formatting. Cause: `data-selection-placeholder` nodes exist before and after the table. These nodes normally have zero height. When selecting all content, these placeholder nodes are also included in the selection. Applying formatting styles them as well, which changes their height from zero. As a result, they become visible and appear as newly added blank lines, even though no new line was actually inserted. Solution Exclude system nodes, such as selection placeholder elements, from formatting operations. This prevents them from being styled and avoids unintended layout shifts. task-5976361 Forward-Port-Of: odoo/odoo#252416
This update resolves an issue where the 'Export XML' button for EU Standard (Peppol Bis 3.0) invoices wasn't functioning correctly. Now, users can download invoices in the required XML format when selecting this eInvoice type, ensuring compliance with Peppol regulations. This improves the process of exchanging invoices with partners in countries like Croatia.
Original PR description
Issue: Export XML button doesn't produce the same file as the send button. Steps to reproduce: - Company in Spain with Peppol (work with any Peppol country) - Partner in Croatia - Select eInvoice…
Issue: Export XML button doesn't produce the same file as the send button. Steps to reproduce: - Company in Spain with Peppol (work with any Peppol country) - Partner in Croatia - Select eInvoice Type as "EU Standard (Peppol Bis 3.0)" - Create an invoice - Confirm it - Click on the Wheel -> Download Current behavior: - without l10n_hr_edi: only "PDF" and "PDF without Payment" - with l10n_hr_edi: "Export XML" appear, but try to create an "ubl_hr" file Cause: "Export XML" button appear only if: - there is a default ubl option for the partner country - there is an XML attached to the invoice when clicked it exports the corresponding one. Whereas, the 'send' button rely on: 1) the partner defined edi format, 2) the default ubl option for the partner country 3) "ubl_bis3" To be noted: The route to download the XML doesn't keep the context of the active company and fallback to the first allowed company. As invoice_edi_format is company dependent it needs to be exported in the format defined for the company of the invoice. opw-5943500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253650
This update ensures the Danish localization for Odoo accurately reflects the latest tax regulations from Denmark. It updates account details, translations, and migration scripts to maintain compliance and provide accurate financial reporting for Danish businesses.
Original PR description
We updated the following in the Danish localization: - Updated the accounts to match the latest version provided by the Danish tax authorities. - Made sure we use the official Danish translations for the accounts and updated all of the English reference translations. - Removed outdated accounts and tags and have a migration script archive them for existing users. - Updated the account groups to match the CoA structure and use the correct Danish and proper English translations. - Adapted the account tags to match the updated accounts/numbers and replaced the outdated ones with their new version on existing accounts. - Removed unused account tags. - Updated some of the default accounts and prefixes on the chart template. task-5929517 Related: https://github.com/odoo/enterprise/pull/112430 Forward-Port-Of: odoo/odoo#257786 Forward-Port-Of: odoo/odoo#256541
This update corrects a previous issue where Point of Sale order reports incorrectly displayed margin values in the wrong currency. The fix ensures that all margin calculations, including the overall order margin, are accurately converted to the company's base currency, providing more reliable reporting for financial analysis. This improves the accuracy of sales data and helps with better business decision-making.
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 addresses a technical issue within the web editor by preventing direct modifications to its history. Removing this functionality also resolves a previous error related to 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 preventing portal users from saving changes to their profile information. The change adjusts how access rights are handled, ensuring a `sudo` is only used when explicitly needed. This improves the user experience for managing their portal profiles.
Original PR description
# How to reproduce - Install the eLearning module - Log in as a portal user - Make sure this portal user has more than 0 karma (Use demo Joel Willis or go through a quick Course) - Go to Courses >…
# How to reproduce - Install the eLearning module - Log in as a portal user - Make sure this portal user has more than 0 karma (Use demo Joel Willis or go through a quick Course) - Go to Courses > View your profile (on the right side) > Edit Profile - Edit any value and confirm by clicking on the Update button # The problem The popup is not saved and a warning notification is displayed with : "You are not allowed to modifiy 'User' (res.users) records" # Why In 19.0, there was no access rights problem because the write operation was done in `sudo` due to this code that checked that every edited field was safe : https://github.com/odoo/odoo/blob/4f77b4c8f7a3ee9f85f045eea02a5749affd4b6a/odoo/addons/base/models/res_users.py#L615 This was the case because we preventively filtered only the safe fields in the save controller : https://github.com/odoo/odoo/blob/355643291e2f4bb05185b996adce6e1f403ecbd4/addons/website_profile/controllers/main.py#L153 In 19.1 though, this commit totally changed the way the acces rights for the fields of the user model were handled : https://github.com/odoo/odoo/commit/a816d151ae16afc62d7980cedc492942bc181884 One of the purpose of this improvement was to make sure a `sudo` is not automatically introduced and rather should be done explicitely when it is needed. # Proposed solution We first check that the current user can modifiy the specified user. If that is the case, we write with `sudo` opw-6032339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a minor issue by allowing users to remove certain account move lines that have been created with incomplete or inaccurate information. Previously, these lines remained in the system, potentially causing confusion. This change streamlines the accounting process by removing unnecessary and outdated entries.
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 kit products were being incorrectly rounded during purchase order valuation, leading to inaccurate cost distribution. The fix ensures that kit product costs are accurately split across components, preventing rounding errors and maintaining accurate financial reporting. This improves the reliability of kit product costing.
Original PR description
### Steps to reproduce: - Create a kit product with 6 bom lines (with a `cost_share` of `0.0%`) - Create + confirm a purchase order for 1 unit of the kit product at 60 - Validate the delivery #### >…
### Steps to reproduce: - Create a kit product with 6 bom lines (with a `cost_share` of `0.0%`) - Create + confirm a purchase order for 1 unit of the kit product at 60 - Validate the delivery #### > 6 layers were created with values 9.99, 10, 10, 10, 10 and 10 There are two issues with purchased kit valuation addressed in this PR: ### Issue 1: Since 8c199f7783527735b35c9fbda334cbdcd55a004f, the product price unit is not supposed to be rounded anymore. However, kit products rely on the rounded `cost_share` field of the `mrp.bom.line` to determine which part of the price of the kit product is handled by which component: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/mrp/models/stock_move.py#L245-L246 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L28 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L38 This leads to inevitable rounding issues where `60/6` does not match `10`: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/tests/test_purchase_mrp_flow.py#L1273-L1275 simply because 1/6 is represented as `16.67%` and not by `16.66666666666666%`. However, values such as 1/6 can be obtained if you do not set any `cost_share`, since the kit explosion will equidistribute its cost share: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/mrp_bom.py#L42-L48 ### Fix of this issue: We set the digits to `False` for stability reason as the columns have been initiallised as "numeric" values and needs to stay numeric: https://github.com/odoo/odoo/blob/b007b0a4f7e56f6dc44df3154e13745c9981eae3/odoo/fields.py#L1627-L1650 Note that when the digit is Falsy on the field, the field value is formatted to the second digit by the front end: https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/web/static/src/views/fields/float/float_field.js#L58-L76 https://github.com/odoo/odoo/blob/12e453302a950df4d9ee45954f54bdf610888eda/addons/web/static/src/core/utils/numbers.js#L214-L227 In particular, when we create the bom and set the `cost_share`, all possible values will be rounded to the second decimal just as before. This change will therefore only alter the rounding behavior in the DB for equidistributed values such as `16.66666666666666%`. ### Issue 2: While the value of the kit product is exploded and distributed among components, the values of each individual `stock.valuation.layer` are themselves rounded before creation based on the company currency: https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/product.py#L240-L255 https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/stock_valuation_layer.py#L30 Now, this is problematic since the sum of the values of the layers is expected to match the total value of the purchase order line (that is, the non-rounded value of the components of the purchased kit). ### Fix of this issue: We compute and distribute the rounding error among layers corresponding to the purchased kit product before creation (since layer values are not expected to be modified afterwards), based on the non-rounded computation, since this value should now be exact (as the unit cost is not rounded anymore). opw-5085457 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253734 Forward-Port-Of: odoo/odoo#252034
This update corrects an 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 and allowing for precise editing. This resolves a visual inconsistency and enhances usability.
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 fixes a minor performance issue in the website's breadcrumb visibility preview feature. Previously, the system unnecessarily saved configuration changes even when simply viewing the preview. This change ensures that updates are only saved when a user actively makes a modification, resulting in a smoother user experience.
Original PR description
The option for the visibility option of the breadcrumbs uses a custom save handler (the same as for the header and the footer). To avoid making the rpc to save the options when nothing has been changed, it keeps a flag telling whether there has been any change. This flag was set when changing the visibility option for the breadcrumb even when simply previewing the option. This commit uses the same strategy as for the header and footer's option, and only set the flag if not previewing. task-5149984
This update allows users to disable automatic PDF generation when importing XML invoices. Previously, Odoo automatically created PDFs for these invoices, even if a PDF wasn't included in the XML. This change provides greater flexibility and control over invoice processing, aligning with user preferences and reducing unnecessary file creation.
Original PR description
Commit 7bc35c4 introduced automatic PDF generation for imported XML invoices that don't include an embedded PDF file. However, this behavior was mandatory and couldn't be disabled. This commit adds a new configuration parameter to allow users disable this behaviour. Task-6050566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257604 Forward-Port-Of: odoo/odoo#254847
This update fixes an issue where caching proxies were incorrectly storing the 'load menus' response, potentially leading to all users seeing the same menu structure. The change ensures that intermediaries like caching proxies don't store this data, improving menu performance and consistency across our user base. This was necessary after a previous change removed the 'unique' parameters used to prevent browser caching.
Original PR description
Since odoo/odoo@ff53267db5d3, the `unique` parameters previously passed to `/web/webclient/load_menus` has been removed. That commit, also instructed the browser not to store the result, but this is not sufficient; in case a caching proxy sits in between the user and Odoo, it will see the `Cache-Control: public` and still store the result. As a consequence, depending on the caching proxy configuration, it could happen to serve the same menus structure to all users. This commit ensures the intermediaries proxies do not store the result. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257064
This update corrects a bug where new Point of Sale orders were sometimes duplicated after validation, particularly when a default customer was assigned. The fix involves a change in how default partners are handled, ensuring that orders are correctly identified as empty and preventing the creation of redundant orders. This improves order processing reliability.
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 fixes an issue where Point of Sale emails were incorrectly displaying times in UTC for users outside of a store. The change ensures that emails accurately reflect the store's timezone, improving the clarity and usability of order confirmations and notifications. This resolves a potential confusion for users regarding order timing.
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 address wasn't specified, the system would encounter an error. This change ensures the system gracefully handles missing IP addresses, preventing the application from crashing and improving stability.
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
18 changes
Resolved issues and error corrections
This update enhances error tracking for invoice processing within the account_peppol module. By including full error tracebacks in logs, developers can quickly identify and resolve issues, leading to faster problem resolution and improved system stability.
Original PR description
This change improves error logging when receiving invoices by including the full traceback in the logs. This provides better visibility into the root cause and simplifies debugging by giving more context around the error. opw-6059877 Forward-Port-Of: odoo/odoo#256619
This update resolves an issue where tours would fail to run after making changes to views using the Studio customization tool. The fix filters out a misleading module entry, 'studio_customization,' that was incorrectly identified as an installed module. This ensures tours function correctly after view modifications.
Original PR description
Step to reproduce: - start a fresh db, install studio and pos - using studio, edit any view (add or remove a field) - run any tour Observation: - we are not able to run any tour Traceback ``` File…
Step to reproduce:
- start a fresh db, install studio and pos
- using studio, edit any view (add or remove a field)
- run any tour
Observation:
- we are not able to run any tour Traceback
```
File "/home/odoo/odoo/codebase/odoo/18.0/odoo/addons/base/models/ir_qweb.py", line 2703, in _get_lazy_bundles_from_js
for fname in glob.iglob('**/static/src/**/*.js', root_dir=modroot, recursive=True):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/glob.py", line 46, in iglob
root_dir = os.fspath(root_dir)
^^^^^^^^^^^^^^^^^^^
TypeError: expected str, bytes or os.PathLike object, not bool
```
Cause:
- `_get_lazy_bundles_from_js` fetches module path for all installed module in addons
https://github.com/odoo/odoo/blob/05d0944a7640e196db989039140ae5ddb12152ac/odoo/addons/base/models/ir_qweb.py#L2686-L2697
- in case we have a view edited, we get the `studio_customization` as installled module, which doesn't have any path in addons. i.e. False
Fix:
- filter out such pseudo-modules from the list
Note: this is not a reported issue, i stumbled across it, hence made a fix
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257806This update resolves an issue where accounting data wasn't correctly handling multiple company setups within the Danish localization (l10n_dk) module. The change ensures that accounting records are now associated with the correct company, improving data accuracy and compliance. This update was made after addressing a previous bug report.
Original PR description
Fixes https://github.com/odoo/odoo/pull/257623. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the formatting toolbar would unexpectedly open when selecting text within inline code. Now, formatting commands only apply to the main text content, and pasted HTML within inline code is correctly converted to plain text. This ensures a smoother and more reliable experience for users working with code snippets.
Original PR description
### Purpose of this commit: - Prevent the powerbox and toolbar from opening when the selection is fully inside inline code. When the selection spans inline code and regular text, keep the toolbar visible but ensure formatting commands are applied only to the non-inline-code content. - Ensure that pasted external and editor HTML is converted to plain text when inserted inside inline code. task-5502939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where marketing emails in RTL languages (like Arabic) were incorrectly displayed as left-to-right. The fix adds a necessary style rule to ensure proper formatting by the email composer, maintaining the intended RTL layout. This improves the user experience for international customers.
Original PR description
**Steps to reproduce:** - Install Mail Marketing app - Change user language to a RTL language (such as Arabic) - Create a marketing campaign with RTL content - Send it (with the campaign, test mail works properly) - Mail received changes from RTL to LTR **Issue:** Table `direction` style is removed by the `_Cleaner` as it is not in its `_style_whitelist` during the composer creation. **Fix:** Add it to the valid styling to ensure rtl mails are properly formatted by the rtlcss library. related fix: https://github.com/odoo/odoo/commit/4ac3766fa5b458864c1728441cf4a157df943d39 sanitize on `mail.composer.mixin`: https://github.com/odoo/odoo/commit/24731938f75358fd3c72b91465b72ab80d62d208 opw-5982854
This update resolves a problem where custom paper format settings for lot/serial number labels resulted in multiple blank pages in the PDF output. The fix adjusts the underlying report design to correctly handle smaller paper sizes, ensuring labels print accurately and efficiently.
Original PR description
__ ## Short functional explanation of the error When printing labels of lot or serial products with a custom paper format, the obtained pdf contains several empty pages. ## Reproduction Steps 1.…
__ ## Short functional explanation of the error When printing labels of lot or serial products with a custom paper format, the obtained pdf contains several empty pages. ## Reproduction Steps 1. Enable Debug Mode. In Settings, click on the Technical tab. In the reporting section, click on Paper Format. 2. Click on New. Give a name to your paper format. In the Paper Size field, select Custom. For Page Height and Page Width, make sure that they're smaller than A4 measurements. For example, set the Page Height at 57 and Page Width at 35. Set Margins at 0. In the Associated Reports field, select `lot/Serial Number (PDF)`. 3. Go to Inventory. Click on the Products tab > Lots / Serial Numbers. Click on any Serial Number. Click on the Cog on the top left > Print > Lots / Serial Number (PDF). ### Expected behavior We obtain a PDF of only one page containing the barcode of the serial number. ### Unexpected behavior We obtain a PDF of 5 pages, including 4 blank pages and only one page holding the barcode. ## Origin of the issue In the XML of the label reports, we use the css class `o_label_sheet`: https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/stock/report/report_lot_barcode.xml#L9 In this class, the height and width of sheets are hardcoded to A4 dimensions: https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/product/static/src/scss/report_label_sheet.scss#L5-L6 Therefore, if we set the dimensions of the custom paper format to be smaller than an A4 page, we'll obtain several blank pages, until the dimensions of an A4 pages are met. Moreover, the dimensions of the padding are also hardcoded, which can be an issue in the case of very small custom dimensions. Finally, we nest barcodes in an HTML table: https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/stock/report/report_lot_barcode.xml#L10 for which we hardcode the dimensions: https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/stock/report/report_lot_barcode.xml#L6-L7 This will result in always printing the same amount of barcodes per row in the case of batch printing, even if the dimensions are too small to hold them all. This will also result in always nesting 12x4 barcodes, even when only printing one, while hiding the others, which also produces additional unrequired blank pages. Therefore, we need the dimensions indicated in the paper format of the report to dynamically compute the dimensions of the padding and the rows/columns of the HTML table. __ opw-6071885
This update fixes an issue where Backspace within a blockquote would remove the blockquote itself, moving content outside. It also resolves problems with trailing line breaks after tables and prevents lists from being created inside blockquotes. These changes enhance the editor's usability and allow for more flexible content formatting.
Original PR description
Description of the issue this PR addresses: - Pressing Backspace inside a blockquote that has visible content but no text content removes the blockquote instead of the content. The content (image or table) gets moved outside of the blockquote. - Trailing BR was kept after tables because tables are marked as unsplittable blocks. This left unnecessary BR nodes after tables in blockquote. - Lists could not be created inside a `blockquote`. Desired behavior after PR is merged: - Backspace removes the inner content first when blockquote contains nodes. - Trailing BR is removed when placed table inside blockquote. Cursor can still be placed at the edge of the table without requiring a BR anchor. - Lists can be created directly inside a blockquote. task-5864080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a flaw in how the digest KPI tracks user connections. Previously, it only considered a user's 'Default Company,' leading to inaccurate counts for users working across multiple companies. Now, the KPI correctly accounts for all companies a user belongs to, providing a more reliable measure of user engagement.
Original PR description
**Problem:** Currently, the digest KPI for connected users checks the "company_id" field (as with all other models), but this field corresponds to "Default Company" on res.users, meaning a user can only be considered for one company when computing the digest KPI. This can cause misleading digest KPIs if users work in multiple companies, or mainly in a company that isn't their default company. **Solution:** Instead of always using the "company_id" field, we use the "company_ids" field if present on the model. opw-5404940 Forward-Port-Of: odoo/odoo#247806
This update resolves an issue where empty attachments during PEPPOL invoice imports could cause errors and prevent invoice creation. The fix safely falls back to default settings, ensuring invoices are created and any errors are logged, improving invoice processing reliability. The root cause of the empty attachments is currently being investigated.
Original PR description
Empty attachments could crash parsing during import, this commit falls back on default journal and move type in case of error, allowing the invoice to be created and the issue logged properly. Root cause of empty XML remains unclear, likely a 3rd party error. opw-6060739 opw-6018364
This update ensures that attachments uploaded to cloud storage retain their original file type (mimetype). Previously, the system was incorrectly guessing the file type, which could lead to issues with file display and functionality. This fix improves the reliability of cloud storage attachments.
Original PR description
When uploading an attachment to cloud storage via `_post_add_create(cloud_storage=True)`, the attachment's original `mimetype` is guessed even if we specify it. With this commit we explicitly preserve given mimetype Discovered during task-5153790
This update resolves a technical issue that was preventing the system from correctly validating software package requirements. Specifically, the system could not handle version strings with non-integer components like 'post1'. This fix ensures accurate requirement checks, improving system stability and reliability.
Original PR description
This commit fixes a crash in the parse_version() function where it doesn't support non-integer castable version parts (i.e. 5.4.2.post1).
This update corrects a previous issue where loyalty point transactions in a single POS order were only recorded as a net difference. The fix now accurately tracks both points earned and spent, ensuring a complete and precise record of loyalty card activity in the system. This improves the reliability of loyalty program reporting.
Original PR description
When a loyalty card both earned and spent points in the same POS order, the history entry only reflected the net difference instead of the gross amounts. The root cause was that the JS payload sent only a single `points` field representing the net change. Fix by tracking `points_earned` and `points_spent` separately in `couponData` and sending them to the server. opw-6041420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where invoices for downpayments weren't consistently using the correct expense account. The change ensures that downpayment invoice lines now automatically use the designated account (ACC1) when creating bills, streamlining the accounting process and improving accuracy. This resolves a previous error related to downpayment accounting.
Original PR description
Steps to reproduce: 1/ install purchase and accountant 2/ create and setup an expense account dedicated to your downpayments (typically code 60-, account type "expense"), ACC1. 3/ setup a service type product named "downpayment" 4/ set the default expense account on that product to be ACC1. 5/ create a PO for any product other than the downpayment (PO1). take note of the partner. 6/ create a bill for the same partner as the one set on PO1. Call it BILL1. 7/ On BILL1, add one invoice line with the "downpayment" product. Set a unit price. 8/ Confirm BILL1 and match it with PO1 via the "bill matching" smart button. Add it as a downpayment. 9/ Back on PO1, receive the products. Create a bill (BILL2). => The account suggested for the downpayment line in BILL2 will use the default expense account instead of ACC1. After this commit, the account suggested will be the one used in BILL1 for the downpayment line. opw-5253877
This update fixes an issue where floors were incorrectly displayed in the restaurant's point-of-sale (POS) system. Previously, floors were loaded through indirect processes, leading to inaccurate selections. Now, the system correctly uses the configured floor IDs for each POS setup, ensuring accurate floor selection for restaurant staff.
Original PR description
Floors loaded indirectly (e.g. via recursive loading of paid orders) could appear in the floor selector even if they belonged to a different PoS config. The selector was iterating over the full in-memory model store instead of the floors explicitly assigned to the current config. opw-6025172 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where attendance records were incorrectly flagged as 'already checked-in' due to a timezone calculation error. The fix ensures accurate attendance tracking by correctly applying employee timezones when determining absence times, regardless of the database timezone.
Original PR description
### Steps to reproduce: - Have a database in timezone America/Asuncion for example - Create an employee - Create an attendance for the day before yesterday from 13h to 19h - Run the absence detection cron - An error will be raised saying the user is already checked-in on that day ### Cause: When trying to create an absence attendance we localized yesterday's midnight into UTC and then apply the employee timezone. Which cause a one-day shift when having a timezone behind UTC as at that point we try to create an attendance on the day before yesterday not yesterday ### Fix: We use the timezone of the employee to localize midnight then get this time in UTC. opw-5930309
This update resolves a problem where the POS cashier user couldn't correctly process ZATCA EDI documents due to a lack of necessary permissions. The change ensures the system elevates privileges when writing to these documents, preventing errors and enabling proper transaction processing. This improves the reliability of the POS system for Saudi Arabia.
Original PR description
The POS cashier user does not have the Accounting group, so calling _process_documents_web_services() on account.edi.document without elevated privileges raises an AccessError on the write() in _postprocess_post_edi_results. The original flow avoids this because _generate_and_send_invoices uses move.sudo() as the dict key, propagating the sudo context through action_process_edi_web_services() down to the EDI document write. Our override must do the same by accessing edi_document_ids via account_move.sudo(). opw-6106524 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a silent error in the Nilvera EINvoice module, which prevented proper invoice imports. The method name was incorrectly updated, causing the override to be ignored. By renaming the override to match the parent class, the import process is now functioning as intended.
Original PR description
# Description of the issue/feature this PR addresses The parent class `account.edi.xml.ubl_20` renamed `_import_fill_invoice_form` to `_import_fill_invoice`. The override in `l10n_tr_nilvera_einvoice` was not updated to match, causing the override to be silently ignored. # Current behavior before PR The `_import_fill_invoice_form` override in `l10n_tr_nilvera_einvoice` is never called because the parent method no longer exists under that name. # Desired behavior after PR is merged The override is renamed to `_import_fill_invoice` to match the parent class, restoring correct behaviour for Nilvera invoice imports. task-id: None --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that new purchase orders, repairs, and stock picking batches display translated names instead of 'New' in English. This change aligns with existing Odoo logic, providing a more consistent and user-friendly experience, even before records are saved.
Original PR description
New POs, repairs, and batch pickings always showed "New" in English for the name of a new (not saved) record. We now make it match the SO logic to show up as translated so as to not confuse users (even though it will automatically change to another name once saved) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
10 changes
Resolved issues and error corrections
This update enhances error tracking for invoice processing within the account_peppol module. By including full error tracebacks in logs, developers can now quickly identify and resolve issues related to invoice receipt, leading to faster problem resolution and improved system stability.
Original PR description
This change improves error logging when receiving invoices by including the full traceback in the logs. This provides better visibility into the root cause and simplifies debugging by giving more context around the error. opw-6059877 Forward-Port-Of: odoo/odoo#256619
This update prevents the system from deleting user-modified views (COW views) during a routine cleanup process. Previously, these views were incorrectly identified as orphaned and removed, disrupting website customizations. The fix ensures that only truly orphaned views are deleted, preserving user-created content.
Original PR description
**Description** This PR fixes an issue where COW views created by users were being deleted during `_theme_cleanup`. **Issue:** [odoo/odoo#233723](https://github.com/odoo/odoo/issues/233723) ### Explanation The `_theme_cleanup` method deleted all views with `theme_template_id=False`. COW views created when users edited generic views also had `theme_template_id=False` because the field has `copy=False`. As a result, the method couldn’t distinguish between true orphans and user customizations. ### Solution Before deleting, the cleanup process now checks if a generic parent view exists. Only views without generic parents (true orphans) are deleted. task-5248173
This update corrects a bug preventing the correct setting of a unique identifier (UUID) for Nilvera electronic invoices during import. The method name in the Nilvera module was out of sync with a recent update to the core Odoo system. Merging this change ensures that Nilvera invoices are imported correctly and reliably.
Original PR description
# Description of the issue/feature this PR addresses The parent class `account.edi.xml.ubl_20` renamed `_import_fill_invoice_form` to `_import_fill_invoice`. The override in `l10n_tr_nilvera_einvoice` was not updated to match, causing the override to be silently ignored. # Current behavior before PR The `_import_fill_invoice_form` override in `l10n_tr_nilvera_einvoice` is never called because the parent method no longer exists under that name, so the Nilvera UUID is not set on imported invoices. # Desired behavior after PR is merged The override is renamed to `_import_fill_invoice` to match the parent class, restoring correct behaviour for Nilvera invoice imports. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug preventing automatic stock reservations when products arrive at child locations within the warehouse. The change ensures that outbound moves from any parent location are considered, allowing for correct inventory tracking after receiving stock. This improves order fulfillment accuracy and prevents stock discrepancies.
Original PR description
Steps to reproduce 1. Create a product with no stock 2. Confirm a delivery order sourced from WH/Stock 3. Receive the product via a purchase order into WH/Stock/Shelf 1 (a child of WH/Stock) 4.…
Steps to reproduce
1. Create a product with no stock
2. Confirm a delivery order sourced from WH/Stock
3. Receive the product via a purchase order into WH/Stock/Shelf 1 (a child of WH/Stock)
4. Observe that the delivery is not automatically reserved
Issue
_trigger_assign builds a domain to find outbound moves to re-attempt reservation after a receipt is validated. The domain used an exact match ('location_id', '=', move.location_dest_id.id), so only moves whose source location was identical to the receipt's destination were considered. A move sourced from WH/Stock was never found when stock arrived at a child like WH/Stock/Shelf 1, even though _action_assign already uses child_of internally to gather available quants from sub-locations.
Solution
Replace '=' with 'parent_of' so that when stock arrives at a child location, _trigger_assign also wakes up moves sourced from any ancestor of that location. The reservation attempt itself is already correct — _action_assign with strict=False searches child locations — so only the trigger was missing.
opw-6052753This update resolves an issue where archived product filters were failing in Odoo 17.0. The fix ensures that display names are correctly loaded for archived records, allowing them to be included in spreadsheet global filters and improving overall filter functionality. This ensures accurate reporting and data access for archived items.
Original PR description
## Description: Steps to reproduce: - Open Dashboard > Sales > Sales. - Search for an item to filter. - Click the "Product" filter. - Click "Search more". - Search for an archived product. - Select it to add it to the filter. Issue: The filter needs `nameService.loadDisplayNames()` to resolve the label of the selected record ids. In 17.0, that service calls `webSearchRead()` without `active_test=False`, so archived records are filtered out and treated as missing. This makes spreadsheet global filters fail on archived records. Fix: Fetch display names with `active_test=False` in the shared web `nameService`, so already-known archived record ids can still be resolved. Task: [6094596](https://www.odoo.com/odoo/project/2328/tasks/6094596) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical issue where sending snailmail letters with a large number of pages (over 8) would result in a generic error. The change provides a more specific error message to help users quickly identify and resolve this problem, improving the overall user experience.
Original PR description
When a user attempted to send a letter with snailmail that had more than 8 pages, sending would fail, and a generic error message is logged on the letter. This commit makes the error message generated in that flow more specific to help users better understand the root cause of sending failure. task-5883011
This update fixes an issue where invoicing a Point of Sale order multiple times would create unnecessary stock pickings. This prevented incorrect inventory tracking, particularly when using the 'Anglo-Saxon' invoicing method and automatic stock updates. The change ensures that stock pickings are only created once, regardless of how many times an invoice is generated.
Original PR description
Calling `action_pos_order_invoice` on an already-invoiced POS order (e.g. a backend user clicking "Invoice" more than once) would unconditionally invoke `_create_order_picking`, producing one extra `stock.picking` per click under anglo-saxon + update_stock_at_closing configurations. opw-6092999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where deleting a project stage caused unexpected view behavior, switching to a filtered tasks view and displaying archived tasks. The fix ensures the original view remains active and the stage is properly removed, improving the user experience during stage deletion.
Original PR description
# Steps to reproduce 1. Create a project 2. Create a stage 4. Remove the stage # Current behavior Instead of remaining in the project tasks view, it switches to the tasks view filtered with the current project. Additionally, it displays archived tasks because no filter is selected, thereby discarding original ones. This also applies to stage deletion in other views (e.g., My Tasks), where the search filters are completely discarded. # Expected behavior The dialog should be closed, the stage should be deleted, and the original view should remain active. This is done through a soft-reload of the page, ensuring the original view is kept, together with original breadcrumbs, and the stage is visually disappearing. task-5498274
This update corrects a bug that prevented KPI cards (Billable Hours, etc.) from accurately reflecting data when global filters were applied. The issue stemmed from a hardcoded filter limiting data to a single user, causing incorrect results with other filters. This fix ensures KPI cards display correct data based on applied filters.
Original PR description
Steps to reproduce: - 1. Go to the dashboard app > Timesheets. 2. Apply any global filter. Issue: - The main KPI cards (Billable Hours, Non-billable Hours, Billable Rate) do not update correctly when any global filter is applied. Filtering by 'Employee' causes the cards to show zero. Other filters like 'Project' or 'Department' show incomplete and incorrect data, reflecting only the timesheets of a single hardcoded user. Cause: - The pivot tables (`pivot 5` and `pivot 6`) that source the data for the KPI cards contained a hardcoded domain `['user_id', '=', 2]`. This condition changes any selection made in the global filter and shows incorrect data. Fix: - The hardcoded `['user_id', '=', 2]` condition has been removed. task-4782213
This update fixes a bug where creating a new sale order line would inadvertently generate a duplicate Sale Order. The fix ensures existing Sale Orders are reused when new lines are added, streamlining the order creation process and preventing unnecessary order duplication. This improves data accuracy and efficiency.
Original PR description
_*= sale_project **Issue:** When a new sale order line is created on the fly, a new Sale Order is being created instead of reusing an existing one. **Root Cause:** This happens when the project_sale_order is not being passed correctly in the context, causing a new Sale Order to be created. **Fix:** Explicitly pass the default_order_id in the context. If an existing Sale Order is found, it will be reused instead of creating a new one. **Technical Details:** Updated the `default_order_id` to use sale_order_id instead of `project_sale_order_id` in `sale_project`. This ensures that the field functions correctly even when `project_sale_order_id` is empty. **task-4276677** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr