Daily updates from Odoo
Navigate
Branch
Friday, April 10, 2026
251 changes
9 changes
Resolved issues and error corrections
This update resolves an issue where certain actions were unintentionally disabled on locked spreadsheets. The change re-enables these actions, improving usability and functionality for users working with spreadsheet data. This ensures users can perform necessary tasks within the spreadsheet environment.
Original PR description
Some actions were mistakenly disabled on locked sheet. This commit re-enable them. Task: [6033269](https://www.odoo.com/web#id=6033269&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This update removes a leftover reference to a previously removed reporting code. The 'KMD INF Report (EE)' account type was removed in the saas-19.2 release, and this change ensures the system is clean and efficient. This is a routine maintenance fix.
Original PR description
The account_return_type record 'KMD INF Report (EE)' (l10n_ee_reports.ee_kmd_inf_tax_return_type) was removed [here](https://github.com/odoo/enterprise/pull/98471/changes#diff-73727ce6b3fc23788e37d59fb9160d29158b84e7f082db85b6732a731e814a42L11), but its reference code still existed in the condition. opw- 6056471
This fix resolves an issue where the bank reconciliation process would fail when using the liquidity account as an outstanding payment account. The update prevents automatic reconciliation attempts in this scenario, ensuring data integrity and preventing the form from becoming unsavable. This improves stability for users managing transactions with liquidity accounts.
Original PR description
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity…
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity account - Go to the Transactions of the Journal - Add a new Transaction for partner X and amount Y - Add a second Transaction also for partner X and amount Y # The issue A popup appears that can never be saved # Cause When we click on "Add & New" or "Add & Close", we run the `validate()` function : https://github.com/odoo/enterprise/blob/9abb50b9b29e01897b4fb90ae228beecbdfcd5af/account_accountant/static/src/components/bank_reconciliation/quick_create/quick_create.xml#L14-L16 Which tries to do a model save, but it fails so it show the Form dialog : https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/web/static/src/views/kanban/kanban_record_quick_create.js#L159-L163 The save fails because : This commit (https://github.com/odoo/enterprise/commit/e2b3439dcda26f84b9a290c8d5fb819dd3250825) changed the the logic behind auto-reconcilation with an outstanding account. When there is an outstanding account, we try to auto-reconcile the bank statement with that account and succesfully do so : https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L381-L385 https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L245 But this should not happen when the outstanding account is the liquidity account, because it will end up throwing an error when the amount is matched more than once: https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/account/models/account_bank_statement_line.py#L727-L737 opw-6063654 Forward-Port-Of: odoo/enterprise#113358 Forward-Port-Of: odoo/enterprise#112750
This update fixes an issue where Odoo incorrectly consumed stock from the wrong location when scanning serial numbers on Manufacturing Orders. Previously, the system prioritized a default location, leading to inaccurate stock tracking. This change ensures the correct warehouse location is always selected, improving inventory accuracy and preventing costly errors.
Original PR description
Steps to reproduce: - Create a Manufacturing Order with a serial-tracked component. - Open the Shop Floor. - Scan the serial number barcode to register the component. - Observe which location the component was consumed from. Issue: When a product is received from a vendor, Odoo creates two quants for the same serial number — one at Partners/Vendors location and one at WH/Stock location. Because get_quant_from_barcode searched for a matching serial number with no location filter, it returned whichever quant had the lowest database ID — which was always the Partners/Vendors or Production quant created first — instead of the correct WH/Stock quant. Solution: Prevent selecting a quant from an incorrect location when multiple quants exist for the same serial number, as this can lead to consuming stock from the wrong location. opw-5974474 Forward-Port-Of: odoo/enterprise#113210 Forward-Port-Of: odoo/enterprise#112691
This update resolves an issue where the payment report screen incorrectly attempted to create a new Company Autopay Account without a designated partner. The fix disables this automatic creation, ensuring accurate bank account setup. Adding a new related field to set the company partner was deemed unnecessary for this specific workflow.
Original PR description
Disable creating a new Company Autopay Account from the payment report screen, as it doesn't work without a default partner in the context. Setting the partner to the company one would be another solution, but it requires adding a new related field which may not be worth it for this flow only. task-6098463
This update fixes an error in the Pakistan localization payroll calculation. Specifically, the tax amount was being incorrectly calculated for employees with annual salaries exceeding 2.2 million PKR. The fix ensures accurate tax calculations based on official Pakistani tax regulations, preventing overpayment of taxes.
Original PR description
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install…
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install `l10n_pk_hr_payroll_account`,`hr_contract_salary` with demo data. 2) Switch to PK company. 3) Create an employee and a running contract with yearly cost 2,200,001 4) Create a payslip and compute it from the Salary Computation tab. ### **Observed Behavior:** 'Tax Bracket Yearly' is computed as `122000.24` ### **Expected Behavior:** 'Tax Bracket Yearly' should be `116000.24` ### **Root Cause:** since [commit](https://github.com/odoo/enterprise/pull/98345/commits/62f5e216518d83317618d7dbc0be4db92d1881a3), the tax computation relies on [_l10n_pk_get_tax](https://github.com/odoo/enterprise/blob/a9656336583a4d5c5b12d4d6120ec62ba1cf9151/l10n_pk_hr_payroll/models/hr_payslip.py#L9-L20) , In this method, the `result` is incorrectly accumulated with `fix` when iterating through brackets, leading to an inflated tax value. [official pakistan document](https://download1.fbr.gov.pk/Docs/20258181281745641WHT-RateCard.pdf) ### **Fix:** Use `result = fix` instead of `result += fix` so that the cumulative tax is correctly reset at each bracket. **opw-5979265** Forward-Port-Of: odoo/enterprise#112726 Forward-Port-Of: odoo/enterprise#110939
This update fixes an issue where rental shift statuses weren't updating correctly after confirming a rental order. The system now automatically marks shifts as 'published' when a rental order is created, ensuring accurate status tracking and consistency with the user interface. This improves the reliability of rental planning workflows.
Original PR description
**Issue 1** **Steps to Reproduce:** Create a shift in Planning. Click New Order. Save and confirm the rental order. Check the shift in Planning it is still in draft. **Issue:** The shift stays in draft even after the rental order is confirmed. **Cause** When creating a rental order from a shift, the shift is not marked as planned. It only gets linked to the order after saving, so it never updates its status. **Fix:** Mark the shift as published when confirming a new rental order. This makes the shift show the correct status right away and keeps it consistent with the “Add to Last Order” button. task-5075839 Forward-Port-Of: odoo/enterprise#112702 Forward-Port-Of: odoo/enterprise#99642
This update resolves an issue where material resources with assigned roles were still visible when filtering by employees in the Planning app. The fix improved the filter logic to accurately exclude these resources, ensuring that only employee-type resources and those without assigned roles are displayed. This improves the accuracy of the Planning view.
Original PR description
Steps to Reproduce: 1. Open the Planning app. 2. Go to Configuration -> Materials. 3. Set a role on either the demo material resource laptop or toolkit. 4. Go back to the Planning view. 5. Apply the view filter employee (filter by Employees). Issue: The material resource with a role should not be visible, but it is still present. Current behaviour: When filtering the Planning view by Employees, material resources with an assigned role remain visible. Expected behaviour: Material resources with an assigned role should be excluded from the Planning view when filtered by Employees — only employee-type resources and resources on which role is not set should appear. Fix: Improved the filter domain so unnecessary data are excluded. Task-4526989 Forward-Port-Of: odoo/enterprise#92816
This update resolves a bug that prevented the random tour feature within the industry_fsm report module from functioning correctly. The fix, triggered by a runbot test, ensures that users can now consistently access and utilize the random tour functionality as intended. This improves the usability of the industry_fsm reporting tools.
Original PR description
runbot issue-242264 Forward-Port-Of: odoo/enterprise#113483 Forward-Port-Of: odoo/enterprise#113272
9 changes
Enhancements to existing features
This update optimizes how Odoo searches for calendar resources, specifically when filtering by user. By adding an index, the system now responds more quickly to these searches, leading to a smoother user experience. This change focuses on internal performance improvements.
Original PR description
This commit adds an index on `planning.calendar.resource.user_id`, as it's the only criteria used in `get_calendar_filters` for the `search_count` and the `search_read` done after. Forward-Port-Of: odoo/enterprise#113304
Resolved issues and error corrections
This update resolves a test failure within the Odoo Enterprise accounting module. The issue stemmed from incorrect data values during testing, specifically related to payment processing and multi-bill statements. This ensures the accounting tests run reliably and accurately.
Original PR description
Fixup for test test_early_payment_discount_multi_bill_statement that will fail when accountant is not installed due to mismatched amls values opw-5881976 Forward-Port-Of: odoo/enterprise#113425
This update fixes a reporting issue where the employee sick leave warning incorrectly flagged employees with long absences before 31 days. The change now accurately identifies employees who have been on sick leave for at least the past 31 days, ensuring more accurate reporting for payroll and HR compliance.
Original PR description
-**Issue**: The warning shows employees who had a long sick leaves before 31 days, which is incorrect. -**Fix**: Adjust the logic to include employees who have been on a sick leave for the past 31 days (at least). Forward-Port-Of: odoo/enterprise#113249 Forward-Port-Of: odoo/enterprise#112985
This update resolves an issue where automatic bank reconciliation failed when using the liquidity account as an outstanding payment account. The fix prevents a save error by correctly handling reconciliation logic, ensuring transactions involving the liquidity account can be processed without causing the form to become un-saveable.
Original PR description
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity…
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity account - Go to the Transactions of the Journal - Add a new Transaction for partner X and amount Y - Add a second Transaction also for partner X and amount Y # The issue A popup appears that can never be saved # Cause When we click on "Add & New" or "Add & Close", we run the `validate()` function : https://github.com/odoo/enterprise/blob/9abb50b9b29e01897b4fb90ae228beecbdfcd5af/account_accountant/static/src/components/bank_reconciliation/quick_create/quick_create.xml#L14-L16 Which tries to do a model save, but it fails so it show the Form dialog : https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/web/static/src/views/kanban/kanban_record_quick_create.js#L159-L163 The save fails because : This commit (https://github.com/odoo/enterprise/commit/e2b3439dcda26f84b9a290c8d5fb819dd3250825) changed the the logic behind auto-reconcilation with an outstanding account. When there is an outstanding account, we try to auto-reconcile the bank statement with that account and succesfully do so : https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L381-L385 https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L245 But this should not happen when the outstanding account is the liquidity account, because it will end up throwing an error when the amount is matched more than once: https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/account/models/account_bank_statement_line.py#L727-L737 opw-6063654 Forward-Port-Of: odoo/enterprise#113358 Forward-Port-Of: odoo/enterprise#112750
A bug was preventing users from deleting timesheets when a confirmation dialog was open. Pressing the Enter key instead started the timer. This update ensures that pressing Enter now correctly confirms the deletion dialog, resolving a frustrating user experience issue.
Original PR description
When a delete confirmation dialog is open in the timesheet list view, pressing Enter starts/stops the timer instead of confirming the dialog. This happens because the timer's window keydown handler does not check for active modals before intercepting the Enter key. Add a `.modal` check consistent with the grid renderer's onKeyDown. Steps to reproduce: 1) Open timesheet list view 2) Select a record and delete it 3) When the confirmation dialog opens, hit ENTER key Current behavior: The Timer starts recording timesheet Expected behavior: The record should be deleted For ref: https://youtu.be/tzm_3RNe1ig Forward-Port-Of: odoo/enterprise#113207 Forward-Port-Of: odoo/enterprise#112583
This update resolves a technical glitch that was occasionally preventing the automated 'random tour' feature within the industry_fsm reports from running correctly. The fix, identified by a runbot issue, ensures that users can consistently access and utilize this helpful guide for navigating the FSM reports. This improves the user experience and efficiency.
Original PR description
runbot issue-242264 Forward-Port-Of: odoo/enterprise#113272
This update resolves an issue where material resources with assigned roles were incorrectly displayed when filtering by employees in the Planning app. The fix improves the filter domain to accurately exclude these resources, ensuring that only employee-type resources are shown when using the employee filter.
Original PR description
Steps to Reproduce: 1. Open the Planning app. 2. Go to Configuration -> Materials. 3. Set a role on either the demo material resource laptop or toolkit. 4. Go back to the Planning view. 5. Apply the view filter employee (filter by Employees). Issue: The material resource with a role should not be visible, but it is still present. Current behaviour: When filtering the Planning view by Employees, material resources with an assigned role remain visible. Expected behaviour: Material resources with an assigned role should be excluded from the Planning view when filtered by Employees — only employee-type resources and resources on which role is not set should appear. Fix: Improved the filter domain so unnecessary data are excluded. Task-4526989 Forward-Port-Of: odoo/enterprise#92816
This update fixes an issue where Odoo incorrectly selected stock locations when scanning serial numbers on Manufacturing Orders. Previously, the system favored a location created first, leading to potential stock discrepancies. This change ensures the correct warehouse location is always used, improving inventory accuracy.
Original PR description
Steps to reproduce: - Create a Manufacturing Order with a serial-tracked component. - Open the Shop Floor. - Scan the serial number barcode to register the component. - Observe which location the component was consumed from. Issue: When a product is received from a vendor, Odoo creates two quants for the same serial number — one at Partners/Vendors location and one at WH/Stock location. Because get_quant_from_barcode searched for a matching serial number with no location filter, it returned whichever quant had the lowest database ID — which was always the Partners/Vendors or Production quant created first — instead of the correct WH/Stock quant. Solution: Prevent selecting a quant from an incorrect location when multiple quants exist for the same serial number, as this can lead to consuming stock from the wrong location. opw-5974474 Forward-Port-Of: odoo/enterprise#113210 Forward-Port-Of: odoo/enterprise#112691
Code cleanup and technical improvements
This update adjusts how attendance analysis reports calculate costs, specifically incorporating hourly rates associated with each employee. This ensures more accurate tracking of labor expenses within the attendance reports, improving the reliability of time and attendance data. The change was made to align with a new employee versioning model.
Original PR description
Update the attendance analysis report initial query according to the hourly_cost change. **PR com**: https://github.com/odoo/odoo/pull/258081 task-6098429
5 changes
Resolved issues and error corrections
This update fixes an issue where the Helpdesk return wizard incorrectly displayed receipt operations alongside delivery operations. The fix specifically excludes receipts from the wizard's domain, ensuring users only see eligible deliveries for returns. This improves the accuracy and usability of the return process.
Original PR description
Steps to reproduce: - 1. Create a Sale Order for a customer and fully process the delivery. 2. Create a Helpdesk ticket for that customer. 3. From the ticket, click the 'Return' button to open the wizard. 4. Select the sales order or open the 'Delivery to Return' dropdown. Issue: - The list of available pickings shows both receipts and deliveries operations. Fix: - The domain for the return wizard is updated to explicitly exclude receipts. Note: - This bug is present until saas-18.4. From 19.0 onward it is already fixed in this PR: https://github.com/odoo/enterprise/pull/90371 task-5075205 Forward-Port-Of: odoo/enterprise#95418
This update resolves a problem where the automated tour generation feature in the industry_fsm module was failing intermittently. The fix, triggered by a runbot test, ensures the tour consistently runs as expected, improving the reliability of this onboarding tool. This prevents potential user frustration and ensures a smoother experience for new users.
Original PR description
runbot issue-242264 Forward-Port-Of: odoo/enterprise#113272
This update fixes a misleading warning in the employee health dashboard. Previously, the warning incorrectly flagged employees with sick leaves exceeding 31 days before the cutoff date. The change now accurately identifies employees who have been on sick leave for at least the past 31 days, providing a more reliable view of employee health status.
Original PR description
-**Issue**: The warning shows employees who had a long sick leaves before 31 days, which is incorrect. -**Fix**: Adjust the logic to include employees who have been on a sick leave for the past 31 days (at least). Forward-Port-Of: odoo/enterprise#113249 Forward-Port-Of: odoo/enterprise#112985
This update resolves a test failure in the account accounting module that occurred when the accountant component wasn't active. The fix addresses a mismatch in data values, ensuring the test now consistently passes and the accounting functionality remains stable. This prevents potential disruptions to financial reporting.
Original PR description
Fixup for test test_early_payment_discount_multi_bill_statement that will fail when accountant is not installed due to mismatched amls values opw-5881976 Forward-Port-Of: odoo/enterprise#113425
Code cleanup and technical improvements
This update adjusts how hourly costs are handled for employee attendance tracking. Moving the hourly cost to the employee versioning model ensures more accurate calculations in reports, particularly for employees with varying rates. This improves the reliability of attendance analysis and forecasting.
Original PR description
Update the attendance analysis report initial query according to the hourly_cost change PR com: https://github.com/odoo/odoo/pull/258077 task-6098429
16 changes
Resolved issues and error corrections
This update fixes a tax-related issue where invoices displayed multiple company names (like 'X, Y') when using a child contact. This ensured invoices comply with tax regulations by clearly identifying the correct recipient, preventing potential input tax deduction denials. The change updates the display of delivery addresses on invoices.
Original PR description
If two GmbH (Ltd.) names appear in the invoice address field (e.g., "Proveco GmbH, Test GmbH"), the invoice is problematic from a tax perspective, as two GmbH are considered separate legal entities, and it is not clearly identifiable who the actual recipient of the service is. Consequently, the tax office can refuse the input tax deduction if the invoice recipient is not clearly identifiable. Steps: - Create a company contact (X) and a delivery address (Y) - Create an invoice for X, delivery address will be Y - Open preview -> The delivery partner's display name is 'X, Y', it should be only 'Y' Fix: Adding a context key to the invoice document to conditionally display the parent contact name in the display_name Ticket [link](https://www.odoo.com/odoo/project.task/5900567) opw-5900567 Forward-Port-Of: odoo/odoo#258317 Forward-Port-Of: odoo/odoo#257652
This update fixes an issue where the product name displayed in purchase order lines would change when navigating between pages. The fix ensures the product name remains consistent across all purchase order lines, improving clarity and accuracy for users. It corrects a technical problem related to how data is fetched and displayed in the purchase order interface.
Original PR description
**Steps to reproduce:** * Install the *Purchase* module * Create a product and set an *Reference* and Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*. * Create a Purchase…
**Steps to reproduce:** * Install the *Purchase* module * Create a product and set an *Reference* and Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*. * Create a Purchase Order with the same vendor set as on the product. * Add the configured product to the *Purchase Order Lines*. * Add the same product again on a second line and save the order. * Activate debug mode * Go to the view:Form and add a limit to have only 1 POL per page * Return to your PO * Go to the second page **Observed behavior:** * The *product display name* in the purchase order lines is different on the second page compared to the first page. **Cause:** * On the first page, purchase order lines are fetched via a web_read on the purchase order. * On subsequent pages, lines are fetched via a web_read directly on the purchase order lines. * The client requests both name and product_id.display_name. product field context includes partner_id, causing product_id.display_name to be computed as the vendor name. * As both values resolve to the vendor name, the original product name is lost, leading to inconsistent display across pages. **Note:** A similar issue was addressed in this commit : https://github.com/odoo/odoo/commit/28d53e0e565e266ca3fa2b67e359b4383fa42c36 * but its consequence it breaks the search using the vendor code/name in POL. * That change was reverted in this commit duo to the there consequence : https://github.com/odoo/odoo/commit/c9e8a802315be27a076ae677b9191c075e4c239d **Fix:** * This ensures the product name is propagated correctly in the form view while preserving search by vendor code or name. --- opw-5170924 Forward-Port-Of: odoo/odoo#240515
This update corrects a reporting issue where employee leave balances incorrectly displayed outdated department information. The fix ensures that leave balances always reflect the employee's current department, resolving duplicate entries in reports and providing accurate data for payroll and HR analysis. This improvement enhances the reliability of our leave reporting functionality.
Original PR description
Steps to reproduce: ------------------------- 1. Install the Time Off module. 2. Go to Time Off > Management > Allocations, create an allocation for an employee, and approve it. 3. Go to Reporting >…
Steps to reproduce: ------------------------- 1. Install the Time Off module. 2. Go to Time Off > Management > Allocations, create an allocation for an employee, and approve it. 3. Go to Reporting > Balance and apply the filter Department > Employee. 4. Change the employee’s department. 5. Create an allocation for the same employee and approve. 6. Apply the Department > Employee filter again. Observed behaviour: ---------------------------- After a department change: * Existing allocations keep the old department * New allocations use the new department As a result, duplicate employee entries appear in the report Cause: ---------- It is using [allocation.department_id.](https://github.com/odoo/odoo/blob/4c91eb3b2469cd04718005162b4572e9e3d07e72/addons/hr_holidays/report/hr_leave_employee_type_report.py#L62) Allocations store the department at creation time, which may differ from the employee’s current department, causing an incorrect report filtering. Solution: ------------ Fetch department_id from hr_employee instead of hr_leave_allocation in the hr_leave_employee_type_report and hr_leave_report. This ensures: * Leave balances always follow the employee’s current department * Correct aggregation when grouping by Department → Employee **NOTE:** Before this [commit](https://github.com/odoo-dev/odoo/commit/976e0f9a667f4573e73e33737425d370ec1e1452), the issue was resolved starting from version saas-18.4, as the balances were filtered using the employee's department (via `hr_version`). https://github.com/odoo/odoo/blob/104a33f093ca583c91db9705f087c73d8464c173/addons/hr_holidays/report/hr_leave_employee_type_report.py#L65-L74 related commit: https://github.com/odoo/odoo/commit/21f18b1a6fdbf1a01c3dda83acfa66addd01a759 Since `hr_version` is no longer used in the query, this issue needs to be addressed again and forward-ported to all versions up to master. Before: <img width="1238" height="857" alt="image" src="https://github.com/user-attachments/assets/15e1293b-dc50-4067-a12f-079c046c2074" /> After: <img width="1247" height="824" alt="image" src="https://github.com/user-attachments/assets/feea32de-0d9c-4eef-9ae5-639f4658560c" /> opw-5220577 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243076
This update fixes an issue where sales invoice email notifications incorrectly displayed a zero amount and a missing record reference. The fix ensures that the correct invoice amount and record details are sent to the salesperson, improving the accuracy of email communications. This impacts sales order processing and reporting.
Original PR description
Steps to produce: --- - Install `Sales` module. - Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab. - Confirm the sale order and create an invoice. Issue:…
Steps to produce: --- - Install `Sales` module. - Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab. - Confirm the sale order and create an invoice. Issue: --- - In the email notification sent to the salesperson, the record reference displays as False and the amount shows as 0.00. Root cause: --- - Here at [1], the record name is False because the invoice is still in draft state. - In [18], _sync_invoice sets amount_currency = line.balance for new lines, but balance is precomputed as 0 before the INSERT because _compute_balance returns 0 for invoice lines. In [17] it read price_subtotal directly, which is always correct. - In 17.0 the same mail fires at the same moment, but _sync_invoice had already set balance = −295 and amount_currency = −295 from price_subtotal, so the email reads the correct 295.00. Solution: --- - Use record.display_name instead of record.name, as display_name is always present regardless of the record state. - Use the tax totals amount instead of amount_total, which is not yet computed on draft invoices. [1]https://github.com/odoo/odoo/blob/0bcc34ec2f92b9b95cde321423d810002bb317ce/addons/account/models/account_move.py#L6478 [18]https://github.com/odoo/odoo/blob/b0a50104a12b205958316d382b4c7b2176395877/addons/account/models/account_move_line.py#L1566-L1610 [17]https://github.com/odoo/odoo/blob/73c076893de79df5a86aa970fde46a7aacbeaf3d/addons/account/models/account_move_line.py#L1536-L1585 Before: --- <img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/48c2dc03-765a-49c3-bad3-fd0b14405786" /> After: --- <img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/53682171-155f-46b3-85dd-0c7c98482067" /> opw-6023827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254862
This update fixes an issue where the Helpdesk return wizard incorrectly displayed receipt operations alongside delivery operations. The fix specifically excludes receipts from the wizard's domain, ensuring users only see eligible deliveries for returns. This improves the accuracy and usability of the return process.
Original PR description
Steps to reproduce: - 1. Create a Sale Order for a customer and fully process the delivery. 2. Create a Helpdesk ticket for that customer. 3. From the ticket, click the 'Return' button to open the wizard. 4. Select the sales order or open the 'Delivery to Return' dropdown. Issue: - The list of available pickings shows both receipts and deliveries operations. Fix: - The domain for the return wizard is updated to explicitly exclude receipts. Note: - This bug is present until saas-18.4. From 19.0 onward it is already fixed in this PR: https://github.com/odoo/enterprise/pull/90371 task-5075205 Forward-Port-Of: odoo/enterprise#95418
This update resolves a technical problem with the formatting of data within the marketing card module. Specifically, a malformed XML tag was causing errors. This fix ensures that marketing campaigns are processed correctly, preventing potential disruptions to email campaigns and data accuracy.
Original PR description
This commit fixes a malformed HTML/XML tag in CardCampaign. Note: before libxml2 v2.14.0, this issue was automagically cleaned up, but not anymore. Forward-Port-Of: odoo/odoo#258388
This update corrects a bug that prevented KPI cards (Billable Hours, etc.) from accurately reflecting timesheet data when global filters were applied. The issue stemmed from a hardcoded filter limiting data to a single user. Removing this restriction ensures KPI cards display correct data based on selected filters.
Original PR description
Steps to reproduce: - 1. Go to the dashboard app > Timesheets. 2. Apply any global filter. Issue: - The main KPI cards (Billable Hours, Non-billable Hours, Billable Rate) do not update correctly when any global filter is applied. Filtering by 'Employee' causes the cards to show zero. Other filters like 'Project' or 'Department' show incomplete and incorrect data, reflecting only the timesheets of a single hardcoded user. Cause: - The pivot tables (`pivot 5` and `pivot 6`) that source the data for the KPI cards contained a hardcoded domain `['user_id', '=', 2]`. This condition changes any selection made in the global filter and shows incorrect data. Fix: - The hardcoded `['user_id', '=', 2]` condition has been removed. task-4782213 Forward-Port-Of: odoo/odoo#258200 Forward-Port-Of: odoo/odoo#224810
This update fixes an issue related to how accounting data is handled for multiple companies within the Odoo system. Specifically, it ensures that company-specific information is correctly used when processing accounts for Danish businesses (l10n_dk). This improves the accuracy and reliability of financial reporting for businesses operating in Denmark.
Original PR description
Fixes https://github.com/odoo/odoo/pull/257623. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257852
This update resolves an issue where Chrome processes weren't completely shutting down, leading to potential disruptions in Odoo's operation. By ensuring all Chrome subprocesses are terminated, we prevent lingering connections and errors that could impact performance and stability. This is a critical fix to maintain a smooth user experience.
Original PR description
It's not clear when it started to happen (possibly forever), but apparently waiting for the main chrome process to terminate does not ensure all subprocesses are also terminated. Depending how long these subprocesses stick around, this can lead to: - remaining http or websocket requests - the inability to delete or re-creation of the user directory - possibly other confusing situations Update the chrome termination flow to make sure every subprocess is gone before proceeding to the next step. Kinda-sorta backport of #258062 Forward-Port-Of: odoo/odoo#258069
This update fixes an issue where archived warehouses were incorrectly included when creating quotations from Contacts. The change ensures that only active warehouses are considered, resolving a potential confusion for users and improving data accuracy. This was caused by a misconfiguration in how the system determines warehouse selection.
Original PR description
Currently, when a user creates a quotation from the Opportunities available in Contacts, archived warehouses are also considered for the quotation. ## Steps to replicate: - Install Sales, CRM, and…
Currently, when a user creates a quotation from the Opportunities available in Contacts, archived warehouses are also considered for the quotation.
## Steps to replicate:
- Install Sales, CRM, and Inventory.
- Create a new Warehouse and move it to the first position in the warehouse list view (highest priority).
- Archive the newly created warehouse.
- Navigate to Contacts > Acme Corporation > Opportunities >Office Design Project
- New Quotation > Other Info > Delivery and check the Warehouse field.
## Observed behavior
The archived warehouse is still assigned to the Warehouse field in the Delivery section. This issue does not occur when the user creates a quotation directly from the CRM app, it only happens when the quotation is created through the Contacts apps.
## Root cause:
This unintentional behavior was introduced after commit [1]. When a user opens 'Opportunities' from the contacts view, the function `action_view_opportunity` [2] is triggered, which sets `active_test` to False in the context.
Later, when a new quotation is created, the compute method [3] is executed. This method calls `_get_default_warehouse_id` [4], which performs a search. Because `active_test` is already set to False in the context, the search also includes archived warehouses, causing them to be fetched unintentionally.
[2]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/crm/models/res_partner.py#L39-L53 [3]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/sale_stock/models/sale_order.py#L194-L204
[4]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/stock/models/res_users.py#L9-L12
## Solution:
Explicitly set `active_test=True` in the context when preparing the quotation for an opportunity. This ensures that archived warehouses are excluded from the search and prevents them from being selected.
**Alternate Solution:**
We could also make `active_test` to true when searching for warehouse directly as well.
```py
def _get_default_warehouse_id(self):
# !!! Any change to the following search domain should probably
# be also applied in sale_stock/models/sale_order.py/_init_column.
return self.env['stock.warehouse'].with_context(active_test=True).search([('company_id', '=', self.env.company.id)], limit=1)
```
[1]:
https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717
opw-5999034
Forward-Port-Of: odoo/odoo#252166This update resolves an issue where importing invoices could cause a system crash due to excessive matching of purchase orders. The fix filters out purchase orders with empty vendor references, which were being incorrectly identified during the import process. This improves the stability and performance of the invoice import feature.
Original PR description
Description of the issue/feature this PR addresses:
A Peppol message contains a reference with a trailing comma.
```
<cac:OrderReference>
<cbc:ID> Uw bestelling,</cbc:ID>
</cac:OrderReference>
<cac:BillingReference>
<cac:InvoiceDocumentReference>
<cbc:ID> Uw bestelling,</cbc:ID>
</cac:InvoiceDocumentReference>
</cac:BillingReference>
```
Current behavior before PR:
A MemoryError occurs in `_cron_peppol_get_new_documents` because the trailing comma leads to a fetching hundreds of thousands of purchase orders with domain `[('partner_ref', 'in', [('Uw bestelling', '')]`
Desired behavior after PR is merged:
Purchase orders are not matched by empty reference.
opw-6102641
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257851This update fixes a bug that prevented Peppol invoices from importing correctly. Specifically, changing a Peppol journal type to non-purchase caused import errors. This change ensures that Peppol invoices are processed reliably, avoiding disruptions in receiving and accounting.
Original PR description
Prevent changing a Peppol journal to a non-purchase type, to avoid import errors when receiving Peppol invoices. Step to reproduce: - Setup a company with Peppol - Change the Peppol reception journal type to non-purchase - Try to run Peppol cron to import invoice, it fails with "Cannot create a purchase document in a non purchase journal" opw-6071992 opw-6064502 Forward-Port-Of: odoo/odoo#258274 Forward-Port-Of: odoo/odoo#256823
This update significantly speeds up the process of retrieving sale order information linked to stock lots. Previously, searching through millions of stock records took 20-40 seconds. By adding an index to the lot ID field, the lookup time has been reduced to just 1-4 seconds, improving overall sales efficiency.
Original PR description
Issue: -- The query created by the function '_compute_sale_order_ids' takes around 20-40 seconds since its doing "WHERE" searches on millions of stock.picking records Fix: -- Added an index to the…
Issue: -- The query created by the function '_compute_sale_order_ids' takes around 20-40 seconds since its doing "WHERE" searches on millions of stock.picking records Fix: -- Added an index to the "lot_id" field of the stock.move.line model. (Already existing databases can be fixed by using the webshell) Steps to recreate the issue: -- 1. Have around a million stock.picking records 2. Go to "Inventory/Products/Lots/Serial Numbers" 3. Select any existing record or create and save a new one 4. These actions will take around 20-40 seconds to complete Before this commit: -- Selecting or saving any 'stock.lot' takes around 20 seconds After this commit: -- Selecting or saving any 'stock.lot' takes around 1-4 second Benchmark: -- Benchmark test was done one a database with ~4000 stock.move records and 1.74 million stock.picking records Opw-5459842 | Before this Commit | ~20 seconds | After this Commit | **~1-4 seconds & Memory usage just a little bit higher --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255255
This update fixes a bug where a new Sale Order was incorrectly created when adding lines to a sale order. The fix ensures that existing Sale Orders are reused, streamlining the process and preventing duplicate orders. This improves order management efficiency.
Original PR description
_*= sale_project **Issue:** When a new sale order line is created on the fly, a new Sale Order is being created instead of reusing an existing one. **Root Cause:** This happens when the project_sale_order is not being passed correctly in the context, causing a new Sale Order to be created. **Fix:** Explicitly pass the default_order_id in the context. If an existing Sale Order is found, it will be reused instead of creating a new one. **Technical Details:** Updated the `default_order_id` to use sale_order_id instead of `project_sale_order_id` in `sale_project`. This ensures that the field functions correctly even when `project_sale_order_id` is empty. **task-4276677** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258201 Forward-Port-Of: odoo/odoo#203230
This update corrects a bug where the product count in the stat button on Sale Order Lines created from tasks would incorrectly show '0 products' until the task was saved. Now, the count accurately reflects the products in the order line, improving the accuracy of sales reporting and order management.
Original PR description
Previously, when creating a Sale Order Line on the fly from a task, the product count in the stat button showed '0 products' until the task was saved. Now, the counter no longer drops to 0 when the record is not saved. task-4276677 Forward-Port-Of: odoo/enterprise#113334 Forward-Port-Of: odoo/enterprise#95100
This update corrects a bug where material resources with assigned roles were incorrectly displayed when filtering by employees in the Planning app. The fix ensures that only employee-type resources and those without assigned roles are shown, improving data accuracy and usability. This resolves a previous issue where the employee filter wasn't functioning as intended.
Original PR description
Steps to Reproduce: 1. Open the Planning app. 2. Go to Configuration -> Materials. 3. Set a role on either the demo material resource laptop or toolkit. 4. Go back to the Planning view. 5. Apply the view filter employee (filter by Employees). Issue: The material resource with a role should not be visible, but it is still present. Current behaviour: When filtering the Planning view by Employees, material resources with an assigned role remain visible. Expected behaviour: Material resources with an assigned role should be excluded from the Planning view when filtered by Employees — only employee-type resources and resources on which role is not set should appear. Fix: Improved the filter domain so unnecessary data are excluded. Task-4526989 Forward-Port-Of: odoo/enterprise#92816
2 changes
Resolved issues and error corrections
This update fixes a misleading warning related to employee sick leave durations. Previously, the warning incorrectly flagged employees with sick leaves exceeding 31 days. The change now accurately identifies employees who have been on sick leave for at least 31 days, ensuring more accurate reporting.
Original PR description
-**Issue**: The warning shows employees who had a long sick leaves before 31 days, which is incorrect. -**Fix**: Adjust the logic to include employees who have been on a sick leave for the past 31 days (at least). Forward-Port-Of: odoo/enterprise#113249 Forward-Port-Of: odoo/enterprise#112985
This update resolves a bug where only the last employee to clock in at a Point of Sale (PoS) session was successfully recorded. The fix ensures that all employees attempting to clock in simultaneously are properly recognized, improving PoS session management.
Original PR description
If you have multiple employee trying to clock in at the same time in a PoS session, only the last one will actually be clocked in. Steps to reproduce: ------------------- * Setup a PoS to use the blackbox * Activate the multi employee on the PoS * Open the PoS with employee A * Open the PoS on another device/browser with employee B * Try to add a product with employee A > Observation: You get an error saying you are not clocked in Why the fix: ------------ The `employees_clocked_ids` was used as a list of ids and not a list of employees/user. But when a session synchronisation was triggered the `employees_clocked_ids` would become a list of employee/user instead of a list of ids. This would cause `checkIfUserClocked` to fail because it was comparing employee object with ids. opw-6034985 Forward-Port-Of: odoo/enterprise#112323
47 changes
New functionality added to Odoo
This update introduces electronic invoicing functionality for Dominican Republic businesses, fulfilling a key client request. Users can now generate invoices in XML format for submission to DGII, with automated status checks and email notifications upon acceptance. It streamlines the invoice process and ensures compliance with local regulations.
Original PR description
Purpose: - Support electronic invoicing for Dominican Republic which was a highly requested feature from clients - Generate XML files to send to Infile to send to DGII - Document types supported: 31,…
Purpose: - Support electronic invoicing for Dominican Republic which was a highly requested feature from clients - Generate XML files to send to Infile to send to DGII - Document types supported: 31, 32, 33, 34 Additions: - Scheduled action, Dominican Republic EDI: Update DGII Status, to request DGII status of the sent invoices - Model: l10n_do_edi.document.type.range - Stores the authorized sequence range of the document type Expected Workflow: - Users will provide their Infile credentials in company settings - Users will need to set the authorized sequence range on document types - Users will be able to create invoices with the supported document types and confirm and send to Infile for validation, either Infile accepts or rejects the invoice and its xml - Once Infile accepts the invoice and its xml, the user will need to click on the 'Request DGII Status' button to get the final verdict from DGII or they can automate the process via the scheduled action - Once the DGII accepts the invoice and its xml, an email with the invoice pdf and its xml attached will be sent to the partner task-5468081
This update expands the capabilities of our AI agents by allowing them to execute client actions, previously restricted to opening standard views. The change introduces a new system for agents to interact with the frontend, improving their responsiveness and ability to perform tasks. This enhances the agent's functionality within the Odoo platform.
Original PR description
Before this commit, the agents were only able to open views of type `ir.actions.act_window`. With this change, the `ir.actions.client` are made available to the agent in the `_get_available_menus()` of the `AIAgent`. This implies the following changes: - Addition of the `ir.actions.client` menus to the `_get_available_menus()`, - Addition of a new tool `_run_client_action` allowing the agent to execute client actions. This method takes the id of the selected action in argument, and then forwards it to the frontend via the bus, - Addition of a new event `AI_CLIENT_ACTION` for the bus to send information to the front-end to execute the selected client action. task-5960556
This update introduces sample data for the planning field service application, allowing developers and testers to work with a realistic scenario. The addition of roles, customers, and tasks improves the ability to thoroughly test the application's functionality and workflows. This enhances the quality assurance process.
Original PR description
This PR adds demo data for the planning field service app, in order to be able to test the application with a realistic dataset. More precisely, it adds some planning roles, customers, descriptions, projects and tasks to the existing planning slots (interventions). task-5955800
This update introduces a new accounting rule within the Belgian payroll module to accurately reflect the 'ONSS TOTAL' calculation required by Belgian tax regulations. This ensures that payroll reports align with official reporting standards, improving compliance and financial accuracy. The change impacts how salary data is processed and accounted for.
Original PR description
Task: 6072450
This update adds a convenient button to CRM leads, allowing sales teams to quickly access and respond to ongoing WhatsApp conversations. The button appears only when a WhatsApp conversation is active, streamlining follow-up and improving lead engagement. This enhancement simplifies the sales process by integrating WhatsApp directly into the lead management system.
Original PR description
Adds a smart button on CRM leads to quickly access ongoing WhatsApp conversations related to the lead. The button is displayed only when a conversation exists, allowing seamless follow-up directly from the Lead. Task-5240269
Enhancements to existing features
This update replaces the traditional helpdesk knowledge section with an AI live chat widget when both the live chat and helpdesk modules are installed. The ‘Odoo Compliance Assistant’ AI agent is automatically assigned when demo data is available, ensuring a seamless customer experience. This change improves customer support by providing instant AI-powered assistance.
Original PR description
Currently, when the website_helpdesk_knowledge module is installed, customers can use the knowledge form and help section for assistance. Now, when both ai_website_livechat and helpdesk modules are…
Currently, when the website_helpdesk_knowledge module is installed, customers can use the knowledge form and help section for assistance. Now, when both ai_website_livechat and helpdesk modules are installed,
the knowledge section is replaced with the AI live chat widget.
When demo data is available, the **“Odoo Compliance Assistant”** AI agent is set by default.
Technical Details:
----------
1)
When we update AI agent, placeholder, or live chat channel values from the snippet, we need to allow those attributes by adding them to the **_get_allowed_root_attrs** method.
2)
file: demo.xml
```xml
<odoo>
<data noupdate="1">
<template id="ai_helpdesk_knowledge_demo" inherit_id="ai_website_helpdesk.ai_helpdesk_knowledge">
<xpath expr="//section[hasclass('s_ai_livechat')]" position="attributes">
<attribute name="t-att-data-agent-id">request.env.ref('ai.ai_agent_1').id</attribute>
</xpath>
</template>
</data>
</odoo>
```
However, when we set the AI agent from demo data, the snippet does not update correctly.This happens because the **replace_arch_section()** method does not update `t-att-data-agent-id` in inherited views. As a result, the snippet updates the data-agent-id in the main view, but when the page loads, the inherited view’s agent value takes priority. so, I have to use this demo data **(Odoo Compliance Assistant)** AI agent in the controller.
task-5166174This update enhances the way time off is displayed on pay runs, providing a clearer view of pending requests. It ensures the Gantt chart accurately reflects the pay run period and includes a notification to quickly approve outstanding time off. This improves payroll accuracy and reporting.
Original PR description
- Added a styled "X to approve" notification pill to the Pay Run Kanban card that dynamically hides when 0, and redirects to a pre-filtered list of pending time offs. - Updated the time off window actions to pass `initialDate` and a mapped `default_scale` in the context, forcing the Gantt chart to perfectly match the pay run's specific period. - [WIP] Refactored `_gantt_progress_bar` in `hr.leave` to calculate actual daily working hours by subtracting time off intervals from the employee's `resource.calendar` schedule. - Injected a hidden `span` containing the computed daily working hours into the Gantt chart cells (`web_gantt.GanttRenderer.RowContent`), laying the structural groundwork for CSS hover effects. task-5965514
This update allows users to control duplex printing within the report printer selection wizard. This provides greater flexibility in how reports are printed, catering to different user preferences and output requirements. The change was driven by a request to enhance the user experience and printing capabilities.
Original PR description
We now allow users to disable duplex printing in report printer selection wizard. see odoo/odoo#257843 task-6089016
This update streamlines the calculation of prices for subscription-based sales (sale_subscription) by optimizing how pricelist rules are applied. It allows for faster filtering of rules based on minimal quantities, improving efficiency and reducing processing time. This change enhances the overall performance of subscription sales pricing.
Original PR description
*= sale_subscription, website_sale_subscription * This change introduces batching of price computation by product periodicity to enable early filtering of pricelist rules based on minimal quantities directly in SQL through `_get_applicable_rules` and `_get_applicable_rules_domain`. * It also aligns method overrides with the main method signatures to ensure consistency and maintainability. task-4875803 Co-authored-by: Victor Feyens (vfe) <vfe@odoo.com> See Also: - https://github.com/odoo/odoo/pull/234935
This update enhances the Odoo Enterprise spreadsheet edition by allowing users to directly link cells to data sources. This provides a more seamless way to integrate spreadsheet data with other Odoo modules, streamlining reporting and analysis. It's an improvement to the spreadsheet functionality.
Original PR description
Task-5932139
This update optimizes how the system searches for calendar resources, specifically when filtering by user. Adding an index on `planning.calendar.resource.user_id` speeds up these searches, leading to faster response times for calendar-related operations. This improves overall system performance.
Original PR description
This commit adds an index on `planning.calendar.resource.user_id`, as it's the only criteria used in `get_calendar_filters` for the `search_count` and the `search_read` done after. Forward-Port-Of: odoo/enterprise#113304
This update introduces geo-fencing to control where employees can check in and out. It prevents check-ins outside designated workplace areas, improving accuracy and potentially reducing errors in attendance tracking. The system now flags and warns employees if check-ins occur outside of their defined work locations.
Original PR description
-Currently, employees can check in and check out from any location, which may not always be desirable. This commit introduces a geo-fencing mechanism to restrict attendances to a defined workplace area. -Established geo_fence functionality on configuration. -Refined '_attendance_action_change' logic to handle check-in from various work location. Also implemented the warnings to be displayed if the check-in is not as per the defined work location. -Added the method _calculate_employee_distance_from_workplace to find the distance between workplace and employee's location. -Added the filter to fetch offsite and conflicting attendance. task-4963427
This update standardizes the messages displayed in Odoo's drop zones across different modules. Previously, instructions varied, leading to potential confusion for users. Now, all drop zones use consistent language, making it clearer where elements should be placed and improving the overall user experience.
Original PR description
This commit changes the messages shown in some drop zones to indicate where dropped elements will appear, for example: "Drag blocks here, apply to all blogs". Before this commit, the messages used different wording depending on the module. After this commit, the messages are standardized to use the same wording across all modules. task-5921283
This update allows administrators to set a default joint committee for new employees. Employees can now be assigned a committee based on a pre-defined type or fall back to the company's main committee. This simplifies the process of setting up employee committees and ensures consistency across the organization.
Original PR description
This commit adds the possibility to set a default joint committee on a newly created employee from a JC defined on the employee type or a fallback to the company's main JC. TaskID-5972507
This update enhances the user experience of the Salary Attachment form by simplifying labels and button text, moving the priority indicator, and adjusting the layout. These changes aim to improve usability and clarity for HR staff managing salary adjustments.
Original PR description
This commit introduces some UI/UX changes to the form view of Salary Attachments. The changes are: - The text under Salary Adjustment in the top is not "Type + Durantion Type" anymore but "Type + Employee Display Name". - The "Mark as completed" button now instead reads "Done". - The "closed" state text is now "Done" instead of "Closed". - The priority widget (3 stars) has been moved to the top right of the form. - The Type selection menu has been shrinked to half width. - The date_end or date_estimated_end are no longer editable. Task: 5959289
This update removes unnecessary code overrides within the Odoo Enterprise system. These cleanup efforts streamline the application, reducing potential complexity and improving performance. The changes contribute to a more efficient and stable user experience.
Original PR description
Some overrides were unused and could be removed. This commit cleans them up.
This update aligns the Odoo spreadsheet functionality with a recent upgrade to the underlying library. Specifically, several actions previously disabled on locked spreadsheets have been re-enabled, and new datasource links have been added to cells. This improves usability and expands the capabilities of the spreadsheet feature.
This update streamlines the booking process in our Point of Sale system by improving calendar views and adding new functionality for managing table reservations. Specifically, users can now easily add or update bookings through various interfaces, confirm table assignments, and filter bookings based on key criteria, leading to more efficient operations.
Original PR description
In this commit: --------- - We are improving the calendar event views on the booking page in PoS. - Added a flow to add or update resources on clicking the kanban/gantt popover `check in` button, on kanban state change to `check in`, and on clicking the list view `Set Table` button. - Added a flow to update table booking on long press on a table in the floor plan. - Introduced a new search view with filters based on booking states, booking start time, etc. - Added a confirmation pop-up when opening a table with an appointment, allowing the user to confirm and link the order to the calendar event or automatically change the appointment resource. - Updated the calendar event form view. - Removed the calendar view from the booking page in PoS. Related PRs: - Community: https://github.com/odoo/odoo/pull/255217 - Upgrade: https://github.com/odoo/upgrade/pull/9746 Task-6018428
This update adapts various Odoo modules to the recent catalog refactor, improving its design and extensibility. Specifically, it prepares for future changes in unit of measure handling and simplifies data transmission to the frontend, leading to more efficient product catalog updates. This change enhances the overall product catalog experience.
Original PR description
In https://github.com/odoo/odoo/pull/209316, The catalog was refactored to have a better and an easier to extend design. As well as adding a feature that shows the price per product unit, if the line's unit or seller's unit is different In this commit, uom was added to the parameters passed to `update_order_line_info` in order to prepare it for the upcoming PR that will allow the change of the UoM directly from the catalog. New method was introduced in the catalog refactor, and the modules needed to be adapted to use the new method, which would make sending new props to the frontend much easier without having to loop over all the products everytime.
This update enhances financial reporting by providing a 'coverage ratio' for each analytic plan. This allows users to easily identify if journal items are fully distributed across their planned analytics, which is crucial for accurate audit trails and financial analysis. It addresses discrepancies in P&L and BS reports caused by partial analytic distributions.
Original PR description
The objective is to bridge the gap between journal items and analytic items in the reporting. As Odoo allows for partial analytic distribution, this creates discrepancies in the P&L and BS when filtered by an analytic plan. This features aims to provide users with a clear 'coverage ratio' per plan to identify incomplete distributions during audits. task-5887978 Forward-Port-Of: odoo/enterprise#106750
Resolved issues and error corrections
This update resolves a technical issue that was preventing accurate invoice calculations for subscription sales orders. The fix ensures that the system correctly handles cases where the next invoice date is not specified, preventing a potential error. This ensures reliable invoice generation and accurate financial reporting for subscription customers.
Original PR description
Fix a TypeError when `next_invoice_date` is unset by guarding the date comparison against a falsy value. Community PR: odoo/odoo#252198
This update corrects a previous issue where the Amazon fulfillment channel in the sales module was not editable for users. The fix ensures that users can now properly manage their Amazon fulfillment options, streamlining the order fulfillment process. This resolves a reported usability problem.
Original PR description
Commit 67c45d6494f082e2ee83b9a84611e8b8fe8f4fd5 intended to make `amazon_channel` editable by users. However, the field was displayed with the `badge` widget, which is read-only, so it remained uneditable. Use an editable display for `amazon_channel` so the original fix works as intended. Forward-Port-Of: odoo/enterprise#113196 Forward-Port-Of: odoo/enterprise#112866
This update fixes an issue where rental products displayed an 'out of stock' ribbon even when they had available quantity. The change ensures that rental products are not flagged as out of stock, aligning with their time-based stock management. This improves the customer experience for rental orders.
Original PR description
Currently, when a rental product's quantity on hand drops to 0, the out-of-stock ribbon is displayed on the website for that product. Steps to produce: --- - Install the `eCommerce Rental with Stock…
Currently, when a rental product's quantity on hand drops to 0, the out-of-stock ribbon is displayed on the website for that product. Steps to produce: --- - Install the `eCommerce Rental with Stock Management` module. - Create a rental product and set Quantity On Hand to 1. - Under the Sales tab, disable `Sell when Out of Stock`. - Under the Rental Prices tab, add pricing. - Go to `website > ecommerce > products > product ribbons`. - Open `out of stock` ribbon > set assign as `when out of stock`. - Create and Confirm a rental order for that product and validate the pickup. - The product's Quantity On Hand drops to 0. - Opening the product on the website Observation: --- - The product shows the out-of-stock ribbon. Cause: --- - At [1], the or condition evaluates to True because the ribbon is configured as `when out of stock`, `Sell when Out of Stock` is disabled under the Sales tab, and `_is_sold_out` also returns True since the quantity dropped to 0 after the pickup was validated. As all conditions are met, the ribbon is returned and displayed without ever checking whether the product is a rental. Skip the out-of-stock ribbon assignment for rental products, since their stock availability is time-based. [1]: https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/website_sale_stock/models/product_ribbon.py#L21-L28 opw-6081483 --- Forward-Port-Of: odoo/enterprise#113280 Forward-Port-Of: odoo/enterprise#112660
This update fixes a limitation in Odoo Enterprise's delivery carrier options. Previously, cash on delivery was unavailable for UPS (legacy), UPS REST, and Shiprocket carriers. Now, these carriers will display the cash on delivery checkbox, providing users with more flexible payment choices.
Original PR description
*: delivery_ups,delivery_ups_rest,delivery_shiprocket Override `_compute_supports_cash_on_delivery` so that UPS (legacy), UPS REST, and Shiprocket carriers expose the cash on delivery checkbox. task-none See also: - https://github.com/odoo/odoo/pull/254459
This update fixes an issue where failed quality checks didn't correctly route items to their designated failure locations. Now, when a user marks an item as failed, a wizard appears to select the correct location, ensuring accurate stock management and preventing misdirected transfers. This improves efficiency and data consistency.
Original PR description
Currently, when a user clicks the 'FAIL' button on a quality check form with available failure locations for a control point, the quality check is directly marked as failed, and the user is not allowed to select the failure location. This leads to inconsistencies in stock management, as the failed items may be transferred to an incorrect location instead of the intended failure location. This improvement ensures that when the 'FAIL' button is clicked, and if failure locations are defined for the control point, a wizard is triggered, allowing the user to select the appropriate failure location. Once confirmed, the chosen failure location is set as the destination for the move. This change improves stock management for failed items and resolves inconsistencies in the transfer process. Task Id: 5367964
This update fixes an issue where the canteen cost was incorrectly calculated for Belgian employees, even when they had no attendance recorded. The fix ensures that the canteen cost is only applied when the employee has worked during the payslip period, aligning with accurate payroll processing. This improves the reliability of the Belgian payroll module.
Original PR description
[FIX] l10n_be_payroll: fix canteen cost computation
Bug reproduction: belgium company -> create a new employee -> new contract (payroll wage > 0) -> canteen_cost = 50 -> create payslip -> allocate time off for full month (such that there will be no attendance) -> recompute payslip -> still canteen cost is calculated
Bug cause:
1 - If l10n_be_canteen_cost is > 0 it was computing the canteen cost line for sure
2 - If result_rules['BASIC']['total'] is > 0 then the canteen cost was 50.
Bug solution:
1 - I add worked_days['WORK100'].amount != 0 to the computation condition.
2 - If there is any earned money from attendance or working in that payslip duration, the canteen cost should be deducted completely
3 - If the employee is absent during the payslip, the employee should not pay the canteen cost.
task - 6045406
Forward-Port-Of: odoo/enterprise#112462
Forward-Port-Of: odoo/enterprise#110991This update resolves an error that occurred during the registration of super payments in the Australian payroll system. By initializing the error message to an empty string, the system now correctly handles payment processing without returning NULL values. Associated tests have been added to ensure this fix functions as expected.
Original PR description
. Initialize the error message with an empty string to avoid returning NULL. . Add corresponding tests task-6091444 Forward-Port-Of: odoo/enterprise#113202 Forward-Port-Of: odoo/enterprise#112930
A technical glitch in the UrbanPiper test order wizard was causing errors. This update removes a feature that was incorrectly attempting to open product forms, preventing the error and ensuring the wizard functions correctly. This improves the stability of the test order process.
Original PR description
Steps to Reproduce ---------- - Make an UrbanPiper Test Order - Select a product - Click the external-link (open) icon - POS traceback appears Issue ----------- Clicking the “open product” icon triggered a traceback because the POS attempted to load the missing hr_expense_product_form view. Fix -------------- Disable form open/create for the product field to remove the quick-open product icon, as there is no need to open the product form from this wizard. Task-6089707 Forward-Port-Of: odoo/enterprise#112819
This update fixes a problem where users weren't receiving clear error messages when the SendCloud delivery service failed. A helpful hint has been added to the system, guiding users to resolve delivery issues more effectively. This improves the user experience and reduces potential delays.
Original PR description
Add hint with error message. ----- Ticket: opw-6072855 Forward-Port-Of: odoo/enterprise#112463
This update resolves a technical problem where the Knowledge editor wasn't properly initializing its features. By ensuring the editor calls the parent implementation of `onEditorReady`, this fix restores the expected functionality and prevents missing initialization logic. This improves the overall stability and reliability of the Knowledge module.
Original PR description
Problem: The Knowledge editor overrides `onEditorReady` but does not call the parent implementation, which leads to missing initialization logic. opw-5266687
This update fixes a technical issue that was causing upgrade testing to fail for the Dimona payroll module. Specifically, a check was preventing the loading of menus during the upgrade process when the company wasn't set to Belgian. The fix moves the check to a safer location, ensuring proper functionality during upgrades while maintaining the intended business rule.
Original PR description
The Dimona models were raising an exception in get_views() when the current company was not Belgian. This caused upgrade mock crawl tests to fail, since opening the related menus after upgrade triggered the error and made them appear as broken. This commit moves the check to default_get() instead, so the restriction is still enforced when creating records, while keeping menu/view loading safe during upgrade crawling.
This fix resolves an issue where the bank reconciliation process would fail when using the liquidity account as an outstanding payment account. The update prevents automatic reconciliation attempts in this scenario, ensuring data integrity and preventing the form from becoming unsavable.
Original PR description
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity…
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity account - Go to the Transactions of the Journal - Add a new Transaction for partner X and amount Y - Add a second Transaction also for partner X and amount Y # The issue A popup appears that can never be saved # Cause When we click on "Add & New" or "Add & Close", we run the `validate()` function : https://github.com/odoo/enterprise/blob/9abb50b9b29e01897b4fb90ae228beecbdfcd5af/account_accountant/static/src/components/bank_reconciliation/quick_create/quick_create.xml#L14-L16 Which tries to do a model save, but it fails so it show the Form dialog : https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/web/static/src/views/kanban/kanban_record_quick_create.js#L159-L163 The save fails because : This commit (https://github.com/odoo/enterprise/commit/e2b3439dcda26f84b9a290c8d5fb819dd3250825) changed the the logic behind auto-reconcilation with an outstanding account. When there is an outstanding account, we try to auto-reconcile the bank statement with that account and succesfully do so : https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L381-L385 https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L245 But this should not happen when the outstanding account is the liquidity account, because it will end up throwing an error when the amount is matched more than once: https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/account/models/account_bank_statement_line.py#L727-L737 opw-6063654 Forward-Port-Of: odoo/enterprise#113358 Forward-Port-Of: odoo/enterprise#112750
This update prevents the 'Plan Services' field from appearing on product forms when 'Sales' functionality isn't enabled. This ensures that users only see relevant options based on their business needs, streamlining the product selection process. The change improves data consistency and user experience.
Original PR description
In the product form, the plan services field was visible even if 'sales' was not enabled on the product. We therefore fix the visibility conditions not to show the field if sales is not enabled. Upgrade PR: https://github.com/odoo/upgrade/pull/9214 task-4886404
This update resolves a bug preventing users with sign access from editing custom fields created by other users. The fix ensures authorized users can correctly access and modify shared custom fields within sign templates, improving collaboration and usability. This change enhances the functionality of the sign process.
Original PR description
Steps to Reproduce: Create a custom field as User A. Log in as User B (with sign user access). Try to use the same field in a template or open its configuration. Attempt to edit the field. Issue: Users were facing access errors when interacting with custom fields created by other users in sign templates, limiting usability and collaboration. Current Behavior: Users cannot edit custom fields created by other users even if they are shared. Expected Behavior: Authorized users can use shared custom fields without any errors. Shared fields can be edited when access conditions are satisfied. Fix: Modified the backend flow so shared items are authorized during sign item creation instead of loosening record rule for shared templates and tests task id - 6102273
This update reverts a recent change to the Belgian payroll accounting rules, specifically related to ONSS total calculations. The change was rolled back to ensure accurate reporting and compliance with Belgian tax regulations. This ensures consistent and reliable payroll processing for our Belgian clients.
This update resolves a technical issue where incorrect HTML messages were appearing in the ‘chat’ feature when creating asset bills. This ensures that all bill-related information is displayed correctly, improving the clarity and accuracy of communication within the system. It’s a minor fix that enhances the user experience.
Original PR description
This commit fixes the broken message in chatter posted during asset creation when confirming bill. task-6103974
This update removes unnecessary visual elements from the settings forms, streamlining the user interface. The change was made to address an issue caused by a previous project and simplifies the layout for a cleaner experience. This improves usability and reduces visual clutter.
Original PR description
Before this commit, some unwanted boxes appeared due to the m3 project. This commit removes them from certain settings forms. To do so, we simplified the view by removing ´<group>´ elements, as the labels were not needed. This avoids the issue.
This update resolves issues with inconsistent tour experiences by refining the triggers used in various Odoo modules. The changes ensure tours run reliably and predictably, leading to a smoother user experience. This primarily impacts the visual onboarding and guidance provided within Odoo.
Original PR description
Fix undeterministic tours by making some triggers more precise in a few steps.
This update enhances the security of Odoo's core modules by making compute methods private. Previously, these methods were accessible via RPC, which wasn't appropriate and could pose a security risk. This change ensures that compute methods only access internal data, improving overall system stability and security.
Original PR description
Compute methods should be private (via prefixing it with '_'). Without that, and with no `@api.private` defined on it, they are publicly exposed for RPC, which doesn't make sense for a compute method, reading instead of reading the computed field instead.
This update corrects a minor technical issue where a previously removed code reference persisted in a reporting module. The change ensures the system functions correctly and avoids potential inconsistencies. It's a routine maintenance update to improve the stability of the Odoo Enterprise platform.
Original PR description
The account_return_type record 'KMD INF Report (EE)' (l10n_ee_reports.ee_kmd_inf_tax_return_type) was removed [here](https://github.com/odoo/enterprise/pull/98471/changes#diff-73727ce6b3fc23788e37d59fb9160d29158b84e7f082db85b6732a731e814a42L11), but its reference code still existed in the condition. opw- 6056471 Forward-Port-Of: odoo/enterprise#113401
This update resolves an issue where material resources with assigned roles were still visible when filtering by employees in the Planning app. The fix improved the filter logic to accurately exclude these resources, ensuring that only employee-type resources and those without assigned roles are displayed. This improves the accuracy of the Planning view.
Original PR description
Steps to Reproduce: 1. Open the Planning app. 2. Go to Configuration -> Materials. 3. Set a role on either the demo material resource laptop or toolkit. 4. Go back to the Planning view. 5. Apply the view filter employee (filter by Employees). Issue: The material resource with a role should not be visible, but it is still present. Current behaviour: When filtering the Planning view by Employees, material resources with an assigned role remain visible. Expected behaviour: Material resources with an assigned role should be excluded from the Planning view when filtered by Employees — only employee-type resources and resources on which role is not set should appear. Fix: Improved the filter domain so unnecessary data are excluded. Task-4526989 Forward-Port-Of: odoo/enterprise#113477 Forward-Port-Of: odoo/enterprise#92816
This update fixes an issue where rental order confirmations didn't properly update the status of related shifts in the planning system. Now, shifts are automatically marked as 'published' when a rental order is created, ensuring accurate status tracking and consistency with other actions. This improves the reliability of rental planning workflows.
Original PR description
**Issue 1** **Steps to Reproduce:** Create a shift in Planning. Click New Order. Save and confirm the rental order. Check the shift in Planning it is still in draft. **Issue:** The shift stays in draft even after the rental order is confirmed. **Cause** When creating a rental order from a shift, the shift is not marked as planned. It only gets linked to the order after saving, so it never updates its status. **Fix:** Mark the shift as published when confirming a new rental order. This makes the shift show the correct status right away and keeps it consistent with the “Add to Last Order” button. task-5075839 Forward-Port-Of: odoo/enterprise#113286 Forward-Port-Of: odoo/enterprise#99642
This update resolves an issue where the payment report screen incorrectly attempted to create a new Company Autopay Account without a properly configured partner. The fix disables this automatic creation to ensure accurate bank account setup. Adding a new field to always use the company partner was considered but deemed unnecessary for this specific workflow.
Original PR description
Disable creating a new Company Autopay Account from the payment report screen, as it doesn't work without a default partner in the context. Setting the partner to the company one would be another solution, but it requires adding a new related field which may not be worth it for this flow only. task-6098463 Forward-Port-Of: odoo/enterprise#113252
This update fixes an error in the Pakistan localization payroll calculation. Previously, tax was being calculated incorrectly for employees with annual salaries exceeding PKR 2,200,000. The fix ensures accurate tax calculations based on official Pakistani tax regulations, preventing overpayment of taxes.
Original PR description
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install…
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install `l10n_pk_hr_payroll_account`,`hr_contract_salary` with demo data. 2) Switch to PK company. 3) Create an employee and a running contract with yearly cost 2,200,001 4) Create a payslip and compute it from the Salary Computation tab. ### **Observed Behavior:** 'Tax Bracket Yearly' is computed as `122000.24` ### **Expected Behavior:** 'Tax Bracket Yearly' should be `116000.24` ### **Root Cause:** since [commit](https://github.com/odoo/enterprise/pull/98345/commits/62f5e216518d83317618d7dbc0be4db92d1881a3), the tax computation relies on [_l10n_pk_get_tax](https://github.com/odoo/enterprise/blob/a9656336583a4d5c5b12d4d6120ec62ba1cf9151/l10n_pk_hr_payroll/models/hr_payslip.py#L9-L20) , In this method, the `result` is incorrectly accumulated with `fix` when iterating through brackets, leading to an inflated tax value. [official pakistan document](https://download1.fbr.gov.pk/Docs/20258181281745641WHT-RateCard.pdf) ### **Fix:** Use `result = fix` instead of `result += fix` so that the cumulative tax is correctly reset at each bracket. **opw-5979265** Forward-Port-Of: odoo/enterprise#112875 Forward-Port-Of: odoo/enterprise#110939
This update corrects a technical issue where payroll data was being unintentionally transmitted in non-production (test) environments. This change ensures that sensitive payroll information remains isolated to testing, improving data security and preventing potential errors in live operations. The fix focuses on a specific module within the Odoo Enterprise platform.
Original PR description
Forward-Port-Of: odoo/enterprise#113504
This update fixes an issue where the filter for unfinished workorders would disappear after marking an operation as complete. The fix prevents the filter from being unintentionally erased during the process of marking operations as done, ensuring users can accurately track remaining tasks. This improves the usability of the shopfloor operations module.
Original PR description
While working on a workorder from the shopfloor, if there is several operation when closing the first one, the filter will disapear Steps to reproduce: ------------------- * Create a Product * Create a BoM for that product with two operation * Create a MO for this product * Click on the smart button "Shop Floor" * Open the Operations * Mark as Done one of the operation -> the filter disappears Observation: ------------- When cliking on "mark as done" or "closing production" both goes through validate(), At the end of this function the filter is erased: https://github.com/odoo/enterprise/blob/85bd9d80a1a784f1baff1493b2eaec4a17ea9c9b/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L384 opw-5959166 Forward-Port-Of: odoo/enterprise#111333
Code cleanup and technical improvements
This update replaces a risky, older method of evaluating expressions with a safer, dedicated system. It simplifies calculations within Odoo reports, specifically in the account_report module, and reduces potential security vulnerabilities. This change improves the stability and maintainability of our reporting features.
Original PR description
Replace the legacy eval-based expr_eval with an AST evaluator for simple expressions, that now also supports variables and context
The new `expr_eval` has a small subset of python syntax: arithmetic, comparisons, boolean operators, literals, lists, tuples, dicts, sets, variables passed as context, subscripting, and min/max.
This works for simple formulas and simple domain expressions and avoids ever going through `eval` for these
(https://github.com/odoo/enterprise/pull/107659 already deprecates `const_eval` btw)
community: https://github.com/odoo/odoo/pull/2552168 changes
Resolved issues and error corrections
This update resolves a problem where the automated tour feature within the industry_fsm module was failing intermittently. The fix, triggered by a runbot test, ensures the tour consistently runs as expected, improving the user experience and streamlining onboarding for new users of the industry_fsm functionality. This prevents potential frustration and ensures users can quickly learn the key features.
Original PR description
runbot issue-242264 Forward-Port-Of: odoo/enterprise#113272
This update resolves an issue where retry attempts for Fiskaly SCU setup were incorrectly triggered by client errors, leading to confusing error messages. The fix now only retries on server errors and intelligently reuses existing SCU instances to avoid exceeding Fiskaly's signature creation limits, ensuring smoother and more reliable SCU setup.
Original PR description
- Only retry on server errors (5xx) instead of client errors (4xx), which caused confusing RetryError instead of the actual API response. - Reuse the existing active SCU when Fiskaly's limit of 1 active signature creation unit is reached (E_SCU_LIMIT_REACHED). opw-5958673
This update fixes an issue where Field Service orders were incorrectly reserving all stock moves within a delivery chain, leading to all picking steps being marked as 'Ready' instead of just the customer-bound ones. The change ensures that stock reservations are applied only to the necessary picking steps, improving order fulfillment accuracy. This resolves a conflict arising from a recent database update.
Original PR description
Since db76eb2020383, `move_ids` on sale order line is link to all stock move of a delivery chain. Meaning there is 3 moves by default for 3 steps delivery config. Creating a sale order via field service will force the reservation of the sale order moves. This will lead to all the picking being marked as "Ready" instead of only the one going to "Customer" location. Task: 5914851
This update fixes an issue where users could order unlimited quantities of rental products through the website. The change limits the available quantity to the minimum rental availability, ensuring accurate resource allocation and preventing overbooking. This improves the reliability of our rental service.
Original PR description
It is possible to order as many products as we want of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning module 2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period 3. In the General Information tab, click on the internal link to "Developer" 4. Enable Sync Shifts and Rental Orders 5. Go to the eCommerce website and search for product "test" 6. You can add as many quantity of the product to your cart Issue: We don't limit the maximum quantity of the product Solution: Look through the renting availabilities of the product and set the maximum quantity to the minimum of the availabilities relevant to the renting dates selected opw-6009928
This update fixes a display issue in Odoo's approval chatter. When an approval request is canceled before a purchase order is created, a misleading 'This message has been removed' message appeared. The fix ensures chatter messages are only logged when relevant, improving the user experience and clarity.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install `approvals_purchase` module with demo 2. Approvals > New Request in Borrow Items 3. Create request with any product 4. Click on the Submit button 5. Click on the Cancel button Observation: ------------------------------------ In chatter there's a message stating: 'This message has been removed' Issue: ------------------------------------ When you cancel an approval request that has no purchase orders created yet, the `_log_po_cancellation_to_chatter` method is called with an empty `cancellation_log_msg` string, which causes Odoo to display 'This message has been removed' in the chatter. Solution: ------------------------------------ Only log to chatter if there's actually a message to log opw-6063998
This update allows users to create pricelist rules for subscription products that also offer one-time sales. Previously, the system restricted pricelist items based on recurring invoice settings, preventing flexible pricing options. This change ensures users can accurately define pricing for hybrid subscription models.
Original PR description
Currently, the pricelist item form strictly filters out any product marked as a recurring invoice (`recurring_invoice` = True). This prevents users from defining standard pricelist rules for "hybrid" products that are subscriptions but also have `allow_one_time_sale` enabled. This commit updates the domain on `product_tmpl_id` in the pricelist item form to include an OR condition. Products are now visible if they are NOT a recurring invoice, OR if they explicitly allow one-time sales. Task: 6052066
This update resolves an error that prevented non-administrator users from viewing subscription options for products without recurring plans. The fix changes how the system checks for subscription rules, ensuring a smoother experience for all users accessing the shop. This prevents a frustrating error message and improves usability.
Original PR description
__ ## Short functional explanation of the error When a user other than Admin goes to the Shop app and clicks on a subscription for which no recurring plan has been set, an error message appears. ##…
__ ## Short functional explanation of the error When a user other than Admin goes to the Shop app and clicks on a subscription for which no recurring plan has been set, an error message appears. ## Reproduction Steps 1. As admin, create a product. Check the Subscription box and make sure to *not* create any recurring plan. 2. Publish the product on website. 3. Log in as another user. 4. Click on Shop > product you've just created. ### Expected behavior As this is a subscription without recurring plan, the error message should be `This product has no valid combination.` ### Unexpected behavior An error occurs: `Error message: You do not have enough rights to access the field "subscription_rule_ids" on Product (product.template). Please contact your system administrator. Operation: read` ## Origin of the issue The access group of `subscription_rule_ids` is `sales_team .group_sale_salesman`, which a simple user who wants to access the shop to buy items doesn't have. Therefore, we have to proceed like in 19.1: instead of checking the `subscription_rule_ids` field, we check `pricelist_rule_ids.plan_id` to access the recurring plan of the item. __ opw-6024874
This update fixes a discrepancy in how planning times are displayed. Previously, reports printed times in 24-hour format while the user interface used 12-hour format. The fix ensures that all printed planning reports consistently use the same time format as the user interface, improving clarity and accuracy for users.
Original PR description
Steps to reproduce: - Install the Planning module - Open the Planning app - Click the Print action Issue: Planning slots display in 12-hour format in the UI but print in 24-hour format. Cause: A hard-coded time format was used when printing planning slots. Fix: Remove the explicit format and rely on the locale aware short time format. task-5462276
3 changes
Resolved issues and error corrections
This update resolves an issue where the Helpdesk return wizard incorrectly displayed receipt operations alongside delivery operations. The fix specifically excludes receipts from the wizard's domain, ensuring users only see eligible deliveries for returns. This improvement enhances the accuracy and usability of the Helpdesk return process.
Original PR description
Steps to reproduce: - 1. Create a Sale Order for a customer and fully process the delivery. 2. Create a Helpdesk ticket for that customer. 3. From the ticket, click the 'Return' button to open the wizard. 4. Select the sales order or open the 'Delivery to Return' dropdown. Issue: - The list of available pickings shows both receipts and deliveries operations. Fix: - The domain for the return wizard is updated to explicitly exclude receipts. Note: - This bug is present until saas-18.4. From 19.0 onward it is already fixed in this PR: https://github.com/odoo/enterprise/pull/90371 task-5075205 Forward-Port-Of: odoo/enterprise#95418
This update resolves an issue where material resources with assigned roles were incorrectly displayed when filtering by employees in the Planning app. The fix improves the filter logic to accurately exclude these resources, ensuring that only employee-type resources and those without assigned roles are shown.
Original PR description
Steps to Reproduce: 1. Open the Planning app. 2. Go to Configuration -> Materials. 3. Set a role on either the demo material resource laptop or toolkit. 4. Go back to the Planning view. 5. Apply the view filter employee (filter by Employees). Issue: The material resource with a role should not be visible, but it is still present. Current behaviour: When filtering the Planning view by Employees, material resources with an assigned role remain visible. Expected behaviour: Material resources with an assigned role should be excluded from the Planning view when filtered by Employees — only employee-type resources and resources on which role is not set should appear. Fix: Improved the filter domain so unnecessary data are excluded. Task-4526989 Forward-Port-Of: odoo/enterprise#92816
This update fixes an issue where closing entries for OSS reports were incorrectly generated as standard tax returns. The change simplifies a process that inadvertently treated OSS reports the same as standard tax reports, leading to incorrect document types. Now, closing entries accurately generate OSS report documents after posting.
Original PR description
### Issue: When closing an OSS report, the generated tax closing entry was incorrectly identified as a standard Tax Return After posting, the document type remained `Tax Return` instead of the…
### Issue: When closing an OSS report, the generated tax closing entry was incorrectly identified as a standard Tax Return After posting, the document type remained `Tax Return` instead of the expected OSS report type ### Cause: In this PR: https://github.com/odoo/enterprise/pull/95775, a condition was simplified to unify closing moves across report variants However, this caused OSS reports to be treated as standard tax reports As a result, only one closing move could be created and reused for both Tax Reports and OSS Reports for the same period The document was also incorrect because of this simplification ### Steps to reproduce: - Install `l10n_nl` and switch to NL Company - Activate `EU Intra-Community Distance Selling` in Settings (reload taxes if needed) - Confirm invoices for a Belgian Customer using the tax 21% BE VAT - Go in Accounting > Reports > Tax Return - Select the report type OSS Sales and the quarterly period - Click `Closing Entry` - Post the entry A Tax Return document is created instead of an OSS report ### Other Fix: If a standard Tax Report closing entry is created first, the closing move becomes linked to it and is then incorrectly reused for the OSS report opw-5489822 opw-5882188
1 change
Resolved issues and error corrections
This update resolves an issue where the LU reports were incorrectly showing only the first product with a missing internal reference. The change ensures all products with missing internal references are now displayed, providing a more accurate and complete report for Luxembourg accounting. This aligns with reporting requirements and improves data accuracy.
Original PR description
This is one of several commits fixing the FAIA xml export. The internal reference must be set for all products reported in the FAIA report. When there are multiple products missing this field, our previous code only reported the first ID to the customer. This commit shows the customer all incorrectly configured products. opw-5427296, opw-6113665