Monday, January 26, 2026
40 changes · master
Resolved issues and error corrections
This update removes unnecessary integer rounding from the monthly Italian VAT reports. The rounding was mistakenly carried over from annual reports due to a previous split in the codebase. This ensures accurate VAT reporting for Italian businesses.
Original PR description
Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in [#193662](https://github.com/odoo/odoo/pull/193662). [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) Forward-Port-Of: odoo/enterprise#104679 Forward-Port-Of: odoo/enterprise#103852
This update resolves an issue where website tour tests would fail after changing the header template to 'Sidebar'. The fix ensures the website builder remounts correctly before the tour proceeds, preventing the builder from resetting to its initial state and maintaining test stability.
Original PR description
When changing the header template to 'Sidebar', the loading screen disappears but the WebsiteBuilder component remounts asynchronously. If the tour proceeds to the theme tab before the remount completes, the builder resets to the Edit tab (its initial state), breaking the test flow. We wait for the builder to remount, and add `.editor_enable` class to the body of the iframe, so then nothing disrupts the flow. runbot-234504 Forward-Port-Of: odoo/odoo#245271 Forward-Port-Of: odoo/odoo#243518
This update fixes an issue where fiscal data for Chinese credit notes wasn't appearing in the PDF reports. The fix involved ensuring the correct display of a conditional element within the report template, now correctly rendering the required financial information.
Original PR description
The fiscal data is not displayed in the credit note pdf. This is because we're relaying on a div that is conditionnally displayed in the inherited template. opw-5467583 Forward-Port-Of: odoo/enterprise#104924
This update resolves an issue where the invite input field automatically gained focus, disrupting other dialogs like the call permission dialog. Now, the input only focuses when it's active and the user's context is engaged. Additionally, a testing helper was moved to improve test reliability.
Original PR description
**Current behavior before PR:** - The invite input always tried to autofocus, in turn stealing focus from dialogs like the call-permission dialog. **Desired behavior after PR is merged:** - Autofocus only when the input exists and the context is active. - Moved `mockPermissionsPrompt` to `mail_test_helpers`. **Part of task-**[5227387](https://www.odoo.com/odoo/project/1519/tasks/5227387) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245334 Forward-Port-Of: odoo/odoo#236248
This update improves the product information displayed in the point-of-sale system. It now shows the product's internal 'default_code' alongside its name in the product info popup. This provides additional context and traceability for sales staff and inventory management.
Original PR description
This commit adds the default_code (internal reference) to the display name of the product in the product info popup. opw-5493827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244068
A recent test for our live chat feature was intermittently failing due to a timing issue. This update increases the test's waiting period, allowing it to reliably process notifications even under heavy load. This ensures the live chat test remains stable and provides consistent results.
Original PR description
The `Only two quick actions are shown` live chat test awaits the first posted message because to avoid conflict with the reaction being added afterwards. To do so, the test uses the `waitForSteps` helper. However, during high load, 200ms might be too short to receive the notification, leading to the test failing. This commit increases the timeout. runbot-237587 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#245421
This update resolves an intermittent error that occurred when printing multiple receipts quickly via USB. The fix prevents multiple threads from accessing the printer simultaneously, ensuring reliable ESC/POS printing and eliminating fallback to CUPS. This improves the overall stability of receipt generation.
Original PR description
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS…
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS status ERROR ? root: Could not set configuration: [Errno 16] Resource busy ``` This would cause `python-escpos` to be disabled and fallback to just CUPS printing. The issue was caused by two threads trying to access the printer at the same time, which could happen in two ways: - IoT thread with `python-escpos` and CUPS try to access the printer at the same time. - Two IoT threads with `python-escpos` try to access the printer at the same time (this can happen if two receipt actions are received at the same time). Both of these scenarios should now prevented: - Now, if we are using `python-escpos`, we also use it to print the receipt as well as checking the status. CUPS is never used so there should be no interference from it. - We now have an `escpos_lock` (per printer, not global) that is acquired when accessing the printer via `python-escpos`. This ensures that different threads cannot both try to access the printer at the same time. task-5490942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245122 Forward-Port-Of: odoo/odoo#244031
This update resolves an issue preventing grouping within the planning module's slot templates. The fix ensures that parameters are passed to the underlying method in the correct order, enabling proper data aggregation. This improves the functionality of the planning system.
Original PR description
Before this commit, it was impossible to group by on any field in `planning.slot.template` model, because the parameters given to the parent method of `formatted_read_group` method were not given into the right order. This commit makes sure the order is respected. Forward-Port-Of: odoo/enterprise#105211
A technical error prevented the creation of a key email template when rental orders were present. This fix moved a necessary method to the `sale_renting` module, ensuring template validation works correctly regardless of whether the rental module is installed. This resolves a potential issue with e-commerce order emails.
Original PR description
The mail template `mail_template_sale_cart_recovery` creation fails in some cases if there is a rental order in the database. Indeed, during a template creation, the first record of the corresponding model is used to validate the template validity. In this case, the template is only meant for e-commerce orders and there won't be any e-commerce rental order without `website_sale_renting` but the validation is not aware of functional specificities, leading to a traceback because the method `_get_rental_pricing_description` doesn't exist when only `sale_renting` and `website_sale` are installed. To avoid this error, we move the method to `sale_renting`, even though there is no real life flows where this was breaking (except templates validation ofc). Was fixed first with c3f5dafa23a8b1fd36eaedd83a575b717e5e9377 but moved back into `website_sale_renting` by mistake with fd1d7f91e7e60a20a5401201ff89a7e875faad82 Forward-Port-Of: odoo/enterprise#105318
This update removes the Sign menu item from Odoo's Discuss channels. Previously, this menu was incorrectly displayed, which was confusing for users. This change ensures Discuss channels function as intended, focusing on mail threads instead of sign requests.
Original PR description
Currently, the Sign menu item is displayed in discuss channels, which is not making sense. This was due to an incomplete check in the isDisplayed method of the SignRequestCogMenu component. To fix this, we enhance the condition to ensure that the menu item is not displayed when the current model is 'discuss.channel'. Discuss channels inherently support mail threads, but should not have the Sign menu item. task-5494751 Forward-Port-Of: odoo/enterprise#105201
This update resolves an issue where the l10n_cl_edi module was incorrectly creating duplicate vendor bills when receiving identical XML invoices via the incoming mail server. The fix prevents duplicate bill creation, ensuring accurate record-keeping and avoiding potential accounting discrepancies. This addresses previous support tickets opw-5362664 and opw-5409700.
Original PR description
Steps to reproduce: - With a CL Company setup - Configure an incoming mail server with DTE server option enabled - In Vendor Bills journal, enable 'Use Documents?' - Receive the same XML twice via the incoming mail server - Check created vendor bills Issue: There will be duplicated bills. Each duplicate will show the message 'E-invoice already exist: nnnnn' However, the system should avoid duplicates from being created. opw-5362664 opw-5409700 Forward-Port-Of: odoo/enterprise#103211
This update resolves an issue where Odoo could encounter errors due to invalid IDs used when browsing data. The fix adds a filter to ensure all IDs are valid before processing, preventing a potential crash. This improves stability and reliability of Odoo trials.
Original PR description
Since https://github.com/odoo/odoo/pull/227477, using falsy ids ids illegal This commit adds an additional filter to the domain used to browse `ir.model.data` to compute the following fields:…
Since https://github.com/odoo/odoo/pull/227477, using falsy ids ids illegal
This commit adds an additional filter to the domain used to browse `ir.model.data` to compute the following fields: `(menus|views|reports)_by_module` in order to avoid selecting any that would contain a falsy `res_id` and thus cause the above-mentioned assertion to fail.
One way to reproduce this in a new trial:
- Create a new trial with several modules: `account`, `crm`, `project`, `sales`
- Install `web_studio`
- Uninstall `base_automation`
- Traceback
```
File “/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py”, line 5200, in browse
assert all(ids) or all(isinstance(x, NewId) or x for x in ids), “Invalid falsy real id”
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```
This is due to an `ir.model.data` containing a falsy res_id in the internal code of `saas_trial` (`installed-17`)
This fix will avoid any additional traceback like this one.
opw-5865316
Forward-Port-Of: odoo/odoo#245469This update resolves a problem where a test tour for tax reports failed when specific localization modules weren't installed. The fix involved adjusting how the tour handles date calculations and ensuring it correctly identifies the appropriate tax report type based on the company's configuration. This ensures the test tour runs reliably across different Odoo environments.
Original PR description
- The tour shouldn't run if a localization with 'Tax Report' for the country is not installed (i.e. l10n_us_account) - Dynamic Javascript dates calculation don't mix well with Python's freeze_time running in the "No future" 2026 preparation build, so I froze the time in the Python test but resorted to hardcode the Javascript dates. - No need to check the position of the column "Column 1". In debug mode for the tour, there will be the "Debug" column where the info about the computations are shown, so it won't be the last. We just need to see that it shows, after all. Runbot error [link](https://runbot.odoo.com/odoo/error/234624) runbot-234624 Forward-Port-Of: odoo/enterprise#101689
This update corrects a display issue in the Barcode application where the inventory count badge incorrectly showed requests from one company even when no count existed for another. The fix ensures the badge accurately reflects the current inventory count for the company currently being viewed, improving data accuracy and reporting.
Original PR description
Steps to reproduce: - Create two companies (A and B) - Create a storable product "P1" - Log in with company A - Update the on-hand quantity of P1 in company A only - From Physical Inventory, request an inventory count for P1 - Switch to company B - Open the Barcode application Problem: The inventory count badge in the Barcode main menu displays a request count created for company A, even though no inventory count exists for company B. The badge incorrectly shows "1" instead of "0". opw-[5472031](https://www.odoo.com/web#id=5472031&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#104065
This update resolves an issue where currency rounding errors were causing the system to incorrectly remove small cash differences from reports. The fix ensures that even minor discrepancies, resulting from rounding, are accurately reflected, preventing unintended cash adjustments. This improves the reliability of our sales reporting.
Original PR description
Before this commit, when calculating the cash difference in the report, the code did not account for currency rounding. This could lead to situations where a very small cash difference, due to rounding errors, was not recognized as zero, resulting in the unintended removal of cash moves. opw-5489958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245251
This update fixes an issue where the 'Pending' button in the manufacturing order system incorrectly stopped productivity records for all employees involved, instead of just the current one. The change ensures that only the employee actively working on the operation is impacted, improving workflow efficiency and preventing unnecessary resource allocation.
Original PR description
Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
- Create a new operation OP1
- Create a manufacturing order to produce one unit of P1
- Confirm the manufacturing order
- Log in as Mitchel (admin) and start OP1
- Log in as Marc (demo) and also start OP1
- Click on Pending
Problem:
Both “mrp.workcenter.productivity” records are stopped, instead of stopping only the one linked to
The `button_pending` method was stopping productivity records for all employees linked to the work order.
opw-5453752
Forward-Port-Of: odoo/enterprise#105238
Forward-Port-Of: odoo/enterprise#103553This update allows users to modify fields within the 'stock.quant' view through Odoo's Studio interface, even if those fields don't have a unique identifier. Previously, this was restricted, but this change ensures Studio customizations are correctly applied to stock quantities.
Original PR description
In versions prior to 18.3, the “stock.quant” view did not have an “xml_id”, which prevented it from being modified through Studio. However, starting from version 18.3 and specifically since this commit: https://github.com/odoo/enterprise/commit/f4a4d54d45392c2ba46a123d4951f8b4468c5cba it is now possible to modify views through Studio even if they don't have an xml_id. But in the 'stock.quant' view, we perform a check at creation time to ensure that the field is among the allowed fields. Fields coming from Studio or from a customized view should, however, be ignored by this check and allowed. opw-5107591 Forward-Port-Of: odoo/odoo#230126
This update fixes a potential issue in the Swiss payroll reporting process. It now only creates a snapshot of the required data if one doesn't already exist, preventing unnecessary data duplication and improving the efficiency of the reporting system. This ensures more accurate and timely payroll reports for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#105258 Forward-Port-Of: odoo/enterprise#105135
This update resolves a potential issue where tracking numbers in the POS Self Order module could collide. Due to limitations in adding new fields to the main Odoo version, a simple method was implemented to randomly add a letter prefix (K) to tracking numbers, preventing duplicates and ensuring accurate order tracking.
Original PR description
Since we cannot add fields in stable we use a little trick to avoid collisions in tracking numbers for POS Self Order module. We do a modulo operation on the ID of the PoS config to select a random letter from A-Z and prepend it to the tracking number. Forward-Port-Of: odoo/odoo#245476
This change removes a previous restriction that limited the ability to use certain journal accounts for reconciliation. Previously, accounts used as default debit or credit accounts within journals were automatically prevented from being reconciled. This update provides greater flexibility for users to reconcile accounts as needed, improving the system's usability.
Original PR description
Previously, a constraint prevented accounts from being non-reconcilable if they were used as default debit/credit accounts involved in journals. This behavior is too restrictive. This commit removes the constraint. task-5254202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245608 Forward-Port-Of: odoo/odoo#244398
This update resolves a bug that occurred when generating German reports. Specifically, a division-by-zero error was triggered when currency exchange differences (where the amount_currency was zero) were processed. The fix ensures that these lines are correctly handled, preventing the error and improving report accuracy.
Original PR description
On move lines with zero `amount_currency` ( ex. currency exchange difference ), `_get_product_base_line_currency_rate` returns 0 currency rate which causes a division by zero error. Ignore the rate for lines with zero `amount_currency` opt-5358954 Forward-Port-Of: odoo/enterprise#105432 Forward-Port-Of: odoo/enterprise#105360
This update resolves a technical issue where creating two Sri Lanka companies resulted in an error due to duplicate tax IDs with periods. The fix removes the periods from the tax IDs in the system's configuration, ensuring proper company identification and preventing the error. This improves data accuracy for Sri Lankan businesses using Odoo.
Original PR description
**STEP TO REPRODUCE** 1. create a company, and set country to Sri Lanka. 2. create a 2nd company, and do the same. 3. There is a company inconsistencies error. **CAUSE** There is 2 taxes defined in `account.tax-lk.csv` with `.` in their id. This messes up with the function `company_xmlid()`: we end up loading the `account.tax` record of the 1st company when saving the 2nd company. opw-5473952 Forward-Port-Of: odoo/odoo#245244
A test failure in the payroll system's 13th month calculation was identified and fixed. The issue stemmed from incorrect date calculations within the test environment, specifically related to standard work hour calendars. This change ensures accurate 13th month pay calculations for employees.
Original PR description
[FIX] test_l10n_be_hr_payroll_account: fix the test of 13th month full leave Bug production: It is a runbot error occurred in test_13th_month_full_leave (version: master); 1 - Install and update…
[FIX] test_l10n_be_hr_payroll_account: fix the test of 13th month full leave
Bug production: It is a runbot error occurred in test_13th_month_full_leave (version: master);
1 - Install and update l10n_be_hr_payroll,l10n_be_hr_payroll_account,test_l10n_be_hr_payroll_account,hr_holidays,resource modules in localhost
2 - Execute the test test_13th_month_full_leave and it will fail, also in the same class (Test13thMonth) many other tests were failing.
Bug cause:
1 - In test test_13th_month_full_leave, for all year the sick day timeoff is allocated. (year: 2025), generate work entries for 2025 and expecting payslip amount must be 0 but it is not.
2 - When I looked to _get_paid_amount -> _get_paid_amount_13th_month -> _compute_presence_prorated_fixed_wage: Some days in the year was not counted as sick day and since few days are not counted, the payslip amount is > 0.
3 - By diving deeper: in function _get_calendar_days: date_to = min(date_max, leave.date_to.date()), from this line, I observed that leave.date_to is calculated 1 days before sometimes.
4 - In hr.leave model -> _compute_date_from_to -> hour_from, hour_to = holiday._get_hour_from_to(holiday.request_date_from, holiday.request_date_to) -> In here hour_from and hour_to is (0,0) when the calendar (id = 1) standard 40h/week is used.
5 - Since it returns (0,0) and converted to UTC in the next line, the date_to becomes 1 day before the expected date_to.
6 - After finding that, the standard 40h/week calendar returns (0,0) for work start hour and work end hour, I looked to 'resource.calendar' model.
7 - In function _get_default_attendance_ids, hour_from and hour_to returns 0,0 for typical 40 hours/week calendar which is not true.
8 - This standard calendar with id = 1 is used in other 4 tests in class Test13thMonth and they were failing as well, now all of them are fixed.
Bug solution:
1 - Fixing the hour_from and hour_to of standard 40h/week calendar from (0,0) -> (8, 16).
task - 5853076
Runbot Error
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-prThis update resolves an issue where applying text colors to lists in the HTML editor didn't correctly color the list markers. The fix corrects a logic error that was removing the text color class from the list item itself. Now, text color selections will consistently apply to both the text and the list marker.
Original PR description
### Steps to reproduce: - Create a list and type some text. - Press Ctrl + A and apply a text color from the toolbar. - Observe that the list marker is not colored. ### Description of the issue/feature this PR addresses: - `getFonts` looked for the closest element with a text color class, and this also matched `<li>` elements. When a `<li>` was selected, its text color class was removed and moved to a new <font> element created inside the `<li>`. - As a result, the color class was removed from the list item itself, which broke list marker coloring. ### Desired behavior after PR is merged: - Text color classes remain on list item, so list markers are colored correctly. task-5454639 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243005
This update resolves an issue that caused a traceback during employee searches within appraisals. The fix removes a restricted field from the search domain, ensuring compatibility with the public employee model and preventing errors. This improves the reliability of the appraisal process.
Original PR description
Steps to reproduce: 1. Log in with demo user 2. Create a new appraisal 3. Search for an employee Issue: A traceback occurs when searching for an employee. Cause: The `registration_number` field is not available on the `hr.employee.public` model for public users. Fix: Remove `registration_number` from the employee search domain and restrict the search to fields available on the public model. task-5864546
This update resolves an issue where using certain reserved words (like 'constructor') as customer names would trigger an error in reporting. The fix prevents the system from incorrectly interpreting these names, ensuring customer data can be accurately displayed in reports. This improves the reliability of customer reporting.
Original PR description
Steps:
- Have a customer named "constructor" (or any valid json prototype key value)
- Install `sale_management`
- Create a sale order with "constructor"
- Open Reporting -> Customers
- Traceback `Caused by: TypeError: groupedDataPoints[key].push is not a function`
This problem occurs because we use the client name directly in an object, and “constructor” already exists in all objects but is not initialized correctly, which raises a traceback.
One solution is to use `let object = Object.create(null)` instead of `let object = {}`, which prevents inheritance of `Object.prototype` properties.
https://github.com/odoo/odoo/blob/5e74f04ff35ed3efa25be295567be41f42024692/addons/web/static/src/views/graph/graph_model.js#L451-L457
opw-5474691
Forward-Port-Of: odoo/odoo#245369
Forward-Port-Of: odoo/odoo#245206This update resolves an issue where invoices sent to Peppol were failing validation due to an incorrect UN/ECE code. The fix removes a specific code ('HD') that was valid under UN/ECE standards but not accepted by Peppol, ensuring invoices now pass validation and can be successfully transmitted.
Original PR description
**Steps to reproduce:** - Use a Belgian company - Create a Belgian contact with "EU Standard (Peppol Bis 3.0)" as eInvoice format - Create an invoice for that customer with a product using "Pack of 6" as unit of measure - Confirm the invoice - Send it to Peppol **Issue:** The validation of the invoice fails with the following error: "[BR-CL-23]-Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21 extension" **Cause:** The UNECE code used for "Pack of 6" UoM is "HD". "HD" is a correct UNECE code for "Half Dozen". However, it is not part of the subset of codes accepted by Peppol. opw-5463212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244668
This update reorganizes code within the Odoo platform to better align with project standards. Specifically, a previously misplaced override function has been moved to the `portal_rating` module, as the `rating` module doesn't require direct portal integration. This improves maintainability and reduces potential conflicts.
Original PR description
Since #234356, `_get_allowed_message_post_params` method of the `PortalChatter` has been overridden in the `rating` module. As the `rating` has no dependency on the portal, the current change moves this override to the `portal_rating` module.
This update fixes tests related to overtime calculations, specifically those using quantity-based rules. The changes align the tests with a recent update to the overtime calculation logic, ensuring accurate tracking and reporting of overtime hours. This improves the reliability of our attendance data.
Original PR description
this PR made some changes to how overtime is calculated by quantity based rules. This PR aims to adapt the test to the new calculation logic Forward-Port-Of: odoo/enterprise#104607
This update fixes an issue where portal users from other companies couldn't be mentioned in chat due to incorrect access permissions. The fix ensures that read access to portal users is correctly determined based on the currently active company, resolving a previous data storage issue. This improves the usability of the portal for users across different companies.
Original PR description
* = test_discuss_full Before this commit, mentioning a portal user from another company would result in an access error. Steps to reproduce: 1. Install `hr_holidays` module. 2 Have a portal user in company A. 3. Switch the active company to company B. 4. In any chatter, try to mention said portal user. This happens because portal user read access depends on the current active company (see `res_users_rule`). The access error happens since [1], which added user information to the partner's default Store fields. [1] https://github.com/odoo/odoo/pull/212173 task-5499827 Forward-Port-Of: odoo/odoo#245395 Forward-Port-Of: odoo/odoo#245224
This update resolves a customer complaint regarding demo data containing the name "Deco Addict". All instances of "Deco Addict" have been replaced with "Acme Corporation" across multiple Odoo modules to ensure accurate demo data and avoid user confusion. This improves the user experience and data integrity.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/odoo#245659 Forward-Port-Of: odoo/odoo#245205
This update resolves a customer complaint regarding test data. The name "Deco Addict" has been replaced with "Acme Corporation" to ensure demo data accurately reflects business scenarios. This change improves the user experience and avoids confusion.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502 Forward-Port-Of: odoo/enterprise#105447 Forward-Port-Of: odoo/enterprise#105151
This update resolves an issue where the tour pointer might not function correctly if the element it's trying to trigger isn't immediately available. The change ensures the tour pointer only attempts to interact with elements that are accessible, improving the overall tour experience and preventing potential errors. This is a technical fix to enhance usability.
Original PR description
POC for task-5490670 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 visual issue in the VoIP demo mode, ensuring a helpful tooltip is consistently displayed when hovering over the 'Demo Mode' indicator in the Softphone header. Previously, the tooltip text wasn't correctly linked, but this change ensures users understand how to configure Production Mode and improves the demo experience. This resolves a minor usability concern.
Original PR description
## Context There are two modes in VoIP: _Production Mode_ and _Demo Mode_. Demo Mode enables you to simulate a call in the UI without actually calling someone. This is useful for showing customers…
## Context There are two modes in VoIP: _Production Mode_ and _Demo Mode_. Demo Mode enables you to simulate a call in the UI without actually calling someone. This is useful for showing customers the features and for developers to test the UI 💡 Though useful, this feature can be confusing. Users may not realize they aren't in Production Mode, and developers may forget to switch back to Demo Mode when testing the UI. 535a7aef3e410d997baa093cc111527814c29253 improved the situation by displaying "Demo Mode" in the Softphone header when Demo Mode is enabled. It was intended to include a tooltip explaining how to configure Production Mode when hovering over it. However, although the tooltip text is present in the code, it was not correctly mapped to the "demo indicator" ¯\\\_(ツ)\_/¯ ## In this PR After this commit, - the tooltip text is correctly provided to the "demo indicator", enabling it to be displayed on hover; - the tooltip text is slightly reworded in the hope of making it clearer. [Task-5804537](https://www.odoo.com/odoo/project/5778/tasks/5804537) Fix https://github.com/odoo/enterprise/pull/95742 Forward-Port-Of: odoo/enterprise#105284
This update removes an unnecessary delay in Odoo's tour engine, resolving inconsistent behavior and improving tour reliability. By eliminating this delay, tours now execute predictably, reducing errors and enhancing the user experience. This change ensures tours function consistently across all modules.
Original PR description
We noticed that allowing a delay between each step of the tours (in the macro engine) leads to indeterministic behavior within the tours, such as: - letting animationframes to be calculated - waiting for the RPC response, which sometimes arrives, sometimes not within 50ms. Most of the time, a tour is indeterministic because it takes a wrong way by pointing to overly general triggers. Removing this (arbitrary) delay is the final step to ensure the macro engine always works the same way. Find trigger => Do Action => Find trigger => Do Action => ... No more delay between each step of the process. With this commit, by default, the delay is removed in all tours by default but it is necessary to tag the tours which are still indeterministic.
This update enhances the reliability of Odoo's tour functionality by adding a key to handle tours that previously caused crashes. This resolves an issue affecting approximately 220 tours, improving overall performance and user experience. The change aims to eliminate random errors and make tour execution more deterministic.
Original PR description
Add tags to tours
This update simplifies the process for creating leave requests in Odoo. The toggle button for date ranges has been removed, now requiring users to select a start and end date for their leave. This change ensures more accurate leave tracking and reporting.
Original PR description
- removed the toggle button so leaves can be only created with date range task-id: 5065209
A test failure related to employee assignments within the MRP Work Order module has been resolved. The fix prevents a constraint error that occurred when multiple employees were repeatedly assigned to the same user, ensuring consistent test results. This improves the reliability of our core work order processes.
Original PR description
Before this commit, the test `test_allowed_employees_restriction` was failing because two different employees of the same company were assigned one after another to a same user. When the changes are commited, the constraint `_user_uniq` was triggered. Solution: use a different user instead of reassigning to the same one so that the constraint isn't triggered when setting another employee to the user. fixes odoo/enterprise#96931 runbot error 234537 Forward-Port-Of: odoo/enterprise#103833
This update fixes a build error that occurred when displaying call status badges, preventing a crash in certain scenarios. The issue stemmed from an undefined 'id' value within the call status calculation logic. The fix ensures the correct record ID is used, regardless of whether the call is a real or virtual record, improving stability.
Original PR description
We fix the build error 238415: _Cannot read properties of undefined (reading 'isInProgress')_. That error is raised in the class UserAgent ```js isInProgress(callId) { return (…
We fix the build error 238415: _Cannot read properties of undefined (reading 'isInProgress')_.
That error is raised in the class UserAgent
```js
isInProgress(callId) {
return (
(this.mainSession?.call?.id === callId && this.mainSession.isInProgress) ||
(this.transferSession?.call?.id === callId && this.transferSession.isInProgress)
);
}
```
because both this.mainSession and callId are undefined in the test context.
### Root cause
In the class CallStatusBadgeField
```js
get statusLabel() {
const isInProgress = this.isInProgress(this.props.record.data.id);
const { direction, state } = this.props.record.data;
return Call.getStatus({ direction, isInProgress, state });
}
```
isInProgress is called with this.props.record.data.id but id can not be found in this.props.record.data so that when there
is no main voip session, the crash occurs.
Actually, for a real record, the id is given by this.props.record.resId and for a virtual record (a record not already created in db) the id is given by this.props.record.virtualId. Note that resId and virtualId are never both defined.
### Fix
Since a session is always linked to a read record, we pass to isInProgress the id given by this.props.record.resId but we have to protect us from the case were the record is virtual. Hence the use of the optional chaining operator in case the sessions would not be defined.
runbot-error-238415This update prevents the OCR from automatically updating a user's address information when processing QR-bills. Previously, the system would incorrectly overwrite existing partner details, causing confusion for users who receive QR-bills via email and forward them. This change ensures accurate address data is maintained, streamlining the billing process.
Original PR description
When the OCR detects that the document is a QR-bill, it will always overwrite the address information from the partner currently set on the record. We shouldn't do that if the partner wasn't created by the OCR. In the following scenario, it's pretty obvious why it is a bad idea: - User receives his QR-bills on his personnal email address. - He forwards it to the email alias set up for vendor bills. - A vendor bill is created with himself set as the supplier (already a bit annoying for him) - The OCR automatically analyses the document and updates the user's record with the address found in the QR-bill (really annoying). The same issue can arise if the user manually sets a supplier before sending the QR-bill for digitization. task-none Forward-Port-Of: odoo/enterprise#105343 Forward-Port-Of: odoo/enterprise#104902