Tuesday, June 9, 2026
12 changes · saas-18.3
Resolved issues and error corrections
This update corrects a bug in how leads are assigned to sales teams, ensuring a more equitable distribution of leads. Previously, team members created earlier received a disproportionate number of leads, particularly when quotas were equal. The fix introduces random tie-breaking to ensure fair lead assignment across the team.
Original PR description
_assign_and_convert_leads() is biased towards team members created earlier because they're ordered by create_date, id. When members have equal quota, the round-robin order falls back to the order of the team members. If the amount of leads distributed across the team is not a multiple of the team size, then the oldest members will get more leads assigned. This advantage repeats each time the cron runs and can add up to a big difference, the provided test case ends up assigning all 30 leads to the more senior member without the fix. Note that the lead_day_count field used in _get_assignment_quota() doesn't solve the problem. It helps to balance leads assigned in the same 24 hour window, but because the same senior person always goes first inside one of those windows, they will always get more leads assigned to them. To fix it we break ties in the quota randomly. task-6119168 Forward-Port-Of: odoo/odoo#268350 Forward-Port-Of: odoo/odoo#259775
This update fixes a visual issue in the portal chatter interface where elements like the Follow/Unfollow button appeared misaligned due to excessive padding. The problem was caused by a duplicated padding setting that has now been removed from the core code. This ensures a cleaner and more professional appearance for portal users.
Original PR description
**Steps to reproduce:** 1. Log in as a portal user. 2. Open a shared project and then open any task within it. 3. Observe the vertical spacing above the Follow/Unfollow button and the chatter component. **Issue:** The chatter UI has incorrect vertical spacing, causing elements like the Follow/Unfollow button to sit too far down and appear misaligned. **Cause:** The pt-2 padding class was hardcoded in two separate locations: 1. The compileChatter wrapper in project_sharing_form_compiler.js. 2. The portal.Chatter XML template. When combined this caused a double-padding effect forcing excessive space. **Fix:** Removed the hardcoded pt-2 class from both the JavaScript compiler wrapper and the core XML template. This eliminates the double-padding conflict. This resolves the alignment issue in Project Sharing and does not affect the layout or functionality of other portal components. task-4203362 Forward-Port-Of: odoo/odoo#257490
This update ensures the KSeF vendor bill download cron job continues to run even if some XML files are corrupted. Previously, a single error would halt the entire process. Now, errors are logged, and the cron job successfully processes the remaining valid invoices, preventing data loss.
Original PR description
Description of the issue/feature this PR addresses: Issue: When downloading vendor bills from KSeF via the cron, the system attempts to parse the XML files sequentially. If a single XML file is…
Description of the issue/feature this PR addresses: Issue: When downloading vendor bills from KSeF via the cron, the system attempts to parse the XML files sequentially. If a single XML file is missing something that is expected, the parser raises a UserError. This unhandled exception halts the entire cron job and rolls back the database transaction, clogging up the rest of the queue. Solution: This PR wraps the l10n_pl_edi_get_ksef_bill_vals_from_xml parsing step inside a try/except block within the batch download loop. If a UserError is encountered for a specific invoice, the error is logged as a warning, and the cron proceeds. Current behavior before PR: A single malformed XML file causes the cron to fail completely. Valid invoices in the same batch are not created due to the halted queue. Desired behavior after PR is merged: The cron successfully processes the batch of downloaded XMLs even if one or more files are invalid. Errors on specific invoices are logged for the user to investigate, while the rest of the valid vendor bills in the batch are succesfully created. opw-6218288 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268681 Forward-Port-Of: odoo/odoo#267816
This update corrects a bug where new lines added to sales orders from deliveries were missing descriptions. Now, when a delivery line is created, the corresponding sale order line automatically uses the product's existing description, ensuring accurate record-keeping and improved reporting. This prevents inconsistencies in sales order details.
Original PR description
When a line is added to a delivery related to a sale order, the corresponding line created in the sale order uses only the display_name as a description. This commit makes sure that if a previous SO line exists for the product, the new line uses the same description. Otherwise we call `get_product_multiline_description_sale()` Steps to reproduce: - Create a product with a description in the Sales tab - Create a quotation with any product (can be said product) and confirm it - Go to the delivery action, and add a new line with the product in the view, set delivered quantity to 1 - After Validating, you'll notice that the new line in the Quotation doesn't have a description opw-6175891 Forward-Port-Of: odoo/odoo#262276
This update resolves a test failure related to how data was being processed. The issue stemmed from incorrectly sending raw PDF content instead of the expected base64 encoded data, which caused a validation error. This ensures the testing process runs smoothly.
Original PR description
This commit fixes an error when running the `test_employee_job_change` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw PDF content was being passed when a base64 representation was actually expected (which is obviously invalid base64). runbot-938173 Forward-Port-Of: odoo/enterprise#118523
This update fixes a visual glitch in the website builder's carousel feature. Previously, changing image sizes or adding borders could cause layout instability. Now, the carousel automatically adjusts its item heights to maintain a smooth, consistent appearance, regardless of content changes.
Original PR description
In a carousel snippet all carousel items keep a consistent height to prevent layout jitter when sliding. The height synchronization was broken in the `s_carousel` snippet when item dimensions were modified via border overlays (padding changes). The issue was caused by the resize event being triggered from a different jQuery instance than the one used to register the height synchronization listener, preventing the handler from being executed. Steps to reproduce (Border Overlay): 1. In the website builder, add the `s_carousel` snippet. 2. Drag the lower border overlay so that the height of an image increases. 3. Navigate through the carousel and observe height changes causing a jitter effect. Task: [5135520](https://www.odoo.com/odoo/project/974/tasks/5135520) Forward-Port-Of: odoo/odoo#266173 Forward-Port-Of: odoo/odoo#265549
This update fixes a potential problem where users could accidentally trigger mass email campaigns bypassing intended filters. The change prevents users from directly retrying failed emails linked to marketing automation, avoiding unintended spam and ensuring targeted email delivery. A user interface update also hides the 'Retry' button to prevent this action.
Original PR description
When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing…
When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam. This commit fixes the issue by: 1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`). 2. Hiding the "Retry" button in the frontend view to prevent confusion. 3. Adding a unit test to ensure this edge case is caught in the future. Steps to reproduce: 1. Create a marketing campaign with a filter and an email activity. 2. Run the activity and ensure at least one email trace fails. 3. Open the mailing template via the "Templates" smart button. 4. Click the "Retry" button on the template form. 5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model. OPW-6220106 Forward-Port-Of: odoo/enterprise#119517 Forward-Port-Of: odoo/enterprise#118759
This update prevents empty ICS calendar files from being generated when scheduling shifts. Previously, a lack of available slots resulted in an empty file when the 'Add to Calendar' button was clicked. Now, the ICS file is only created when a valid shift slot is linked to an employee.
Original PR description
**Step:** - install planning - create a resource - create an open shift for a future date - in Gantt view: - publish shift and select the created resource - click “Publish & Send” - check the email and click “Add to Calendar” **Issue:** Currently, clicking “Add to Calendar” generates an empty ics file. **Reason:** During ics file generation, the planning token to find a slot using the planning date and employee. but, no matching slot is found, so the process returns an empty slot, resulting in an empty ics file. **Fix:** Generate the `planning_url_ics` only when a slot is linked with an employee. Otherwise, hide the “Add to Calendar” button and do not generate the ics file. Forward-Port-Of: odoo/enterprise#118978
This update fixes an issue where undoing the auto-plan feature would reset a shift's allocated workload hours, leading to inaccurate reporting. The change ensures that allocated hours remain consistent after undoing, allowing for more reliable tracking of resource utilization. This improves the accuracy of shift planning and reporting.
Original PR description
Steps to Reproduce --- 1. Open the Planning module 2. Create an open shift with allocated_hours 3. Click Auto Plan 4. Click Undo on the auto-plan notification Issue --- Undoing an auto-plan operation…
Steps to Reproduce --- 1. Open the Planning module 2. Create an open shift with allocated_hours 3. Click Auto Plan 4. Click Undo on the auto-plan notification Issue --- Undoing an auto-plan operation triggers recomputation of allocated_hours, causing the shift to lose its original workload value. Current Behaviour --- When resource_id is set to False during undo: - _compute_allocated_hours is triggered (depends on resource_id) - _compute_allocated_percentage is triggered (depends on allocated_hours) - Both fields are recalculated, potentially changing allocated_hours from its pre-assignment value Expected Behaviour --- Undoing auto-plan should preserve allocated_hours at its pre-assignment value while allowing allocated_percentage to adapt to the new context (open slot vs assigned resource). Fix --- Use protecting context manager in action_rollback_auto_plan_ids to prevent allocated_hours from being recomputed when resource_id is removed. This allows allocated_percentage to recalculate naturally based on slot duration while keeping allocated_hours stable. task - 4952149 Forward-Port-Of: odoo/enterprise#102864
This update fixes an issue where invoices were incorrectly re-adding timesheets after a partial refund. The fix ensures that timesheets linked to previously fully invoiced orders are no longer considered when generating new invoices, preventing duplicate entries and maintaining accurate financial records. This improves invoice accuracy and reduces the risk of errors.
Original PR description
### Steps to reproduce: - Download 'Sales' and 'Timesheets' apps - Create 2 lines for the services product in the SO, invoicing policy = based on timesheets - Create 2 timesheets for both SO items - Invoice the SO - Create a credit note for line 1 => only line 2 is invoiced and line 1 is now released - Back to the SO > create invoice again > Line 2 is added to the invoice again. ### Cause of Issue: When generating the new invoice, `_recompute_qty_to_invoice` identifies timesheets linked to refunded invoices. Because the original invoice was partially refunded, all timesheets attached to that invoice match the domain used to locate timesheets—even the timesheets for line 2, which wasn't refunded. ### Fix: Ensures that lines that have already been completely invoiced are safely ignored and not inadvertently re-added to subsequent invoices. opw-6217684 Forward-Port-Of: odoo/odoo#265840
This update resolves an issue where updating the website's extra menu caused the main site menu to unexpectedly close, leading to inconsistent user experience. The fix ensures the extra menu is closed before opening the site menu, guaranteeing a more reliable and predictable website navigation for users.
Original PR description
[FIX] website: close the extra menu before opening site menu Update of the extra menu item is done multiple times (cfr `afterFontsloading`). If the extra menu item and the site menu were already open before an update of the extra menu item, the result is a close of the site menu. This can lead to undeterministic error. To solve the problem, the extra menu dropdown is closed before opening the site menu. runbot-240955 Forward-Port-Of: odoo/odoo#268652 Forward-Port-Of: odoo/odoo#266376
This update fixes a bug where follow invitations weren't appearing in user inboxes unless a comment was added. The change ensures that the notification subject is always displayed, regardless of the comment content, resulting in more reliable and visible notifications for users receiving follow invitations. This improves the user experience and ensures timely updates.
Original PR description
Steps to reproduce: - Configure user A to receive inbox notifications. - As user B, invite user A to follow a record with Notify recipients enabled. - Open the inbox of user A. The Invitation to follow notification is not displayed in the inbox when no additional comment is provided. This happens because the notification body is empty unless extra comments are added. This commit fixes the issue by displaying only the subject when the body is empty. Task-[5485727](https://www.odoo.com/odoo/project/1519/tasks/5485727) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268583 Forward-Port-Of: odoo/odoo#244653