Daily updates from Odoo
Thursday, December 11, 2025
123 changes
31 changes
Enhancements to existing features
This update ensures that newly imported customer and supplier records are correctly identified as ‘companies’ within Odoo. This improves data accuracy and streamlines processes related to invoicing and reporting. The change was made to align with best practices for account management.
Original PR description
Ensure imported partner records are marked as companies when creating new partners. Task-5353923 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239116 Forward-Port-Of: odoo/odoo#238793
This update enhances the refresh cycle for return data in the accounting reports. Previously, the refresh period was inconsistent, leading to unpredictable data updates. Now, the system refreshes data over a consistent one-year past and future window, ensuring reliable and predictable reporting.
Original PR description
Previously, the minimum date used for the refresh period in `_try_create_returns_for_fiscal_year` was the fiscal year itself, which caused confusion. Depending on whether we were at the beginning or the end of the fiscal year, the amount of past data being updated was inconsistent. The new behavior refreshes a fixed window of one year in the past and one year in the future, making the update range predictable and consistent. task-5388423
Resolved issues and error corrections
This update fixes an issue where the LWF report incorrectly included data from previous departments when a new department was selected. The fix clears existing report data before generating a new report with the chosen department, ensuring accurate reporting of labour welfare fund contributions. This improves the reliability of the LWF report for users.
Original PR description
Step to reproduce: - Install l10n_in_hr_payroll. - Create 3-4 employee with labour welfare fund, all in different departments. - Open the LWF report wizard and do not select any department. -…
Step to reproduce: - Install l10n_in_hr_payroll. - Create 3-4 employee with labour welfare fund, all in different departments. - Open the LWF report wizard and do not select any department. - Download report , all employee will come in report. - Now select any department and download report again. - All employee(It is fetching previous data) + employee from selected department will come in report. Cause: - In '_compute_line_ids()' wizard computed field 'line_ids' doesn't properly reset previous lines as a result previous data remains in lines. - When the department is changed, the wizard id remain same, so previously lines added to wizard are coming with new lines. - Using `Command.link()` for new lines is invalid because it requires an existing database record ID, but wizard lines are creating inside a compute method so their IDs are only saved after the flush. Fix: - Since this is a stable version, clear the previously existing lines using 'Command.clear()' before creating new ones. Task - 5366498 Forward-Port-Of: odoo/enterprise#101190
This update resolves an issue where outdated records in the system's data management (ir.model.data) persisted after a model was removed. These lingering records could cause errors and instability. The fix ensures that these records are properly cleaned up, improving system reliability and preventing potential problems.
Original PR description
When a model is unlinked, the `ir.model.data` related to that model wasn't cleaned up. This leaves dangling records that can generate issues. sentry-6938852090 Forward-Port-Of: odoo/odoo#236615
This update resolves an issue where the demo stock data installation incorrectly used US currency, causing problems when users have databases with different currencies (like EUR). The fix ensures the demo data installation works correctly regardless of the company's currency, improving data consistency and usability.
Original PR description
Currently in the `_merge_move_itemgetter` the system call `self.company_id.currency_id.decimal_places`. However the demo data of stock create a database with US currency and some `stock.move` in it. If we have an existing database with EUR for example. The upper call will return a `currency_id.decimal_places` since we have multiple currency. The best solution, would be to split `_action_confirm` to do a loop by company. But it would need a small refactoring and we will do a minimal diff to fix this issue. Using the smallest currency among all the company is not always correct but it's a super edge case and we should probably remove this code since it went to far. Close #230965, #234078 Forward-Port-Of: odoo/odoo#239273
This update resolves an issue where a test for the website color picker was failing due to timing problems. The fix ensures the test waits for all steps in the color selection process, preventing inconsistent and unreliable test results. This improves the stability of the website customization feature.
Original PR description
__Behavior before commit:__ Since `edit` writes one character after the other, using it on a color picker to write an RGBA color calls `make_scss_customization` when the input value reaches the RGB color. Then, another call is made when the entire color is written (because they are both valid colors). However usually the test finished before the steps for the second call were reached because the `Deferred` was only waiting for the first call. __Fix:__ Wait for all steps to avoid nondeterministic behavior. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/234621
A recent change in the Employee Skills pie chart report caused an error when users clicked on individual data points. This fix prevents the error by addressing a removal of a previous list view functionality. Users can now reliably access the chart data.
Original PR description
Clicking a record in the Employee Skills pie chart report currently triggers a traceback. Steps to reproduce the error: - Install ``hr_skills`` module with demo data - Open any employee > In Resume…
Clicking a record in the Employee Skills pie chart report currently triggers a traceback. Steps to reproduce the error: - Install ``hr_skills`` module with demo data - Open any employee > In Resume tab, Click on TIMELINE - Switch to Pie chart > click on any record Traceback: ```py UndefinedColumn: column hr_employee_skill_history_report.id does not exist LINE 1: SELECT "hr_employee_skill_history_report"."id" FROM "hr_empl... ``` ``hr.employee.skill.history.report`` model is ``_auto=False``, meaning that no database table is created for this model. In earlier versions, clicking on the record opens the list view. In the [commit](https://github.com/odoo/odoo/commit/341fe890d2b7001dab1e3cd65ecb0c3bb4ed327e), list view was removed. So, now clicking on the record will lead to the above traceback. [1]: https://github.com/odoo/odoo/commit/341fe890d2b7001dab1e3cd65ecb0c3bb4ed327e sentry-7099766240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue where website snippets were displaying incorrectly, often leaving them blank. The fix focuses on limiting the snippet's visibility to product pages, ensuring it functions as intended without impacting other website areas. This improves the overall user experience on product listings.
Original PR description
This PR fixes an issue introduced in Commit[^1] while trying to fix an issue with the alternative products section being displayed even with no alternative products. In Commit[^1], the rule was set in the snippet file, which worked but was affecting all the places where this snippet is displayed, which made the snippet preview empty. To ensure this does not happen, we scope the rule to the product page only, ensuring the snippet remains untouched. [^1]: https://github.com/odoo/odoo/commit/0dfc5a6cfbae808f2dc5c7042bc07180eaa49e9a task-5404601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that a key stock test consistently produces the same results. Previously, slight timing differences in test execution could cause the test to fail intermittently. To guarantee reliable test results, the test now freezes time to eliminate these timing variations.
Original PR description
In a previous fix in #174442, we ensured that the order of moves when freeing reservation would remain deterministic, even if move dates were the same. In the test however, we didn't make sure that both moves were created at the exact same time, meaning that in some case, a millisecond could pass between the two moves creation, making the later assert checking if both dates are the same wrong, and making the test irrelevant. Now freeze the time at an irrelevant date just to make sure the test always does what it was intended to do. runbot-233470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239229
This update fixes an issue where subscription details weren't being displayed correctly within the dashboard. Specifically, it corrected a filtering problem and ensured subscription titles were accurately shown. This improves the clarity and usability of the subscription section for users.
Original PR description
Before this commit, when subscriptions were linked to the analytic account of a project, the sale order items appears in an unwanted section when the section is unfolded. Meanwhile, when the subscription section is unfolded the title of the subscriptions items are not correctly displayed. The first issue is due to the fact that we did not correctly exclude the subscriptions items from the domain. The second issue is due to the fact that we fetch the field 'name' from the subscription search instead of the field 'display_name' task-5159781 Forward-Port-Of: odoo/enterprise#97238
This update corrects a technical issue that was preventing the generation of WPS files in the Saudi HR payroll module. The fix addresses an error caused by incorrect function usage, ensuring reports are now created reliably. This resolves a potential disruption to payroll reporting.
Original PR description
this commit addresses traceback errors occured due to incorrect usage of `_` function. task-5310946 Forward-Port-Of: odoo/enterprise#99789
This update resolves a problem in the tests for the 'pos_settle_due' module that was failing due to a hardcoded year. The fix ensures the tests work correctly regardless of the current year, improving the reliability of the testing process. This prevents potential disruptions during development and ensures accurate test results.
Original PR description
When running the pos_settle_due tests with faketime, the tour pos_settle_account_due was failing cause of a hardcoded year which would not work on another year. This is now fixed. runbot-error: 234052 Forward-Port-Of: odoo/enterprise#101217
This update fixes a technical issue where users could inadvertently modify parser rules after the parser was initially set up. This change ensures data integrity by preventing unauthorized modifications to the parser, improving the stability and reliability of Odoo's data processing.
Original PR description
The parser rules cannot be modified once the parser has been instantiated. task-5091744 Forward-Port-Of: odoo/odoo#239046
This update resolves a problem where invoices generated in Arabic were sometimes printed incorrectly, with missing logos or repeated headers. The fix reduces the number of invoices processed at once, allowing the printing software to render them correctly. This ensures all invoices are printed accurately.
Original PR description
Repro steps: 1. Create a customer whose language is Arabic 2. Create 16 or more invoices for that customer 3. Send these invoices together all at once Issue: PDFs generated for the invoices are strange, some have missing logo in the header, while others have the header repeated multiple times on the page. Root cause: wkhtmltopdf does not have enough time to render all these PDFs at once, so it fails to render them properly leading to these half-rendered PDFs. Solution: This commit solves this issue by reducing the number of invoices that the cron processes at once from 20 to only 10 (the default of the function _cron_account_move_send). This would ensure that wkhtmltopdf has enough time to process and render a batch of invoices at once. opw-4997495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236810
This update fixes an issue where GIF image sizes were incorrectly displayed in the Odoo builder. A previous workaround was removed, and the system now accurately shows the size of GIF images, aligning with other image types. This ensures consistent and accurate image representation within the builder.
Original PR description
`*` = html_builder, html_editor A previous workaround [[1]](https://github.com/odoo/odoo/commit/520dde6f20742229de32c7bf781ab4208284ee79) hid GIF file sizes in the builder because `_processImage` used to return incorrect data for GIFs, causing their size to appear as "NaN kb". The underlying `_processImage` issue was fixed in [[2]](https://github.com/odoo/odoo/commit/27be6d81497b49939d039361dc602d4575e23502), but the workaround from [[1]](https://github.com/odoo/odoo/commit/520dde6f20742229de32c7bf781ab4208284ee79) was never reverted. This commit removes that leftover logic and restores correct size display for GIF images, bringing them back in line with other image types. task-[5071548](https://www.odoo.com/odoo/project.task/5071548) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures compatibility with new IoT Boxes by adding a necessary request parameter. The customer display data service was recently simplified, but this change restores functionality to support the v19.1 IoT Boxes and their response formats. This ensures a smooth experience for users utilizing these devices.
Original PR description
In `saas-18.4` and `19.0` the customer display data service was simplified as we refactored to control IoT displays with actions instead of controllers.
However, to ensure compatibility with v19.1 IoT Boxes, we need to add a request parameter back and to accept both responses: `result: { data: { ... } }` and `result: { ... }`.This update resolves an issue where document previews were not updating correctly after renaming documents. The fix ensures that the preview always displays the most recent document name, regardless of how the document was renamed (e.g., via the 'Rename' action or the chatter interface).
Original PR description
BUG 1: --------- **steps to reproduce**: 1. Install documents 2. Open any document 3. Go to Action > Rename 4. Rename the document 5. Preview it and read the name showed there **issue**: When…
BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there
**issue**:
When previewing the document, it still shows the old attachment name.
**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:
1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130
2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383
**solution**:
Use the document name when previewing it
BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.
**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.
**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.
Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.
**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.
**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
<summary>Click here to see the results:</summary>
Before:
<img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
After:
<img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>
</details>
opw-5065433
Forward-Port-Of: odoo/enterprise#101183
Forward-Port-Of: odoo/enterprise#95111This update resolves a technical issue that caused a traceback when reloading the WorkEntries page in Odoo Studio. The fix ensures Studio correctly loads the page after a reload, improving stability and preventing disruptions for users. This change focuses on internal technical improvements.
Original PR description
**Verison:** - saas-18.2 **Steps to reproduce:** - Go to an employee form view. - Click on the WorkEntries smart button. - Open Studio. - Reload page. **Issue:** - A traceback appears after reloading the page in Studio. **Cause:** - The smart button URL uses the model name hr.work.entry, but Studio’s service_action expects a path without dots. Because the action cannot be loaded correctly, the view breaks and triggers the traceback. **Solution:** - Return the proper path instead of the model name so that the action loads correctly. This prevents the error when reloading the page. task-5236317 Forward-Port-Of: odoo/odoo#239335 Forward-Port-Of: odoo/odoo#235662
This update resolves an issue where removing a video URL in the HTML editor would leave a broken iframe in the system, leading to errors. The fix ensures that when a video URL is deleted, the associated options are properly cleared, preventing the creation of invalid media entries and improving the user experience. This prevents 404 errors and ensures data integrity.
Original PR description
*=website **Steps to reproduce:** 1. Drop a video 2. Reopen the media dialog 3. Remove the URL 4. Confirm **Issue:** When the URL was removed and confirmed, an iframe without a valid source was saved, leading to a 404 error. **Fix:** When the video URL is cleared, VideoSelector component calls selectMedia with an empty object. MediaDialog did not previously handle this case, so the media selection was not cleared. Now we Update MediaDialog to treat an empty object as a clear-selection signal and disable the Add button accordingly. task-5190485 Forward-Port-Of: odoo/odoo#238884 Forward-Port-Of: odoo/odoo#234085
This update resolves an issue where tests relying on internal URLs (like 'blob:') required a mock 'fetch' to work correctly. The change ensures these URLs function seamlessly without the need for mocking, enhancing test reliability and streamlining the testing process. This improves the consistency and accuracy of our automated tests.
Original PR description
Before this commit, internal URLs (i.e. "blob:" and "data:") required 'fetch' to be mocked to work. This is wierd because these requests are handled directly by the browser and shouldn't require any…
Before this commit, internal URLs (i.e. "blob:" and "data:") required
'fetch' to be mocked to work. This is wierd because these requests are
handled directly by the browser and shouldn't require any particular
manipulation from the (mocked) server.
This commit ensures that internal URLs still work without fetch being
mocked.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239237
Forward-Port-Of: odoo/odoo#239011This update resolves a technical issue that was causing test failures. The change prevents the use of internal testing tools outside of test environments, ensuring the stability and reliability of our core system. This improves the overall quality and performance of the Odoo Enterprise platform.
Original PR description
This commit adapts tests failing due to a recent fix preventing the use of 'mock...' helpers outside of tests. - Community: https://github.com/odoo/odoo/pull/239237 Forward-Port-Of: odoo/enterprise#101780
This update resolves an issue where a previously revoked portal user could inadvertently become the default public user for a new website. This prevented potential confidentiality risks and ensures that website public user assignments are correctly managed. The fix maintains the ability to reactivate revoked users.
Original PR description
**Steps to reproduce:** - Go to a Contact - Go to the actions dropdown menu of the record - Grant Portal Access - Revoke that Access - Create a new Website in the same Company that Portal Access was…
**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions
**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)
if public_users_for_company:
return public_users_for_company[0]
```
This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).
**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).
For now the fix remove the public group on the revoked portal user, to still be able to reactivate it later on, without mistaking it for the default public user of a company.
Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.
related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b
opw-4760550
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#236014
Forward-Port-Of: odoo/odoo#233757This update prevents a frontend error from appearing when employees with limited access attempt to view the history of their employee records. The fix ensures that access controls within the payroll module are correctly applied to the employee record search view, improving usability for all users.
Original PR description
Steps to reproduce: - Log in as a user with only Employee Administrator rights (no payroll access). - Open the Employees app and create a new employee. - Click the History smart button. - A traceback is raised. Cause: The payroll module restricts contract_date_start and contract_date_end to hr_payroll.group_hr_payroll_user, but the search view still referenced these fields. Since the view was not updated accordingly, non-payroll users triggered a frontend parsing error. Fix: Override the search view to update the filters and match the model's access restrictions. task-5401143
This update resolves an issue where SN labels weren't generated when creating multiple units within a manufacturing order. The fix ensures that SN labels are consistently printed regardless of the quantity produced, improving accuracy in tracking and inventory management. This resolves a reported problem impacting order fulfillment.
Original PR description
This commit fixes the issue of not printing Lot/SN labels when generating them on the MO that has more than 1 unit on the quantity to produce. To reproduce the bug: 1- Go to Operation Types → Manufacturing → Hardware → activate the print `Lot/SN Label` (Print When "Create New Lot/SN") 2- Create an MO with quantity of 5 for a tracked product. 3- Click on `Produce All` and use the wizard to generate SNs and produce or confirm the MO. = SNs should be printed but they are not. opw-5347787 Forward-Port-Of: odoo/odoo#238739
This update resolves a technical issue that caused the Gantt chart to crash when event start or end dates were cleared. The fix ensures the Gantt calculation only runs with valid date ranges, preventing errors and improving stability for event tracking.
Original PR description
When removing the start or end date on an Event, the system raises a traceback during Gantt information computation. **Steps to Reproduce:** 1. Install `website_event_track_gantt` module. 2. Create a new Event. 3. Add at least one **Track** with a track **Date** and **Duration**. 4. In the Event form, clear the Start or End Date field. **Error:** `TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'` **Cause:** When the event start or end date is removed, those fields become False. During computation, the system attempts to compare these False values with the track dates (which are real datetimes), resulting in an invalid datetime-boolean comparison, causing the error. **Fix:** This commit ensures the Gantt calculation only executes when the event has a valid date range, avoiding comparisons that include missing values. no id Forward-Port-Of: odoo/enterprise#101541
This update fixes a potential issue in the Chilean VAT (l10n_cl_edi) module where incorrect sequence numbers could be generated for VAT documents. Previously, if a specific journal setting wasn't configured, the system might have produced sequences starting with 'False'. This change ensures accurate and reliable sequence generation, preventing potential reporting errors.
Original PR description
Before this commit, if the journal is not set to using the document (l10n_latam_use_documents), the method _get_last_sequence could return a sequence that starts with False. opw-5404813 Forward-Port-Of: odoo/enterprise#101824
This update addresses a technical issue that could cause website errors when users configured event tickets with unusual rental settings. The fix prevents these errors from displaying to the user, improving the overall website experience and stability. While the rentable ticket feature itself is being addressed, this change focuses on robust error handling.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have `website_event_sale` but not `stock` installed; 2. create an event with a ticket; 3. make the ticket's product rentable; 4. change ticket's product type to Goods; 5. publish the event to website; 6. register for the event via website; 7. go to payment. Issue ----- AttributeError: 'bool' object has no attribute 'tzinfo' Cause ----- Having odd configurations like rentable tickets creates rental orders without rental dates, leading to unhandled errors. Solution -------- While rentable event tickets doesn't make enough sense to make it work, we can still improve the error handling to prevent showing tracebacks to the client. opw-5207045 Forward-Port-Of: odoo/enterprise#101640 Forward-Port-Of: odoo/enterprise#99000
This update fixes an issue where multiple quality checks were being created for the same receiving activity, leading to potential inefficiencies. The change adds a validation step to ensure only one quality check is generated per operation, streamlining the receiving process and reducing manual effort. This improves data accuracy and reduces the risk of errors.
Original PR description
Steps to reproduce: -------------------------- 1. Install the Quality module. 2. Create a Quality Control Point with: * Control per: Control on Operation. * Operation: Receipts (set in the Operations…
Steps to reproduce: -------------------------- 1. Install the Quality module. 2. Create a Quality Control Point with: * Control per: Control on Operation. * Operation: Receipts (set in the Operations field). 3. Create a Receipt containing one product. 4. Click the Mark as To Do button. 5. Add another product to the same Receipt and save it. Observation: -------------------------- Two quality checks are generated for the same picking, despite the tooltip indicating that only one check should be created per operation. Issue: -------------------------- No validation existed to verify whether an operation-based quality check had already been created for the picking when adding additional stock moves after confirmation. Solution: -------------------------- Add a check ensuring that if a quality check already exists for the same picking type and operation (with no product or category criteria), no additional operation-based quality checks are created. opw-5249233 Forward-Port-Of: odoo/enterprise#100118
This update prevents resetting an invoice to draft from recomputing and overwriting the previously set delivery date. This ensures users retain control over delivery dates when editing invoices, improving accuracy and workflow efficiency. The change corrects a bug related to how the invoice draft button interacts with delivery date calculations.
Original PR description
**PROBLEM** Resetting to draft an invoice can sometimes recompute the delivery date, overwritting any value the user may have enter. **STEP TO REPRODUCE** 1. Enable anglo-saxon accounting 2. have a product category with automated AVCO 3. assign category to a deliverable product 4. set product to invoice on delivery 5. add product to a sales order 6. confirm order & delivery 7. create invoice 8. change the delivery on the invoice 9. confirm the invoice. 10. reset the invoice to draft. **CAUSE** button_draft() unlinks some account.move.lines, triggering the compute on delivery_date. see for more info : https://github.com/odoo/odoo/pull/231186 opw-5347939 Forward-Port-Of: odoo/odoo#237612
This update fixes an issue where newly created employees were incorrectly marked as unavailable in the Planning Gantt view. The fix addresses a problem with how the system identified employee contracts and calculated working periods, ensuring accurate scheduling for all employees, including those without established contracts.
Original PR description
Steps to reproduce: - 1. Install Planning module. 2. Create a new employee without setting a contract start date. 3. Go to the Planning Gantt view by resource. Issue: - The Planning Gantt view…
Steps to reproduce:
-
1. Install Planning module.
2. Create a new employee without setting a contract start date.
3. Go to the Planning Gantt view by resource.
Issue:
-
The Planning Gantt view incorrectly grays out the entire schedule for newly created employees. It can also incorrectly gray out the initial days of a contract.
Cause:
-
1) With the introduction of `hr.version`, a version is now created for every employee by default. The logic to identify employees with a contract history was using a domain `[("employee_id", "in", ...)]`, which selects all employees, even those with no contract. This incorrectly flagged new employees as having a contract history, causing them to be marked as unavailable.
2) The view was using the computed `version.date_start` field. The computed `date_start` is calculated as the maximum of the version's creation date and the contract's start date. (e.g., contract starts Sep 1st, version created Sep 5th), the computed start date becomes Sep 5th, incorrectly graying out the period from Sep 1st to Sep 4th.
Fix:
-
1) The query that checks for an employee's contract history is now filtered by `('contract_date_start', '!=', False)`.
2) The Gantt view's working period calculation now uses the stored, `contract_date_start` and `contract_date_end` fields.
task-5058866This update resolves a bug where imported invoices were incorrectly displayed in filtered invoice views, even when already reconciled. The fix ensures that filters accurately exclude all unpaid and overdue entries, providing a cleaner and more reliable view of outstanding invoices. This improves data accuracy and reporting.
Original PR description
Error steps: - Create or import "miscellaneous" entries in a sales journal (through the FEC import e.g.) - Have at least one late or unpaid invoice in the same journal. - The journal dashboard view should display a "X Unpaid" or "X Late" suggestion -> click on it => The filtered view shows the correct unpaid or overdue invoices/bills AS WELL as the imported entries, even if the latter are fully reconciled already. Now the filters correctly filter out the entries. opw-5215997 Forward-Port-Of: odoo/odoo#237092
15 changes
Resolved issues and error corrections
This update resolves a bug that prevented users from setting invalid default values for certain fields. Specifically, attempting to set an integer as a default date caused an error. The fix ensures users can only define valid default values, improving data integrity and preventing unexpected system behavior.
Original PR description
Steps:
- Create a user defined defaults value
- Model: res.partner
- Field: date
- Value: 1
- Create a new contact
Actual result:
- invalid field type
- 'int' object is not subscriptable (depends of field type)
Expected result:
- No error
- User is not able to put an invalid value as a default
task-3729963
Forward-Port-Of: odoo/odoo#237265
Forward-Port-Of: odoo/odoo#225991This update resolves an issue where previously revoked portal users could inadvertently become the default public user for new websites. This prevented potential confidentiality risks and ensures that website public user settings are correctly managed. The fix maintains the ability to reactivate these users while preventing misconfiguration.
Original PR description
**Steps to reproduce:** - Go to a Contact - Go to the actions dropdown menu of the record - Grant Portal Access - Revoke that Access - Create a new Website in the same Company that Portal Access was…
**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions
**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)
if public_users_for_company:
return public_users_for_company[0]
```
This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).
**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).
For now the fix remove the public group on the revoked portal user, to still be able to reactivate it later on, without mistaking it for the default public user of a company.
Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.
related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b
opw-4760550
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#236014
Forward-Port-Of: odoo/odoo#233757This update fixes a bug where the 'Other Expenses' account type wasn't reflected in the Balance Sheet report. A new account type was recently added to simplify vendor bill expense tracking. This change ensures all financial data is accurately represented in the Balance Sheet.
Original PR description
In saas-18.3 a new account type was added: "Other Expenses" These accounts are excluded from the account many2one field to make it easier to find relevant expense accounts for vendor bills. Issue: This account type is not included in the Balance Sheet report. see comment in opw-5269456 related to opw-5191111
This update resolves a problem that prevented users from correctly configuring tax returns within the Accounting module. Specifically, a missing step in the installation process caused an error when setting the opening date for tax returns. The fix ensures the necessary setup is performed, allowing users to proceed with configuring their tax returns without issues.
Original PR description
From **saas-18.3**, when installing the accountant module, after [this PR](https://github.com/odoo/enterprise/commit/49aca723c2422fedcc8bda963a6346a172825617#diff-c703c688dc3f80644a43c96657cb2db0122b83cee9bcfa417554b0c7f1e4f550L22) the `_initiate_account_onboardings()` was not called anymore for companies that already had a chart template. This caused a traceback while configuring the Accounting Period on the Tax Returns journal: `ValueError - Expected singleton: onboarding.progress()` We now fix this behavior by ensuring that `_initiate_account_onboardings()` is called when installing the chart_template, filling the gap that was introduced. **Steps to Reproduce:** 1. Install `accountant` module without demo data. 2. Accounting > Dashboard > _Tax Returns_ Journal, click on the **"Tax Returns"** button. 3. Set an **Opening Date** in the wizard and try to apply the **Accounting Periods**. sentry-7064593163
This update fixes a potential issue in the Chilean VAT (l10n_cl_edi) module where incorrect sequence numbers could be generated for VAT documents. Previously, if a specific journal setting wasn't used, the system might have produced sequences starting with 'False'. This change ensures accurate and reliable sequence generation, preventing potential reporting errors.
Original PR description
Before this commit, if the journal is not set to using the document (l10n_latam_use_documents), the method _get_last_sequence could return a sequence that starts with False. opw-5404813 Forward-Port-Of: odoo/enterprise#101824
This update ensures that Turkish translations are properly applied when installing the 'l10n_tr_nilvera' language pack in new Odoo databases. Previously, translations weren't automatically updated, requiring manual intervention. This fix streamlines the language installation process for Turkish users.
Original PR description
### Issue: When installing "l10n_tr_nilvera" on a new DB the Turkish language is installed but the translation of previously installed modules are not updated. ### Steps to reproduce: - Install…
### Issue: When installing "l10n_tr_nilvera" on a new DB the Turkish language is installed but the translation of previously installed modules are not updated. ### Steps to reproduce: - Install 'l10n_tr_nilvera' and switch to a Saudi company - Check the view "report_invoice_document" - Click the translation icon on the view - No Turkish translations are loaded ### Cause: When installing "l10n_gcc_invoice" the Arabic language is installed ([src](https://github.com/odoo/odoo/blob/70404624d7ea6f971182cbe4f4fe8fc064d2afd8/addons/l10n_gcc_invoice/__init__.py#L4-L5)). But the method [`_activate_lang()`](https://github.com/odoo/odoo/blob/70404624d7ea6f971182cbe4f4fe8fc064d2afd8/odoo/addons/base/models/res_lang.py#L161-L169) only activates the language, it does not update the translations. ### Solution: Create a new method that activate the language and calls `_update_translations()` on the installed modules. opw-5219783 Forward-Port-Of: odoo/odoo#239310 Forward-Port-Of: odoo/odoo#237041
This update resolves a problem where imported invoices were incorrectly displayed in filtered invoice views, even when already reconciled. The fix ensures that filters accurately exclude imported entries, providing a cleaner and more reliable view of unpaid invoices for users. This improves data accuracy and simplifies invoice management.
Original PR description
Error steps: - Create or import "miscellaneous" entries in a sales journal (through the FEC import e.g.) - Have at least one late or unpaid invoice in the same journal. - The journal dashboard view should display a "X Unpaid" or "X Late" suggestion -> click on it => The filtered view shows the correct unpaid or overdue invoices/bills AS WELL as the imported entries, even if the latter are fully reconciled already. Now the filters correctly filter out the entries. opw-5215997 Forward-Port-Of: odoo/odoo#237092
This update resolves an issue where SN labels weren't generated when producing multiple units of a product through the manufacturing process. Previously, MOs with quantities greater than one would fail to print the required labels. This fix ensures that SN labels are consistently printed for all produced units, streamlining tracking and traceability.
Original PR description
This commit fixes the issue of not printing Lot/SN labels when generating them on the MO that has more than 1 unit on the quantity to produce. To reproduce the bug: 1- Go to Operation Types → Manufacturing → Hardware → activate the print `Lot/SN Label` (Print When "Create New Lot/SN") 2- Create an MO with quantity of 5 for a tracked product. 3- Click on `Produce All` and use the wizard to generate SNs and produce or confirm the MO. = SNs should be printed but they are not. opw-5347787 Forward-Port-Of: odoo/odoo#238739
This update resolves an issue where the Gantt chart would crash when event start or end dates were cleared. The fix ensures the Gantt calculation only runs when a valid date range exists, preventing a type error that occurred when comparing dates with boolean values. This improves stability and usability of event scheduling.
Original PR description
When removing the start or end date on an Event, the system raises a traceback during Gantt information computation. **Steps to Reproduce:** 1. Install `website_event_track_gantt` module. 2. Create a new Event. 3. Add at least one **Track** with a track **Date** and **Duration**. 4. In the Event form, clear the Start or End Date field. **Error:** `TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'` **Cause:** When the event start or end date is removed, those fields become False. During computation, the system attempts to compare these False values with the track dates (which are real datetimes), resulting in an invalid datetime-boolean comparison, causing the error. **Fix:** This commit ensures the Gantt calculation only executes when the event has a valid date range, avoiding comparisons that include missing values. no id Forward-Port-Of: odoo/enterprise#101541
This update fixes a bug that caused invoices with zero amounts to crash during confirmation. The fix prevents a division-by-zero error by adding a check to ensure the invoice total is not zero before calculating currency rates. This ensures invoices can be processed correctly, regardless of the currency or line item values.
Original PR description
Steps to reproduce:
--------------------
1. Install l10n_cl and switch to the CL company
2. Create a new invoice:
- Change the currency to a value different from the company currency
(e.g., from CLP to USD)
- Add an invoice line with a price value of 0
- Remove the default tax value
3. Try to confirm the invoice
Issue:
------
A traceback occurs:
`ZeroDivisionError: float division by zero`
Cause:
------
Since the price value is 0, the `amount_total` of the move becomes 0.
When computing the currency rate, it tries to divides by `amount_total`, resulting in a ZeroDivisionError.
Solution:
---------
Add a conditional check before division to ensure the `amount_total` is non-zero
Related enterprise PR: https://github.com/odoo/enterprise/pull/99518
opw-5247058
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239063
Forward-Port-Of: odoo/odoo#235252This update fixes a potential error that could prevent invoices from being confirmed when specific currency and pricing settings are used. The fix adds a check to ensure invoice amounts are non-zero before currency calculations, preventing a division-by-zero error. This ensures smoother invoice processing and avoids disruptions to financial operations.
Original PR description
Steps to reproduce: -------------------- 1. Install l10n_cl and switch to the CL company 2. Create a new invoice: - Change the currency to a value different from the company currency (e.g., from CLP to USD) - Add an invoice line with a price value of 0 - Remove the default tax value 3. Try to confirm the invoice Issue: ------ A traceback occurs: `ZeroDivisionError: float division by zero` Cause: ------ Since the price value is 0, the `amount_total` of the move becomes 0. When computing the currency rate, it tries to divides by `amount_total`, resulting in a ZeroDivisionError. Solution: --------- Add a conditional check before division to ensure the `amount_total` is non-zero Related community PR: https://github.com/odoo/odoo/pull/235252 opw-5247058 Forward-Port-Of: odoo/enterprise#101587 Forward-Port-Of: odoo/enterprise#99518
This update prevents the delivery date from being automatically recalculated when an invoice is reset to draft. Previously, this could overwrite user-entered delivery dates, causing confusion and requiring manual corrections. This change ensures accurate delivery date tracking for invoices.
Original PR description
**PROBLEM** Resetting to draft an invoice can sometimes recompute the delivery date, overwritting any value the user may have enter. **STEP TO REPRODUCE** 1. Enable anglo-saxon accounting 2. have a product category with automated AVCO 3. assign category to a deliverable product 4. set product to invoice on delivery 5. add product to a sales order 6. confirm order & delivery 7. create invoice 8. change the delivery on the invoice 9. confirm the invoice. 10. reset the invoice to draft. **CAUSE** button_draft() unlinks some account.move.lines, triggering the compute on delivery_date. see for more info : https://github.com/odoo/odoo/pull/231186 opw-5347939 Forward-Port-Of: odoo/odoo#237612
This update resolves a bug that prevented users from completing the address confirmation process after purchasing a ticket. The issue stemmed from a problem with how the system handled missing customer names during the confirmation step. The fix ensures a smooth redirect after address confirmation, improving the user experience.
Original PR description
Steps to reproduce: =================== 1. On an event, make sure to: - Have at least one paying ticket; - Remove any "name" or "email" type of question. 2. Go to the event website page as a public…
Steps to reproduce: =================== 1. On an event, make sure to: - Have at least one paying ticket; - Remove any "name" or "email" type of question. 2. Go to the event website page as a public visitor and buy one ticket. Fill in the form and click on "Go to payment". -> Nothing happens. Cause: ====== Clicking on "Go to payment" triggers the registration_confirm function: https://github.com/odoo/odoo/blob/e91c3817574af8bd48a634e3fb0b2f0e08b21ee9/addons/website_event_sale/controllers/main.py#L78 Triggering `_create_or_update_address` for the first time will create a partner without a `name`: https://github.com/odoo/odoo/blob/fa137d08669db2f10cf735a2bc1278b3f1b4f5a9/addons/portal/controllers/portal.py#L543 When clicking on the confirm button, it will re-trigger `_create_or_update_address`. At that moment, `partner_sudo.name` is `False`, so the confirmation breaks on: `partner_sudo.name.strip()` because you cannot call `.strip()` on a `False` value. Solution: ========= If the name is not set, simply treat it as unchanged and continue. In the registration form, a name should normally be provided by default. opw-5357924 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing non-POS users from archiving products. Previously, a lack of POS access rights triggered an error, even if the product wasn't used in a POS session. This change ensures that all users can archive products, regardless of their POS access, improving workflow efficiency.
Original PR description
### Steps to reproduce: - With Admin open a pos session - With an other user without pos access rights archive a product unrelated to pos (e.g. not used in the session) #### > Access error: You are…
### Steps to reproduce: - With Admin open a pos session - With an other user without pos access rights archive a product unrelated to pos (e.g. not used in the session) #### > Access error: You are not allowed to access 'Point of Sale Session' (pos.session) records. This operation is allowed for the following groups: - Point of Sale/User ### Cause of the issue: Since 985fd5821fe1e8633503d713f1f1c3650bcf0c91 the `action_archive` of products, check that the product is not used by an order of any opened `pos.session` before allowing the user to archive it: https://github.com/odoo/odoo/blob/2011885246f5473ddc16fe5bd17db98ebff712f3/addons/point_of_sale/models/product_product.py#L51-L53 https://github.com/odoo/odoo/blob/2011885246f5473ddc16fe5bd17db98ebff712f3/addons/point_of_sale/models/product_template.py#L313-L320 However, if the user does not have any pos access rights he can not access the pos session to check if the product is used which raises an access error even if the product is un-used. ### Note: This is notably problematic as it makes it impossible to archive products via the `action_archive` in unrelated stock tests relying on a non-admin user. opw-stock-tests --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows the 'Emissions stat' button to be displayed on a wider range of accounting documents, including Purchase Receipts, previously it was limited to Vendor Bills. This expands the data available for tracking and reporting environmental impact within our accounting processes.
Original PR description
Prior to this PR, we limited the display of the Emissions stat button of 'account.move' to Vendor Bills and Credit Vendor Bills ('in_invoice' and 'in_refund'). But emissions could be reported in other types of moves (e.g. Purchase Receipt), so we remove that condition.
task-54077612 changes
Resolved issues and error corrections
This update fixes an issue where the Chilean accounting module could generate incorrect journal sequences. Previously, if a specific setting wasn't enabled, the system might produce sequences starting with 'False'. This change ensures sequences are always generated correctly, improving the reliability of financial data reporting.
Original PR description
Before this commit, if the journal is not set to using the document (l10n_latam_use_documents), the method _get_last_sequence could return a sequence that starts with False. opw-5404813 Forward-Port-Of: odoo/enterprise#101824
This update fixes a bug that caused the Gantt chart to crash when users cleared the start or end dates of an event. The change ensures the Gantt calculation only runs when a valid date range exists, preventing errors and improving stability.
Original PR description
When removing the start or end date on an Event, the system raises a traceback during Gantt information computation. **Steps to Reproduce:** 1. Install `website_event_track_gantt` module. 2. Create a new Event. 3. Add at least one **Track** with a track **Date** and **Duration**. 4. In the Event form, clear the Start or End Date field. **Error:** `TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'` **Cause:** When the event start or end date is removed, those fields become False. During computation, the system attempts to compare these False values with the track dates (which are real datetimes), resulting in an invalid datetime-boolean comparison, causing the error. **Fix:** This commit ensures the Gantt calculation only executes when the event has a valid date range, avoiding comparisons that include missing values. no id Forward-Port-Of: odoo/enterprise#101541
16 changes
Enhancements to existing features
This update enhances the user interface for selecting online accounts within Odoo Enterprise. The outdated 'online_account_radio' component has been removed, streamlining the process and improving usability. This change focuses on a better user experience for managing online accounts.
Original PR description
This commit refactor the online account selection widget to have a better ui. Removed the online_account_radio since it's not used anymore. task-5090281
This update enhances the HR Homeworking Calendar module by moving a key field to the Calendar module itself. This allows for better reuse of components and simplifies the overall design, leading to a more streamlined user experience for managing homeworking arrangements. It’s a small, internal improvement focused on code organization.
Original PR description
Moved the badge_selection_icon_mapping_field to the Calendar module, so that it can be reused in hr_homeworking.calendar module Added optional default icon prop Task ID: 5215931 Community PR: https://github.com/odoo/odoo/pull/235440
This update improves the visibility of Kanban groups in the Helpdesk module. The system now displays the group name within the no-content helper, making it easier to identify and manage tickets. This change was implemented as an improvement to the user experience.
Original PR description
Due to changes made in https://github.com/odoo/odoo/pull/236049, the CSS class for the Kanban group no-content helper has been updated. task-5266317
This update clarifies the setup for approval categories within the Odoo Enterprise system. Specifically, the tooltip for automatic sequence settings has been updated for better understanding, and a label change (Code to Prefix Code) has been made to improve consistency and reduce confusion.
Original PR description
- Updating the tooltip for the automatic sequence field in the approval category setting - Renaming label Code to Prefix Code Task: 5384511
Resolved issues and error corrections
This update allows HR to now select a PDF template and designated signatories when creating offers for employee versions. Previously, this functionality was unavailable, limiting the customization options for offer documents. This change streamlines the offer creation process and ensures greater control over offer presentation.
Original PR description
Before if you created an offer for an employee version and not a contract template, it was impossible to choose a pdf template or signatories. This commit fixes this issue. Task-5375821
This update improves our internal referral process by logging all emails sent when a job promotion is initiated. Previously, no record was kept of these emails, making it difficult to track and analyze promotion activity. Now, only key email details (subject, body, recipient) are logged for auditing and reporting.
Original PR description
Before: - Once a job is published, a Promote button appears. The steps are: Recruitment > select a job (configuration) > Publish > Promote - After clicking the Promote button and sending the email, no log was being maintained for that job. After: - With this commit, we will log every promote email sent to the employee. - We will log only the subject, the body (skeleton only), and the recipient of the email. Task: 5375111
This update corrects a previous issue where employees working less than 6 months were incorrectly denied PFA (Pension Funds Agreement) eligibility. The change now accurately checks if an employee started their employment at least 6 months ago, ensuring correct PFA rights for all employees regardless of their tenure.
Original PR description
If you worked less than 6 months, you could have the right to the PFA. Instead of verifying that the employee worked for 6 full months, we should check that he started at least 6 months ago. task-5405293 Forward-Port-Of: odoo/enterprise#101721
This update corrects a technical issue where reverting a payslip incorrectly flagged related payslips as duplicates, leading to confusing warnings. The fix ensures that payslips linked to a reverted payslip are properly identified as 'Related Payslips' instead of duplicates, streamlining the payroll process.
Original PR description
## Steps to Reproduce 1. Create a payslip and validate it. 2. Mark it as Paid. 3. Click on Revert and it will create a new payslips related to the other payslip. ## Issue When reverting a payslip, it is flagged as a "Duplicate". When there is a payslip that has "Related payslips", it should not be considered as a duplicate. ## Fix Duplicate warnings now ignore the original and refund payslips linked to each other (`origin_payslip_id/related_payslip_ids`) are removed from the duplicate recordset. task - [5240436](https://www.odoo.com/odoo/project/1251/tasks/5240436) Forward-Port-Of: odoo/enterprise#99988
This update removes a problematic field from the employee data module, preventing errors during debugging. The issue stemmed from a previous, poorly handled code change. The fix involves removing the unnecessary computed field and adjusting its storage settings.
Original PR description
### Issue: The field `l10n_sa_leaves_count_compensable` is a computed field with no compute method. When in debug mode, trying to look at the fields of an employee results in a traceback because of…
### Issue: The field `l10n_sa_leaves_count_compensable` is a computed field with no compute method. When in debug mode, trying to look at the fields of an employee results in a traceback because of this. ### Cause: This [forward port](https://github.com/odoo/enterprise/commit/4124dc4c13055d39d233d7ea9374b5191afdfcf2#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5) had a conflict that was badly resolved by re-adding a previously deleted field. The field was replaced by `l10n_sa_remaining_annual_leave_balance` in [this commit](https://github.com/odoo/enterprise/commit/339bc032aa763c62d4dd27b73fc42488b3e1c3aa#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5). [Failing FWP](https://github.com/odoo/enterprise/commit/b3f276d0d73a24faf322aa2ae8965c3d5aad4a87#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5) ### Solution: We can no longer delete the field because of the stable policy. The solution is to remove the compute and add `store=False`. Then remove the field in master. opw-5352456 Forward-Port-Of: odoo/enterprise#100756
This update resolves a technical issue causing errors during the creation of WPS reports for Saudi Arabia's HR payroll. The problem stemmed from an incorrect function usage, which has now been corrected. This ensures accurate report generation and avoids potential disruptions to payroll processing.
Original PR description
this commit addresses traceback errors occured due to incorrect usage of `_` function. task-5310946 Forward-Port-Of: odoo/enterprise#99789
This update fixes a visual issue in the Odoo Enterprise Icon Creator dialog, which previously lacked proper spacing. The change adds necessary padding to improve the dialog's appearance and usability, ensuring icons are displayed correctly within the interface. This enhances the user experience when customizing application icons.
Original PR description
Before this commit When editing an application icon, the IconCreator dialog was missing top and bottom padding. This regression occurred after the milk dialogs, where top and bottom padding was removed from the `modal-body`, [see reference](https://github.com/odoo/odoo/blob/2ace54d281f15baef2a498b0a5f5ad7f7be79387/addons/web/static/src/core/dialog/dialog.scss#L46) After this commit Added the necessary padding to the IconCreator dialog. task-5345762
This update eliminates a technical issue where call recordings were duplicated in the chatter attachments after transcription. The change ensures that only the necessary recording is retained, streamlining call history and improving the user experience. This resolves a minor inconsistency in the system.
Original PR description
When the transciption in on, you always find two recordings in the call attachments in the chatter. This is because there is an original recording and another one for the transcription that wasn't deleted. This commit deletes the additional recording after using it in the transcription. Task-5404304
This update resolves a technical problem preventing the correct installation of the Indian demo data for Odoo Enterprise's payroll module. The issue stemmed from an incorrect calculation within the demo data, which was replaced with the correct value, ensuring proper functionality.
Original PR description
Issue: Demo leave used an invalid eval value for leave_type_request_unit, causing a NameError during installation. Fix: Replaced the eval expression with the correct string value `half_day`. task-5410134
Features or functions removed from Odoo
This update removes the reliance on a signature dependency within the Odoo Enterprise accounting module. This simplifies the system and reduces potential complexity for users. The change improves the overall stability and maintainability of the accounting features.
Original PR description
task-5154292
This update removes outdated and unused code within the Voip module, streamlining the system and improving performance. Specifically, a component and a related feature were identified as no longer needed, resulting in a cleaner and more efficient codebase. This change focuses on internal improvements and doesn't impact external users.
Original PR description
### Changes - DeviceSelectionDialog component is no more needed - The only use case for `Voip.bus` was made by CallQueueSwitch component but the event it was listening to is never triggered. Removed. - CallQueueSwitch has been renamed in CallQueueSwitchField to better reflect what this component is.
Code cleanup and technical improvements
This update streamlines maintenance request notifications by consolidating message logic and removing a redundant custom controller. The changes ensure consistent user feedback across Odoo, aligning with other key actions and improving the overall user experience.
Original PR description
_* = mrp_maintenance 1. Refactor Completion Notifications * Converted the constant notification message mapping into a getter method, as the constant was not reused elsewhere. This improves extensibility and allows easier overrides in inheriting modules. 2. Remove Custom Form Controller * This custom form controller was originally added to display a feedback notification when Maintenance Requests are successfully created from the shopfloor. After this PR (#76035), the action notification can now be handled directly there, making the custom controller unnecessary. * The notification message is also updated to use the correct phrasing, aligning it with Scrap and Quality Alert actions for consistent user feedback. This cleanup removes redundant code and keeps the notification logic in a single place, avoiding the need to maintain separate implementations across modules.
16 changes
Enhancements to existing features
This update allows users to accurately display the account holder's name alongside bank details, even when it differs from the partner's name. Previously, the account holder name was automatically set to the partner's name, which is now corrected to ensure accurate reporting and reconciliation. This change enhances data clarity and reduces potential errors.
Original PR description
Allow changing of the account holder name in case it is different from the partner name which was the computed default. Task-5222712 [Related PR](https://github.com/odoo/enterprise/pull/98572)
Resolved issues and error corrections
This update resolves a bug in the Odoo Studio interface that caused incorrect field choices when switching between different field types. The fix ensures that field selections always reflect the currently chosen field, preventing errors and improving the user experience. This improves the reliability of the Studio tool.
Original PR description
Before this commit when selecting fields in studio caused `getFieldChoices` to read from this.props which could still reference the previously selected field’s relation. when switching from a non-relational field to a relational one, the stale props sometimes provided an incorrect `relation` value This resulted in incorrect choice and errors such as `Invalid model name: undefined` during loadField. After this commit getFieldChoices now uses the updated props and safely guards relation lookups. this ensures that the available choices always correspond to the currently selected field and prevents loading choices from the previous field’s relation and avoids the traceback. task-5241639
This update resolves a technical issue that caused a traceback when reloading the WorkEntries page in Studio. The fix ensures Studio correctly loads the page action, preventing errors and improving stability. This change primarily impacts the Studio user experience.
Original PR description
**Verison:** - saas-18.2 **Steps to reproduce:** - Go to an employee form view. - Click on the WorkEntries smart button. - Open Studio. - Reload page. **Issue:** - A traceback appears after reloading the page in Studio. **Cause:** - The smart button URL uses the model name hr.work.entry, but Studio’s service_action expects a path without dots. Because the action cannot be loaded correctly, the view breaks and triggers the traceback. **Solution:** - Return the proper path instead of the model name so that the action loads correctly. This prevents the error when reloading the page. task-5236317 Forward-Port-Of: odoo/odoo#239335 Forward-Port-Of: odoo/odoo#235662
This update resolves an issue where multiple daily attendance entries were incorrectly merging, resulting in inaccurate duration calculations. The fix ensures that each attendance entry is accurately recorded, preventing overlaps and providing correct work time data. This improves the reliability of employee time tracking.
Original PR description
In this commit, we fixed the merge of multiple attendance work entries on the same day. Currently, when you create multiple attendances on the same day, the work entry duration is considering the last one's duration. Reason: converting a work entry into intervals will be in a full day interval which is wrong, it will consider previous work entries as included ones within the new one. Fix: we need to regenerate the old ones too. Related task: 5405642
This update fixes a technical error preventing the Nilvera E-Invoice module from correctly generating invoices when using bank accounts. The issue stemmed from a mismatch in how the system identifies address fields, specifically when dealing with bank records. This fix ensures invoices can now be successfully sent.
Original PR description
**Steps to reproduce:** * Install the **Türkiye - Nilvera E-Invoice (l10n_tr_nilvera_einvoice)** modules * Configure test mode following the [setup…
**Steps to reproduce:**
* Install the **Türkiye - Nilvera E-Invoice (l10n_tr_nilvera_einvoice)** modules
* Configure test mode following the [setup guide](https://docs.google.com/document/d/1EUzvTBnSm9-VwIfBsX299MHGXIVys-uijnsJ1fpz7vI/edit?tab=t.0).
* Create a bank account for the main company and fill the **Bank** selector (bank identifier dropdown).
* Create and attempt to send a customer invoice via Nilvera.
**Observed behavior:**
* A server error occurs: `KeyError: 'country_id'` in `l10n_tr_nilvera_einvoice/models/account_edi_xml_ubl_tr.py` at line 172 while generating `<cac:PayeeFinancialAccount>`.
* The invoice cannot be sent.
**Cause:**
* `_get_address_node()` determines field names using `vals.get('model', 'res.partner')`.
* When the parent class calls `_get_address_node({**vals, 'partner': bank})` with a `res.bank` record, it does **not** pass a `model` parameter.
* The method falls back to `'res.partner'` and attempts to read `country_id` from a `res.bank` record, which instead uses the field `country`.
* This mismatch triggers a `KeyError`.
**Fix:**
* Detect the appropriate field set by checking `partner._name` rather than relying on `vals.get('model')`.
* Use `country` / `state` when the record is `res.bank`.
* Use `country_id` / `state_id` when the record is `res.partner`.
opw-5380246This update corrects a potential issue in the Chilean VAT (l10n_cl_edi) module where an incorrect sequence number could be generated for VAT documents. Previously, if a specific journal setting wasn't configured, the system might produce sequences starting with 'False'. This fix ensures accurate and reliable sequence generation, preventing reporting errors.
Original PR description
Before this commit, if the journal is not set to using the document (l10n_latam_use_documents), the method _get_last_sequence could return a sequence that starts with False. opw-5404813 Forward-Port-Of: odoo/enterprise#101824
This update corrects a display issue in the SA EDI version of vendor bills. When a bill's currency doesn't match the company's local currency, the amounts shown in the currency conversion section were incorrectly appearing as negative. The fix ensures accurate currency calculations and proper bill formatting.
Original PR description
**Steps to reproduce:** - Create a vendor bill with currency not matching the currency of an SA company - Print the bill in the SA EDI specific format (is not shown on preview) or export as PDF **Issue:** Amounts displayed in the currency conversion section of the bill incorrectly show negative values for subtotal and total. **Solution:** The view affecting the bill in question referred to `o.amount_untaxed_signed` and `o.amount_total_signed` where either unsigned `o.amount_untaxed` and `o.amount_total` or `abs(o.amount_[...]_signed)` should be used instead, as in other localizations. opw-5253213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236654
This update resolves an issue where top-up events would fail when a company's archived account was used. The team has simplified the reconciliation process, now skipping it as it's considered a 'nice to have'. This ensures top-ups function correctly even with archived accounts.
Original PR description
Before this commit: Webhook 'topup.succeeded' events would fail if the company `transfer_account_id` field is set to an archived account at the reconciliation step After this commit: As the reconciliation is a "nice to have", we skip the reconciliation step Steps to reproduce: - Install `hr_expense_stripe_demo` - Fill the KYC of doom - Archive the account set on the company `transfer_account_id` field - Create a top-up - Nothing happens, error 550 logged on IAP test
This update fixes a technical issue that prevented product catalog search options from being properly translated into different languages. By wrapping labels with the '_t' function, the system now supports localization, ensuring consistent and accurate translations across all Odoo languages. This improves the user experience for international customers.
Original PR description
When adding the search options in the catalog view[^1], the labels were not made translatable. This commit wraps the labels with the _t function to ensure they can be translated into different languages. [^1]: https://github.com/odoo/odoo/commit/96dc626f8d489817c944420178c22dba5c916799
This update fixes a technical issue related to how audit status information is calculated in financial reports. The previous calculation used incorrect settings, leading to inaccurate reporting. This change ensures that audit status data is correctly processed across various localized versions of Odoo Enterprise.
Original PR description
When computing allow_account_audit_status_on_lines, we used the wrong field_name and default_value. Removed all the localized value as this fix should have been the one done in the first place. task-5106852
This update resolves an issue where the Gantt chart would crash when event start or end dates were cleared. The fix ensures the Gantt calculation only runs when a valid date range exists, preventing errors caused by comparing dates with empty values. This improves stability and usability of event scheduling.
Original PR description
When removing the start or end date on an Event, the system raises a traceback during Gantt information computation. **Steps to Reproduce:** 1. Install `website_event_track_gantt` module. 2. Create a new Event. 3. Add at least one **Track** with a track **Date** and **Duration**. 4. In the Event form, clear the Start or End Date field. **Error:** `TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'` **Cause:** When the event start or end date is removed, those fields become False. During computation, the system attempts to compare these False values with the track dates (which are real datetimes), resulting in an invalid datetime-boolean comparison, causing the error. **Fix:** This commit ensures the Gantt calculation only executes when the event has a valid date range, avoiding comparisons that include missing values. no id Forward-Port-Of: odoo/enterprise#101541
This update resolves an issue where the color picker test was failing intermittently due to timing problems. The fix ensures the test waits for all steps to complete, preventing unpredictable results and improving the reliability of the website customization process. This enhances the overall quality and stability of the website builder.
Original PR description
__Behavior before commit:__ Since `edit` writes one character after the other, using it on a color picker to write an RGBA color calls `make_scss_customization` when the input value reaches the RGB color. Then, another call is made when the entire color is written (because they are both valid colors). However usually the test finished before the steps for the second call were reached because the `Deferred` was only waiting for the first call. __Fix:__ Wait for all steps to avoid nondeterministic behavior. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/234621 Forward-Port-Of: odoo/odoo#239441
This update removes the display of guest amounts from the payment screen in the Odoo Restaurant Point of Sale module. Previously, this information was shown for all orders, which was causing confusion and unnecessary data. This change simplifies the payment process for users.
Original PR description
Before this commit, for all of the orders there was the amount per guest displayed in the payment screen. opw-5394429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a minor usability issue where clicking the question mark (?) on the website would unexpectedly focus a field. This was causing a frustrating user experience, particularly on mobile devices. The fix ensures the question mark only displays the tooltip, as intended.
Original PR description
On desktop: - Hovering the "?" opens the tooltip; - Clicking on the "?" focuses the field => bug On Mobile: - Clicking on the "?" focuses the field => bug Clicking on the "?" should not focus the field (annoying because it could open a "Search more" on M2O, a bottom sheet, etc.) task-5359752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the IoT app by providing clear notification feedback when users enable remote debug. Previously, there was no indication of success or failure when entering the debug token. Now, users will receive a confirmation message, improving the user experience and troubleshooting.
Original PR description
When activating the remote debug from iot app backend there is no feedback when entering the token. We now display a notification to inform whether the remote debug is enabled or not. Task: 5388242
This update resolves a confusing issue with audio/video device selection in Odoo's Discuss calls, specifically on Chromium browsers. The system now correctly requests necessary permissions and displays a clear 'Permission Needed' message when permissions aren't granted, leading to a smoother user experience.
Original PR description
Backport of https://github.com/odoo/odoo/pull/236499 This commit removes the 'Browser Default' placeholder for audio/video device selection on Chromium-based browsers, as they already return their own default device and the placeholder causes confusion. The device-selection dropdown will now display 'Permission Needed' when permissions are not granted. Clicking the dropdown will trigger the permission dialog if the necessary permissions are not granted. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
16 changes
Enhancements to existing features
This update enhances the formatting of invoices generated for the Co-dian region in Odoo. Specifically, it standardizes the way floating-point numbers are formatted within the account_edi_common module, ensuring accurate and compliant invoice generation. This change improves the reliability of financial reports and tax filings for Co-dian customers.
Resolved issues and error corrections
This update corrects a potential issue in the Chilean VAT (l10n_cl_edi) module where an incorrect sequence number could be generated if a specific journal setting wasn't properly configured. This prevented errors when creating VAT documents and ensured accurate VAT processing. The change improves the reliability of the module.
Original PR description
Before this commit, if the journal is not set to using the document (l10n_latam_use_documents), the method _get_last_sequence could return a sequence that starts with False. opw-5404813
This update resolves an issue preventing users from loading demo data in the Appraisal module when creating a new company. The fix uses elevated permissions during demo data loading to bypass company-specific access restrictions, allowing users to successfully load the sample data.
Original PR description
Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module. **Steps to Reproduce:** 1. Install `hr_appraisal_skills` without demo data. 2.…
Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module.
**Steps to Reproduce:**
1. Install `hr_appraisal_skills` without demo data.
2. Create a new company and switch to it.
3. Appraisals > Click "Load sample data".
**Traceback:**
```
AccessError
Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Sengsourigna Phonkaseumsouk (id=2) doesn't have 'read' access to:
- Employee, Emma Granger (hr.employee: 3, company=TPX Solutions)
Blame the following rules:
- Employee multi company rule
If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.
This seems to be a multi-company issue, you might be able to access the record by switching to the company: TPX Solutions.
ParseError
while parsing /home/odoo/src/enterprise/19.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside <function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref('hr_appraisal.hr_appraisal_2')]"/>
ValueError
ParseError('while parsing /home/odoo/src/enterprise/19.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside\n<function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref(\'hr_appraisal.hr_appraisal_2\')]"/>') while evaluating 'action = model._load_demo_data()'
````
**Cause:**
The demo data loading process attempts to access employee records without the required permissions. Since the user belongs to a different company, the multi-company security rules prevent reading those employees.
**Fix:**
This commit resolves the issue by using sudo during demo data loading to ensure the required access rights are granted.
sentry-7032880299This update ensures that manually set currency rates for foreign currency invoices are preserved when the invoice is posted. Previously, the system automatically recalculated rates, leading to potential discrepancies. This fix maintains the user's intended rate, improving accuracy and reducing errors in financial reporting.
Original PR description
When creating a customer invoice in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. This fix ensures that any manually entered rate is preserved during posting. The problem was that when posting the invoice_date field changes and the function compute_invoice_rate were called. Solution check if it is manually inserted and do not compute the invoice_rate again task-5391774 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where background colors were lost when copying tables from the Knowledge editor to other Odoo applications. The change ensures that the correct formatting is preserved during copy and paste operations, improving the user experience when working with tables.
Original PR description
To make it possible to properly copy DOM elements across editors, the `application/vnd.odoo.odoo-editor` mimetype was introduced in the `ClipboardPlugin`. However, this was not used inside the `HtmlViewer`. Because of this, some content formatting could be lost when copying elements from an `HtmlViewer` to an editor. This commit solves this by also invoking the code that fills the clipboard in `ClipboardPlugin` when content is copied in an `HtmlViewer`. Steps to reproduce: - Insert a table in Knowledge - Set a background color on a few cells - Use the "lock" feature of Knowledge (inside a dropdown the menu on the right) - Select the entire table - Copy/paste it in a project task => The background colors in the cells were lost task-4017841
This update corrects a printing issue where Sale Order PDFs using the DIN5008 document layout displayed customer addresses twice. The fix prevents this duplication by ensuring addresses are only added once, specifically when the 'Customer Addresses' setting is disabled. This ensures consistent and accurate reporting for our German clients.
Original PR description
## Issue: When DIN5008 is selected as the document layout, printing a Sale Order may show the customer address twice ## Cause: The address is first added by `external_layout_din5008`, then again by `report_saleorder_document` This duplication only makes sense when the partner address differs from the invoice or delivery address If the Customer Addresses setting is disabled, displaying it multiple times is unnecessary ## Steps to reproduce: - Install a company using DIN 5008 (e.g., l10n_de) - Select the DE company and go to Settings - Disable `Customer addresses` and ensure the document layout is set to DIN 5008 - Create a Quotation with any customer and product - Print the PDF → the address appears twice before the fix opw-5176593
This update resolves an issue where branch users couldn't see matching entries in the reconciliation screen. The fix ensures that the system correctly retrieves accounts based on user access permissions, allowing accurate reconciliation for branch operations. This improves the usability of the accounting module for branch-specific transactions.
Original PR description
**Steps to reproduce:** - Install Accounting - Create a branch company - Switch to the branch - Create a Bank journal for the branch - Create a Sales journal for the branch (You can duplicate the journals from the parent company) - Make sure that the accounts configured on the journals are linked the branch - Grant only access to the branch to a user - Connect with that user - Create an invoice - In the bank journal, create a statement line matching the amount of the invoice - Select the statement line **Issue:** In the "Matching Existing Entries" tab, there is no entry. **Cause:** When retrieving the accounts required for the domain to fetch these entries, no account can be retrieved because the user doesn't have access to the parent company. opw-5181909 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that a 'partner ID' is always required when creating SEPA payments in Odoo. Previously, missing this information could cause errors during batch payment creation, leading to processing disruptions. This change improves payment stability and reliability for SEPA transactions.
Original PR description
When doing a payment with SEPA as the payment method, and then create a batch payment out of it. It could happen that the partner_id of the payment was not set. That would cause a traceback because in the _get_CdtTrfTxInf we do a browse on the partner to use it later on. But since the partner is False, we have an empty record set. task-5213880
This update fixes an issue where the Partena export file incorrectly used the active company's code when generating exports for inactive companies. The change ensures the correct Partena code is included in the CSV file, resolving a potential data discrepancy for Partena reporting. Tests have been added to verify this fix.
Original PR description
### Issue: In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file. ### Steps to reproduce: - Install…
### Issue: In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file. ### Steps to reproduce: - Install 'l10n_be_hr_payroll_partena' and switch to a Belgian company - Make sure the company has a "Partena Affiliation Number" - Create an employee for this company, with a "Partena code" - Create a contract for this employee, set it a running - Create a new Belgian company with a different "Partena Affiliation Number" - Activate both Belgian companies, but set the second one as active - Payroll > Reporting > Export work entries to Partena - Create a new one, populate it with the employee just created - Click "Generate Export File" ### Cause: When getting the data for the CSV file, we use `self.env.company` which is the active company. So when this company is not the one of the export record, we input the wrong code values. ### Solution: Use `self.company_id` instead of `self.env.company_id`. Also adds the test class with basic tests. opw-5345786
This update ensures that coupon emails sent to customers use the localized date format (e.g., yyyy-MM-dd) based on their language settings. Previously, emails displayed a technical date format, causing confusion. This change improves the customer experience by presenting dates in a familiar and understandable way.
Original PR description
Steps to reproduce: 1. Install `loyalty` and `sale_management` 2. Activate another language with another date format, eg. English (AU) 3. Set that language on a contact 4. Sales > Product > Discount…
Steps to reproduce: 1. Install `loyalty` and `sale_management` 2. Activate another language with another date format, eg. English (AU) 3. Set that language on a contact 4. Sales > Product > Discount & loyalty 5. Create a record with program type coupons 6. Generate a coupon for that AU contact with an expiration date Issue: The coupon email received by the customer shows the expiration date using the yyyy-MM-dd format, and the attachment shows the same technical format instead of the customer’s localized date format. Cause: We are not using a formatted date according to the customer before: Customer with English AU language <img width="601" height="563" alt="image" src="https://github.com/user-attachments/assets/faea2840-aca6-4850-bfc9-b0d24da65a3b" /> <img width="1510" height="883" alt="image" src="https://github.com/user-attachments/assets/b0ebc0cc-6243-450d-ad12-cecda4858e26" /> After: <img width="603" height="543" alt="image" src="https://github.com/user-attachments/assets/5be2332b-3237-4ce5-8122-0766cd274650" /> <img width="1482" height="886" alt="image" src="https://github.com/user-attachments/assets/99d31b4c-33fa-4f92-9970-56720181911e" /> opw-5247621
This update corrects a previous error that prevented users from saving XML files within the Odoo Studio. Specifically, the system would throw an error when an XML encoding declaration was included. The fix ensures a clearer error message is displayed, guiding users to correctly format their XML files.
Original PR description
Currently, an error occurs when a user includes an XML encoding declaration in the studio XML editor. **Steps to produce:** - Install the `web_studio` module and enable `developer mode` - Open `Apps` > `studio` > `view` > `</> xml` - Declare encoding as: `<?xml version='1.0' encoding='utf-8'?>` and click `save` **Error:** `ValueError: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration.` **Root cause:** At [1], an error is raised when the XML declaration contains an `encoding` attribute, as encoding declarations are invalid in Unicode strings. **Fix:** This commit ensures that a `UserError` is raised, improving the error message clarity. A similar fix was applied in https://github.com/odoo/odoo/pull/205324. [1]: https://github.com/odoo/odoo/blob/8a22b6ca09e1da3ccba3540bc4851a5174e035cc/odoo/tools/translate.py#L316 sentry-6981234548
This update resolves an issue where removing a combo name and then clicking 'Edit Configuration' on an order line would trigger an error. The fix ensures that the 'Edit Configuration' option is only displayed when a product template is associated with the combo, improving usability and preventing unexpected errors.
Original PR description
Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered. Steps to replicate: - Install `sale_management`…
Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered. Steps to replicate: - Install `sale_management` with demo and create a new SO. - Add a combo product and remove the combo name and click Edit Configuration (pencil icon). Error: `TypeError: SaleProductConfiguratorController.sale_combo_configurator_get_data() missing 1 required positional argument: 'product_template_id'` Cause: - When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_combo_configurator_get_data()` which expects `product_template_id` at [1] and since it is removed from order line the error is encountered. Solution: - Changed the content of method `isCombo()` to use the product_template_id to make sure the Edit Configuration is only visible when product template is present. Similar PR for reference: https://github.com/odoo/odoo/pull/217464 [1]: https://github.com/odoo/odoo/blob/fa4307b9758800f26c9ee87cf3698fd60bfd1ab5/addons/sale/controllers/combo_configurator.py#L12-L14 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue that caused the Gantt chart to crash when event start or end dates were cleared. The fix ensures the Gantt calculation only runs when a valid date range exists, preventing errors related to comparing dates with boolean values. This improves the stability and reliability of event scheduling.
Original PR description
When removing the start or end date on an Event, the system raises a traceback during Gantt information computation. **Steps to Reproduce:** 1. Install `website_event_track_gantt` module. 2. Create a new Event. 3. Add at least one **Track** with a track **Date** and **Duration**. 4. In the Event form, clear the Start or End Date field. **Error:** `TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'` **Cause:** When the event start or end date is removed, those fields become False. During computation, the system attempts to compare these False values with the track dates (which are real datetimes), resulting in an invalid datetime-boolean comparison, causing the error. **Fix:** This commit ensures the Gantt calculation only executes when the event has a valid date range, avoiding comparisons that include missing values. no id Forward-Port-Of: odoo/enterprise#101541
This update resolves an issue where Odoo's logging system incorrectly handled complex log messages containing mappings. The fix moves the message formatting logic to the logger, ensuring accurate log output and preventing data loss. This improves the reliability of Odoo's logging and helps identify potential problems more effectively.
Original PR description
When `lower_logging` encounters a `LogRecord.args: Mapping`, it fucks up and strips out all the values keeping only the mapping keys (as a tuple), which then breaks when trying to format it in `LogRecord.msg`. Fix the issue by moving the entire message munging into, appropriately, the formatter: `getMessage` will do the `str.__mod__` call at which point we don't need to deal with the args at all, then `formatMessage` generates the full message line (not including the stack traces from `exc_info` and `stack_info`, those are added in the second half of `Formatter.format`). https://runbot.odoo.com/odoo/error/234669 Forward-Port-Of: odoo/odoo#239454 Forward-Port-Of: odoo/odoo#239410
This update removes a confusing measure from the Task Analysis report, preventing double-counting of time across tasks and subtasks. The change simplifies reporting by eliminating the 'Hours by Tasks (including subtask)' measure, ensuring more accurate project time tracking. This update is specific to version 18.0.
Original PR description
Steps to Reproduce --- Go to Project -> Reporting -> Task Analysis and switch to pivot view or graph view. Issue --- The "Hours by Tasks (including subtask)" measure duplicates due to the complicated hours counted on main task Current Behaviour --- Total time for a project is summed twice due to the inclusion of subtask hours in both parent and child tasks. Expected Behaviour --- Remove the measure Hours by Tasks ( including subtask) from both pivot and graph views. Fix --- Removed the "Hours by Tasks (including subtask)" measure from the Task Analysis report to avoid confusion. This change applies only to version 18.0. Related:https://github.com/odoo/odoo/pull/184934 task-5144487
This update fixes a potential user confusion during POS session closure. When a cashier isn't properly selected, a notification is now displayed, guiding the user to complete the process. This enhances the overall user experience and prevents errors.
Original PR description
After this commit, when attempting to close a POS session, if the logged-in employee is not selected, a notification will inform the user. This prevents confusion. opw-5244818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
4 changes
Resolved issues and error corrections
This update fixes an issue where very long text inputs in the Web Studio application would overflow and cause display problems. Now, long text fields are automatically truncated, ensuring a clean and usable experience for users. This prevents data loss and improves the overall stability of the Web Studio interface.
Original PR description
**Before this commit:** Long input text overflowed and was not truncated. **After this commit:** Long input text is now properly truncated, preventing overflow. task-5240113
This update resolves an issue where a previous odoo version would crash when a Many2one field contained an empty record. The change ensures the system gracefully handles empty records by returning 'False' instead of raising an error, preventing service disruptions.
Original PR description
In OCA we develop a module that assigns dynamic attributes to a product. In odoo 16.0 and prevous 14.0 the module is running smoothly with odoo. In this version convert_to_read method is introduced…
In OCA we develop a module that assigns dynamic attributes to a product. In odoo 16.0 and prevous 14.0 the module is running smoothly with odoo. In this version convert_to_read method is introduced and it deals with use_display_name and value, it assumes value record is always has a value Aluthough use_display_name can be False or value record can be empty. In that case I retun False instead of causing the server to raise error because it assumes value has id and it is just an empty recordset.
Description of the issue/feature this PR addresses:
Current behavior before PR:
========================================================================================
2025-02-19 20:15:58,724 46176 ERROR pim_17_1 odoo.http: Exception during request handling.
Traceback (most recent call last):
File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 2206, in __call__
response = request._serve_db()
^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 1782, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/service/model.py", line 133, in retrying
result = func()
^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 1809, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 2013, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/addons/base/models/ir_http.py", line 221, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 757, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/addons/web/models/models.py", line 86, in web_read
values_list: List[Dict] = self.read(fields_to_read, load=None)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/models.py", line 3557, in read
return self._read_format(fnames=fields, load=load)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/models.py", line 3770, in _read_format
vals[name] = convert(record[name], record, use_display_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/kobros/Workspace/odoo17/odoo/odoo/fields.py", line 3110, in convert_to_read
return value.id
^^^^^^^^
Attri
buteError: 'mail.thread' object has no attribute 'id'
========================================================================================
Desired behavior after PR is merged:
The method can just retun False if no condition is met.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update ensures that Thai VAT numbers entered into the system are valid. The system now checks that all Thai VAT numbers consist of exactly 13 digits, aligning with Thai regulations. This improves data accuracy and prevents incorrect VAT number entries.
Original PR description
**Description of the issue/feature this PR addresses:** This PR adds a validation method `check_vat_th()` to verify Thai VAT numbers. In Thailand, a VAT number must consist of exactly 13 numeric digits. **Desired behavior after PR is merged:** For partners with country set to Thailand, the system will only allow VAT numbers that are exactly 13 digits long. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug that caused invoices with journal items lacking labels to trigger error tracebacks. The fix ensures that all labels are treated as strings, defaulting to an empty string if a label isn't present, preventing the error and improving invoice validation stability. This change impacts the stock_account module.
Original PR description
Creating an invoice containing journal items without a label triggers a traceback because the code unconditionally slices the 'name' field (line.name[:64]) without ensuring it is not False. Since 'name' is not a required field on account.move.line, it must be safely handled.
This commit ensures that the label is always a string by falling back to an empty string when the value is missing.
Steps to reproduce the bug:
- Create a storable product
- Create an invoice:
- Add the product to the invoice
- Set any customer
- Go to the journal items tab
- Remove the label of the journal item corresponding to the product
- Try to validate the invoice
- A traceback is raised
opw-5360602