Thursday, December 11, 2025
36 changes · saas-18.4
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
This update resolves an issue where users were unable to set invalid default values for certain fields. Specifically, attempting to set an integer as a default date caused an error. The fix ensures that users cannot input incorrect data types as defaults, improving data integrity.
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#238539
Forward-Port-Of: odoo/odoo#225991This update resolves an issue where users with access to multiple companies but only one employee were unable to schedule themselves for planning slots in other companies. The fix restores the previous functionality, allowing all users with company access to utilize planning slots across their organizations. This ensures consistent planning capabilities for all users.
Original PR description
Since #91616, if a user has access to multiple companies but only has an employee in one, they are unable to assign themselves to a planning slot from a company other than that of their employee. This was not the case in previous versions and is causing issues in our internal db. To restore the previous behavior, any user with access to a company but only 1 employee will be able to assign themselves to slots of said company. opw-5163200 Forward-Port-Of: odoo/enterprise#101659
This update fixes an issue where the CAI expiration date format in delivery guide reports was incorrect. The change ensures that dates are displayed properly, improving the accuracy and clarity of reports for accounting and tax purposes. This resolves a reporting discrepancy related to Arabic tax regulations.
Original PR description
The CAI expiration date is not well formated in the delivery guide report. opw-5004345
This update allows the 'Emissions Stat' button to be displayed on a wider range of account moves, including Purchase Receipts, previously it was limited to specific invoice types. This expands the ability to track and report emissions data across all financial transactions, providing a more complete picture of our sustainability efforts.
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-5407761
Forward-Port-Of: odoo/enterprise#101906This update fixes a bug where the 'Other Expenses' account type wasn't displayed in the Balance Sheet report. The change was made to align the report with a recent addition to the system that simplifies expense tracking for vendors. This ensures all financial data is accurately reflected 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 Forward-Port-Of: odoo/enterprise#101591