Daily updates from Odoo
Wednesday, January 21, 2026
352 changes
20 changes
Enhancements to existing features
This update simplifies the process of generating consolidated invoices from Point of Sale orders. Previously, invalid orders (like those already invoiced) would halt the entire process. Now, any problematic orders are automatically ignored, allowing users to generate invoices for the valid orders efficiently. This enhances bulk invoice generation capabilities.
Original PR description
When trying to create a consolidated invoice in the POS from multiple orders, if any of them would not be valid (i.e. invoice already generated, or order still in draft), then Odoo would throw an error and not do anything. Now the orders for which invoices can't be generated will just be ignored, but for the rest of the orders the invoices will be generated as usual. This should make it easier to bulk select and generate invoices only where necessary. Task-[5491082](https://www.odoo.com/odoo/project/1737/tasks/5491082) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243851
This update enhances the restaurant POS system by automatically summing guest counts when multiple linked tables are used. Previously, each table was tracked separately. Now, when tables are linked, the system accurately reflects the total number of guests across all linked tables, providing a more complete picture of customer occupancy.
Original PR description
When two tables are linked in the pos, we would like to sum the guests. Here an example : If Table 1 has two guests and Table 2 has three guests, then Table 1&2 will have five guests. task: 5490906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243726
Resolved issues and error corrections
This update resolves a bug where changing an inactive currency on invoices and bills caused display errors and crashes in the invoice/bill list views. The fix ensures the front-end correctly receives and uses currency data, preventing these issues and improving the user experience when working with multiple currencies.
Original PR description
In the form view of invoices and bills, if the currency is changed to an inactive one, an option to activate it from the form view was available, but when the button is pressed the front-end doesn't receive the new data related to the currency which resulted in unexpected errors when trying to view the invoice/bill or the list of invoices/bills task-5412003
This update prevents users from misconfiguring the category snippet within the website builder. Previously, users could unintentionally change the snippet's content to display products or blogs instead of categories, resulting in empty blocks. This fix ensures the snippet functions as intended for category listings.
Original PR description
Steps to reproduce: ==================== 1- Go to any product and in the tab Sales add some accessory products 2- Go to the website and edit a page 3- Add a category list block 4- Change category list filter to "Accessories for product" 5- Save -> The block is empty Cause: ====== The category snippet was meant to be used only for categories. The problem is that its possible to change from "Categories List" to anything else. When the user makes the choice to add a categories snippet he shouldn't be able to change the content of the snippet from categories to products, blogs, etc.. Solution: ========== Prevent replacing the category snippet to anything else. opw-5497284 Forward-Port-Of: odoo/odoo#244053
The picking operations report was incorrectly printing all deliveries on a single page when multiple deliveries were selected. This change addresses a layout update that removed automatic page breaks, now forcing the report to split across multiple pages for better readability and printing. This ensures reports are easier to manage and print effectively.
Original PR description
When printing several picking operation at once, they are all in the same page. Steps to reproduce: ------------------- * Inventory>Operations>Deliveries * Create several Deliveries * Open list view to see all the deliveries * Select several deliveries * Print > Picking Operations -> All the picking operation report are on the same page. Observation: ------------- Since the change on the picking report layout https://github.com/odoo/odoo/pull/152280/changes#diff-7542c191def78bd64f54f1c33fde2c73e19e4d27f92b195c464d1d84e55b682fL6-R8 the report now uses a single article container for all records, this don't trigger automatic page break. opw-5481034 Forward-Port-Of: odoo/odoo#243817
This update enhances the security of user profile editing by utilizing a new internal function, '_can_edit_country()', to determine if a user is authorized to change their country setting. This change, following a previous update, ensures that only permitted users can modify their profile information, improving data integrity and security.
Original PR description
In 'save_edited_profile()', we check that the user can edit his country_id if he tries. As from saas-18.4, a new helper '_can_edit_country()' is available. This commit uses that helper to perform the check. Follow-up of #239789 Task-5331916 Forward-Port-Of: odoo/odoo#244694
This update resolves an issue where registration emails for events were displaying duplicate headers and footers. The fix removed an unnecessary email layout setting that was causing this duplication. This ensures a cleaner and more professional email experience for event attendees.
Original PR description
**Steps to reproduce:** - Go to Event module - Go to an open event - Register for the event - Go to the Attendees of the event - On the attendee record, click `Send by Email` - The received email shows twice the header and footer **Issue:** Encapsulating notification layout was applied with `default_email_layout_xmlid` but the main template used is `event_registration_mail_template_badge` which already has its own header and footer. **Fix:** Removed the `default_email_layout_xmlid` opw-5032767 Forward-Port-Of: odoo/odoo#236667
This update fixes a visual glitch in the spreadsheet edition where the chart's data source selection panel didn't update correctly after linking a datasource. Users could link a datasource, but the interface would still display the previously linked one. This ensures a smoother and more accurate data source selection experience.
Original PR description
Currently, when a user links a chart to an odoo datasource, the sidepanel is not updated properly when the user tries to select a datasource from the same type as the one already selected. How to reproduce: - In a spreadsheet, insert a chart and a list datasource - duplicate the list datasource - in the chart sidepanel, select list#1 as link - now try to select list#2 -> the model update the link to list#2 but the interface still shows list#1. Task-5725964
This update resolves an issue where the partner ID wasn't correctly passed through stock move processes, particularly in multi-step delivery scenarios. The fix harmonizes how partner information is set within procurement records, ensuring accurate customer association for shipments. This prevents incorrect customer assignments during order fulfillment.
Original PR description
*mrp{,_subcontracting_dropshipping}, point_of_sale, sale_purchase, {purchase_,sale_,}stock ### Issue: The partner_id (contact field) of stock move is no longer propagated in pull chain since the…
*mrp{,_subcontracting_dropshipping}, point_of_sale, sale_purchase, {purchase_,sale_,}stock
### Issue:
The partner_id (contact field) of stock move is no longer propagated in pull chain since the procurement/reference refactoring of 19.0 see 2713876dbc70d3984e584a9037a2206dcda4e84a
#### Steps to reproduce:
- In the settings enable Multi-Steps routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Set your warehouse in two step deliveries
- Modify the routes to have two pull rules: Stock -> Out -> Customer
- Create and confirm an SO, 1 unit of a storable product for a customer
#### > While the customer is set on the ship move and picking it is not on the pick move and picking.
### Cause of the issue:
Due to the configuration, the ship move is created by the `action_launch_stock_rule` and linked to the customer via the procurement created from the sale order line:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/sale_order_line.py#L295 Then, the confirmation of the ship move generates a second procurement for the pick move creation. Prior to 19.0, the partner_id of this second procurement was set to the customer via the procurement group: https://github.com/odoo/odoo/blob/712cd806c38e193acdb966e4d3b339ab780f158e/addons/stock/models/stock_rule.py#L333 However, since procurement groups have been removed by the reference refactor 2713876dbc70d3984e584a9037a2206dcda4e84a, the partner id is now expected to be set from the procurement values:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L332 As it is not set by any mean in this procurement values it will therefore not be propagated.
### Additional changes:
1. The `partner_id` of the procurement values needs to be harmonized are some methods set a recordset and others a record id:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/point_of_sale/models/pos_order.py#L1707
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/mrp_subcontracting_dropshipping/models/stock_orderpoint.py#L10-L13
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/sale_order_line.py#L295
The correct behavior is to set an id since the `partner_id` value of the procurement group is used in the `_get_stock_move_values` and written in its "raw state" as the `partner_id` values for the stock move for creation (when sale_stock is installed):
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/stock.py#L171-L174
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L378-L381
2. The `partner` key of the procurement values is set by to `partner_id` in every overrides but since 2713876dbc70d3984e584a9037a2206dcda4e84 was incorrectly cahnged to `partner`:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L332
We change back this key to the expected `partner_id` and revert the associated pos fix 203f807a2b764821ec4673515dd29f392ec37b3a using the changed `_get_partner_id` method.
3. In certain use cases, such as inter-warehouse transfer the the `partner_id` should not be propagated by the pull chain as it is expected to be set by the `_get_stock_move_values`:
https://github.com/odoo/odoo/blob/df01277bc053218dda6157f2f0657432e91e1d58/addons/stock/models/stock_rule.py#L339-L346
4. Since the `partner_id` is used to set the `dest_address_id` here:
https://github.com/odoo/odoo/blob/92486bab9b73f4370629452c454c25371d5063ac/addons/purchase_stock/models/stock_rule.py#L350
But is suppose to be reset for non dropshipping use case:
https://github.com/odoo/odoo/blob/df01277bc053218dda6157f2f0657432e91e1d58/addons/purchase_stock/models/purchase_order.py#L80-L82
We need to modify the fix of 3fb81df557553d471ff72998200097b3a0ea666f in order for the value set by th epartner_id to be reset in case we are not in a dropshipping use case.
Similarly, we should only add the `partner_id` of the procurement value as a possible `dest_address_id` in the dropship use case:
https://github.com/odoo/odoo/blob/2c0c26e6cc61f70c91617617ef77f23cfaa1dde6/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L19-L23
5. Since we are setting a default falsy 'partner_id' values in the `_prepare_procurement_values` of stock moves (e.g.`self.partner_id.id`) we needed to slightly alter the `_prepare_purchase_order` of the `mrp_subcontracting_dropshipping` module so that it sets the partner of the subcontractor when the move sets it to `False` rather than unset:
https://github.com/odoo/odoo/blob/1ac7834a9b9d07760700f6d7c73dfe270a247752/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L10-L11
opw-5428063
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243028This update fixes a problem where canceled orders and their items persisted in the system, leading to incorrect order displays. Now, when an order is canceled and a new one is created, the system accurately reflects the changes, ensuring correct quantities and totals are shown. This improves the user experience for self-order functionality.
Original PR description
`point_of_sale`, `pos_self_order` ### step to reproduce: - Configure self order with online payment. - Open POS Self Order. - Add some products to the cart. - Cancel the order. - Create a new order and pay it via an "online payment" method. - Click on "Order Now". ### issue: - Previously cancelled products reappear as selected in the new order. ### reason: - Cancelled orders and orderlines were not removed from IndexedDB. - With Pay after Meal, a second order on the same table reused the existing one, causing the product card, order widget, and cart to show quantity and total from the old order instead of the new changes. ### fix: - Ensure both the order and its orderlines are removed from indexeddb when cancelling an order. - Product/cart page must show changed quantity and amount. task: 5005174 Forward-Port-Of: odoo/odoo#243971 Forward-Port-Of: odoo/odoo#224918
This update resolves an error that appeared when users set their timezone to "localtime" in Odoo, causing the Avatar card to display an "Invalid DateTime" message. The fix converts "localtime" to the browser's timezone and adds a validation check to ensure time formatting only occurs with valid timezones, improving the user experience.
Original PR description
Purpose of commit: Avatar cards displays “Invalid DateTime local time” when a user’s tz was stored as the literal “localtime”, which Luxon can’t resolve. Add a helper to resolve “localtime” to the browser zone and keep a validity guard so formatting only runs with valid timezones. Steps to reproduce: - Login with user A change the timezone of the user A from the preferences tab. Change it to "localtime" - Login with user B, open avatar card of user A, the below error is shown. <img width="200" height="200" alt="image" src="https://github.com/user-attachments/assets/bd0ad9dd-619f-41dc-bdf1-0a111e2a8862" /> task-5477788
This update resolves a technical issue where assets components were missing from the merged account_batch_payment module. This ensures the module functions correctly and avoids potential performance problems. The fix was implemented as a routine maintenance update.
Original PR description
During the merge of the module account_accountant_batch_payment and account_batch_payment, we forgot to add the components to the assets of the merged module cfr: https://github.com/odoo/enterprise/pull/97544/files#diff-59095aa2812fc8b48436f7aaf3416dc40bb273c7d234ec18a37ac1576d0643e4
A bug preventing the Gantt view from opening has been fixed. This issue occurred when the system couldn't properly access project data, resulting in an error. This update ensures the Gantt view functions correctly for all users.
Original PR description
Currently, an error occurs when the user opens the Gantt view. **Steps to Reproduce:** - Install `timesheet_grid` without demo data. - Go to `Settings` and enable `Project Stages`. - Go to `Projects` and switch to the `Gantt view`. `UnboundLocalError: cannot access local variable 'project' where it is not associated with a value` This error occurs because, in [this commit], line [1] is mistakenly placed outside the loop. If self has no records, project is not defined, and accessing project.date_start raises an error. This commit moves the line inside the loop. [1]: https://github.com/odoo/enterprise/blob/34feeda7d0835d8c65d91493314133b8e83610d1/timesheet_grid/models/project_project.py#L50 [this commit]: https://github.com/odoo/enterprise/commit/c3296d1441400d20e3815207baa1188b5cb8fd93#diff-59e7d75aff5c1e890cd536834137eac5cd3ad185cb45ee1e157be15402cbc90fR50 sentry-7204644855
This update adds a 'Reload Data' button to error dialogs in the Point of Sale system, providing users with a simple way to resolve common issues. Previously, users only had an 'Ok' button, making it difficult to recover from errors. This change reduces downtime and improves the overall user experience for restaurant and online payment operations.
Original PR description
Purpose: ------------ - On Error dialogs, users only had "Ok" or could close the dialog, with no guidance on what to do next. - Many blocking issues are resolved simply by reloading POS data. Before this commit: ----------- - Error dialogs only had an "Ok" button. After this commit: ------------------ - Added a "Reload Data" button for quick recovery of common blocking issues. - Added a warning message in the reload data popup - For POS Restaurant, orders will attempt to sync before reloading data, reducing the risk of data loss. Task-5353590 Forward-Port-Of: odoo/odoo#243863 Forward-Port-Of: odoo/odoo#238112
This update resolves a bug where combo choices weren't displaying correctly in the self-order kiosk and online ordering systems. Previously, users had to reconfigure combo choices after selection. This fix ensures combo choices are displayed correctly without requiring manual reconfigurations, improving the user experience.
Original PR description
Before the fix, when we set a product variant as combo choice. In self/kiosk, we'll see the product template instead of the product itself. And we need to configure it again. It occured because for all of the products in the kiosk/self, we display the product template. The expected behavior if we set a product variant as combo choice is to have the product variant in the combo directly without having to reconfigure it. The bug occurs only since 19.0 because a fix was already done from 18.3 to 18.4 in this pr : #219908 but the fwport for 19.0 has never been merged. task: 5493798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244055
This update resolves an issue where invoices sent to Viettel's SInvoice system were failing due to incorrect decimal formatting. The change ensures the tax amount is calculated using the currency's rounding rules, preventing these errors and improving invoice processing with SInvoice.
Original PR description
When sending an invoice to SInvoice (Viettel), the API raises an `INVALID_DECIMAL_POINT_TAX_MONEY` error if the tax amount contains excessive decimal places (e.g., 100.02999999999997). This occurs because the tax amount is currently calculated using simple subtraction (`total - subtotal`). Due to standard floating-point precision issues, this can result in unrounded values that the API rejects. The tax amount calculation is now updated to explicitly use the currency's rounding method, ensuring the value is accepted by SInvoice. task-[5484845](https://www.odoo.com/odoo/project/967/tasks/5484845) Forward-Port-Of: odoo/odoo#244647
This update corrects a bug where the 'Import Bank Statement' action incorrectly selected a journal in multi-company Odoo setups. The fix ensures the action filters by the currently chosen company, preventing errors and ensuring accurate bank statement encoding. A new test confirms the fix's reliability under sudo rights.
Original PR description
Issue: when using the server action 'Import Bank Statement' the code would not filter on the currently selected company for choosing the journal on which to encode the bank statement and simply take the first result. Because the server action is running with sudo rights, in a multi-company environment more then one journals are found and the selected one is often wrong. Solution: filter on company during the selection of the journal. Note: a test was added in which we run the function with sudo rights to ensure an error is raised when the journal does not exist on the currently selected company, even if it is present on another company. Task-5494685 Forward-Port-Of: odoo/enterprise#104970 Forward-Port-Of: odoo/enterprise#104326
This update fixes an issue where employees on leave were incorrectly flagged for overtime. Now, when an employee is on a full day of leave, all hours worked are treated as overtime, without considering breaks. This ensures accurate overtime calculations for all employees.
Original PR description
This PR aims to fix how the overtime is being calculated with quantity based rules : - The expected _hours didn't take into account the leaves of the day , so if the user was on a leave, it would considered him absent ( give him negative overtime) , because he has no attendances that day. - if the employee took a whole day off, and decided to work on it, all the hours should be considered as overtime, the brake shouldn't be included (ex : his normal work sched is morning (9h-12h) , break(12h-13h), afternoon(13-17h) , he's already getting paid for that time , so every single hour worked that day from 12am to 12 pm is added time , and there is no break in added time) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244048
This update fixes tests related to overtime calculations based on quantity. The changes reflect a recent update to the overtime calculation logic, ensuring the tests accurately reflect the new system. This improves the reliability of our overtime tracking processes.
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 resolves a bug where the column layout within the HTML editor would break after performing undo operations. Specifically, changing the number of columns using Powerbox would corrupt the column structure. This change ensures the column layout remains consistent and functional after undoing changes.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create 3 columns using powerbox - Convert it into 4 columns - Press ctrl + z to make it 3 columns - Convert it into 4 columns again using powerbox Notice that column structure is broken. This happens because after undo operation, in `changeColumnsNumber` the regex replaces column div className incorrectly leading to invalid colund structure. **Desired behavior after PR is merged:** This PR ensures that column structure doesn't break. task-5468578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242500
9 changes
Enhancements to existing features
This update enhances the testing process for paying invoices with bank statement lines within the Odoo accounting system. The change introduces a reusable test helper, streamlining testing and ensuring more accurate invoice payment simulations. This improves the reliability of our accounting module's payment functionality.
Original PR description
Forward-Port-Of: odoo/odoo#244377 Forward-Port-Of: odoo/odoo#244281
Resolved issues and error corrections
This update resolves a technical issue that was preventing the employee version timeline from automatically saving correctly. The fix involved updating the test code to use a method that simulates a consistent time environment, ensuring data is saved reliably. This improves the stability and accuracy of employee version tracking.
Original PR description
As runbot faketimes test fail because the usage of dynamic dates now the test uses freeze_time Task#5717031 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where importing invoices could halt the entire process if one invoice encountered an error. Previously, failing on a single invoice would cause duplicate invoices to be created. This change ensures that the import process continues smoothly even if individual invoices have problems, improving data accuracy and reliability.
Original PR description
When you import a batch of invoice and one of them gets an unexpected Exception, the others are created but we stop the method. It's a problem with crons that don't expect to be interrupted in the middle. It creates duplicates as we fail on the same invoice each time. Of course, we should avoid all Exceptions when we can, but we should not loop on the same error. opw-5503069 part of task-5499871 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where multiple delivery reports were printed on the same page. The change in the report layout prevented automatic page breaks, causing reports with multiple deliveries to be combined. This ensures that reports with multiple deliveries are formatted correctly for printing.
Original PR description
When printing several picking operation at once, they are all in the same page. Steps to reproduce: ------------------- * Inventory>Operations>Deliveries * Create several Deliveries * Open list view to see all the deliveries * Select several deliveries * Print > Picking Operations -> All the picking operation report are on the same page. Observation: ------------- Since the change on the picking report layout https://github.com/odoo/odoo/pull/152280/changes#diff-7542c191def78bd64f54f1c33fde2c73e19e4d27f92b195c464d1d84e55b682fL6-R8 the report now uses a single article container for all records, this don't trigger automatic page break. opw-5481034 Forward-Port-Of: odoo/odoo#243817
This update fixes a critical issue where the Moroccan tax report XML export incorrectly handled cash basis accounting. The fix ensures bills are accurately reflected in the export, aligning with Moroccan tax regulations. This improves data consistency and reliability for tax reporting.
Original PR description
[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that,…
[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that, and always reported all bills in the period. Solving this requires using an SQL query so that cash basis can be properly computed, like in the report. This also makes the export much more efficient, and resilient to bigger amount of data. Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA company - Create and confirm a bill: Bill Date: 10/01/2025 Vendor: Azure Interior Invoice Lines: Price 100, Taxes 20% (S 140) - Go to `Bank Reconciliation` - Add a transaction (Vendor: Azure Interior, Amount: -120 DH, any Memo) - Select the transaction and the invoice, then click Validate - Open the Tax Return for November. Section D should show data linked to the created invoice - Export the XML using the Gear → XML The created bill is missing in the XML and others may be present, showing inconsistent data opw-5002779 [IMP] l10n_ma_reports: call the report to compute the prorata value Searching explicitly for external values is a bad practice ; calling the report ensures consistency between the data displayed, and the one exported into the file. Forward-Port-Of: odoo/enterprise#104667 Forward-Port-Of: odoo/enterprise#104619
This update resolves an issue where registration emails for events were displaying duplicate headers and footers. The fix removed a redundant email layout setting, ensuring that only the event's standard header and footer are included in the sent emails. This improves the email experience for registered users.
Original PR description
**Steps to reproduce:** - Go to Event module - Go to an open event - Register for the event - Go to the Attendees of the event - On the attendee record, click `Send by Email` - The received email shows twice the header and footer **Issue:** Encapsulating notification layout was applied with `default_email_layout_xmlid` but the main template used is `event_registration_mail_template_badge` which already has its own header and footer. **Fix:** Removed the `default_email_layout_xmlid` opw-5032767 Forward-Port-Of: odoo/odoo#236667
This update ensures popover animations in our tests run consistently, preventing unexpected behavior and reducing test complexity. A fix was implemented to address timing issues and enable the ResizeObserver, improving the reliability of our test suite. This enhances the stability of the web application.
Original PR description
This commit fixes two things; 1. Because the popover had his animation enabled in tests, it could on very rare occasion end too fast and call it's finished callback, triggering extra repositionning (and thus extra expect.steps). 2. The ResizeObserver could never trigger if there where no animations, it now can but some tests had to be adapted. --- 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 IoT driver was adding unnecessary IDs to the system, slowing down performance when actions took longer than 6 seconds. The fix ensures IDs are only added to the cache when actions complete successfully, optimizing the driver's responsiveness and reducing potential bottlenecks.
Original PR description
If an action takes a long time to execute (>6s), then we don't add the unique id during this time as the action didn't finish. As it exceeds 6 seconds, we also send one through websocket, that isn't filtered as duplicate as the action id isn't set yet in the `_recent_action_ids` cache. To avoid this, we add the action id to the cache, then execute the action and remove the id from the cache if there is an exception.
This update resolves an issue where invoices sent to the Viettel SInvoice system were failing due to incorrect tax amount formatting. The change ensures the tax amount is calculated using the currency's rounding method, aligning with SInvoice's requirements and preventing errors.
Original PR description
When sending an invoice to SInvoice (Viettel), the API raises an `INVALID_DECIMAL_POINT_TAX_MONEY` error if the tax amount contains excessive decimal places (e.g., 100.02999999999997). This occurs because the tax amount is currently calculated using simple subtraction (`total - subtotal`). Due to standard floating-point precision issues, this can result in unrounded values that the API rejects. The tax amount calculation is now updated to explicitly use the currency's rounding method, ensuring the value is accepted by SInvoice. task-[5484845](https://www.odoo.com/odoo/project/967/tasks/5484845) Forward-Port-Of: odoo/odoo#244647
15 changes
Enhancements to existing features
This update enhances the user experience by adding a cursor pointer to the headers of statement summaries in the accounting module. This allows users to easily navigate and explore their financial data more efficiently. It's a simple change designed to improve usability.
Original PR description
This improves the user experience by indicating that the headers are clickable. No task ID
This update ensures Odoo correctly handles the new 11% and 21% VAT rates introduced in Romania. By adding missing tax mappings, the system now accurately reflects the latest Romanian VAT regulations and ensures proper fiscal position calculations.
Original PR description
The new 11% and 21% taxes introduced with the updated Romanian VAT law were added with this commit https://github.com/odoo/odoo/commit/2026212d0f7ffc217be3c6a2ff2abe5288c18afb , but some tax mappings were missing. This commit completes the setup by adding the required tax mappings, ensuring the new rates work correctly with fiscal positions. task-5480159 Forward-Port-Of: odoo/odoo#244602 Forward-Port-Of: odoo/odoo#243452
This update enhances the reliability of our IoT Box connections by directly using IP addresses instead of domain names. When LNA is enabled, the system now retrieves the IoT Box's IP address, preventing potential issues caused by DNS resolution delays. This ensures smoother data transmission and improved system performance.
Original PR description
In order to avoid DNS resolution issues, we now parse the domain to get the IP of the IoT Box if LNA is enabled.
This update adjusts the location of UBL test files within the system, streamlining the testing process for future developments. This change prepares the system for supporting varied invoice formats and enhances the ability to validate schema compliance. It’s a routine update to improve development efficiency.
Original PR description
This commit rearranges the UBL test files' subfolder to be one level higher, from `export/bis3/be` to `export/bis3/invoice/be`, in preparation for supporting different move formats and for better ignore schema support. task-4891206 Forward-Port-Of: odoo/odoo#244665
Resolved issues and error corrections
This update fixes an issue where the website's cookie consent settings weren't being saved correctly after changing the appearance of the 'I agree' button. The change in button style triggered an unintended closure of the consent modal, preventing the user's consent from being recorded. This ensures that cookie consent settings are reliably saved, improving user experience and compliance.
Original PR description
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape…
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape to "Default" (this applies the `.btn-primary` class). & Save 4. Accept the cookies & refresh -> The cookie bar appears again because the consent was not saved. Cause: ====== The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup. By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written. Solution: ========= Override the event to avoid side effects on hide. opw-5484578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243562
This update resolves an issue where the map component wasn't displaying correctly within the Odoo Studio. The fix addressed a missing size constraint, allowing the map to render. However, the map remains non-interactive, indicating a separate problem that needs attention.
Original PR description
Before this commit, the map did not render in studio. This was because the container did not have a size. After this commit, the map renders correctly, but it is still not clickable or interactable. task-5432169 Forward-Port-Of: odoo/enterprise#104743 Forward-Port-Of: odoo/enterprise#104114
This update resolves an issue where multiple delivery reports were printed on the same page. The change in the report layout prevented automatic page breaks, causing reports with multiple deliveries to be combined. This ensures that all picking operations are displayed on separate pages for easier printing and readability.
Original PR description
When printing several picking operation at once, they are all in the same page. Steps to reproduce: ------------------- * Inventory>Operations>Deliveries * Create several Deliveries * Open list view to see all the deliveries * Select several deliveries * Print > Picking Operations -> All the picking operation report are on the same page. Observation: ------------- Since the change on the picking report layout https://github.com/odoo/odoo/pull/152280/changes#diff-7542c191def78bd64f54f1c33fde2c73e19e4d27f92b195c464d1d84e55b682fL6-R8 the report now uses a single article container for all records, this don't trigger automatic page break. opw-5481034 Forward-Port-Of: odoo/odoo#243817
A bug in the demo test setup was preventing it from correctly accessing necessary user permissions. This fix ensures the test accurately simulates real user access, specifically addressing a failure when testing the 'Overdue Customer Invoices' filter. The update adds the required access groups to the demo user, resolving the test failure.
Original PR description
__Steps to reproduce:__ 1. Create a new db with `contacts` and `account_followup` installed without demo data. 2. Run `TestMenusDemo` using `--test-tags click_all:TestMenusDemo`. => It fails when testing the "Overdue Customer Invoices" filter. __Reason:__ `TestMenusDemo` inherits from `HttpCaseWithUserDemo`, which creates a fake user demo if the database does not already contain one (meaning that it has no demo data). However, when doing so, it does not include all the access groups needed by the different modules. Since this filter requires access to `account.move.line`, an `AccessError` is raised and the test fails. __Fix:__ - Inside `TransactionCaseWithUserDemo` setup, add all the access groups in which Marc Demo normally is included to better represent the real flow. - Clean up the duplicate code. runbot-231045
This update creates a dedicated test company to isolate Shop Floor tests from demo data, ensuring more reliable results. It also re-enables key test tours related to Shop Floor operations, allowing for better validation of the system. This improves the quality and consistency of our Shop Floor testing procedures.
Original PR description
This PR does 2 things: ## Create a test company Add a company dedicated to TestShopFloor's tests so those tests won't be affected by demo data anymore. ## Enable tours Until then, 10 tours related to Shop Floor were skipped after [a refactor of the Shop Floor](https://github.com/odoo/enterprise/pull/80469) design and functionality. This PR re-enables 7 of these 10 tests tour (3 remaining need more work to pass when demo data are installed.) Also it adds a test helper method, `_enable_settings`, to enable wanted setting(s) easily. [task-5365014](https://www.odoo.com/odoo/966/tasks/5365014)
This update resolves an issue where registration emails for events were displaying duplicate headers and footers. The fix removed a redundant email layout setting that was causing this duplication. This ensures a cleaner and more professional email experience for event attendees.
Original PR description
**Steps to reproduce:** - Go to Event module - Go to an open event - Register for the event - Go to the Attendees of the event - On the attendee record, click `Send by Email` - The received email shows twice the header and footer **Issue:** Encapsulating notification layout was applied with `default_email_layout_xmlid` but the main template used is `event_registration_mail_template_badge` which already has its own header and footer. **Fix:** Removed the `default_email_layout_xmlid` opw-5032767 Forward-Port-Of: odoo/odoo#236667
This update automatically adjusts the start and end dates for salary certificate reporting in Odoo's Swiss localization module (l10n_ch_hr_payroll). Previously, these dates were static, now they dynamically pull from the configured data, ensuring accurate reporting for Swiss businesses. This change simplifies the process and reduces the risk of errors.
Original PR description
make Period until and from dynamic from data Forward-Port-Of: odoo/enterprise#104903
This update fixes an issue where role mentions were lost when editing messages in Odoo. Now, role mentions are correctly preserved during the editing process, ensuring accurate communication and collaboration within the system. This improvement enhances the reliability of message editing and avoids confusion for users.
Original PR description
**Current behavior before PR:** Editing a message with a role mention would cause the mention to be lost. **Desired behavior after PR is merged:** Role mentions are now preserved when editing a message. task-4702960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects an error in VAT import bills. Previously, journal entries were incorrect due to a change in the default account used for VAT taxes. This fix updates the default account for three specific VAT taxes, ensuring accurate financial reporting.
Original PR description
Due to the change of account 33312 from liability to payable, the journal entries generated when creating bills with VAT import taxes were incorrect. This fix updates the default account on the following taxes: - tax_purchase_import_10 - tax_purchase_import_8 - tax_purchase_import_5 task-5695253 Forward-Port-Of: odoo/odoo#244434
This update resolves an issue where invoices sent to Viettel's SInvoice system were failing due to incorrect decimal formatting. The fix ensures the tax amount is calculated using the correct currency rounding method, preventing the 'INVALID_DECIMAL_POINT_TAX_MONEY' error and ensuring invoices are properly processed.
Original PR description
When sending an invoice to SInvoice (Viettel), the API raises an `INVALID_DECIMAL_POINT_TAX_MONEY` error if the tax amount contains excessive decimal places (e.g., 100.02999999999997). This occurs because the tax amount is currently calculated using simple subtraction (`total - subtotal`). Due to standard floating-point precision issues, this can result in unrounded values that the API rejects. The tax amount calculation is now updated to explicitly use the currency's rounding method, ensuring the value is accepted by SInvoice. task-[5484845](https://www.odoo.com/odoo/project/967/tasks/5484845) Forward-Port-Of: odoo/odoo#244647
This update ensures that delivery carriers are consistently applied across all stages of a multi-step delivery process, regardless of whether they're initially set on the sale order or manually configured during picking. This change addresses a previous limitation where carrier settings weren't propagated, now allowing logistics teams to manage carrier selection effectively.
Original PR description
Issue Before This Commit: ================================ Previously, the delivery carrier was only propagated between pickings when it was set from the sale order. If the carrier was manually set…
Issue Before This Commit: ================================ Previously, the delivery carrier was only propagated between pickings when it was set from the sale order. If the carrier was manually set on a picking (e.g., during the packing step in a multi-step delivery flow), it was not propagated to the consequent pickings, even when the stock rules had `Propagation of carrier` enabled. Steps to reproduce: ================================ 1. Activate Multi-Step Routes and Delivery Methods. 2. Configure a 3-step delivery route in the warehouse and enable Propagate Carrier on all rules. 3. Create a sale order with a product but without setting a delivery carrier. 4. Confirm the sale order to generate picking. 5. On the first picking (i.e., pick), manually set a delivery carrier (e.g., Local Delivery) and validate. 6. On the next transfer (i.e., pack), observe that the delivery carrier is not propagated. After this commit: ================================ The delivery carrier set on any picking is propagated to subsequent transfers when the corresponding stock rule has `Propagation of carrier` enabled and no carrier is already configured on the next picking. This ensures consistent carrier propagation across all routing configurations (all pull rules, all push rules, and mixed push/pull flows), even when the carrier is configured at the picking level rather than on the sale order. This behavior is required because, in many business scenarios, carrier selection is managed by the logistics team rather than the sales team. task-4454313 Forward-Port-Of: odoo/odoo#202700
6 changes
Resolved issues and error corrections
This update prevents excessive email notifications to managers when employees submit expenses. Previously, every state change triggered an email, leading to potential spam. Now, a weekly email is still sent to managers if they have pending expenses, streamlining the approval process and improving user experience.
Original PR description
When an employee submits an expense and assigns a manager, an approval activity is scheduled. However, email notifications are now disabled to avoid spamming the assigned managers. * Prevent notifying the expense manager when expense state changes. * Email 'Next expense is waiting your approval' is scheduled to be sent to the manager once a week if the manager has any expenses left to approve. task-4676396 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update automatically adjusts the start and end dates for salary certificate reporting in Odoo's Swiss accounting module (l10n_ch_hr_payroll). Previously, these dates were static, now they dynamically pull from the configured data, ensuring accurate and up-to-date reporting for Swiss businesses.
Original PR description
make Period until and from dynamic from data Forward-Port-Of: odoo/enterprise#104903
This update resolves an issue where registration emails for events were displaying duplicate headers and footers. The fix removed a redundant email layout setting, ensuring consistent and correct email formatting for attendees. This improves the overall user experience and email deliverability.
Original PR description
**Steps to reproduce:** - Go to Event module - Go to an open event - Register for the event - Go to the Attendees of the event - On the attendee record, click `Send by Email` - The received email shows twice the header and footer **Issue:** Encapsulating notification layout was applied with `default_email_layout_xmlid` but the main template used is `event_registration_mail_template_badge` which already has its own header and footer. **Fix:** Removed the `default_email_layout_xmlid` opw-5032767 Forward-Port-Of: odoo/odoo#236667
This update removes a previous fix for the website slides module, which was no longer needed due to recent changes. This streamlines the code and prevents duplication, ensuring a more efficient and stable user experience for customers.
Original PR description
Following the changes in PR #236475, the fix in PR #232696 is no longer required. This commit reverts commit 4c02c970ed824e2b1ade90b905365519044abc69, ensuring that the fix remains within the portal_rating module and preventing duplicate code for the same issue. This change should be forward ported up to saas-18.2. For later versions, the revert is already handled in PR #243783. Forward-Port-Of: odoo/odoo#244057
This update resolves a visual glitch on mobile websites where the header would briefly scroll off-screen when returning to the top. The fix ensures the header's styling is correctly synchronized, preventing a momentary horizontal scrollbar. This improves the user experience and ensures consistent appearance across languages.
Original PR description
There was an horizontal scrollbar that would appear for a short time after scrolling back to the top of the page. This would occur because the header would still have the "transform" property but the class "o_header_affixed" was already removed. To fix the issue, the header transform is now applied using dynamicContent, to synchronize the style and class correctly. This requires the standard header to have "transition: none" applied after it is scrolled since "translate(0, -100%)" would trigger an animation when hiding the header. task-5155878
This update resolves an issue where archived journals were still appearing as selectable payment methods when creating company expenses. The fix ensures that only active journals are displayed, preventing users from selecting inactive or archived options. This improves data accuracy and simplifies the expense creation process.
Original PR description
Steps to Reproduce: 1. Go to Accounting > Configuration > Journals 2. Archive a Journal with outgoing payment method 3. Go to Expenses > Create an Expense paid by company 4. Note that payment methods…
Steps to Reproduce:
1. Go to Accounting > Configuration > Journals
2. Archive a Journal with outgoing payment method
3. Go to Expenses > Create an Expense paid by company
4. Note that payment methods from archived journal are still visible and can be selected.
Issue:
- Archived journals with outbound payment methods were still selectable when creating company-paid expenses.
- Due to this [commit](https://github.com/odoo/odoo/commit/5c9a6704dd54bbbde1703850619ddcc1a3552547) The journals can be archived without system prevention as the action_archived method has been removed.
Solution:
- This occurred because selectable_payment_method_line_ids did not filter out inactive journals when falling back to a generic search. -Aligning the search domain with
[company_expense_allowed_payment_method_line_ids]
(https://github.com/odoo/odoo/blob/19.0/addons/hr_expense/models/res_company.py#L20) by excluding payment method lines linked to inactive journals.
Before Fix:
```py
In [1]: expense = self.env['hr.expense'].browse(1639)
In [2]: expense.selectable_payment_method_line_ids
Out[2]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [3]: archived_journal_ids = []
In [4]: payment_method_lines = self.env['account.payment.method.line'].search([
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ])
In [5]: payment_method_lines
Out[5]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [6]: for payment_method_line in payment_method_lines:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids.append(payment_method_line.journal_id.id)
...:
In [7]: archived_journal_ids
Out[7]: [7, 8]
```
After Fix:
```py
In [8]: payment_method_lines_with_fix = self.env['account.payment.method.line'].search([
...: # The journal is the source of the payment method line company
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ('journal_id.active', '=', True),
...: ])
In [9]: payment_method_lines_with_fix
Out[9]: account.payment.method.line(153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [10]: archived_journal_ids_with_fix = []
In [11]: for payment_method_line in payment_method_lines_with_fix:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids_with_fix.append(payment_method_line.journal_id.id)
In [12]: archived_journal_ids_with_fix
Out[12]: []
```
OPW-5461359
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-pr37 changes
Security fixes and vulnerability patches
This update enhances the security of our website by proactively preventing potential cross-site scripting (XSS) attacks. Previously, new cart HTML was vulnerable to tampering just before it was displayed. Now, the HTML is checked and sanitized immediately upon retrieval, ensuring a safer user experience.
Original PR description
Previously, new cart HTML was marked up at the last possible moment, right before insertion into the page. This is inherently insecure, as there is no reliable way to ensure it hasn't been tampered with. To reduce the risk of XSS attacks, the "markup-ing" of the updated HTML is now performed at the moment it is fetched from the server. This ensures that the new element is escaped back to a regular string if it is tampered with in any way before being inserted into the page. task-5082207 See also: - https://github.com/odoo/odoo/pull/234965
New functionality added to Odoo
This update centralizes address form logic, simplifying maintenance and improving consistency across Odoo. It introduces a new 'portal_address_extended' module that supports city selection when 'enforce_cities' is enabled, specifically improving address management in Chile. Localization modules have been updated to utilize this common implementation.
Original PR description
This commit introduces a new bridge module to centralize and simplify the frontend address management logic when `enforce_cities=True`. Before this commit: --- - Several localization modules were…
This commit introduces a new bridge module to centralize and simplify the frontend address management logic when `enforce_cities=True`. Before this commit: --- - Several localization modules were overriding `base_address_extended` and its `address_form_fields` template to customize the address form. - Each localization duplicated similar logic related to city selection. In this commit: --- - Add a new module `portal_address_extended` providing a generic frontend address template that supports selecting a city from the list of cities when `enforce_cities=True`. - Enable enforce_cities support in Chile with added cities data. - Adapt localization modules to rely on this common implementation. --- If `enforce_cities=False`: --- <img width="1826" height="941" alt="image" src="https://github.com/user-attachments/assets/47f667a7-cdbb-41e5-b9e2-3c62f16ce8ee" /> If `enforce_cities=True`: --- `city selection` instead of `city text` field <img width="1893" height="942" alt="image" src="https://github.com/user-attachments/assets/03f311f5-8e73-4ce6-897a-362af641f2ae" /> <img width="1821" height="942" alt="image" src="https://github.com/user-attachments/assets/695f2fc2-cde9-4a7d-9197-57edb3bf9160" /> --- Task-5098839 enterprise- odoo/enterprise#95885
This update centralizes address form logic, simplifying maintenance and ensuring consistency when city enforcement (`enforce_cities=True`) is enabled. It introduces a generic address template with a city selection field, improving the user experience and reducing duplication across localization modules. This change primarily impacts Chile and supports the new city enforcement feature.
Original PR description
This commit introduces a new bridge module to centralize and simplify the frontend address management logic when `enforce_cities=True`. Before this commit: --- - Several localization modules were…
This commit introduces a new bridge module to centralize and simplify the frontend address management logic when `enforce_cities=True`. Before this commit: --- - Several localization modules were overriding `base_address_extended` and its `address_form_fields` template to customize the address form. - Each localization duplicated similar logic related to city selection. In this commit: --- - Add a new module `portal_address_extended` providing a generic frontend address template that supports selecting a city from the list of cities when `enforce_cities=True`. - Enable enforce_cities support in Chile with added cities data. - Adapt localization modules to rely on this common implementation. --- If `enforce_cities=False`: --- <img width="1826" height="941" alt="image" src="https://github.com/user-attachments/assets/47f667a7-cdbb-41e5-b9e2-3c62f16ce8ee" /> If `enforce_cities=True`: --- `city selection` instead of `city text` field <img width="1893" height="942" alt="image" src="https://github.com/user-attachments/assets/2f182870-8e19-44a2-8801-792b0e8137a6" /> <img width="1821" height="942" alt="image" src="https://github.com/user-attachments/assets/695f2fc2-cde9-4a7d-9197-57edb3bf9160" /> --- Task-5098839 community- odoo/odoo#229243
This update introduces a new setting that lets users decide whether attachments uploaded through the web client are automatically sent to the cloud. This gives administrators more control over data storage and allows them to tailor workflows without impacting the core functionality of the web client.
Original PR description
Introduce the 'Upload Record Attachments' configuration setting to control whether the web client automatically uploads new attachments to the cloud. This allows users to keep a valid cloud storage provider configured for customized backend logic or specific workflows, while preventing the default web client behavior from uploading every UI attachment to the cloud. Upgrade: https://github.com/odoo/upgrade/pull/9288 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
Enhancements to existing features
This update enhances the flexibility of website design within Odoo by introducing a new system for modifying shape groups. Plugins can now directly adjust these groups, allowing for more dynamic and customizable website layouts. This change improves the ability to tailor website designs to specific business needs.
Original PR description
This commit defines `image_shape_groups_providers` and `background_shape_groups_providers` as new plugin resources. These resources return functions that receive the current shape groups, allowing plugins to mutate them directly or return groups to be merged into the final configuration. Forward-Port-Of: odoo/odoo#244589 Forward-Port-Of: odoo/odoo#243121
This update removes problematic native HTML `<select>` elements from the o-spreadsheet module, addressing inconsistencies in appearance and functionality across different browsers and operating systems. This change ensures a more uniform and reliable user experience within the spreadsheet application.
Original PR description
### [IMP] *spreadsheet*: stop using native HTML `<select>` The native `<select>` inputs have multiple issues: - Since their dropdown is rendered by the OS/browser, we have no control over its style and it can look wildly different to the rest of our UI. - We also cannot control its size, which can make it even uglier. - And on some browsers/OS, clicking on a <select> doesn't even trigger a click event(!?), which breaks our onClick external listeners. We decided to remove all of the native <select> inputs in o-spreadsheet. This commit adapts the enterprise tests accordingly. Task: [5213725](https://www.odoo.com/web#id=5213725&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This update enhances the testing process for Odoo's point-of-sale and self-order modules by making test utilities more realistic. The changes ensure proper initialization and validation of ticket generation, leading to more reliable test results. Additionally, a redundant model has been removed to streamline the system.
Original PR description
pos*: point_of_sale, pos_self_order Previously, ticket-generation tests relied on manual render calls, bypassing initialization logic and missing key method flows. This update refactors the test utilities to mimic real-life execution: tickets are now initialized via the main generation methods, and the final printed ticket is validated through the printer model. Additionally, Remove the extra pos.printer model from the self-order model loading Task-5391327
This update streamlines the process of uploading certifications within Odoo. The team has simplified the system by using a standard activity type for uploads, removing a redundant and complex setup. This change improves efficiency and reduces potential issues with managing certification data.
Original PR description
Simplify the activity type corpus as there is no dedicated logic requiring a specific mail activity type for uploading certifications. Task-5484984
This update enhances the UBO Form data upload process by adding a key piece of information – the ‘res_model’ – to the activity data. This improves the accuracy and completeness of the data sent during uploads, streamlining the reporting process for compliance. It’s a small change designed to improve convenience and data quality.
Original PR description
Improve convenience. Task-5484984
This update enhances how Odoo determines if a holiday falls within a specific year. The change utilizes a more reliable method for comparing dates, ensuring greater accuracy in holiday calculations and scheduling. This improves the overall reliability of the holiday management system.
Original PR description
This commit uses the Luxon method `hasSame` to compare `DateTime` years.
This update introduces a new panel within polls that displays who has voted for each option. This allows users to gain a better understanding of poll participation and trends, improving decision-making based on voting data. It enhances the poll experience by providing valuable insights.
Original PR description
Like for reactions, its interresting to be able to see who votes for which option during a poll. This PR introduces a panel in order to show it. task-5207317 <img width="500" alt="image" src="https://github.com/user-attachments/assets/8c15053b-9520-4603-8099-26521d09efdb" /> <img width="403" height="572" alt="image" src="https://github.com/user-attachments/assets/e1f0ebe3-97f9-488c-a735-825dd0ff6494" />
This update allows us to manage properties for all applicants, not just those linked to a specific job. Previously, applicants without a job were unmanageable. Now, properties are defined at the company level, streamlining recruitment processes and providing a more complete view of potential candidates.
Original PR description
Before this PR it was not possible to assign or manage properties for Talents or Applicants who were not linked to any specific Job Position. After this PR the properties are defined based on the company , allowing properties to be managed at the company level and used for applicants without job_id. Task-5212981
Resolved issues and error corrections
This update resolves an issue where scanning cashier barcodes would cause an error if employee logging was turned off. Now, the barcode scanning functionality works as expected regardless of whether employee logging is enabled, ensuring a smoother checkout experience for users. This change improves reliability and prevents disruptions during transactions.
Original PR description
Before this commit, if logging with employee was disabled, scanning a cashier barcode would raise an error. opw-5437310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241756 Forward-Port-Of: odoo/odoo#241131
This update enhances how Odoo's spreadsheet feature retrieves cell data. Previously, data was organized as an object, but now it's returned as a simple array, making it easier for the spreadsheet to process and display information. This change improves the overall performance and reliability of the spreadsheet functionality.
Original PR description
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 resolves a test case issue related to creating public leave in Odoo. Specifically, the system now correctly passes the company information during leave creation, preventing errors that could occur due to conflicting work entries. This ensures accurate public leave functionality.
Original PR description
In this PR, We are explicitly passing the company to create a public leave Task-4596057
This update resolves a crash that occurred when users accessed the Gantt Overview within the Time Off application. The fix involved adjustments to how unavailable time periods are handled, ensuring data integrity and stability during Gantt rendering. This improves the reliability of the Time Off module.
Original PR description
Version: - saas-19.2 Steps to reproduce: - Install hr_holidays_gantt - Open the Time Off application - Click on the Overview menu item Issue: - A server traceback occurs when loading the Gantt Overview. Solution: - Adapt _gantt_unavailability() to handle the new return structure of _unavailable_intervals_batch(), which now returns multiple intervals per resource. - Ensure all datetime comparisons are performed using timezone-aware UTC datetimes by converting contract dates with fields.Datetime.to_datetime(). - Properly append unavailable intervals as (start, stop) tuples to avoid data corruption during Gantt rendering. Task- 5702559
This update corrects a visual bug where an 'Add Item' button incorrectly remained visible when no topics were present in a web page snippet. The fix ensures the button disappears when there are no topics, preventing a traceback and improving the user experience. This change impacts the Topics List snippet and related website builder components.
Original PR description
Steps to reproduce: - Drag and drop a "Topics List" snippet onto a web page. - Remove all "Topic" items from the snippet so that none remain. - Click the "Add New" button. - A traceback occurs. This bug is caused by the fact that the "Add item" option is defined in the "Options" section of the parent element of the topics. As a result, the option button remains visible even when no topics exist anymore. Clicking it then triggers a traceback because the option attempts to duplicate an element that does not exist. In this commit, we fix the issue by adding an "applyTo" on the option, targeting the topics, so that the "Add New" button no longer appears when no topic is present. Note that the same bug exists for other snippets, and this commit fixes them as well. task-5462596 Forward-Port-Of: odoo/odoo#244126 Forward-Port-Of: odoo/odoo#244034
This update resolves a technical issue preventing users with the Romanian language pack installed from accessing the settings within the l10n_ro_edi_stock module. The fix corrects a mismatch in the system's text search, ensuring proper functionality for Romanian users. This improves the usability of the module for Romanian-speaking businesses.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
This update resolves an issue where government entities using a TAN instead of a PAN for their GSTIN were incorrectly flagged with an error during partner creation. The fix adjusts the validation process to recognize and support GSTINs based on TANs, ensuring accurate data entry for these important customers. This improves the system's ability to handle government-related business transactions.
Original PR description
### Issue: When using a GSTIN belonging to a government institution, saving the partner raises a ValidationError This happens because these entities often use a TAN (Tax Deduction and Collection…
### Issue: When using a GSTIN belonging to a government institution, saving the partner raises a ValidationError This happens because these entities often use a TAN (Tax Deduction and Collection Account Number) instead of a PAN as the base for their GSTIN ### Cause: In 19.0, PAN handling was refactored using the new `pan_entity` mechanism With this change, PAN values are validated through `_check_pan_name()`, which incorrectly raises a `ValidationError` for GSTINs that rely on a TAN instead of a PAN: `The entered PAN seems invalid. Please enter a valid PAN.` The PAN entity shouldn't be created for non PAN number ### Steps to reproduce: - Install `l10n_in` and `contacts`, then switch to IN Company - Create a new contact with GSTIN: `07DELN10357E1DH` - Save and the Error is raised ### Notes: At the same time, we'll set the TAN if the GSTIN is based on it The documentation for the TAN structure: https://incometaxindia.gov.in/tutorials/23.%20tan.pdf opw-5461356 Forward-Port-Of: odoo/odoo#243737
This update corrects a calculation error in the fleet module related to the initial acquisition date of vehicles. By setting a default acquisition date, the system now accurately calculates baseline ATN (Asset Tracking Net) values, leading to more precise reporting and financial tracking of fleet assets. This ensures better data for business decisions related to vehicle depreciation and asset management.
Original PR description
Forward-Port-Of: odoo/odoo#244705
This update resolves a technical issue where a default rate was incorrectly overriding the rate used in testing for FedEx deliveries in the EUR currency. By clearing these outdated rates, the test environment now accurately reflects the intended pricing, ensuring reliable testing and accurate delivery calculations.
Original PR description
Issue ----- There is some existing rate that takes precedence over the one specified in the test. Rates should be unlinked for safety. ----- Runbot error 237965 Forward-Port-Of: odoo/enterprise#104779
This update ensures the minimum wage is accurately calculated and pro-rated based on employee work time. The change addresses a previous issue (302bf2b4e201da8f56b1da012dd7f03c81a85e22) to comply with Belgian labor laws, improving payroll accuracy.
Original PR description
Since changes made in 302bf2b4e201da8f56b1da012dd7f03c81a85e22 the minimum wage should be pro-rated to the work time rate. Forward-Port-Of: odoo/enterprise#104781 Forward-Port-Of: odoo/enterprise#104419
This update resolves intermittent failures in image edit tests within the Odoo website builder. These tests were failing due to delays in how the website builder's sidebar updates asynchronously. By adding a 'wait' function to ensure the sidebar is fully loaded before tests run, we've significantly improved test reliability and stability.
Original PR description
Image edit tests using the builder sidebar were failing intermittently because image elements rely on async actions with non-deterministic timing, causing the sidebar options to be unavailable sometimes. Use `waitSidebarUpdated` to ensure the sidebar is fully updated before asserting on its content. Here is an example of an error: error-234951 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#243343 Forward-Port-Of: odoo/odoo#243008
This update prevents users from incorrectly configuring a website category snippet to display product accessories instead of categories. The change ensures that the snippet functions as intended, displaying relevant category lists on product pages. This resolves an issue where the category snippet was producing empty results.
Original PR description
Steps to reproduce: ==================== 1- Go to any product and in the tab Sales add some accessory products 2- Go to the website and edit a page 3- Add a category list block 4- Change category list filter to "Accessories for product" 5- Save -> The block is empty Cause: ====== The category snippet was meant to be used only for categories. The problem is that its possible to change from "Categories List" to anything else. When the user makes the choice to add a categories snippet he shouldn't be able to change the content of the snippet from categories to products, blogs, etc.. Solution: ========== Prevent replacing the category snippet to anything else. opw-5497284 Forward-Port-Of: odoo/odoo#244053
This update resolves a sporadic issue where live chat sessions would unexpectedly crash. The fix addresses a timing conflict between guest leaving and chat closing, preventing a system error. This ensures a more reliable and consistent live chat experience for users.
Original PR description
This commit fixes the `visitor leaving ends the livechat conversation` test that was sometimes failing. There is a race between the simulation of the guest leaving the chat that uses `withGuest` which is known to be problematic and the `action_unfollow` method, called when the chat window is closed. The unfollow method deletes the agent member, but since the guest cookie is still present, the `channels_as_member` rpc retrieves the guest member. The rest of the code doesn't expect this mismatch and a crash occurs. This commit ensures the `channels_as_member` rpc is properly done before closing the chat window. runbot-237947 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#244677
This update ensures that the live chat information and member lists automatically open by default when navigating between conversations. Previously, opening one panel would disable the other. This change improves the user experience by providing the most relevant information upfront, making it easier to manage conversations.
Original PR description
*: crm_livechat, im_livechat Before this commit, auto-open of member panel and livechat info panel did not combine from [1]. This means that when livechat info was auto-open in livechat, this…
*: crm_livechat, im_livechat Before this commit, auto-open of member panel and livechat info panel did not combine from [1]. This means that when livechat info was auto-open in livechat, this necessarily meant the auto-open of member list was disabled, and vice-versa. This is a problem because when navigating between livechat and non-livechat would necessarily imply the dismiss of either panel, which is not good because the best default is having livechat panel open by default, and for non-livechat conversations it should auto-open the member list panel. This commit fixes the issue as follow: - auto-close of panel are aware of whether action are active, as removal of auto-open from auto-close makes sense only when another panel is made active when the older panel was visible - closing of member panel by opening the livechat info panel should preserve auto-open of member list for other conversations Task-5496830 [1]: https://github.com/odoo/odoo/pull/238472 https://github.com/odoo/enterprise/pull/104435 Forward-Port-Of: odoo/odoo#244320 Forward-Port-Of: odoo/odoo#243864
This update combines member and live chat information automatically when creating helpdesk tickets, providing a more complete view of the customer's interaction. Previously, this data was displayed separately, which was confusing for support staff. This change streamlines the support process and improves customer service.
Original PR description
*: website_helpdesk_livechat, whatsapp Task-5496830 https://github.com/odoo/odoo/pull/243864 Forward-Port-Of: odoo/enterprise#104644 Forward-Port-Of: odoo/enterprise#104435
This update fixes an issue where payslip names were not being generated accurately in the Chinese HR payroll module. The change ensures that payslip names are now correctly computed, improving data accuracy and reporting for payroll processing. This impacts the accuracy of payroll reports and employee records.
Original PR description
Forward-Port-Of: odoo/enterprise#104376 Forward-Port-Of: odoo/enterprise#104289
This update fixes a potential issue where default journal types for Turkish invoice documents were incorrectly set. The default value has been changed from 'in_invoice' to 'purchase' to prevent incorrect accounting and ensure proper document handling. This ensures compliance and avoids potential errors in financial reporting.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id Forward-Port-Of: odoo/odoo#243139 Forward-Port-Of: odoo/odoo#242865
This update prevents subscription start dates or plan changes from automatically resetting manual discounts on order lines. Previously, changes triggered a recalculation that wiped out user-entered commercial discounts. Now, the system checks if the line content has changed before recalculating, preserving user-defined discounts.
Original PR description
Before this commit, changing the `start_date` or `plan_id` on a Subscription would trigger a recomputation of the `discount` field on all order lines. This triggered the standard `_compute_discount`…
Before this commit, changing the `start_date` or `plan_id` on a Subscription would trigger a recomputation of the `discount` field on all order lines. This triggered the standard `_compute_discount` method, which recalculates the price and discount based on the Pricelist, effectively wiping out any manually entered commercial discounts. This occurred because the `_compute_discount` method in `sale_subscription` depends on `order_id.start_date` to calculate pro-rated amounts for upsells. However, it was unconditionally calling `super()`, which runs the standard pricelist logic even when the line content itself (Product, Qty) had not changed. This commit introduces a check to detect if the line content has actually been modified by the user (comparing against the database origin). - If the line content (Product, Qty, UoM) is unchanged, we skip the `super()` call to preserve the manual discount. - If the line content is changed (or it is a new line), we allow `super()` to run to update the price according to the pricelist. This ensures that contextual changes (like shifting the start date) do not destroy manual data entered on the lines. Task: 5788384
This update fixes a layout issue that occurred when reordering items in the cart, ensuring a consistent and functional cart page for all users. The change improves the overall user experience by dynamically adjusting the cart layout and implementing security measures to prevent potential vulnerabilities.
Original PR description
The current cart page layout supports two states: - Empty cart: A single column spans the entire screen width to display a simple message in the center. - Non-empty cart: Two columns are displayed,…
The current cart page layout supports two states: - Empty cart: A single column spans the entire screen width to display a simple message in the center. - Non-empty cart: Two columns are displayed, where the left column shows a detailed view of each order line, and the right column shows a summary and navigation buttons. Before #226128, using the quick reorder feature on the cart page would break the page layout. The initial single-column layout would span the entire screen width, forcing the cart summary onto a new row. The fix in #226128 used a small trick in JavaScript to adjust the cart's column widths on the client side, ensuring compatibility with existing database templates. This commit reworks how the `website_sale.shorter_cart_summary` template is updated. Instead of replacing the inner content of a hook element in the layout, we now replace the hook element entirely with a new version of itself. This ensures that custom styling classes applied to the hook element are updated as well, resolving cart layout discrepancies. Additionally, to reduce the risk of XSS attacks, the "markup-ing" of the updated HTML is now performed at the moment it is fetched from the server. This ensures that the new element is escaped back to a regular string if it is tampered with in any way before being inserted into the page. task-5082207 See also: - https://github.com/odoo/enterprise/pull/104917
This update resolves a minor issue where a menu item was incorrectly linked to a different Odoo module, preventing proper translation for non-English users. The change avoids forcing the menu item into another module, ensuring correct localization within the Enterprise POS module. It's a low-impact fix that enhances the user experience for international customers.
Original PR description
When the "Preparation Display" menuitem was added, its id was set to `point_of_sale.menu_pos_preparation_display`. This forced the record to be considered part of the `point_of_sale` module and because it's part of community while this record is defined in Enterprise, it was never translatable because the link was missing in the `pos_enterprise` pot file. This issue was not fixed in stable because it is non-trivial to move records in existing DBs and it is not a blocking bug, just confusing/annoying for non-English speaking users.
This update removes the Gemini 1.5 model from the AI platform, addressing a technical issue that would have caused errors when using the AI agent. The model is now hidden from selection fields, ensuring a smoother and more reliable user experience. This change improves stability and simplifies the AI platform's functionality.
Original PR description
This PR deprecates the Gemini 1.5 models. Specifically, it gives a proper non-technical error when the model is used. The error occurs either when the user tries to set the model on an agent or if the model is already on the agent, it will raise the error upon usage of the agent. The deprecated models are also hidden from the selection field. task-5129790 Upgrade PR: https://github.com/odoo/upgrade/pull/9253
This update fixes a misleading message in the HR contract salary payroll module. The change reflects a new calculation method using part-time gross salaries instead of full-time salaries. This ensures the salary message accurately reflects the employee's compensation.
Original PR description
Since we are now setting the part-time gross and not the full time gross, this message is misleading. Forward-Port-Of: odoo/enterprise#104877
This update resolves a visual issue where document signing would intermittently flicker due to automatic zoom adjustments. The fix removes the code that dynamically changed the zoom level, defaulting to 'Automatic zoom' for a smoother and more stable signing experience. This improves user satisfaction and prevents a distracting visual glitch.
Original PR description
Before this commit, when signing a document the zoom would load with 'Automatic zoom' then less than one second later change to another zoom by the code, e.g. '100%', causing a flickering issue. After this commit, the zoom is not flickering anymore as we remove the code of changing the zoom and make the default the 'Automatic zoom'. task-5461663 Forward-Port-Of: odoo/enterprise#103532
The picking operations report was incorrectly printing all deliveries on a single page when multiple deliveries were selected. This change addresses a layout update that removed automatic page breaks, now forcing a page break to ensure reports with multiple deliveries are formatted correctly.
Original PR description
When printing several picking operation at once, they are all in the same page. Steps to reproduce: ------------------- * Inventory>Operations>Deliveries * Create several Deliveries * Open list view to see all the deliveries * Select several deliveries * Print > Picking Operations -> All the picking operation report are on the same page. Observation: ------------- Since the change on the picking report layout https://github.com/odoo/odoo/pull/152280/changes#diff-7542c191def78bd64f54f1c33fde2c73e19e4d27f92b195c464d1d84e55b682fL6-R8 the report now uses a single article container for all records, this don't trigger automatic page break. opw-5481034 Forward-Port-Of: odoo/odoo#243817
Code cleanup and technical improvements
This update adjusts how spreadsheet data is accessed within the Enterprise module. The previous method returned data as an object, which has now been updated to return an array. This change ensures consistent data handling and prepares the system for future enhancements to the spreadsheet sale management functionality.
Original PR description
`model.getters.getCells()` now returns an array instead of an object. This commit adapts the code. Task-5491227
1 change
Resolved issues and error corrections
This update prevents the API documentation endpoint from crashing when encountering models not currently defined in Odoo's code. The fix addresses a situation where outdated model definitions in the database would cause a server error. This ensures the documentation is consistently available.
Original PR description
When accessing the API documentation endpoint (`/doc`), the server could crash with an Internal Server Error if the database contained ir.model records for models that are not loaded in the current registry. Steps to reproduce: 1. Insert a record into `ir_model` with `model='ghost.model'` and `state='base'`. 2. Open `/doc`. 3. The server raises a `KeyError: 'ghost.model'`. Root Cause: The `/doc` endpoint iterates over all records in `ir.model`. For each record, it attempts to resolve the Python class using `self.env[ir_model.model]` to check access rights. If a model exists in the database with `state='base'`, Odoo expects it to be defined in the Python source code and does not generate it dynamically. If the corresponding Python class is missing (e.g., from an old module), it is never added to the registry, causing the lookup to fail with a `KeyError`. opw-5401782
9 changes
Resolved issues and error corrections
This update fixes an issue where the Gantt progress bar displayed an incorrect estimated duration for work orders after changing their assigned workcenter. The previous calculation used the old workcenter's efficiency, leading to inaccurate progress tracking. This ensures the Gantt chart accurately reflects the expected completion time.
Original PR description
**Issue** Changing the workcenter of a workorder to another with a different time efficiency does not correctly update `date_finished`, causing the Gantt progress bar to show an incorrect expected…
**Issue** Changing the workcenter of a workorder to another with a different time efficiency does not correctly update `date_finished`, causing the Gantt progress bar to show an incorrect expected duration. **Steps to reproduce** 1. Create two workcenters marked as alternatives (100% and 50% efficiency). 2. Create a BOM operation that produces 100 products with a 1h expected duration each, on the 100% workcenter. 3. Create and plan an MO using this BOM. 4. In Planning > Planning by Workcenter (Gantt), drag the workorder to the 50% efficiency workcenter. → Expected duration remains 100h instead of 200h. 5. Drag the same workorder back to the 100% workcenter. → Expected duration becomes 200h instead of 100h. **Cause** `date_finished` is recomputed in `write()` using the *previous* workcenter’s efficiency, because the duration calculation happens before the new `workcenter_id` is applied: https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_workorder.py#L471 Since the Gantt progress bar uses the interval [`[date_start, date_finished]`](https://github.com/odoo/enterprise/blob/18.0/mrp_workorder/models/mrp_workorder.py#L672C13-L674C107) to compute the expected duration (via `_web_gantt_progress_bar_workcenter_id`), the displayed duration becomes wrong. opw-5224272
This update resolves an issue where deleting a recurring calendar event caused the application to reset filters and lose context-specific settings, disrupting subsequent record creation. The fix prevents a full page reload, ensuring filters and relevant fields are preserved after event deletion.
Original PR description
Deleting a recurring calendar event triggers a full page reload, which resets the view to default, clearing active filters and causing context-dependent fields (like "Resources") to disappear during subsequent record creation. ### Steps to reproduce 1. Filter the Calendar view (e.g., "Everybody"). 2. Delete a recurring event. 3. Observe the page reload and filter reset. 4. Try to create a new record; context-specific fields are missing. The issue occurs because the deletion action forces a browser refresh (location.reload()), wiping the web client's in-memory state. This state holds the active filters and context keys necessary for rendering specific fields. When cleared, the application reverts to its default configuration. opw-5433604
This update fixes an issue where manufacturing order end dates were incorrectly calculated, assuming work centers operated 24/7. The change now accurately considers work center availability, ensuring more precise scheduling and reducing potential scheduling errors. This improves the accuracy of production timelines.
Original PR description
**Issue** The scheduled end date of a manufacturing order incorrectly assumes that the work center operates 24 hours a day. **Steps to reproduce** 1. Create a manufacturing order with: - A work order…
**Issue** The scheduled end date of a manufacturing order incorrectly assumes that the work center operates 24 hours a day. **Steps to reproduce** 1. Create a manufacturing order with: - A work order with an expected duration of 1440 minutes. - A work center configured to work 8 hours per day. 2. Observe that the scheduled end date is computed as if the work center operates 24h/day resulting in an end date 1 day instead of 4 after the starting date. **Cause** The `date_finish` computation: https://github.com/odoo/odoo/blob/680085b55728dcb000e7bb4277bb83b0e4e2ce91/addons/mrp/models/mrp_production.py#L745C1-L746C105 does not take into account neither the work center’s calendar nor the workorder dependency when estimating the duration. **Solution** Use `_get_first_available_slot`: https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workcenter.py#L332 to consider workcenter availability, inspired from when a workorder is planned: https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workorder.py#L527 **Additionnal notes** - If a workcenter of at least one workorder is unavailable, just fallback on the previous computation. - The solution does not take workorder dependencies into account due to related technical limitation see https://github.com/odoo/odoo/pull/232805 for an earlier attempt to handle dependencies. - Our test rely on the assertAlmostEqual for the same reason than https://github.com/odoo/odoo/commit/e6c958ca226bd8ef7e518243c93e40b92b9b5919 opw-[5084120](https://www.odoo.com/web#id=5084120&view_type=form&model=project.task)
This update fixes a potential crash in the Italian EDI invoicing process when invoices are created with zero amounts in a foreign currency (like USD). The fix prevents a division-by-zero error during currency conversion, ensuring invoices can be generated correctly. This improves stability and avoids disruptions for users.
Original PR description
**Steps to reproduce:** 1. Install the `l10n_it_edi` and switch to IT company 2. Go to Accounting → Invoice. 3. Create an invoice add partner and change the currency to USD 4. Add a product and apply tax and discount of 100% and confirm 3. Click on Send **Issue:** A ZeroDivisionError is raised during the Italian EDI XML generation. `ZeroDivisionError: float division by zero` **Cause:** The conversion rate is computed by dividing `amount_total` by `amount_total_signed` without handling the case where `amount_total_signed` is `0.0`. **Solution:** Skip the conversion rate computation when the signed total amount is zero, preventing the division by zero **opw-5481821**
This update fixes a potential issue where Microsoft calendar synchronization could fail due to a short timeout when communicating with Microsoft's services. Now, administrators can adjust a system setting to increase the timeout, allowing for more reliable synchronization, especially in environments with slower connections or large calendars. This prevents duplicate events from being created.
Original PR description
**Description of the issue/feature this PR addresses:** Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls…
**Description of the issue/feature this PR addresses:** Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls triggered after commit use a fixed 3-second timeout. This can lead to repeated synchronization failures even though the operation would succeed with slightly more time. Additionally, when creating events, the Microsoft Graph request may time out after the event is successfully created on Microsoft’s side but before the response containing the event ID is returned. In this case, Odoo does not store the ID of the event and may create the same event again during the next sync, resulting in duplicate events. **Current behavior before PR:** Microsoft Graph requests (insert, update, delete) are executed with a hardcoded 3-second timeout. If the Graph API response takes longer: • the synchronization fails, • and in the case of event creation, Odoo may not receive the Microsoft event ID even though the event was created remotely, which can lead to duplicate events in Odoo. **Desired behavior after PR is merged:** The Microsoft Graph request timeout is configurable via the optional system parameter `microsoft_calendar.graph_timeout`. If the parameter is not set, the behavior remains unchanged (default 3 seconds). Administrators can increase the timeout to allow successful synchronization in slower environments or with large datasets, reducing synchronization failures and avoiding duplicate event creation caused by missing Microsoft IDs. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241921
This update resolves a potential issue with Microsoft calendar synchronization in slower environments. Previously, a fixed 3-second timeout for Graph requests caused failures. Now, the timeout is configurable, increasing the reliability of calendar syncing and ensuring smoother operation.
Original PR description
Microsoft calendar sync can fail in slower environments due to a fixed 3s timeout for Graph requests triggered after commit. See community changes for details.
This update prevents the use of Amazon Payment Services in Odoo's self-order point-of-sale system. The issue stemmed from Amazon's requirement for customer identification, which isn't reliably available in self-order scenarios. This change ensures compatibility and prevents errors during payment processing.
Original PR description
Currently, it's impossible to use Amazon Payment Services as a online payment provider in the self order. We face a "Signature mismatch" error. Steps to reproduce: ------------------- * Set up the…
Currently, it's impossible to use Amazon Payment Services as a online payment provider in the self order. We face a "Signature mismatch" error. Steps to reproduce: ------------------- * Set up the payment porvider Amazon Payment Services * Create an online pos payment method using Amazon as provider * Set this payment method as the online method for a self * Place an order in the self * Try to pay it > Observation: When the page is redirected to provider's checkout page an error occurs, "Signature mismatch" Why the fix: ------------ Amazon Payment Services (APS) requires a customer to be identified in order to send its email into the request's signature. It is working fine on the website since during the checkout it will ask for the customer information and create a partner related. In the point of sale we cannot guarentee to have a customer registered on the order. Even worse for the self and kiosk, no customer will be registered. Since this provider is not compatible we do not allow it to be used with pos online payment methods. opw-5053492
A recent test was failing intermittently due to an issue with the way redirect URLs were being handled. This update corrects the test to account for both absolute and relative URLs, ensuring consistent test results. This resolves a technical problem that could have impacted the stability of the Odoo Enterprise system.
Original PR description
Bug === On some runs, the redirect URL is absolute and not relative, (eg: `http://127.0.0.1:8069/web/signup?db=...`) and so the test needs to be adapted. Task-5857520
This update resolves an error that occurred when generating PDF reports for accounting, specifically when a contact didn't have a name assigned. The fix ensures that the report exports correctly regardless of whether a contact has a name or not, improving the reliability of the reporting process.
Original PR description
Currently, an error occurs when exporting an accounting report to PDF if any of the selected contacts do not have a name. **Steps to reproduce:** - Install the `account_reports` and `contacts`…
Currently, an error occurs when exporting an accounting report to PDF if any of the selected contacts do not have a name. **Steps to reproduce:** - Install the `account_reports` and `contacts` modules. - Go to Contacts and open any contact (e.g., Azure Interior). - Click `Add` > `Save & Close`, then `save` the contact. - Navigate to Accounting > Reporting > Aged Receivable. - Click `Partners` button and select the newly created contact (e.g., `Azure Interior, Other Address`). - Click `PDF` to export the report. **Error:** `TypeError: sequence item 0: expected str instance, bool found` **Root Cause:** At [1], `options['selected_partner_ids']` is built using `partner.name`, which may be `False` for unnamed contacts. At [2], the `partner_value` list may therefore contain `False` entries coming from `options['selected_partner_ids']`. When calling `', '.join(partner_value)`, an error is raised because the list contains `non-string` (`bool`) values. **Fix:** This commit prevents errors when exporting reports to PDF and ensures that partner names are displayed in the report the same way as in the partner selection widget. [1]: https://github.com/odoo/enterprise/blob/a0ec2fcdc043cf52f1a646e84b9b97466072d47f/account_reports/models/account_report.py#L745 [2]: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/account_reports/data/pdf_export_templates.xml#L84-L93 opw-5467321 Forward-Port-Of: odoo/enterprise#103828
3 changes
Resolved issues and error corrections
This update corrects a fiscal inconsistency in the MX e-invoicing process. The default payment method 'Por Definir' was causing issues with invoices using the PUE payment policy. The fix removes this default, ensuring accurate fiscal reporting and a clearer user experience.
Original PR description
### Issue: The payment method `99 – Por Definir` was used as the default value for invoices, sale orders, and POS orders This leads to fiscal inconsistencies, especially when invoices use the `PUE` payment policy, where this payment method is invalid ### Cause: In the `_compute_l10n_mx_edi_payment_method_id` methods, the default value was always set to `Por Definir` ### Fix: After discussion with the PO (MIAL), the chosen solution is to archive the payment method `99 – Por Definir`and remove it as a default value All valid cases should already be handled explicitly, making it clear to the user that something is missing when the data is blank ### Steps to reproduce: - Install `l10n_mx_edi` and switch to the MX company - Create an invoice with today’s invoice date - The payment policy is set to PUE - Before the fix, the payment method is set to `Por Definir` For Sale Order and POS Order tests, it's the default value as soon as you create an order opw-5406038
This update fixes a bug that caused Odoo server crashes when module descriptions contained invalid formatting (like Markdown). The fix allows for raw text rendering of module descriptions, resolving the issue and improving stability during module installation and updates. This ensures smoother operation for all Odoo modules.
Original PR description
Modules containing valid Markdown in their description or README.md could cause Odoo to crash during startup or module updates if the content confused the reStructuredText (RST) parser. ### Steps to…
Modules containing valid Markdown in their description or README.md could cause Odoo to crash during startup or module updates if the content confused the reStructuredText (RST) parser.
### Steps to reproduce
1. Create a module with a manifest like this:
```py
{
'name': 'base',
'description': """
....
""",
}
```
2. Start the Odoo server or attempt to install or update update the module.
3. The server crashes:
```
docutils.utils.SystemMessage: (SEVERE/4) Unexpected section title or transition.
```
### Cause
The crash occurs during the execution of the `_get_desc` method in the `ir.module.module` model, which computes the `description_html` field.
When Odoo processes a module, it checks for a pre-rendered HTML description at `static/description/index.html`. If this file is missing, the `_get_desc` method attempts to generate HTML from the module's `description` field (often populated from the `README.md` file) by calling the `docutils.core.publish_string` function.
The **docutils** library is designed specifically for **reStructuredText (RST)**. If the input text contains structural patterns that violate RST rules—such as inconsistent header levels or "transitions" in invalid contexts—docutils flags a severe error and raises a `docutils.utils.SystemMessage` exception.
### Fix
This commit handles these exceptions and falls back to a raw text rendering. It also improves the logic by removing the restriction that prevented non-application modules from rendering their description via RST.
opw-5424131This update enhances the security and reliability of our Peppol integration by implementing a safer server-initiated deregistration process. Previously, a critical issue led to disruptions, and this change addresses that by allowing the server to gracefully handle participant departures while providing a mechanism for users to re-register. This improves the overall stability and resilience of the Peppol connection.
Original PR description
Reintroduce server-initiated deregistration on `client_gone`, but only for implementations that explicitly handle it. The base proxy client now just raises the error. Peppol opts in by soft-resetting its configuration so users can re-register. See the IAP postmortem for the rationale and incident history. https://github.com/odoo/iap-apps/pull/1317 no-task Forward-Port-Of: odoo/odoo#239254