Friday, August 29, 2025
18 changes
3 changes
Enhancements to existing features
Installing the Manufacturing app on very large databases is now less likely to run out of memory or time out. The setup process initializes existing stock movement data more efficiently, improving reliability for customers with high transaction volumes.
Original PR description
Description ----------- On large databases with millions of already existing `stock.move`, the post-install computation of compute stored fields can be time-consuming and memory intensive. This commit extends the pre_init_hook that was done in `mrp` to: - Speed up computation of `stock.move.is_done` - Implement SQL query to initialize `stock.move.manual_consumption`. Reference --------- opw-4980036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222299
Odoo now treats ZATCA's duplicate-submission response for Saudi B2C invoices as a successful send. This prevents invoices from remaining uncertain or blocked after a timeout when ZATCA had already received them.
Original PR description
ZATCA introduced a new response code (409) to handle duplicate invoice submissions for B2C. This is helpful because when the submission timesout, we are left unsure whether ZATCA successfuly received the invoice or not. The next time Odoo tries to send the same invoice, Zatca will respond with a 409 error if it was received earlier. In which case, we mark the invoice as successfully sent. A similar flow applies for B2B, with a response code of 208 for duplicate invoices. However, for B2B, ZATCA accepts the duplicate with a warning instead of an error, So the invoice gets marked as sent in Odoo, and no changes need to be done there. task-id: 4745275 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224478 Forward-Port-Of: odoo/odoo#223754
The shop floor now keeps track of the user's active work center when they leave and return through breadcrumbs. This prevents confusing changes in the displayed work centers and helps operators resume work in the same view, while preserving the existing behavior when opening from Manufacturing work centers.
Original PR description
Description of the issue/feature this PR addresses: Incoherent selection of workcenters when using the breadcrumbs to come back to the shopfloor app:…
Description of the issue/feature this PR addresses: Incoherent selection of workcenters when using the breadcrumbs to come back to the shopfloor app: https://drive.google.com/file/d/1C1nVdDHgCss7s7zyXDOpbMj0k79HlJBH/view?usp=drivesdk Current behavior before PR: When leaving the shopfloor app via a WO (WO setting -> Open MO), we set the a **context flag workcenter_id** in the the currentCaller.action.context to save the selected workcenter for breadcrumb logic. The same **context flag workcenter_id** is used in the Manufacturing/workcenters view, when clicking on a workcenter. However, the intended use of the **workcenter_id flag** is different: - 1 From Manufacturing: Open shop floor with **only** workcenter_id selected + visible (no other workcenters visible). - 2 From Shopfloor breadcrumb : Go to shop floor with all previous workcenters same as when leaving. Additionally the current logic for setting the workcenter_id flag from the MrpDisplay record currently handles only the selection of isMyWO ([PR](https://github.com/odoo/enterprise/pull/52258)) Desired behavior after PR is merged: Keep the same behavior when coming from Manufacturing/workcenters ([PR](https://github.com/odoo/enterprise/pull/67318)) but make sure the user come back to same view when leaving shopfloor and coming back via breadcrumbs. task: [4629641](https://www.odoo.com/odoo/project/966/tasks/4629641) I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#93345 Forward-Port-Of: odoo/enterprise#88073
1 change
Enhancements to existing features
The shop floor now remembers the last active work center when users leave and return via breadcrumbs. This keeps the view consistent while preserving the separate behavior for opening shop floor from Manufacturing work center screens.
Original PR description
Description of the issue/feature this PR addresses: Incoherent selection of workcenters when using the breadcrumbs to come back to the shopfloor app:…
13 changes
Enhancements to existing features
Projects created from templates can now automatically plan task dates based on the timing used in the original template. This helps teams start new projects with realistic schedules while still allowing the system to adjust dates to avoid conflicts.
Original PR description
This PR allows planning dates when a project is created from a template. The dates of the created tasks are calculated based on the dates of the task in the template project. Tasks will be scheduled based on the elapsed time between the start of the project and the start of the task in the template. Tasks are scheduled using the smart scheduling algorithm, so the time ranges might not be exact to avoid conflicts, etc. If the template doesn't have planned dates, tasks will be simply scheduled from the start of the created project (or today) using the smart scheduling. Task-4700745
1 change
Enhancements to existing features
The Turkish Nilvera integration now syncs more invoice types, including E-Archive documents and invoices created directly in Nilvera. Users can retrieve statuses and PDFs from one renamed "Sync with Nilvera" action, with documents shown in previews and attached to the invoice chatter.
Original PR description
[IMP] l10n_tr_nilvera_einvoice: refactor API to include E-Invoices & E-Archive Fixed bugs in API calls triggered during fetch requests and added support for fetching the status of E-Archive files. Updated the action button label to "Sync with Nilvera", which now fetches invoice statuses, retrieves PDFs for both E-Archive and E-Invoices, and includes invoices generated directly in Nilvera, enabling support for additional invoice types currently not supported in Odoo. Invoices/Bills are marked as "Successful" once retrieved. Retrieved PDFs are displayed in the preview and automatically attached to the chatter. The original limit of fetching a maximum of 30 records (status and PDFs) is maintained. task-4714467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Description of the issue/feature this PR addresses: Incoherent selection of workcenters when using the breadcrumbs to come back to the shopfloor app: https://drive.google.com/file/d/1C1nVdDHgCss7s7zyXDOpbMj0k79HlJBH/view?usp=drivesdk Current behavior before PR: When leaving the shopfloor app via a WO (WO setting -> Open MO), we set the a **context flag workcenter_id** in the the currentCaller.action.context to save the selected workcenter for breadcrumb logic. The same **context flag workcenter_id** is used in the Manufacturing/workcenters view, when clicking on a workcenter. However, the intended use of the **workcenter_id flag** is different: - 1 From Manufacturing: Open shop floor with **only** workcenter_id selected + visible (no other workcenters visible). - 2 From Shopfloor breadcrumb : Go to shop floor with all previous workcenters same as when leaving. Additionally the current logic for setting the workcenter_id flag from the MrpDisplay record currently handles only the selection of isMyWO ([PR](https://github.com/odoo/enterprise/pull/52258)) Desired behavior after PR is merged: Keep the same behavior when coming from Manufacturing/workcenters ([PR](https://github.com/odoo/enterprise/pull/67318)) but make sure the user come back to same view when leaving shopfloor and coming back via breadcrumbs. task: [4629641](https://www.odoo.com/odoo/project/966/tasks/4629641) I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#93244 Forward-Port-Of: odoo/enterprise#88073
This update makes account return and audit screens clearer and more reliable for users. It fixes navigation and display issues, adds better completion notifications, uses more appropriate dates during setup, and helps prevent duplicate return creation.
Users can now download TDS and TCS tax reports directly as Excel files instead of manually selecting export fields. The file includes the relevant return-filing information and is grouped by section to make review and filing easier.
Original PR description
Receives many feedback from the users that they currently exports report by manually selecting fields to file TDS & TCS return. The problem is many users are unaware of how to export it with existing fields. With this commit, users can now directly download the Excel file from the TDS/TCS Tax report, which includes all the relevant fields needed for filing TDS/TCS returns. Additionally, the XLSX file is grouped by section to make it easier to read. task-4945885 COM PR: https://github.com/odoo/odoo/pull/220707
VoIP call transcription now handles failed uploads more reliably, so users see the correct status instead of calls getting stuck as pending. Calls can also show a short transcript summary and clearer status banner, with demo examples and broader tests added to improve confidence.
Original PR description
Following up on the quick merge of the voip transcription aa5983efc390dc16cff3ee99a55a8878d6e06939 We are improving its state by modifying: **Controller**: doesn't raise errors anymore, returns http…
Following up on the quick merge of the voip transcription aa5983efc390dc16cff3ee99a55a8878d6e06939 We are improving its state by modifying: **Controller**: doesn't raise errors anymore, returns http err codes, keeping transcription_status persist errors (ref.1) **Tests**: added backend controller tests and cron tests covering happy paths and edge cases. (ref.2) **Summary**: added one_liner_summary filed on the voip call, which is generated after successful transcription; (if it fails we still have transcription) **Banner**: Previously we informed user about the transcription_status with a selection field in a view. Now it is replaced by a status banner at the top of the form view **Demo**: added some demo calls to showcase calls in all transcription_status. (ref.3) (ref.1) Without it: when we have an error in the request to transcribe it will rollback the transaction. Example: Controller is asked to transcribe, it can't because the file is too big, so it sets transcription_status=too_big_to_process **and raises**. This revers the transaction resulting in transcription_status set to pending. BAD (ref.2) To avoid gymnastic of creating second cursor for the sake of testing cron try to commit, we restrict committing so it doesn't happen in the test_mode. Subsystem testing covers those <img width="1139" height="408" alt="image" src="https://github.com/user-attachments/assets/90736892-58ce-4a15-b28d-bb8bf4369888" />
Payroll salary rules are now treated as updateable configuration, making it easier to keep standard payroll logic aligned during upgrades. Businesses that need custom payroll behavior should create or duplicate their own rules so those customizations remain protected during migrations.
Original PR description
Purpose ======= Rules that are supposed to be customized and kept over migrations should be created by hand, or duplicated from existing structures.
Employee records now show the official contract type separately from the payroll salary structure category. This helps HR teams keep legally or officially named contracts visible while still seeing the payroll classification needed for compensation processing.
Original PR description
This change ensures that official contract names remain visible while clearly distinguishing them from the salary structure category. task-5013761
Employee work schedule handling has been simplified by removing start and end date limits from resource attendance records. This reduces configuration complexity and supports cleaner payroll and scheduling processes, including Belgian payroll version handling.
Original PR description
Removed date_from and date_to fields for simplification Task: 4929940
This update improves how decimal numbers are displayed and handled by ensuring float fields can keep a minimum number of digits. It helps maintain consistent precision in accounting, payroll, delivery, point of sale, quality, and electronic invoicing workflows, reducing formatting inconsistencies across documents and integrations.
Original PR description
task-4895014
Partner ledger and related customer follow-up reports now include reconciliation date information, giving finance teams clearer context on payments and outstanding balances. This helps users review customer accounts more accurately and align follow-up actions with the latest reconciliation status.
The partner ledger now supports an additional closing date filter, making it easier to view open items up to a specific date. This helps finance teams produce more precise partner balance and reconciliation reports.
Payroll configurations for Jordan and Saudi Arabia now include the missing account mappings for salary rules. This helps ensure payroll entries are posted to the correct accounting accounts, reducing manual corrections and improving reporting accuracy.
Original PR description
xx: jo, sa In this commit we add the maping for all the salary rules accounts Taks: 4882398
Spreadsheet list headers are now kept consistent across user languages, so pivots based on lists continue to work when a spreadsheet is opened by colleagues using a different language. Several spreadsheet dashboard files were also reformatted to make future updates cleaner without changing their business content.
Internal VoIP calls made using extension numbers are now matched to the corresponding Odoo user. This helps employees recognize who is calling instead of seeing only an extension number.
Original PR description
**Purpose:** Improve the user experience by identifying internal calls made using extension numbers (voip usernames) by displaying the corresponding user's name. **Specification:** Enhance the get_contact_info method in the voip.call model to resolve internal extensions by matching the call's phone_number with the voip_username field on res.users. **Task**-4997542