Daily updates from Odoo
Tuesday, March 10, 2026
245 changes
12 changes
Resolved issues and error corrections
This update optimizes the process of linking analytic lines to invoices during reinvoicing. Previously, the system always performed a search for analytic lines, even when no related sale order lines existed, leading to unnecessary queries. Now, the system directly returns an empty recordset when no reinvoicable sale order lines are found, improving performance and efficiency.
Original PR description
Description of the issue/feature this PR addresses: When retrieving analytic lines to link for reinvoicing, the method performs a search even when there are no reinvoicable sale order lines associated with the invoice lines. Current behavior before PR: The method always executes an account.analytic.line search using the domain returned by _analytic_line_domain_get_invoiced_lines, even when no reinvoicable sale order lines are found. This results in an unnecessary query that will always return an empty recordset. Desired behavior after PR is merged: If no reinvoicable sale order lines are found, the method directly returns an empty account.analytic.line recordset, avoiding the extra query and slightly improving performance. part of: https://github.com/odoo/enterprise/pull/108685 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents invoice generation errors when subscriptions include both standard products and timesheet-based services. The fix ensures that invoices can be created correctly even if a timesheet service hasn't been delivered, avoiding a previous crash. This improves the reliability of subscription invoicing.
Original PR description
**Issue:** When generating an invoice for a subscription that contains a mix of regular products (invoiced on order) and timesheet-based services (invoiced on delivery), a traceback can occur if the…
**Issue:** When generating an invoice for a subscription that contains a mix of regular products (invoiced on order) and timesheet-based services (invoiced on delivery), a traceback can occur if the timesheet service has 0 delivered quantity. **Cause:** During the invoice creation process, `_get_reinvoiced_analytic_lines_to_link` iterates over the newly created invoice lines to link analytic lines. It filters the linked sale order lines using `_is_line_reinvoicable()`. If the invoice only contains standard products (because the timesheet line was skipped due to 0 delivery), `so_lines` evaluates to an empty recordset. then calling `_get_range_dates` causes a treace beack because it needs to ensure that ther is at least 1 order `self.ensure_one()` **Fix:** Added a safeguard (`if not so_lines: continue`) inside the loop. If an invoice line does not contain any reinvoicable sale order lines, it is now safely skipped, allowing standard subscription lines to be invoiced alongside undelivered timesheet lines without crashing. task: 5966725
This update resolves an issue where autofilling pivot formulas in certain situations caused errors and incorrect data formatting. Specifically, it prevented crashes and ensured that positional formulas worked as expected when referencing dimensions perpendicular to the header. This enhancement improves the reliability and accuracy of pivot table reports.
Original PR description
If we autofill a positional pivot formula in the dimension perpendicular to the positional header, it would not work correctly: - We would crash if the position wasn't in the original pivot table - We would drop the positional part otherwise (`"#country_id", 1` would become `"country_id", 25`). Task: [5909266](https://www.odoo.com/web#id=5909266&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This update resolves a technical issue preventing the correct display of sales timesheet slots within the planning module. The fix ensures that the planning module integrates seamlessly with the sale timesheet, improving the accuracy of time tracking data. This resolves a minor visual discrepancy.
Original PR description
Steps to reproduce: - Install sale_timesheet & planning; - Install planning_field_service_sale_timesheet; Traceback: Element `'<xpath expr="//field[@name='project_id']">'` cannot be located in parent view This commit fixes the inheritance of the planning.slot tree views.
This update ensures the background color of the 'Discuss' dropdown in the Odoo dark theme matches other dropdowns, resolving a visual inconsistency. Previously, the 'Discuss' dropdown had a darker background than other dropdowns in dark mode. This change improves the overall user experience and visual consistency across the Odoo platform.
Original PR description
Before this commit, background of dropdown discuss actions in dark theme were darker than other dropdown in web client. This comes from https://github.com/odoo/odoo/pull/247352 that harmonized NotificationSettings bg with discuss dropdown bg, by changing discuss dropdown BG to match NotificationSettings. However, the inverse should have been done, which is what this commit does. Before / After <img width="1241" height="810" alt="Screenshot 2026-03-09 at 16 30 10" src="https://github.com/user-attachments/assets/d1b1d201-a175-4f34-b95b-999126616a98" />
This update resolves an issue where chatbot session names weren't displayed correctly in live chat and triggered errors when used with the website editor. The fix ensures the chatbot's name is accurately displayed and prevents a crash caused by conflicting channel operations, improving the overall chatbot experience.
Original PR description
*=test_discuss_full Before this PR: - When starting a session with a chatbot, the name of conversation is not visible on livechat channel. Because the name is computed from agent/customer history and not from bot history. - Using a chatbot while the website editor is active could trigger a TypeError traceback. This PR: - computes the name properly from bot history. - adds a guard that closes the transient channel Steps to reproduce traceback: - go to localhost:8069/@/contactus - start chatbot and select some answer - receive traceback task-[5881970](https://www.odoo.com/odoo/project/1519/tasks/5881970)
This update resolves an issue where navigating back from the message search panel on mobile devices resulted in a technical error (traceback). The fix ensures a smooth navigation experience by correctly handling back button presses within the search panel, aligning with established design patterns for similar components. This improves usability for mobile users.
Original PR description
...in mailboxes on mobile * = crm_livechat, im_livechat Enterprise PR: https://github.com/odoo/enterprise/pull/110150 Before this commit, navigating back from a mailbox message search panel on mobile would result in a traceback. Steps to reproduce: 1. Open Discuss on mobile 2. Navigate to bookmarks in bottom bar 3. Open message search 4. Navigate back -> traceback This happens because the `useBackButton` in ActionPanel registers a callback function taken from the env. Said function is missing when the ActionPanel is mounted outside of a chat window or meeting view. This commit fixes the issue by adding a `close` props to ActionPanel, and using that as a callback for back navigation. This is an established pattern for similar closable components like Popover, Dialog and EmojiPicker. task-6013922
This update fixes a bug on mobile devices where navigating back from the message search panel in Live Chat would cause an error. The fix ensures a smoother user experience by correctly handling back navigation within the ActionPanel component, aligning with established design patterns.
Original PR description
...in mailboxes on mobile community PR: https://github.com/odoo/odoo/pull/252512 Before this commit, navigating back from a mailbox message search panel on mobile would result in a traceback. Steps to reproduce: 1. Open Discuss on mobile 2. Navigate to bookmarks in bottom bar 3. Open message search 4. Navigate back -> traceback This happens because the `useBackButton` in ActionPanel registers a callback function taken from the env. Said function is missing when the ActionPanel is mounted outside of a chat window or meeting view. This commit fixes the issue by adding a `close` props to ActionPanel, and using that as a callback for back navigation. This is an established pattern for similar closable components like Popover, Dialog and EmojiPicker. task-6013922
This update resolves an issue preventing users from generating reports in the Belgian Payroll module. The fix automatically saves the data before report generation, addressing a technical error that caused failures. This ensures consistent and reliable report creation for users.
Original PR description
**Steps to reproduce:** - Open Belgian Payroll - From Reporting Menu select 274.XX Sheets - Create New Sheet - Select a Year and a month with Eligible Employees > 0 (for the Generate dropdown to be enabled) - Press Generate button and then try to generate any form (do this directly without pressing save manullay button) **Issue:** The generation of any form (PDF, XML, XLSX) fails due to the receive of an empty self. **Fix:** If the user tried to generate the reports without saving, do an automatic save internally before attempting to generate the reports in the backend. task-5936740
This update resolves an issue where deleting an account move in the l10n_sa module could trigger a crash. The fix addresses a problem within the system's attachment handling, preventing errors when removing associated records. This ensures smoother operation and prevents data loss during account move deletion.
Original PR description
Since https://github.com/odoo/odoo/pull/242777 the deletion of an account.move may crash. Indeed, the deletion of the move delete its corresponding attachments, and ir.attachment has an ondelete method that checks the attached move, namely _unlink_except_posted_pdf_invoices(). The method checks some condition on the corresponding moves, which have just been deleted, hence raising a MissingError. runbot_build_error-237850 Forward-Port-Of: odoo/odoo#252808
This update fixes an issue where accrual calculations for stock-based orders were inaccurate, particularly when orders were partially delivered. Now, accrual lines are created separately for each sale order line, providing a more precise accounting of invoiced and delivered quantities and their associated unit prices. This ensures accurate financial reporting for sales and purchase orders involving stock.
Original PR description
### [FIX] (stock_)account: cost method
> Before this commit, we tried to access to `product.product` `cost_method` field in `account` module.
> The issue is: this field is defined in `stock_account` which means we can try to read an unexisting field if we try to generate accruals from a sale order or a purchase order without `stock` installed.
>
> This commit creates an helper method, overrided in `stock_account`, to avoid this issue.
### [FIX] account: split stock variation accrual lines
> Before this commit, accrual lines created for stock variations in case of already incoived not delivered quantities were summed together.
> This commit keeps them separate: one line by sale order line.
>
> Also, those lines' label is rewritten to be more specific, giving the amount of invoiced and delivered qties, and with what unit price.
task-5934232
Forward-Port-Of: odoo/odoo#250408This update fixes an issue where payslips weren't being created correctly for employees with flexible working hours. The change ensures that work entries are generated for all employees, regardless of their working hours configuration, leading to accurate payroll calculations. This resolves a previous error impacting employee pay reporting.
Original PR description
**Version:** - 19.0 **Steps to reproduce:** - Create an employee. - Leave the Working Hours field empty. - Set the contract dates and a wage. - Create a payslip using the smart button. **Issue:** - Worked day lines are empty for flexible employees when the payslip is created from the smart button. **Cause:** - Flexible employees were being skipped because their working hours were empty, which results in work entries not being generated. **Solution:** - Updated the condition to also generate work entries for flexible employees. Task-5431870 Forward-Port-Of: odoo/enterprise#109497 Forward-Port-Of: odoo/enterprise#103101
13 changes
Resolved issues and error corrections
This update fixes a minor issue where users received a warning about leaving a chatbot conversation even after it had already ended. Now, the warning only appears when a conversation is actively in progress, providing a smoother and less disruptive user experience. This change ensures a more intuitive flow for users interacting with the chatbot.
Original PR description
Before this commit: When a user finishes a chatbot script and the conversation is already ended, clicking on close / continue still triggers the leave conversation warning. After this commit: The leave conversation warning is no longer shown when the chatbot conversation is already closed or ended. The warning is only shown for active conversations. [Task-5882084](https://www.odoo.com/odoo/project/1519/tasks/5882084) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252622 Forward-Port-Of: odoo/odoo#247918
This update fixes an issue where the sale preview became bloated when using combo products with the 'Hide Composition' option. The change prevents the system from displaying incorrect zero-priced sections, resulting in a cleaner and more efficient preview experience. This improves the overall user experience when managing quotes with combo items.
Original PR description
**Behavior:** When a combo product is added under a section and the 'Hide Composition' option is selected the system will try to get a list of the prices grouped by different taxes, however since combo items usually don't cost anything and are not under any tax group, the quotation preview will try show the section's total prices under no tax which will likely amount to 0$ This results in a bloated preview. Solution: Only accept a grouping under a specific tax (be it no tax or a real tax) if the total price != 0$ **Steps to reproduce:** - Create a combo product containing a product that is taxed - Create a quote with a section - Add the product under the section - Check 'Hide Composition' in the section's options - Preview the sale - You'll notice the section duplicated with no tax and no price opw-5481931 Forward-Port-Of: odoo/odoo#245866
This update resolves a visual issue where list views with search panels (like Rental or Employees) would sometimes display a horizontal scroll bar. This change ensures that list views with search panels display data correctly on mobile devices, providing a consistent and usable experience for users. The fix was implemented to improve the overall user experience and prevent data from being hidden.
Original PR description
This PR aims to fix the horizontal scroll overflow which only affects list views with a search panel (e.g. Rental, Employees, etc.). task-5888678 | Before | After | |--------|--------| | <img width="1125" height="2436" alt="Screen Shot 2026-02-19 at 15 29 15" src="https://github.com/user-attachments/assets/b89d2979-78a8-4c58-8f7f-7dedb6fc8fff" /> | <img width="1125" height="2436" alt="Screen Shot 2026-02-19 at 15 30 10" src="https://github.com/user-attachments/assets/0989b6e7-ef91-43b5-8df5-c27696d43f65" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249506
This update resolves an issue preventing demo users from creating sales orders when project user group permissions were restricted. The fix adjusts how the system accesses project information, now allowing SO creation regardless of project group settings. This expands user access and simplifies the sales order creation process.
Original PR description
Issue: --- Users cannot create so without project user group. Steps to reproduce: --- 1- Install `sale_timesheet`, `sale_project` 2- Change demo user access: - Sales: own documents - Timesheets: own documents - Project: No 3- Login demo user and create a SO. SO creation fails on `read` operation on `project_count`. Cause and Fix: --- This is due to `_compute_show_hours_recorded_button`, which needs `project_count` to be computed. However, `SO.project_count` is only accessible by `project.group_project_user`. This can be fixed by a `compute_sudo` on show_hours_recorded_button. Security-wise this should be fine, as `show_hours_recorded_button` itself is only accessible by `hr_timesheet.group_hr_timesheet_user`. opw-5944881 Forward-Port-Of: odoo/odoo#250694
This update corrects a bug where pressing ALT+P in the asset management module incorrectly navigated to the Posted Entries view instead of the previous asset. The shortcut has been changed to ALT+SHIFT+P to align with existing functionality and improve user experience.
Original PR description
# How to reproduce - Have atleast two assets - Go to the last asset - Type ALT + P on your keyboard # The problem We enter the Posted Entries view instead of going to the previous asset # Why This PR (https://github.com/odoo/enterprise/pull/67840) added shortcuts to the asset form view, but used ALT + P for the Posted Entries. This shortcut is already used on all form views for the "previous page" button. After consulting with the developer of the original PR, we decided to move the Posted Entries shortcut to ALT + SHIFT + P opw-5948523 Forward-Port-Of: odoo/enterprise#109022
This update fixes a bug where POS sessions weren't correctly calculating and posting COGS when using 'real-time' product valuation. The change ensures COGS are accurately recorded regardless of the valuation setting, resolving a potential issue with inventory accounting. This improves the reliability of POS financial reporting.
Original PR description
When the product category valuation is set to `real_time` but the company is set to `periodic`, the POS session closing was not posting COGS entries as expected. If the product category valuation is…
When the product category valuation is set to `real_time` but the company is set to `periodic`, the POS session closing was not posting COGS entries as expected. If the product category valuation is set to `real_time`, it should always prevail over the company setting. And if no valuation is set on the product category, then the company setting should be used. Steps to reproduce: ------------------- * Create a product category with `Inventory Valuation` set to `real_time` (Perpetual). * Create a product in this category and make sure it is storable and has a cost price. * Set the company `Inventory Valuation` to `periodic` (Periodic). * Create a POS order with this product and pay it. * Close the POS session. > Observation: In the session no COGS entries are created for the sold product. Why the fix: ------------ We adapt the `_search_valuation` to correctly fallback on the company setting only if the product category valuation is not set. It was not working before because in some cases the product had no company set (it means that it is visible to all companies) and the domain was not matching. To fix that we check that the current company matches the search value, and if it does we also match all the products without company set. We also adapt the PoS code to use the `product_id.valuation` field to filter all the stock_moves that should create COGS entries when closing the session. opw-5885960 Forward-Port-Of: odoo/odoo#247011
This update optimizes the Point of Sale (POS) system to significantly reduce memory consumption, particularly when handling large product catalogs. The changes result in a substantial decrease in memory usage across Chrome, Safari, and Firefox, leading to a smoother and more responsive POS experience.
Original PR description
This commit reduces memory consumption in the POS, especially when loading a large number of products. Reactivity usage has been optimized, particularly for product data. Additional optimizations were implemented to handle large product sets more efficiently. Metrics 5,000 products • Chrome: 440 MB → 75 MB • Safari / Firefox: 1 GB → 250 MB 20,000 products • Chrome: 1.5 GB → 135 MB • Safari / Firefox: 4 GB → 300 MB Enterprise PR: https://github.com/odoo/enterprise/pull/107978 Forward-Port-Of: odoo/odoo#249542
This update optimizes the Point of Sale system to use less memory, particularly when handling a large number of products. The changes result in significantly reduced memory consumption across browsers, leading to a smoother and more responsive user experience for our retail customers.
Original PR description
This commit reduces memory consumption in the POS, especially when loading a large number of products. Reactivity usage has been optimized, particularly for product data. Additional optimizations were implemented to handle large product sets more efficiently. Metrics 5,000 products • Chrome: 440 MB → 75 MB • Safari / Firefox: 1 GB → 250 MB 20,000 products • Chrome: 1.5 GB → 135 MB • Safari / Firefox: 4 GB → 300 MB Community PR: https://github.com/odoo/odoo/pull/249542 Forward-Port-Of: odoo/enterprise#107978
This update ensures that customers receive receipt emails only after their online self-order payment has been successfully validated. Previously, emails were sent prematurely, potentially confusing customers about the status of their order. This change improves the customer experience by aligning receipt notifications with actual payment success.
Original PR description
In self-order with online payment, the receipt email could be sent when the order was created (before payment validation), which confirms the order too early for customers. This change ensures receipt sending is aligned with actual payment success in the online self-order payment flow. Steps to reproduce: ------------------- * Configure self-order with a preset that has a receipt mail template. * Place a non-zero self-order using online payment and reach the payment step. * Check customer mailbox before validating payment. > Observation: A confirmation email can be sent before the payment is confirmed. Why the fix: ------------ Receipt emails must reflect a successful payment outcome, not just draft order creation. The online self-order payment success path now triggers receipt sending after the order transitions from draft to paid/done, preventing premature emails. opw-5938299 Forward-Port-Of: odoo/odoo#251220
This update prevents the deletion of attachments when removing them from email templates. Previously, removing an attachment from the email composer would permanently remove it from the template, requiring re-creation. This change ensures attachments remain linked to templates, streamlining the email sending process.
Original PR description
**Step to reproduce:** 1. Install `sale_management` 2. Open any email template (e.g., Sale: Order Confirmation). 3. Add an attachment to it 4. Create a Sale Order, confirm it, and click "Send by…
**Step to reproduce:** 1. Install `sale_management` 2. Open any email template (e.g., Sale: Order Confirmation). 3. Add an attachment to it 4. Create a Sale Order, confirm it, and click "Send by Email". 5. In the mail composer, remove the template attachment **Issue:** - The removed attachment is deleted from the database (`ir.attachment`). Consequently, the attachment is permanently removed from the source Email Template and will not appear in future emails. **Cause:** - The `onFileRemove` function in `MailComposerAttachmentList` calls the `unlink` method of the `attachmentUploadService` for every file removed, without considering the existing template attachment. **Solution:** 1. Update `mailComposerAttachmentList` to include `res_model` in `relatedFields` so it is fetched from the server. 2. In `onFileRemove`, check the `res_model` of the attachment. 3. If the `res_model` is not "mail.compose.message", skip the database deletion (unlink) and only remove it from the composer view. opw-5163679 Forward-Port-Of: odoo/odoo#249257 Forward-Port-Of: odoo/odoo#238692
This update fixes an issue where part-time flexible employees were incorrectly showing a full-time work week (40 hours) instead of their actual scheduled hours (e.g., 24 hours). The change ensures that the system accurately reflects the employee's flexible schedule, improving reporting and scheduling accuracy.
Original PR description
### Issue: When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.…
### Issue:
When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.
### Steps to reproduce:
- Have an employee with a part-time flexible schedule
- `full_time_required_hours`: 40
- `hours_per_week`: 24
- `hours_per_day`: 8
- Go in Attendances
- Hover the employee
- It shows ...h/40h but it should show ...h/24h
### Cause:
In `_attendance_intervals_batch()` we build theoretical attendances for flexible employees. Starting at the start of the week, we add an attendance of `hours_per_day` each day until we reached `full_time_required_hours`.
In the case above, we would return five attendances of 8h, ignoring `hours_per_week`.
Then `_get_attendance_intervals_days_data()` counts the hours to display them in the Gantt view.
### Solution:
In `_attendance_intervals_batch()` we use `hours_per_week` instead of `full_time_required_hours` as the weekly limit of hours per week.
A lot of tests needed to be adapted, as they were specifying `full_time_required_hours` but not `hours_per_week` when creating calendars.
opw-5973117
Forward-Port-Of: odoo/odoo#252190This update fixes an issue where part-time employees were incorrectly displaying their maximum weekly hours. The system now accurately uses the employee's defined 'hours_per_week' as the limit, ensuring accurate hour calculations and display in the employee's schedule. This improves the scheduling accuracy for flexible staff.
Original PR description
### Issue: When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.…
### Issue:
When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.
Steps to reproduce:
- Have an employee with a part-time flexible schedule
- `full_time_required_hours`: 40
- `hours_per_week`: 24
- `hours_per_day`: 8
- Go in Attendances
- Hover the employee
- It shows ...h/40h but it should show ...h/24h
Cause:
In `_attendance_intervals_batch()` we build theoretical attendances for flexible employees. Starting at the start of the week, we add an attendance of `hours_per_day` each day until we reached `full_time_required_hours`.
In the case above, we would return five attendances of 8h, ignoring `hours_per_week`.
Then `_get_attendance_intervals_days_data()` counts the hours to display them in the Gantt view.
Solution:
In `_attendance_intervals_batch()` we use `hours_per_week` instead of `full_time_required_hours` as the weekly limit of hours per week.
A lot of tests needed to be adapted, as they were specifying `full_time_required_hours` but not `hours_per_week` when creating calendars.
opw-5973117
Forward-Port-Of: odoo/enterprise#109645This update resolves an issue preventing users from replying to messages received from other companies within Odoo. Previously, attempts to respond resulted in an error. Now, replies are correctly logged when the user has access to the company from which the message originated, improving communication across multiple businesses.
Original PR description
Before these changes, messages from other companies were received, but when trying to reply to them, an error occurred that prevented the response. Steps to reproduce the issue in runbot: 1. In one tab, log in as admin, and in another incognito tab, open demo. 2. Make sure demo has Handle Notifications in Odoo enabled. 3. Set admin in one company and demo in another company. 4. Assign a task to demo. 5. Click on the notification to open the chatter and try to reply. An error is thrown With these changes, the response can be logged when the user has access to the company from which the task was assigned. cc @Tecnativa TT61176 ping @pedrobaeza --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251555 Forward-Port-Of: odoo/odoo#250677
2 changes
Resolved issues and error corrections
This update corrects a bug where archived employee versions were incorrectly included in payroll pay runs. The fix ensures that only currently active employees are processed, preventing inaccurate payroll calculations and reporting. This improves data accuracy and compliance.
Original PR description
Steps to reproduce: 1. Create an employee with a contract for this month 2. Archive the employee (but not the version) 3. Create a pay run 4. The employee's version will appear in the list Cause: The domain takes versions for archived employees. Fix: Add active_employee in the domain. Task: 6022437
This update resolves an issue where payments with outstanding receipts accounts weren't automatically matched in the bank statement reconciliation process. The fix allows for amount matching, ensuring payments are correctly linked to invoices and bank transactions when the outstanding receipts account is active. This improves the accuracy of financial reporting.
Original PR description
Steps to reproduce - Have a Bank journal with Outstanding Receipts accounts set - Create and confirm an invoice with a payment reference - Create the payment - Create a bank transaction with: - Label: any label - Partner: invoice partner - Amount: invoice full amount Issue: Transaction won't be matched automatically Analysis: Transaction will be automatically matched if the outstanding receipts account is not set. It occurs because in case it is set, the sytem will only try to match the communication pattern against the journal item of the payment, without trying amount matching Note: another solution could be to relax the communication matching. In the user case the invoice payment reference is something like `TEST-12345` and the payment communication `AAAAAAAAAAA /BBBBBBBBBBB TEST 12345` opw-5872387 Forward-Port-Of: odoo/enterprise#108564
2 changes
Resolved issues and error corrections
This update fixes a minor display issue where a small floating-point number was appearing in down payment percentages for sale orders. The fix ensures that percentages are rounded correctly, providing a more accurate and professional presentation of payment information. This improves the user experience when accepting and paying for sales.
Original PR description
Issue: --- Due to this issue, a small floating point is shown in down payment percentage of a sale order. Steps to reproduce: --- 1- Create a sale order with lines. 2- From `other info` tab, uncheck `online signature` and check `online payment`, and set it to 14 percent. 3- Click on preview. 4- Click on `Accept & Pay`. The percentage shown is `14.000000000000002`, which is unexpected. Fix: --- By setting the percentage as `float` widget it will be rounded properly: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/odoo/addons/base/models/ir_qweb_fields.py#L185-L208 opw-5975047 Forward-Port-Of: odoo/odoo#252169
This update fixes an issue where certain salary deductions weren't being properly calculated in the Kenyan payroll module. The changes add four new lines to the 'Total deductions' line, adjusting their sequence and sign to accurately reflect attachments of salary, ensuring correct net pay calculations for employees in Kenya.
Original PR description
**Behavior before this commit** Some salary rules (e.g. `ATTACH_SALARY`) were ignored in the NET calculation. **Behavior after this commit** - Four rules are now added to the "Total deductions" line: their sequence and category has been changed. - The sign of these lines has also been switched: an attachment of salary of a positive amount should be added to the amount of total deductions, which is then deducted from the net.  opw-5894647 Forward-Port-Of: odoo/enterprise#107033
8 changes
Resolved issues and error corrections
This update fixes a bug in the softphone's contact search, ensuring it now uses the full partner name instead of just the name. This provides more accurate search results and a better user experience when finding contacts within the softphone application. The change includes updates to both the backend Python code and the frontend JavaScript.
Original PR description
Search by partner's name in softphone should be based on complete_name, while it's currently based on name. To fix it, we do two fixes in this commit: 1. On the python side, make sure voip.call search is based on complete_name like in res.partner. No change for mail.activity search, since it always get all record. When do the search, we also make sure the search_term is escaped so that it won't trigger psql's wildcard. 2. On the js side, make sure we filter the results by complete_name. Task-[5475413](https://www.odoo.com/odoo/5778/tasks/5475413)
This update fixes a problem where users were encountering error pop-ups when accessing the payroll dashboard after making schedule changes. The issue stemmed from an outdated warning update process, now resolved by ensuring updates are performed with elevated permissions. This improves the stability and usability of the payroll module for all users.
Original PR description
Bug production: select your company -> payroll dashboard -> set schedule -> return back to apps -> change to belgium comp. -> payroll dashboard -> try to set schedule -> access error pop ups Bug cause: There is a warning update part when the dashboard is opening, in that part updating other company's warning leads to problems. Bug solution: Make the warning update as sudo task - 5958991
This update fixes an issue where icons were incorrectly displayed on small screens within the VoIP form. The change ensures that icons are only shown on desktop views, aligning with the overall form layout and improving the user experience. This ensures consistent visual presentation across different device sizes.
Original PR description
We only want these icons on desktop, as the content is not aligned with the rest of the form view. On small screens, each field is displayed one below the other, regardless of whether it is inside a header_group or not. So icons have been replaced by the label (which doesn't appear on desktop). task-6010516
This update fixes an issue where YTD payroll calculations were inaccurate after enabling YTD tracking on existing payslips. The change ensures that YTD amounts are consistently computed and displayed correctly, resolving confusion around worked days and salary totals. The YTD checkbox in structures now only controls UI visibility.
Original PR description
Steps: - Take any structure and ensure the YTD option is turned off in that structure. - Go to Payroll > Payslips and create a few payslips with that structure. Confirm them. - Now, enable the YTD…
Steps: - Take any structure and ensure the YTD option is turned off in that structure. - Go to Payroll > Payslips and create a few payslips with that structure. Confirm them. - Now, enable the YTD setting in that structure. - Open those confirmed payslips and check the YTD amount. It's not accurate. Issue: - When YTD tracking was enabled after confirming some payslips, the worked days section showed zero in the YTD column. - This caused confusion because: - The salary line YTD showed the current payslip’s amount, - The worked days YTD showed 0. Both should accurate. - YTD values were only computed if ytd_computation was enabled during compute_sheet method. - As confirmed payslips aren’t recomputed, worked days showed 00 YTD amount, when the setting was turned on later. Fix: - Removed conditional checks on 'ytd_computation' from the YTD calculation logic. - YTD values are now always computed and available on payslips and worked days. - The 'ytd_computation' checkbox in structure is retained only for visibility toggling. - e.g. showing/hiding YTD columns in payslips, reports or UI. Task - 4790749
This update resolves an issue where the Documents app would crash after deleting a payslip run. The fix ensures that associated documents are also deleted when the payslip run is removed, preventing data inconsistencies and improving application stability. This improves the user experience when managing payroll documents.
Original PR description
### Issue: When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app. ### Steps to reproduce: - Have a…
### Issue: When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app. ### Steps to reproduce: - Have a payslip run with payslips - Go to a payslip, validate and generate the document - Then cancel and reset to draft - Reset the Payslip Run to draft - Delete it - Open the Documents app ### Cause: The payslips are linked to the run with a `ondelete='cascade'` relation. https://github.com/odoo/enterprise/blob/03b2a7dae0e5c5ad3142ec2da8f3de5c9b1957f4/hr_payroll/models/hr_payslip.py#L110-L113 This means that deleting the run also deletes its payslips on a database level, bypassing the ORM. As the document is not directly linked by a relational field but instead by `res_model` and `res_id`, these fields are not updated and therefore are still pointing to a record that is no longer in DB. ### Solution: Extend the `unlink()` method in `hr.payslip.run` and unlink the documents there. opw-5501061 Forward-Port-Of: odoo/enterprise#109741 Forward-Port-Of: odoo/enterprise#105969
This update fixes an issue where employees with flexible calendars were incorrectly displaying unavailable days in planning and related modules. The change ensures that flexible employees only show unavailable times for public holidays, improving the accuracy of scheduling and resource allocation. This resolves a visual discrepancy impacting how employees see their availability.
Original PR description
### Issue: When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible…
### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.
### Steps to reproduce:
- Create a new work schedule:
- Flexible Hours
- 24 hours per week
- 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out
### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).
### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.
To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.
Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.
In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.
In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.
Forward-Port-Of: odoo/enterprise#109812
Forward-Port-Of: odoo/enterprise#105521This update enhances the Time Off Gantt view by displaying total worked hours directly on the progress bar and providing more direct actions – Approve and Refuse – instead of a general Save button. These changes streamline the approval process and improve the overall user experience for managing employee time off requests.
Original PR description
Changes Show total worked hours in the progress bar before the employee name. Remove the Save button from the popover and add Approve and Refuse buttons for direct action. Remove the Reset button from the Gantt view. UX improvements: Show the deferred icon on the pill. Fix popover margins and remove unnecessary message. task-5941368 Forward-Port-Of: odoo/enterprise#107938
This update resolves an issue where duplicate move records were being displayed in the shop floor view, leading to a technical error. The fix clarifies how work orders and moves are linked, ensuring accurate display of components and preventing the 'duplicate key' error. This improves the user experience when creating and managing work orders.
Original PR description
*: {quality_,}mrp_workorder, quality_mrp_workorder_worksheet ### Steps to reproduce: - Enable debug mode (to trigger a traceback rather than a silent error) - In the settings, enable `Work Orders` -…
*: {quality_,}mrp_workorder, quality_mrp_workorder_worksheet
### Steps to reproduce:
- Enable debug mode (to trigger a traceback rather than a silent error)
- In the settings, enable `Work Orders`
- Create an MO for a product without a BoM
- Add an operation to be performed in a workcenter
- Confirm the MO and open the Shop Floor
- Enable the workcenter of your operation, switch to it, and click on the three dots at the bottom right of the operation display
- Click on `Add component` and add any valid component via the catalog
#### > Traceback: `OwlError: Got duplicate key in t-foreach`
### Cause of the issue:
The rendering error is raised by the `MrpDisplayRecord` template: https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L69-L72
Two moves with the same `id` are provided to the template. Which is unexpected since the `moves` getter should not return the same move twice:
https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L174-L188
However, neither of the two move pools is well defined. The issue stems from the confusing `operation_id` field, which should rather be `workorder_id`. Currently, the moves associated with the MO are those not linked to an `operation_id` (i.e., not linked to an `mrp.routing.workcenter` from the BoM), whereas they should instead be those linked to a `workorder_id`, representing an operation of the MO: https://github.com/odoo/odoo/blob/0d7e3d4c0ea976e37871ca44a10a442cce7caa85/addons/mrp/models/stock_move.py#L43-L47
Similarly, moves linked to workorders are only those matching the same `operation_id` as the workorder. This can only happen when the workorder is generated from the BoM and therefore has a set `operation_id`, or when both are `False`. In the latter case, all moves unlinked to any `operation_id` are displayed on all operations not generated by the BoM, which is again completely unexpected.
In the present case, our operation has not been generated from the bom and hence will fall in both move pulls for the unexpected reason leading to the duplicate key-error.
Community: https://github.com/odoo/odoo/pull/250966
opw-5417887
Forward-Port-Of: odoo/enterprise#1062001 change
Resolved issues and error corrections
This update fixes an issue where sign requests generated from HR wizards didn't automatically use the expiration dates defined on the sign templates. Now, all sign requests will adhere to the template's configured validity period, ensuring accurate tracking and preventing outdated requests.
Original PR description
Before, when sending sign requests from the HR custom wizards, the validity date defined on the sign template was not applied to the generated signature requests. As a result, requests were created without respecting the template’s configured expiration. task-5928110
5 changes
Resolved issues and error corrections
A test was failing due to an issue with how the system calculates the initial date for planning features. This fix corrects a time zone calculation error that resulted in an incorrect date being used in the test. This ensures the planning functionality operates correctly across different time zones.
Original PR description
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ##…
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ## Origin of the issue In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future. X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e note: backport of https://github.com/odoo/enterprise/pull/108891
This update corrects a bug in the accrual leave calculation that was causing February accruals to be missed. The fix ensures that leave is correctly accrued monthly, preventing delays in accrual calculations. This ensures accurate tracking of employee leave balances.
Original PR description
steps to reproduce: ------------------- 1. Install Time Off 2. Go to Configuration > Accrual Plans 3. Create an accrual plan: * Set the accrued gain time to "At the start of the accrual period" * Set…
steps to reproduce: ------------------- 1. Install Time Off 2. Go to Configuration > Accrual Plans 3. Create an accrual plan: * Set the accrued gain time to "At the start of the accrual period" * Set the carry-over time to "At the start of the year" 4. Create a milestone: * Set the number of accrued days to 1 * Set the accrual frequency to "monthly" and the carry over to "None.Accrued time reset to 0" 5. Go to Management > Allocations 6. Create an allocation: * Set the start date to 2025-01-01 * Set the accrual plan to the one created above 7. Use future allocations to check accruals current behavior: ----------------- - On 2026-01-01 --> accrued days = 1 (correct) - On 2026-02-01 --> accrued days = 1 (should be 2) - On 2026-03-01 --> accrued days = 2 (delayed accrual, off by one month) cause of the issue: ------------------- Commit 30c7011 introduced a condition that accrues time off on the carry over date: https://github.com/odoo/odoo/blob/1416aad902a97ce56aaecc2aadc4dd9f7814ee53/addons/hr_holidays/models/hr_leave_allocation.py#L559 This incorrectly evaluates accruals across the carry over period instead of restricting to the current month, causing February accruals to be skipped. **Reason February accruals are skipped:** https://github.com/odoo/odoo/blob/dcb072f675c5630327d27d785b86e1ec8e2d442d/addons/hr_holidays/models/hr_leave_allocation.py#L559-L561 https://github.com/odoo/odoo/blob/dcb072f675c5630327d27d785b86e1ec8e2d442d/addons/hr_holidays/models/hr_leave_allocation.py#L541-L544 * After January, the last_executed_carryover_date is set to 2026-01-01. * Therefore, February uses last_executed_carryover_date = 2026-01-01. * The condition evaluates as true for February: ```python3 last_executed_carryover_date <= allocation.nextcall <= carryover_period_end 2026-01-01 <= 2026-02-01 <= 2026-02-01 ``` As a result, the February accrual is skipped. **Why it works correctly in March:** * After February, the last_executed_carryover_date is updated to 2027-01-01. * March now uses this updated date: ```python3 last_executed_carryover_date <= allocation.nextcall <= carryover_period_end 2027-01-01 <= 2026-03-01 <= 2027-02-01 ``` The condition is not satisfied, so accruals are processed correctly. solution: ---------- Add a condition to check if the loop has already run for the current carryover period. This ensures the system avoids applying the carryover twice, allowing subsequent accruals to process as expected. opw-5020834 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where multiple picking operations were created when reducing the quantity of a kit product on a sales order. The fix corrects a calculation error within the Odoo system's inventory management process, ensuring accurate procurement generation for kit deliveries with multi-step workflows. This prevents unnecessary stock movements and improves order fulfillment.
Original PR description
Backport of 0432a982dfea6e68419f137502c018c0a9241181 ### Steps to reproduce: 1. In the settings enable: Multi-steps route 2. Put your warehouse in 2-step deliveries 3. Create a kit product: - With…
Backport of 0432a982dfea6e68419f137502c018c0a9241181 ### Steps to reproduce: 1. In the settings enable: Multi-steps route 2. Put your warehouse in 2-step deliveries 3. Create a kit product: - With one component - There is one component in the stock 4. Create and confirm a SO with 1 x K 5. Process the pick and ship 6. Return the delivery 7. Set the sol qty to 0 ### > Two unexpected pickings are created to put the kit in output Decreasing the sol quantity to 0 will call the `_action_launch_stock_rule` in order to create and run procurements related to that quantity change. However, the quantity currently handled by other procurements is determined here by the `_compute_kit_quantities`: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_stock/models/sale_order_line.py#L388 https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_mrp/models/sale_order_line.py#L154-L166 https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/mrp/models/stock_move.py#L578-L580 Now, the issue is that `_compute_kit_quantities` does not handle move chains properly, as all delivery moves contribute to the `incoming_qty` and all return moves contribute to the `outgoing_qty`. This results in an `incoming_qty` of 1 (for the pick) + 1 (for the ship) and an `outgoing_qty` of 1 (for the 1-step return), that is a `qty_processed` of 1. As a result, the procurement will be generated for a quantity of `0 - 1` (rather than 0): https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_stock/models/sale_order_line.py#L388-L402 which leads to the unexpected picking creations. opw-6006543 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the performance of the Point of Sale (POS) system by only loading loyalty cards that meet specific criteria – namely, the associated customer and program are loaded, and the card has points. Previously, loading all loyalty cards, even inactive ones, caused slowdowns, especially with large customer lists. This change significantly improves POS responsiveness.
Original PR description
Before this commit: ------------------------------------------------------------------- - All loyalty cards of a program were loaded into IndexedDB when opening the POS. - For large datasets (e.g., 100k+ cards), this caused performance issues and slowed down the system. After this commit: ------------------------------------------------------------------- - Only loyalty cards matching the following criteria are loaded: - The related partner is loaded. - The related active program is loaded. - Card points > 0. This optimization significantly reduces unnecessary data loading and improves POS performance. task - 4966308 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures Odoo complies with new NACHA regulations regarding payroll payments. Starting March 2026, the Company Entry Description field in NACHA transactions must include 'PAYROLL'. This change is necessary to maintain compliance and avoid potential payment issues.
Original PR description
Starting March 20, 2026, NACHA requires the Company Entry Description field to contain "PAYROLL" for paying wages, salaries, or compensation [1]. [1] https://www.nacha.org/rules/risk-management-topics-company-entry-descriptions task-5981941
2 changes
Resolved issues and error corrections
This update corrects an error in the documentation for a key Odoo date utility function. The original description was misleading, reflecting incorrect behavior. This change ensures the documentation accurately represents the function's purpose and improves clarity for developers.
Original PR description
Docstring was probably copied from `start_of` and not fixed up, so described the wrong semantics. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects an issue in the demo data for the MRR report on sale orders. The change ensures the report accurately reflects MRR calculations by setting an initial MRR value of 15 for the subscription_log_2 demo record in version 17.0, improving the demo's realism.
Original PR description
The MRR report on sale orders uses sale.order.log files to track changes in MRR over time. This demo data may be useful to show how the MRR report should look in a real database, as it is difficult to replicate historical logs functionally. In version 17.0, the sale order subscription_log_2 should have an initial MRR of 15.