Daily updates from Odoo
Friday, March 6, 2026
47 changes · saas-19.2
Resolved issues and error corrections
This update corrects a problem with how leave periods are calculated, specifically addressing potential inconsistencies caused by differences in time zones. By using a new date field, the system now accurately reflects leave periods regardless of where the employee is located, ensuring correct payroll processing.
Original PR description
This commit fixes the leaves work interruption constraint by replacing `date_from` and `date_to` with `request_date_from` and `request_date_to`, thereby resolving any inconsistencies that may arise from time zone differences. task-5966780 Forward-Port-Of: odoo/enterprise#109421 Forward-Port-Of: odoo/enterprise#108541
This update addresses a technical issue within the Odoo `l10n_vn` module related to tax report testing. The change involves updating a tax label to ensure existing tests pass, improving the reliability of the tax reporting functionality for Vietnamese users. This resolves a previously failing test and ensures accurate reporting.
Original PR description
Updates in the `l10n_vn` module revised a tax label. We update it here to pass otherwise failing tests. task-[5904297](https://www.odoo.com/odoo/all-tasks/5904297) odoo-[251906](https://github.com/odoo/odoo/pull/251906)
This update resolves a recurring issue in the l10n_ph_reports_asset module's test suite. The problem stemmed from how daily depreciation calculations were handled, specifically when dealing with leap years, which caused intermittent test failures. This fix ensures accurate depreciation reporting, particularly during leap years.
Original PR description
The test suite fails intermittently due to leap years affecting daily -computed depreciation runbot-[241145](https://runbot.odoo.com/odoo/runbot.build.error/241145)
This update fixes an issue where highlight colors were difficult to see in Odoo's dark mode settings. The change ensures text is black, significantly improving readability and the user experience when navigating the settings interface.
Original PR description
Before this commit, highlights were not readable when searching on the settings in dark mode. Now, we force the text color to black to improuve the contrast and redability. task-id 6003446 Forward-Port-Of: odoo/odoo#251979
This update resolves a technical issue that prevented users from correctly ordering stock when using the replenishment multiple feature. The fix corrects a calculation error within the stock management system, ensuring accurate order quantities are generated. This improves the reliability of stock replenishment processes.
Original PR description
Backport of: https://github.com/odoo/odoo/commit/fe806166968d55a70f5bf335dcb3633e18d8ecc7 Steps to reproduce: - Create a storable product “P1”: - UoM: Unit and Pack of 6 - Purchase tab: add any vendor - Go to Replenishment and create a new rule: - Product: P1 - Min: 10 - Max: 100 - Replenishment Multiple: Pack of 6 - Select the line and click “Replenish” → “Order to Max” Issue: A traceback is raised: “TypeError: unsupported operand types in: uom.uom(2,) - 4.0” In `_get_qty_to_order`, we compute the quantity to order and then adjust it according to the replenishment multiple, but we try to Subtract the rounded remainder from the uom (which is a recordset) instead of the quantity (which is a float). opw-5947919 Forward-Port-Of: odoo/odoo#251756 Forward-Port-Of: odoo/odoo#250608
The loyalty program's redemption popup now correctly displays the program name instead of a generic 'Gift Card' message. This change also uses the appropriate currency symbol for points, providing a clearer and more accurate representation of the customer's reward. This enhances the user experience and ensures consistent messaging across all loyalty programs.
Original PR description
Currently, the popup message shown when redeeming a code is the same for all programs but is always displayed as if it was a giftcard. Steps to reproduce: ------------------- * Create a program of type coupon, points unit: Coupon points, currency: USD * Create x coupons with 5 points * Copy a coupon code * Open shop * Enter code > Popup message says: Gift card: *code*, Balance: $ 5.00 Why the fix: ------------ Since this popup is used for multiple program we try to make it as generic as possible. Now we'll use the prgram name instead of the generic "Gift Card" string. Instead of formatting the points with the currency we can use `points_display` as it reflects the currency symbol or point unit name accordingly. <img width="416" height="82" alt="image" src="https://github.com/user-attachments/assets/a4c3c1ef-e02f-4618-809f-4bff5d99c948" /> opw-5220834 Forward-Port-Of: odoo/odoo#249312
This update fixes a UI issue related to work order completion dates and excludes subcontracted productions from the Kanban view. These changes enhance the clarity and usability of the work order management process, ensuring accurate tracking and reporting.
Original PR description
A few UI Fixes. Fix date_finished when setting a workorder 'in progress'. Exclude subcontracted productions from Kanban view. task: 5945452
This update resolves an issue where work orders weren't correctly displayed in the Kanban view, particularly for subcontracted productions. It also fixes a bug related to accurately reflecting the status of work orders as 'in progress'. This ensures a more accurate and reliable view of work order activity.
Original PR description
A few UI Fixes. Fix date_finished when setting a workorder 'in progress'. Exclude subcontracted productions from Kanban view. task: 5945452
This update fixes several issues within the Odoo spreadsheet component, ensuring it's running the latest version compatible with the 19.2 release. These fixes improve the dynamic pivot table functionality and address minor UI inconsistencies, enhancing the user experience.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ccf90d6262 [REL] 19.2.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ccf90d6262 [REL] 19.2.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5883e326cd [FIX] Dynamic pivot: header alignment [Task: 5922279](https://www.odoo.com/odoo/2328/tasks/5922279) https://github.com/odoo/o-spreadsheet/commit/a714ce64b1 [FIX] chart-panel: reset when changing panel [Task: 5926661](https://www.odoo.com/odoo/2328/tasks/5926661) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update adjusts the minimum and maximum amounts for employee mobility budgets each year, aligning with local regulations. The changes ensure accurate budget calculations and support employee relocation needs. This is a routine maintenance update.
Original PR description
Each year the minimum and maximum amount of mobility budget is indexed, here are the new values. Forward-Port-Of: odoo/enterprise#109641
This update resolves an issue where rapidly clicking the 'Back' button during barcode internal transfer creation resulted in duplicated quantities being added to the transfer. The fix prevents multiple 'save' calls, ensuring accurate quantity tracking.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By…
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By Quantity** and set some *barcode* * Update the on-hand quantity for the product and assign it to one packages. * Open *Barcode > Operations > Internal Transfer* and create a new transfer. * Click the *gear icon* in the top-right corner to open the barcode scanning flow. * manually enter the created product barcode and apply it. * Click the **Back** button multiple times in quick succession. * Go to the backend and open the created internal transfer. **Observed behavior:** * The internal transfer is created with *double quantities* compared to what was added in the barcode interface. **Cause:** * When clicking the *Back* button, the following flow is triggered: `exit()` → `beforeQuit()` → `save()`. https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483 * If the button is clicked multiple times rapidly, `exit()` is called again before the previous `save()` RPC completes. * This results in multiple `save()` calls being executed, causing duplicated quantities on the picking. reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74 **Fix:** * Prevent rapidly clicking the Back button multiple times does not multiply quantities. --- opw-5375899 Forward-Port-Of: odoo/enterprise#109013 Forward-Port-Of: odoo/enterprise#103130
This update fixes an issue where large category images in the Point of Sale selector would overflow, obscuring the category name. The change adjusts the layout to ensure images are appropriately sized, preventing overflow and improving the visual clarity of the selector. This enhances the user experience for product selection.
Original PR description
Before this commit, when a category image was too large, it would overflow and take all the space dedicated to the category name. Now we set the width of the image to 1/3 of the button and the name to 2/3, so that the image never takes too much space. task-id: 5462315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249368 Forward-Port-Of: odoo/odoo#242054
This update corrects a rounding issue that caused incorrect pricing when ordering combos with multiple identical items in Point of Sale. The fix involves adjusting how line prices are calculated to ensure accurate totals, resolving a discrepancy between the displayed price and the backend calculation. This ensures consistent pricing for combo orders.
Original PR description
**Steps to reproduce:** - Create a combo, set the free and max to 3 - Create the product combo and set it's price to 50 - Go to PoS, order said combo and chose the same product 3 times - The price is…
**Steps to reproduce:** - Create a combo, set the free and max to 3 - Create the product combo and set it's price to 50 - Go to PoS, order said combo and chose the same product 3 times - The price is 49.98 instead of 50 **Problem:** When ordering a combo and taking the same product multiple times, the method to adjust the price does not work as it should. In this case, the method would subtract too much from the total, leading it to be only 49.98 instead of 50. **Why the fix:** This happens because when ordering a combo, each line will get it's price_unit from the combo's price divided by the number of lines. In the case where we have 3 different products, hence 3 different lines, the first two would have a unit_price of 16.67 and the last line will be adjusted as to make it equal to the combo's price, so the last line would be 16.66, making the sum 50. But in the case where there is only one line, the last line is still adjusted, making all the lines 16.66, introducing this error. The solution would be to take the line's qty into account when computing how much we should subtract. Unfortunalty, doing so will, in some cases, introduce a rounding error. If the new unit_price does not round up well (like in this case where it is 16.666668 before rounding and 16.67 after), the rounding will cause a difference between what's shown in the frontend and what's written on the lines in the backend, as the lines are rounded up again before being saved to the backend. The introduced solution is to split the lines, and each have a quantity of 1. With this solution, we can have a different price_unit for each line, which resolves our problem, as the first two lines will have 16.67 and the last one will have 16.66 as price_unit. This is how it was done up until version 18.0, showing every line with a quantity of 1 instead of grouping them. As the grouped lines are now single, some rounding with taxes might differ from what it was before, which is why a test was altered. opw-4931215 Forward-Port-Of: odoo/odoo#247995 Forward-Port-Of: odoo/odoo#221189
This update resolves a problem where Odoo couldn't send email templates without a linked record. A recent change in the core system caused this to fail. This fix ensures email templates can now be sent regardless of whether a record is associated, maintaining reliable email functionality.
Original PR description
Add explicit support for sending an email template with no actual record, i.e., calling `template.send_mail(False)`. This used to work but now fails since https://github.com/odoo/odoo/pull/227477. task-6000637 Forward-Port-Of: odoo/odoo#252076
This update fixes an issue where editing recurring events synced from Outlook would trigger unwanted emails to attendees. The change prevents Odoo users from directly modifying Outlook-created recurring events, streamlining the synchronization process and reducing unnecessary notifications. This improves the user experience and avoids potential communication overload.
Original PR description
## Issue: Recurring events created from Outlook should not be able to be edited from Odoo, this is because the changes made are going to be sending unwanted emails to the attendees. ## Steps to…
## Issue: Recurring events created from Outlook should not be able to be edited from Odoo, this is because the changes made are going to be sending unwanted emails to the attendees. ## Steps to reproduce: 1. Connect to Outlook and Sync for user A. 2. Create a recurring event from Outlook. 3. Connect into a user B with access to the event and edit all the events from the series. 4. Run the scheduled action to sync user A. 5. Many emails are going to be sent to the attendees from Outlook. ## Solution: With the current implementation, we are going to avoid editing for the users connected to Outlook, however any user with the access to that event in Odoo and that it has not synced with Outlook is going to be able to edit the event. To avoid this, we should check if the event is recurring and it has been created from Outlook, for this we are going to be looking for the event `microsoft_recurrence_master_id` which will be available only for the recurring events created from Outlook. opw-4374503 Forward-Port-Of: odoo/odoo#252079 Forward-Port-Of: odoo/odoo#199663
This update corrects an issue in the holiday test data, ensuring it aligns with country-specific work entry types. The changes involve moving incorrectly defined work entry types to the correct module, `hr_work_entry`, improving the reliability of testing and the overall functionality of the holiday scheduling feature.
Original PR description
In this commit, we address the issue of types being generic in the tests, when they should be country specific. Task-6004338 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug that caused duplicate Dimona activities to be created when updating employee versions or running automated payroll processes. The change ensures that only one Dimona activity is generated per employee, streamlining payroll calculations and preventing data inconsistencies. This improves the accuracy and reliability of payroll reporting.
Original PR description
This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated. The original bug was: create an instance on…
This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated. The original bug was: create an instance on saas-18.4 with l10n_be_hr_payroll settings > company > my company > update infos > country: Belgium employee > new > payroll > contract > start_date: any date (this should create a first dimona activity) settings > technical > automation > scheduled actions > "HR Employee: Update Current Version" > run manually `_trigger_l10n_be_next_activities` in `hr.version` of `l10n_be_hr_payroll` is duplicating Dimona activities on records that already have one. We check if a dimona activity already exists for a given `hr.employee` before creating the new activity. Same is done for dimona declaration of part times. The activity now redirects to the employee form (instead of the version form) and appears in it. [tasks-5134380](https://www.odoo.com/odoo/project/1251/tasks/5134380) Forward-Port-Of: odoo/enterprise#109605 Forward-Port-Of: odoo/enterprise#96423
This update fixes an issue where emails weren't automatically sent to candidates when they were refused through the recruitment process. The fix ensures that a rejection notification is properly delivered to the applicant's email address, improving candidate communication and transparency. This resolves a reported bug impacting the recruitment workflow.
Original PR description
## Short functional explanation of the error When a candidate is refused, an email isn't sent to their email address. ## Reproduction Steps 1. Open Mailhog in a separate tab. 2. Go to the Recruitment…
## Short functional explanation of the error When a candidate is refused, an email isn't sent to their email address. ## Reproduction Steps 1. Open Mailhog in a separate tab. 2. Go to the Recruitment app and select any job position. 3. Click on new to create a new application. Enter an applicant name and an applicant email. 4. Check Mailhog: a job application has been sent to the applicant. 5. Go back on the Recruitment app and click on Refuse. In the wizard, make sure you toggle Send Email and click on Refuse. ### Expected behavior In Mailhog, a refusal mail has been sent to the applicant. ### Unexpected behavior Nothing is sent. ## Origin of the issue When refusing a candidate, we create a notification in the chatter but an email isn't sent. This is due to the `incoming_email_to` field, which is checked here: https://github.com/odoo/odoo/blob/bfc1c210eca65de1116aa09cdd62749ed9192407/addons/mail/models/mail_thread.py#L4040-L4053 but because this field is already retrieved here: https://github.com/odoo/odoo/blob/bfc1c210eca65de1116aa09cdd62749ed9192407/addons/mail/models/mail_thread.py#L4025 the last condition will always be true, preventing the recipient's data to be added to the message, thus preventing the message to be sent correctly. Note: as of 19.0, the field `outgoing_email_to` can be used to determine the recipient's email address. Note: we remove `'body_is_html': True` because this field is misused in this case: when set at true, the field is always considered as HTML __ opw-5980079 Forward-Port-Of: odoo/odoo#252036
This update resolves an issue where deleting a workspace (folder) linked to a folder setting would trigger a database error. The fix prevents the deletion of these folders during the system's automatic cleanup process, ensuring data integrity and stability. This improves the reliability of the Documents module.
Original PR description
When a workspace(folder) linked to a folder setting is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install…
When a workspace(folder) linked to a folder setting is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install ``documents_account`` module - Go to Documents > Configuration > Files Centralization > Enable Accounting > Select any workspace > Save > - Click on Journals > Create a new > Select any Journal > Create a Workspace A > Save - Go to Documents > Click on Workspace A > Actions > Move to trash - Run the ``Base: Auto-vacuum internal data`` cron Traceback: ```py ForeignKeyViolation: update or delete on table "documents_document" violates foreign key constraint "documents_account_folder_setting_folder_id_fkey" on table "documents_account_folder_setting" ``` solution: override the ``_get_gc_clear_bin_domain`` method to exclude folders linked to folder settings, preventing their deletion during the garbage collection. sentry-7193540869 Forward-Port-Of: odoo/enterprise#109636 Forward-Port-Of: odoo/enterprise#104875
This update resolves an issue where by-products tracked with serial numbers incorrectly displayed extra lines in the shop floor manufacturing order view. The change ensures by-products only show lines that are manually added, aligning with the intended workflow. This improves the clarity and accuracy of shop floor data.
Original PR description
When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in…
When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in shopfloor MO cards (both in overview and work center views). Steps to reproduce: 1. Create a bill of materials for a final product 2. Add a consumable component 3. Create an operation without steps 4. Add a by-product tracked by serial number 5. Specify that the by-product is produced in the operation above 6. In Inventory > Configuration > Operations Types, open the Manufacturing operation type, go to the Traceability section and enable "Pre fill lot/serial numbers in shop floor moves" 7. Create a manufacturing order for the BOM and confirm it 8. Open the Shop Floor view from the MO 9. Observe the extra line for the by-product in both overview and work center views Root cause: The visibleMoveLines getter in stock_move.js was showing ALL move lines (including unpicked ones) when picking_type_prefill_shop_floor_lots was enabled, without distinguishing between raw materials/components and by-products. By-products should never show pre-filled lines since users must register them manually by clicking the + button. Solution: Modified the visibleMoveLines getter to always filter by-products to show only picked move lines, regardless of the prefill_shop_floor_lots setting. This ensures by-products only display lines that have been explicitly registered by the user, while regular components continue to show pre-filled lines when the setting is enabled. Task-5431295 Forward-Port-Of: odoo/enterprise#109689 Forward-Port-Of: odoo/enterprise#103260
This update resolves an issue where users were seeing duplicate settings options (like 'Minimum Digits') when configuring widget types in Odoo Studio. The fix involves a technical workaround to prevent the duplication of label content generated by the underlying OWL2 framework, ensuring a cleaner and more consistent user experience.
Original PR description
steps: - Install Project and Studio - Open studio, add a decimal field - Click on it - There are two "Minimum Digits" instead of "Digits" & "Minimum Digits" Add dummy `t-set` nodes before `t-esc` directives in property sub-templates to prevent label content from being rendered twice. This is a known OWL bug (https://github.com/odoo/owl/issues/1610) where `t-esc` inside a named slot gets duplicated. Since the issue lies in the OWL2 framework itself, a `<t t-set="__dummy"/>` is used as a workaround to break the duplication pattern in owl2. opw-5974611 Forward-Port-Of: odoo/enterprise#109694
This update resolves an issue where commission reports were incorrectly handling large numeric IDs, leading to potential data conflicts. By ensuring the full ID is always used, the system now accurately identifies and manages commission records, improving report reliability. This fix addresses a technical problem that could impact commission calculations.
Original PR description
In commission report, we need unique ids for achievements and commissions. We avoid using row_number because it becomes really slow when the amount of records increases. That's why we need reliable unique ids, build from the account move line/sale order line/sale order log, user_id, commission rules. As it represents a lot of information stored inside a unique integer, bigint are necessary. It works great in python because int() can be used to handle bigint but JavaScript is not great with that. It will cast the value sent by the ORM silently and as a result, when the ORM is called back by the JS framework, it will pass a truncated id that either conflict with another record or may not exists (ids are generated using recipe). This commit ensure that the full id is always accessible and is used to browse records when the framework js contact methods. task-5973128 Forward-Port-Of: odoo/enterprise#108751
A bug preventing users from correctly setting the fiscal year month and day for companies with child companies has been resolved. The fix ensures that all related data is updated before validation checks are performed, preventing a misleading error message.
Original PR description
Having a parent company and a chid company selected, and changing both the last day and the last month of the fiscal year as the same time raises a ValidationError. This is because in this case, in the write we successively modify each changed delegated fields from root company to the branches. Then, when checking the constrains we loop through all delegated fields and check if the value of the branches are the same as the root company. This check triggers the error as all values are not set yet. By using a write on branches for all changed delegated fields instead of a simple assignation, the constrains check occurs once all the value have been updated. Steps: - Have a root company and a branch - Select both in company selector - Go to Accounting configuration - Change fiscalyear last month AND ast day at the same time - Save -> ValidationError in `_check_root_delegated_fields` opw-5431145 Forward-Port-Of: odoo/odoo#252171 Forward-Port-Of: odoo/odoo#241413
This update corrects a discrepancy in the Romanian tax reports, reflecting the recent VAT rate changes (19% to 21% and 5%/9% to 11%). The fix ensures the reports accurately match current Romanian tax regulations, addressing missing tax lines and inactive tax settings to maintain report functionality.
Original PR description
Romanian VAT has increased from 19% to 21% and from 5%/9% to 11%, some taxes were added previously to the module but they were not reflected in the tax report, also other taxes were missing in order for the report to replicate the current up to date version issued by the romanian government. Forward-Port-Of: odoo/odoo#252126 Forward-Port-Of: odoo/odoo#241529
This update prevents Instagram posts from failing due to delays in media processing. We now use a scheduled cron job to automatically retry publishing when a container isn't immediately ready, ensuring posts are successfully created. This improves the overall reliability of Instagram posting functionality.
Original PR description
With the current behavior the Instagram API sometimes requires time to process media containers, the media_id is not yet ready on Instagram side, leading to failed posts. To avoid this, we now use an asynchronous flow: If the media container is not immediately 'FINISHED', we store the container ID in `instagram_post_id` (prefixed with `containerIDs-`), set the state to 'posting', and trigger the scheduled cron to retry in 1 minute. The `_cron_publish_scheduled` method has been updated to detect these pending posts and resume the publication attempt so workers remain free while Instagram processes the media. opw-5081325 Co-authored-by: @ushyme Forward-Port-Of: odoo/enterprise#100313
This update corrects a bug in the HTML editor's test suite that caused inconsistent test results due to overly long timeouts. By using a more robust waiting mechanism, the test now reliably identifies regressions when the toolbar isn't displayed correctly, ensuring greater stability.
Original PR description
Because a timeout in js only ensures to wait at least for that amount of time while giving no upper bound to the actual awaited time, it was possible for advanceTime(100) to actually wait for more…
Because a timeout in js only ensures to wait at least for that amount of time while giving no upper bound to the actual awaited time, it was possible for advanceTime(100) to actually wait for more than 300ms when the runbot was slow enough. In that case, since enough time has elapsed between the action and checking that the toolbar hadn't opened yet, well it was actually already opened, since we had waited too much, and the test failed non-deterministically. This is actually a special case here. Usually we want to use `waitFor` or `expectElementCount` with the toolbar since it's a popover and is therefore affected by [1]. But we cannot use them to check if the toolbar hasn't opened too early, lest we find ourselves with the same problem than explained above. Using only advanceTime with a timeout of 100ms and a synchronous `expect` check ensures that, in the general case when the runbot is fast, the test will fail in case of a regression, since there would have been ample time to have multiple animation frames during 100ms. The regression will only be hidden when the runbot is very slow and no animation frame has happened during the 100ms timeout, which is an acceptable tradeoff. The same issue appeared in another test so I fixed it as well. Timeouts throughout this test file were excessive, with multiple uses of `advanceTime(500)` while OPEN_TOOLBAR_DELAY is 300ms. This is because the commit dates from before [1] and so it was hard to ensure that enough time and animation frames had passed before we could check with `expect`, which is synchronous. Now we are using `expectElementCount`, which uses `waitFor` under the hood which has a proper mechanism to wait for enough animation frames with an additional internal delay. With these, there is no more need for a manual timeout to exceed the value of OPEN_TOOLBAR_DELAY. Note that this only applies to the cases where we check that the toolbar should be displayed, since cases where it should NOT be displayed before a certain timeout should NOT use those utils, as explained above. runbot-238562 [1]: https://github.com/odoo/odoo/commit/54da715df84789f9a1acc0cfc91be41dcdbab140 Co-authored-by: Sébastien Geelen <sge@odoo.com> Forward-Port-Of: odoo/odoo#247551
This update fixes a bug where modifying a Bill of Materials (BoM) after a production order was created would prevent the order from closing. The change ensures that the 'manual consumption' flag on stock moves is updated accurately when the BoM is modified, allowing MOs to be properly closed after BoM adjustments.
Original PR description
Steps to reproduce the issue: - Create a storable product P1 with the following BoM: - A component consumed in an operation. - Create a MO to produce one unit of P1 and confirm it. - Modify the BoM…
Steps to reproduce the issue:
- Create a storable product P1 with the following BoM:
- A component consumed in an operation.
- Create a MO to produce one unit of P1 and confirm it.
- Modify the BoM so that the component is no longer consumed in the operation.
- Update the BoM on the MO.
- Start and finish the operation.
Problem:
The MO cannot be closed because the component is not consumed.
The `manual_consumption` field on the stock move is set to True when the move is linked to a BoM line consumed in an operation. However, when the BoM is modified so that the component is no longer consumed in the operation, this field should be updated to False when the MO is updated from the BoM.
https://github.com/odoo/odoo/blob/1305c7262fff762c00159377a9ce1ca09d423625/addons/mrp/models/mrp_production.py#L1193
https://github.com/odoo/odoo/blob/1305c7262fff762c00159377a9ce1ca09d423625/addons/mrp/models/stock_move.py#L611-L612
opw-5993652
Forward-Port-Of: odoo/odoo#251796This update fixes an error in how the cost of goods sold (COGS) is calculated for kits. Previously, the COGS was incorrectly double-counted due to a calculation issue. This change ensures accurate COGS reporting for kit sales, preventing overstatement of costs.
Original PR description
Bug introduced by: 341928ca477843d92bf7a084f738cf9dcfd3593a Steps to reproduce: - Create a storable product “C1” - Cost: $1 - Create a storable product “P1” - Type: Kit - Category: AVCO - BoM: -…
Bug introduced by: 341928ca477843d92bf7a084f738cf9dcfd3593a
Steps to reproduce:
- Create a storable product “C1”
- Cost: $1
- Create a storable product “P1”
- Type: Kit
- Category: AVCO
- BoM:
- Component: C1 (qty: 20)
- Create a sale order for 1 unit of P1
- Confirm the SO
- Validate the delivery
- Create and post the invoice
- Check the journal items
Problem:
The total COGS posted is $400 instead of $200.
When posting the invoice, `_get_cogs_value` is triggered. It retrieves the price unit of each component based on the stock move quantity of the sale order:
https://github.com/odoo/odoo/blob/963bdc5d8a7cc7d3235a52ac2a2282d95a0da400/addons/sale_mrp/models/account_move.py#L39
However, since commit: https://github.com/odoo/odoo/commit/341928ca477843d92bf7a084f738cf9dcfd3593a#diff-bb93bc1c1d7fd07978c5081adc6dc21dc3eb4c37b5e8f44342fe34b61ee060b5R44
, `_get_price_unit` returns the total cost of the component required to produce one kit (i.e., 20 units * $1 = $20).
Later, `_get_cogs_value` multiplies this value again by the component quantity defined in the BoM (20), resulting in a double multiplication: (20 units * $1) * 20 = $400
opw-5946749
Forward-Port-Of: odoo/odoo#251509This update corrects a visual issue where the unit display (hours/days) for KPIs in the timesheet reporting was misaligned. The change restores the original layout, ensuring accurate and consistent KPI reporting for users. This resolves a minor display problem impacting the clarity of timesheet data.
Original PR description
Due to the recent refactoring of the `formatFloatTime` formatter in odoo/enterprise#108072, the KPIs lost their layout, resulting in a misaligned display. This commit restores the original layour for the KPI header, ensuring the unit (hours/days) is correctly shown next to the value.
This update resolves a problem where the Romanian VAT tax scheme calculation failed when customer records lacked VAT information. The original logic for determining VAT/non-EU VAT was removed during a recent refactor, but is now re-introduced specifically for Romanian customers (CIUSRO).
Original PR description
Problem --------- If the customer has not VAT set up on it record, we use the DEFAULT_VAT value. However, the scheme to be used is computed using the partner company_registry (which might be empty), which fails. Secondly, the piece of logic that compute the VAT/NON_EU_VAT for the Tax Scheme node was removed during the refactor. However, this is needed in Romania. Solution --------- Compute the scheme using the DEFAULT_VAT and add back the VAT/NON_EU_VAT logic for the Romanian CIUSRO only. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251416 Forward-Port-Of: odoo/odoo#250110
A recent update to the Avatax integration caused crashes when processing expense entries. This fix addresses a key error related to how the system handles receipt information, specifically for expense moves. By restricting address checks to moves requiring tax calculations, the system now reliably processes expenses with Avatax.
Original PR description
Currently, the expenses flow with Avatax integration crashes when posting the expense entry. Steps to reproduce: - Have an employee with an address in the US. - Enable 'Detect Automatically' in the Avalara fiscal position. - Create an expense for the employee, paid by Employee. - Submit > Post Journal entry > Post Expense. Action will be blocked by a traceback reporting error `KeyError: 'in_receipt'` Analysis: After [1] expense journal entries are now 'in_receipt'. The dictionary in account_avatax does not take into account this move type. This provides a fallback to 'Any' for any other move types [1] https://github.com/odoo/odoo/commit/f835ac0c8adb49d04bed746fd624b8976cc32991 opw-5872768 Forward-Port-Of: odoo/enterprise#109381
This update resolves an issue where avatars in collaborative lists (like 'To Do' notes) were consistently displayed on the first line, regardless of where the user was viewing the list. The fix ensures avatars now correctly follow the user's focus within the list, improving the user experience. This change was implemented to maintain consistent visual alignment and usability.
Original PR description
Since [1] when using collaboration, the position of the avatar for list items is always displayed on the first line - instead of following the user's focus. This commit fixes this by only applying the patch of [1] when inside an embedded component. Steps to reproduce: - Go to a "To do" note - Add a checked list with indented items - Access the same note from another window - Move around the checked list and observe avatar in other window => Avatar remained on first line while moving around list items [1]: https://github.com/odoo/odoo/commit/9863cb25d6dfdba224897f21634bdaaf3eca91a7 task-5930388 Forward-Port-Of: odoo/odoo#248438
This update fixes an issue where tax reports generated in Belgium were producing negative values in XML files for carried over tax lines. The change ensures that only positive amounts are included in the XML, resolving a potential reporting discrepancy. This improves the accuracy of tax reports.
Original PR description
When generating the xml for tax report, negative values should not be present in the xml for carried over lines (81, 82, 83, 86, 87, and 88) Steps: - Create a RBILL for today - 1 month, add an invoice line with tax using one of the following tags: -81, -82, -83, -86, -87 or -88 in its base refund repartition line - Open the tax report on the month of the RBILL - Generate the xml, either by the dedicated button, or by creating and posting the closing entry -> there is line(s) for negative amounts opw-5955323 opw-5428395 Forward-Port-Of: odoo/enterprise#109568 Forward-Port-Of: odoo/enterprise#108916
This update resolves an issue where rounded corners and background colors weren't consistently applied in mass mailing emails, particularly when using the 'Stretch to Equal Height' option. The fix adjusts table styling to ensure accurate rendering of card designs, improving email presentation and consistency.
Original PR description
**Steps to reproduce:** - Go to mass_mailing app - Add Columns block with multiple content size - Increase Round Corners (e.g. 20 px) - In "Vert. Alignment" field > Select the "Stretch to Equal…
**Steps to reproduce:**
- Go to mass_mailing app
- Add Columns block with multiple content size
- Increase Round Corners (e.g. 20 px)
- In "Vert. Alignment" field > Select the "Stretch to Equal Height" option
- Add color background for the columns
- Save the record and send test mail
- Round corners are not applied
- Background color doesn't expand to the bottom of the body
**Issue:**
Default table style used for the inline conversion of
`await toInline($(editableClone), { $iframe: $(iframe), wysiwyg: this.wysiwyg });` in `mass_mailing_html_field`,
has its 'border-collapse' attribute set to 'collapse' by default in `enforceTablesResponsivity`.
This attribute doesn't work with `border-radius` and the resulting display differs from the preview of the editor.
Relevant links:
https://stackoverflow.com/questions/628301/the-border-radius-property-and-border-collapsecollapse-dont-mix-how-can-i-use https://stackoverflow.com/questions/36035461/what-is-the-difference-between-border-collapse-collapse-and-border-spacing-0
**Fix:**
Use `'border-collapse': 'separate'` and `'border-spacing': 0` but this can
introduce border stacking inside the table element where the original collapse
was needed.
Add back the `overflow` inherited by the card attributes to ensure
inside border are visually properly contained inside the border (but not
sure as to why it was removed 4 years ago).
Also set the height of table sub-elements to `100%` to ensure background
property is properly applied on the whole card body.
opw-5218581
Forward-Port-Of: odoo/odoo#251863
Forward-Port-Of: odoo/odoo#242001This pull request optimizes test execution by streamlining setup processes and reducing unnecessary logging. Specifically, it consolidates setup steps, eliminates redundant HTTP thread usage, and suppresses excessive password reset logging, resulting in faster and more efficient test runs.
Original PR description
- move a bunch of expensive setUp to setUpClass - backport #152378 to avoid password keying in 17.0 also Forward-Port-Of: odoo/odoo#252248 Forward-Port-Of: odoo/odoo#250667
This update fixes a bug preventing warnings on the EC Sales List report when dealing with customers outside of Europe. Specifically, the report now correctly identifies customers with 'Intra-Community' fiscal positions in European companies and those using non-European delivery addresses, ensuring accurate reporting and compliance. This ensures accurate sales reporting for international transactions.
Original PR description
The warnings partner_same_country and partner_no_ec_country on the EC Sales List are never showed. To Reproduce (for partner_same_country warning): - Create a company in Belgium - Create a customer in Belgium with "Intra-Community" as a Fiscal Position - Create an invoice with this customer - Go to the EC Sales List - The customer doesn't appear in it, so the warning is not present. For the partner_no_ec_country, do the same but with the country of the customer being one outside of Europe. Forward-Port-Of: odoo/enterprise#107139
This update fixes a potential issue where user information wasn't consistently being sent, leading to unexpected behavior across several Odoo modules (mail, HR, Portal). Specifically, the system now always includes the `partner_id` with `main_user_id` to ensure accurate identification and data flow. This improves reliability and prevents potential errors.
Original PR description
`main_user_id` should always be sent with its `partner_id` to avoid subtle issues. Indeed the `partner_id` inverse is on `user_ids` not on `main_user_id`. It is indirectly assumed `partner_id` should be set on `res.users`, in particular when using `partner.main_user_id.partner_id`. https://github.com/odoo/enterprise/pull/109364 Forward-Port-Of: odoo/odoo#252320 Forward-Port-Of: odoo/odoo#251641
This pull request corrects a minor issue in the German localization (l10n_de) module where tags were incorrectly formatted in the account data file. This ensures accurate reporting and categorization of financial transactions for German-speaking customers. The fix was verified and approved as part of a standard process.
Original PR description
Commit db0d499952192ede0def2a070e103ba67952387c inverted some tags which is wrong opw-5415426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250744
This update fixes an issue where tax report tags were incorrectly sorted, preventing proper auto-completion functionality. The team has also improved testing to prevent similar errors in the future. This ensures accurate reporting for German tax compliance.
Original PR description
Commit https://github.com/odoo/odoo/commit/db0d499952192ede0def2a070e103ba67952387c inverted some tags which is wrong Tags must be sorted for the auto complete to work properly Improving tests to catch more errors opw-5415426 Forward-Port-Of: odoo/enterprise#108848
This update removes a display field ('Visible Internally Only') from the customer rating form in the Helpdesk module. This field was no longer needed since customer ratings are no longer visible on the website. This change improves the user experience and reduces unnecessary data display.
Original PR description
**Steps to reproduce:** - Open a Helpdesk ticket with a customer rating. - View the rating form. - Observe the field ‘Visible Internally Only’ still showing. **Issue:** - The field is displayed even though ratings are no longer shown on the website. **Reason:** - The field is now irrelevant but still present in the view. **Fix:** - Invisible the ‘Visible Internally Only’ field from the customer rating form in the affected version. **Task id - 5359052** Forward-Port-Of: odoo/enterprise#109287 Forward-Port-Of: odoo/enterprise#100686
A bug causing duplicate 'New' and 'Create New' buttons in the task list has been resolved. This change ensures users only see a single 'New' button when creating tasks, streamlining the process and preventing confusion. The fix addresses a technical issue related to a ControlPanel refactoring.
Original PR description
Steps to Reproduce --- 1. Enable Task Dependencies in Project settings 2. Create project with no task templates 3. Open task form -> Blocked By tab -> Add a line 4. Observe duplicate "New" and "Create New" buttons Issue --- - The task list view displays both “New” and “Create New” buttons, resulting in duplicated creation actions. Current Behaviour --- - Two different creation buttons are displayed simultaneously Expected Behaviour --- - Only a single “New” button should be displayed Root cause --- - ControlPanel refactoring removed props.showButtons without adding !env.inDialog check to task views. Fix --- - Add !env.inDialog check , this prevents the ProjectTaskTemplateDropdown component from rendering in dialog contexts, eliminating the duplicate button issue. Related - https://github.com/odoo/odoo/pull/220325 task - 5403917 Forward-Port-Of: odoo/odoo#241628
This update adds a temporary field to the burndown chart in the project module. This resolves a technical issue that would have prevented a safe upgrade to the latest version of Odoo. It ensures future updates to the burndown chart functionality can be implemented without disrupting existing data.
Original PR description
Add an empty `python_method` field to the burndown chart embedded actions as a preparatory change for a safe upgrade path. Without this, replacing `action_id` with `python_method` in master would temporarily violate the SQL constraint on `ir.embedded.actions` that prevents both from being set simultaneously. references: #239000 task-5347524 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252145
This update resolves an issue where a backlog of PEPPOL messages caused a recurring cron job loop, leading to processing delays. The fix addresses a race condition in token refreshing, preventing errors and ensuring consistent communication with the PEPPOL network. This improves the reliability of Odoo's integration with PEPPOL.
Original PR description
Fix two issues observed on Odoo production. 1) When more than 50 messages from this odoo db/client are queued to be sent on peppol-ap, all client-side messages remain in `processing` If the send queue stays saturated, the retrigger logic repeatedly schedules the cron, causing an infinite `ir_cron_peppol_get_message_status` loop. 2) Each cron refreshes the authentication token, which allows concurrent threads to refresh it in parallel. Due to the `REPEATABLE READ` isolation level, a long-running cron may continue using the old token while another thread has already refreshed it. This leads to `invalid-signature` responses and incorrectly marks the connection as out of sync on one thread, even through the long-running transaction fails on trying to commit. Thus, simply flushing the cursor will block the transaction in such a situation no-task Forward-Port-Of: odoo/odoo#252177
This update fixes a discrepancy in how inventory values are calculated. Previously, the system incorrectly assumed midnight when determining the 'As of' date for valuation reports, leading to inaccurate results. This change ensures that inventory values are calculated through the end of the day, aligning with established business logic and improving reporting accuracy.
Original PR description
### Problem: If `_compute_quantities` is called with only a date specified in `to_date` context (no timestamp), Odoo will assume midnight (00:00:00) instead of end of day (23:59:59). This contradicts logic in other places, such as `_compute_total_value`, which opts for the convention that "As of \<date>" means "through \<date>". ### Solution: We will run `_compute_quantities` with `to_date` at 23:59:59. ### Steps to replicate (Runbot 19): 1. Receive a valued and tracked product (you can make the impact more obvious by setting the cost very high) 2. Backdate the receipt to some day in the past using the method of your choice (inspector tool, server action) 3. Go to the Inventory Valuation report, set "As of" date to the backdated receipt date, note that the value of the validated receipt is not there 4. Set "As of" to the day AFTER the receipt date, note the value is now shown opw-5893999 Forward-Port-Of: odoo/odoo#251253
This update addresses a bug where changing the popup backdrop color or hiding/showing the popup would unexpectedly cause it to disappear. The fix ensures the popup's visibility is correctly tracked during history operations, preventing these disruptions. This improves the user experience when customizing popup appearances.
Original PR description
Steps to reproduce in 18.4: - Add a popup on the page - Click on the popup - Change the backdrop color - Hide the popup by clicking on its entry in "Invisible Elements" - Undo - Redo - Bug: The popup disappears Steps to reproduce in 19.0: - Add a popup on the page - Click on the popup - Hover a color in the colorpicker of the backdrop option of the popup - Stop hovering the color - Bug: The popup disappears Forward-Port-Of: odoo/odoo#251849 Forward-Port-Of: odoo/odoo#244213
This update resolves an issue where customers using customized account settings would receive empty depreciation schedule reports. The fix ensures accurate report generation by granting administrative access to verify compatibility with Odoo's accounting rules, preventing incorrect report output.
Original PR description
Following odoo/enterprise@ece0405785, in case a customer modified the `account.move.line` record rules in a way which is incompatible with the AML shadowing, user will only get an empty deprecation schedule report. This commit as a sudo, to ensure we get a correct report, access rights being already check for `account.asset` records. Forward-Port-Of: odoo/enterprise#108901
This update fixes an issue where link popovers in the preview mode were excessively large, particularly when titles were long. Now, the popover size is consistently maintained, providing a cleaner and more user-friendly preview experience. This ensures consistent visual presentation across different content lengths.
Original PR description
Before this commit: the link popover is oversize when the preview has long title. After this commit: the link popover retains its size. task-6000052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252045