Daily updates from Odoo
Monday, December 1, 2025
20 changes · saas-18.3
Resolved issues and error corrections
This update fixes an issue where tasks created from service orders weren't automatically reflecting the order's quantity in their allocated hours. Previously, the hours were incorrectly set to zero unless the service type was 'milestones' or 'manual'. Now, the task's hours will accurately match the quantity of the corresponding service order line, ensuring accurate time tracking for service projects.
Original PR description
To reproduce: ============= - Create service product with `service_tracking = task_in_project` and `service_type = manual` - Create a SO with this product and set quantity on the line - Confirm the SO - check the created task, allocated hours is 0.0 instead of the quantity of the SO line Problem: ======== When creating tasks from SO lines, allocated hours is initialized to 0 then computed based on the SOL quantity except when the product's service_type is 'milestones' or 'manual'. Solution: ========= Following the logic in `write` method of `sale.order.line`, the allocated hours should be set to the SOL quantity. opw-5153467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237398 Forward-Port-Of: odoo/odoo#234524
This update fixes an issue where vendor bills created in the Documents module incorrectly defaulted to the company's currency instead of the vendor's. Now, when a vendor is selected in the Documents module, the bill automatically uses the vendor's currency, ensuring accurate financial reporting. This improves data consistency and reduces potential errors.
Original PR description
**Issue:** When creating a vendor bill or vendor refund through the Documents module after selecting a supplier, the currency defaults to the company's currency instead of the vendor's. However, if the supplier is selected later in the Accounting module, the correct supplier currency is applied. **Steps to reproduce:** - In Documents, upload a bill. - Click on the bill and assign a vendor (whose supplier currency is different from the company's currency). - Click on "Create Vendor Bill". The used currency isn't that of the supplier. opw-4406074 Forward-Port-Of: odoo/enterprise#97417 Forward-Port-Of: odoo/enterprise#78380
A recent test failure related to editing event descriptions has been resolved. The fix clarifies the HTML tags used to ensure accurate modifications, drawing inspiration from a planned update in the next version. This improves the reliability of the event editing process.
Original PR description
The tour test testUI.test_website_event_tour was failling because the HTML tag specify to edit the event description was not precise enough and led to wrong modification. I specified the itemprop property of the specific tag to edit in order to erase the previous ambiguity. The proposed fix is inspired by the saas-18.4 version of the code. Runbot error: 226574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the invoice date was unexpectedly changing after a company partner's address was modified. The fix prevents the invoice date from being recalculated when an invoice is in the ‘posted’ state, ensuring data accuracy and consistency. This change improves the reliability of invoicing processes for Czech customers.
Original PR description
**Steps to reproduce** 1.Install Accounting, Contacts, and l10n_cz. 2.Create an invoice with a future `invoice date` and confirm it. 3.Go to Contacts → open the company (res.partner). 4.Modify any…
**Steps to reproduce** 1.Install Accounting, Contacts, and l10n_cz. 2.Create an invoice with a future `invoice date` and confirm it. 3.Go to Contacts → open the company (res.partner). 4.Modify any address field (street, zip, etc.) and save. 5.Return to the invoice → in the chatter, the `date` field has change unexpectedly > Note: The `date` field is not shown in invoice default form view. Add it manually for clearer reproduction. **Issue** - The confirmed invoice `date` changes when updating the company partner’s address. **Cause** https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/l10n_cz/models/account_move.py#L20-L24 - When creating an invoice, the `date` field is correctly set based on the `taxable_supply_date` while the invoice is in the draft state. After confirming (posting) the invoice, it moves to the `posted` state. - However, when updating the partner address, the `_compute_date` method is triggered again, which calls `super()` and recomputes the `date` field using the standard logic. Since the invoice is already in the `posted` state, the CZ-specific condition is not satisfied, and the `date` gets updated incorrectly. **Solution** - Update `_compute_date` to only call super() for invoices in draft state. - This prevents unwanted recomputation of the `date` on post invoices. opw - 5086961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229513
This update fixes an issue where negative sales amounts (like credit notes) were not being included in the exported XBRL report for the EC Sales List. The change ensures that all sales figures, including negative ones, are now correctly generated and available for export, improving report accuracy and compliance.
Original PR description
To replicate: 1. Install l10n_nl_reports_sbr_icp 2. Create an european partner with a VAT number 3. Create a credit note for this partner 4. Go to Accounting > Reporting > EC Sales List 5. The negative line appears in the report 6. Click on XBRL to export the report The negative line is not included in the exported report Only non-negative positive lines are added to the report in `_generate_codes_values()`. This commit changes that to include non-zero values. opw-5220622 Forward-Port-Of: odoo/enterprise#100669 Forward-Port-Of: odoo/enterprise#100009
This update corrects a technical error that prevented bookings from appearing correctly in the restaurant appointment system. The fix involves 'freezing time' to ensure bookings are always displayed accurately, regardless of date changes. This improves the reliability of appointment scheduling.
Original PR description
Depending on when the booking form was opened and closed you could end up no seeing the booking if the day had changed. Freezing time should ensure we don't have this scenario error-234349
This update resolves an issue where background blur in video calls would cause video streams to freeze when users switched to another tab. By using a separate worker thread for frame scheduling, the system now maintains a consistent video stream, ensuring a smoother experience for users regardless of which tabs they are using.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab…
**Description of the issue/feature this PR addresses:** This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab during video calls. **Current behavior before PR:** When background blur is enabled during a video call, the user’s video stream freezes if they switch to another browser tab. This happens because currently frame scheduling relies on `requestAnimationFrame` and `setTimeout`, which modern browsers pause or throttle in inactive tabs to conserve system resources and battery life. **Desired behavior after PR is merged:** The user’s video stream continues to render with the background blur effect, even when the browser tab is inactive. This is achieved by moving the frame scheduling logic to a Web Worker, which runs in a separate thread and is not subject to browser throttling. As a result, a consistent frame rate is maintained at all times. task-[4781227](https://www.odoo.com/odoo/project/1519/tasks/4781227) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226455
This update resolves an issue where the system was incorrectly creating multiple bank accounts from UBL invoices. The fix filters out duplicate account numbers, ensuring accurate bank information is imported into Odoo. This improves data integrity and avoids potential accounting errors.
Original PR description
Currently `_import_retrieve_and_fill_partner_bank_details` may try to to create multiple res partner bank with the same account. This can i.e. happen in case there are multiple `cac:PaymenMeans` nodes in the XML. After this commit we filter out duplicate bank accounts numbers. opw-5149621 Forward-Port-Of: odoo/odoo#237850 Forward-Port-Of: odoo/odoo#236676
This update corrects a previous issue where the system incorrectly remembered the first invoice sending method chosen for a partner. This meant users wouldn't be able to easily switch to preferred sending methods like PEPPOL, leading to confusion. This change ensures users can now set their desired sending method without being automatically defaulted back to email.
Original PR description
Before this commit, we were setting the preferred invoice sending method on the Contact depending on what was in the first Send & Print to this specific partner. It's a bad idea because user don't know about this setting and when they want to switch the default method (example email -> peppol) the wizard will keep propose them to send it by email only and they don't know why since they never knowingly set it to "email". task-none (feedback from AVW) Forward-Port-Of: odoo/odoo#237956
This update resolves a recurring test failure (runbot-error-234594) related to timing delays in the Point of Sale module. The fix simplifies the test verification to ensure the `orderAcceptTime` field is present, improving the stability of the testing process.
Original PR description
in this commit: - Fixed the `_acceptOrder, _dispatchOrder, _completeOrder` test, which could fail due to minor timing delays. - Updated the assertion to only verify that `orderAcceptTime` is not empty. runbot-error-234594
This update fixes a technical issue where the Odoo system incorrectly handled failed RPC calls stored in its cache. Specifically, a cached promise would resolve with 'undefined' instead of properly rejecting the error, leading to unexpected behavior. This change ensures that RPC failures are correctly handled and reported, improving system stability.
Original PR description
Let's say we trigger two times a RPC that fails.
The first time, the cache is empty and we make the RPC. The ram cache is filled with `prom`.
The second time, we get `prom` from the ram cache.
When the RPC actually finishes, we end up in
```js
.catch((error) => {
this.ramCache.delete(table, key);
def.reject(error);
});
```
=> the RPC failure is catched, which means `prom` itself is not rejected. Instead, it resolves with the result of `.catch(...)`, which is `undefined`
Here is a simplified toy example:
```js
const prom = Promise.resolve(
Promise.reject(new Error("fetch failed")).catch(() => {})
);
```
In this example, `prom` is successful and the result is `undefined`
"
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-prA bug preventing test orders was fixed. The issue occurred when a product's tax was set as a 'Group of Taxes' without a defined tax rate. This update ensures that test orders can now be created successfully, even with this specific tax configuration, improving PoS functionality.
Original PR description
When creating a test order for a product whose tax is configured as a Group of Taxes without any definitions, a traceback occurs. Steps to reproduce the error: - Install ``pos_urban_piper`` module -…
When creating a test order for a product whose tax is configured as a Group of Taxes without any definitions, a traceback occurs. Steps to reproduce the error: - Install ``pos_urban_piper`` module - Configure Urban Piper integration for the PoS - Create a new tax without Definition > ``Tax Computation: Group of Taxes`` > Save - Create a new product > Set the above tax in sales taxes > Save - Open the session for PoS - Go to Settings > Urban Piper Location > Set Food Delivery Platforms > Save - Click Test Order > Select the product and Delivery Provider > Place Order Traceback: ```py IndexError: list index out of range ``` https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/pos_urban_piper/controllers/main.py#L319-L322 The issue happens because ``flatten_taxes_hierarchy()`` calls ``_flatten_taxes_and_sort_them()`` method at [1], which returns an empty record when the group tax has no children at [2]. As a result, ``tax_types`` becomes an empty list ([]), leading to an IndexError when trying to access ``tax_types[0]``. [1]: https://github.com/odoo/odoo/blob/57850b32332a71933a4f6b52d7428684de831f4b/addons/account/models/account_tax.py#L2786 [2]: https://github.com/odoo/odoo/blob/57850b32332a71933a4f6b52d7428684de831f4b/addons/account/models/account_tax.py#L795 sentry-6984648461 Forward-Port-Of: odoo/enterprise#98542
This update fixes a bug preventing users from seeing email quotes within the Odoo Chatter interface. The issue stemmed from a Shadow DOM configuration that blocked CSS styles, hiding the quote display and toggle button. Applying the necessary CSS from the existing Odoo assets ensures quotes are now correctly visible and accessible.
Original PR description
Currently, in a chatter message, there's no way for a user to toggle on mail quotes. ### Steps to reproduce * install `crm` * in the settings, enable leads * configure a mail alias for a sales team *…
Currently, in a chatter message, there's no way for a user to toggle on mail quotes. ### Steps to reproduce * install `crm` * in the settings, enable leads * configure a mail alias for a sales team * forward an email to that mail alias * open lead that was created, look into the chatter to find the message of the email you sent You should see that the body of the email you forwarded does not appear in the chatter. ### Cause Email quotes are supposed to be hidden in the chatter, with an ellipsis button that allows the user to show them. In this case, all these elements are actually there in the DOM, but not visible/interactable by the user. Both the forwarded email quote and the button are placed inside of a Shadow DOM. However, since Shadow DOMs ignore parent styles, the ellipsis button is lacking the necessary rules to be displayed at all. This leads to there not being any way for the user to unfold email quotes. ### Fix Apply the CSS from the `web.assets_web` bundle into the Shadow DOM. That bundle should already be loaded in the containing document, so there's no cost or extra request by the browser. opw-4863953
A rare bug in the system's request handling was causing errors during testing. This fix ensures the system correctly acquires a lock, preventing failures and improving the reliability of test results. This change addresses a technical issue that could impact the stability of the system.
Original PR description
In some rare cases the late_request_thread could execute so fast without releasing the GIL that assertCanOpenTestCursor was executed before the main_lock.acquire(), causing the lock to be None. In…
In some rare cases the late_request_thread could execute so fast without releasing the GIL that assertCanOpenTestCursor was executed before the main_lock.acquire(), causing the lock to be None. In this case, acquiring the lock is pointless since the late_request_thread has already finished, defeating the purpose of this quire, but we can workaround this keeping a reference to the main_lock before starting the thread. This way, even if the late_request_thread is already finished, we can still acquire the lock even if it is already released. Normal flow: - main_thread acquires main_lock - main_thread span request_thread - main_thread tries to acquire main_lock and again and blocks - request_thread runs and releases main_lock - main_thread acquires main_lock and continues When it fails - main_thread acquires main_lock - main_thread span request_thread - request_thread runs and releases main_lock - main_thread tries to acquire main_lock witch is None and fails Fixed - main_thread acquires main_lock - main_thread span request_thread - request_thread runs and releases main_lock - main_thread tries to acquire main_lock but it is already released - main_thread acquires main_lock and continues Runbot error [229827](https://runbot.odoo.com/odoo/runbot.build.error/229827)
This update resolves an issue where closing the article editing dialog would cause the page to jump back to the top. The fix ensures the correct element focus is maintained during dialog closure, improving the user experience and preventing unexpected page navigation.
Original PR description
Problem: When editing a long Knowledge article and executing the `/article` command, closing the dialog automatically scrolls the page to the top. Cause: This happens because `useActiveElement` inside the `Dialog` component runs its cleanup function when the dialog unmounts. While unmounting, `document.activeElement` is `body`, so the cleanup tries to focus back the `oldActiveElement`, which is the `editable`, and this resets the selection and causes the scroll jump. Solution: Set the selection when closing the dialog, ensuring the `editable` remains the `document.activeElement` during cleanup, preventing the focus reset. Steps to reproduce: - Edit a long article further down the page. - Use the `/article` command. - Dismiss the dialog. → The page scrolls back to the top. opw-4797567
This update corrects a bug where credit notes weren't automatically generating deferred revenue entries. The system was incorrectly using a setting designed for invoices. Now, credit notes will correctly create deferred revenue entries when configured to 'On bill validation', ensuring accurate accounting for deferrals.
Original PR description
The system incorrectly uses the `Deferred Expense Entries` configuration to determine whether to create deferrals for credit notes, while it should follow the `Deferred Revenue Entries` setting, as invoices do. As a result, deferred entries for credit notes are not created when expected. Steps to reproduce: - Go to Accounting → Configuration → Settings. - In the Deferred Expense Entries section, set Generate entries to: Manually & Grouped - In the Deferred Revenue Entries section, set Generate entries to: On bill validation - Navigate to Accounting → Customers → Credit Notes. - Create a credit note with at least one line containing Date From and Date To (i.e., deferrable line). - Validate the credit note. - No deferred revenue entries are created. Ticket [link](https://www.odoo.com/odoo/project.task/5187051) opw-5187051 Forward-Port-Of: odoo/enterprise#100211
This update fixes a technical issue that prevented the 'fuel_type' selection field in the HR contract model from being properly translated. By directly using the variable for options, this change ensures all available fuel types can be localized, improving the system's internationalization capabilities.
Original PR description
The selection field `fuel_type` in the `hr.contract` model was not properly translatable, because it used a function yielding static strings for the options. This commit changes the field to use the variable directly, allowing them to be translated. Forward-Port-Of: odoo/enterprise#100748
This update fixes an issue where replying to messages with only attachments didn't clearly show the original message being responded to. Now, users will always see the context of the message they're replying to, regardless of whether they include text or attachments, leading to a smoother and more intuitive communication experience.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- Currently, when replying to a message with only attachments (no text content), the parent…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- Currently, when replying to a message with only attachments (no text content), the parent message context is not displayed. This makes it unclear which message the user is replying to when they only attach files without typing any text. **Current behavior before PR:** ---------------------------------------------- - Reply messages with only attachments do not show the parent message context - Users cannot see what message they are replying to when only attaching files - The MessageInReply component is not rendered for attachment-only replies **Desired behavior after PR is merged:** ---------------------------------------------- - Reply messages with only attachments now display the parent message context - Users can clearly see what message they are replying to, even with only attachments - The MessageInReply component renders consistently for all reply types - Visual structure maintains proper Odoo message styling - Better user experience with clear reply context Task-5109159 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at https://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238047 Forward-Port-Of: odoo/odoo#230574
This update ensures that the available payment method options in the Point of Sale module are properly translated. Previously, these options were not handled for internationalization, leading to potential issues with localized versions of Odoo. This change improves the system's ability to support multiple languages.
Original PR description
The field `payment_method_type` got its selection values from a function that did not translate the labels. In order to make them translatable, we wrap them in a `env._()` call, so they are properly exported in the POT file and translated at runtime. Forward-Port-Of: odoo/odoo#237768
This update fixes an issue where short feedback messages were incorrectly wrapping the last word, creating a messy layout. The change ensures feedback messages display cleanly, especially when combined with the floating rating image, resulting in a better user experience. This was a minor visual improvement.
Original PR description
**Current behavior before PR:** - Short feedback wraps the last word unnecessary.  **Desired behavior after PR is merged:** - Short messages wrapped unnecessarily due to block-level element conflicting with floated rating image. This fix ensures cleaner inline layout.  Backport of this: [Commit](https://github.com/odoo/odoo/commit/52a1913ea7082655009c9eca1201c8c42e4e4037) task-[4788428](https://www.odoo.com/odoo/project/1519/tasks/4788428) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215577