Tuesday, December 2, 2025
10 changes · saas-18.2
Resolved issues and error corrections
This update refreshes the spreadsheet component to the latest maintenance version and resolves several issues affecting pivots, charts, sheet names, and cell editing behavior. Users should see more reliable spreadsheet calculations and chart creation with fewer confusing interface glitches.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d385099e2 [REL] 18.2.36 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d385099e2 [REL] 18.2.36 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/246af9358 [FIX] pivot: Ensure computed measure range adaptation [Task: 5358213](https://www.odoo.com/odoo/2328/tasks/5358213) https://github.com/odoo/o-spreadsheet/commit/5b371232a [FIX] commands: remove duplicate in invalidateEvaluationCommands [Task: 5358213](https://www.odoo.com/odoo/2328/tasks/5358213) https://github.com/odoo/o-spreadsheet/commit/0da6c8d85 [FIX] composer: keep edition mode inactive on cursor selection change [Task: 5354541](https://www.odoo.com/odoo/2328/tasks/5354541) https://github.com/odoo/o-spreadsheet/commit/cb92d82da [FIX] BottomBarSheet: sheet name should update on foreign changes [Task: 5016252](https://www.odoo.com/odoo/2328/tasks/5016252) https://github.com/odoo/o-spreadsheet/commit/fedfbaad6 [FIX] Charts: Ensure Chart js extension are loaded on chart creation [Task: 5214007](https://www.odoo.com/odoo/2328/tasks/5214007) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This fixes an issue where a participant in a group chat could get an access error when typing in one of that chat's subchannels. Users who already have permission to use the parent group chat can now participate in its subchannels smoothly.
Original PR description
Before this commit, typing in a subchannel of a group DM of which you are not member of would result in an access error. Steps to reproduce: 1. Log in as user A 2. Create group chat with user B 3. Create a subchannel in said group 4. Log in as user B 5. Open the subchannel in the group chat 6. Write in the composer -> access error This is caused by incomplete access rules for the `discuss.channel.member` model. Specifically the issue stems from the fact that a subchannel of a group channel is considered a group, and as such it's only possible to join it via invitation. Since typing in a channel attempts to join it, an access error is raised. This commit fixes the issue by executing the creation of a channel member for subchannels as superuser, on the condition of having write access to the parent channel. task-5357621
When a stock move quantity is increased, Odoo now reserves the added quantity from the correct available stock instead of creating generic move lines without lot or package details. This helps keep warehouse reservations accurate and reduces picking or traceability mistakes.
Original PR description
Increasing the quantity of a stock move will create a move line with the same data as the stock move (location and product), no lot, nor package. This commit make the increase of quantity mimic the reservation process by getting first the available quants. The move line are then created accordingly. Backport of odoo/odoo#230344 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236699
Customers using self-order can no longer choose pickup time slots that have already passed for the current day. This prevents invalid pickup choices, reduces confusion, and helps restaurants manage orders more accurately.
Original PR description
Task: [#5365003](https://www.odoo.com/odoo/project/1737/tasks/5365003) --- before this commit selecting a time slot in self-order, the customer can still pick time slots that are already in the past. For example, if the current time is 14:05, the system still allows selecting 12:00, 12:20, 13:00, etc. This should not be possible. When choosing a pickup time for today, all time slots earlier than the current time should not be generated
Customers can now remove automatically applied promotion rewards from their shopping cart. This fixes a checkout frustration where the remove action appeared available but did not actually remove the promotion line.
Original PR description
Steps: - Add a loyalty program of type promotion - Program trigger should be Automatic - Go to Shop > Add a product that triggers the reward of promotion - Try to remove the promotion added from the cart lines Issue: - Remove does not work for the automatically applied promotion reward Cause: - Context is not properly passed to the unlink method that removes the cart line of the promotion reward. - Since the unlink method is not receiving context properly, removal is bypassed Fix: - Instead of adding context in `self`, adding it directly in the `order_line` context fixes the issue. task-5076061
This update resolves an issue where changes to spreadsheet sale inputs were unexpectedly lost due to system updates or user actions. The fix ensures that input values are correctly saved and reflected, providing a more reliable user experience for updating sales data. This improves data accuracy and reduces potential data loss.
Original PR description
Currently, the FieldSync record input suffers from two issues: 1) The input value can be reset by parasitic renders While the user is inputting a value, if they did not confirm it and a global render occurs (other user joining the session, dragging the mouse on the grid), the input value will be reset to the one stored in the plugin, therefore erasing the last change of the user 2) In Chrome-based navigators, users can change the value of the input by using their mouse scrolling wheel. Such action *does not* trigger an `onChange` event; which means that the new value is never directly saved. Both issues are addressed in this commit by keeping an internal state inside the component `FieldSyncSidePanel` and ensure this state is properly reflected in the plugin once we stop editing the input. Task-5123069 Forward-Port-Of: odoo/enterprise#96431
This update fixes a critical issue preventing correct XML generation for Colombian e-invoices related to the 'INC Bolsas' plastic bags tax. The changes add a dedicated logic flow to accurately report this tax, ensuring compliance with DIAN requirements and preventing validation errors. This allows invoices with plastic bags tax to be successfully submitted.
Original PR description
Before PR: -The plastic bags tax (INC Bolsas) was not handled by a specific flow. -This resulted in incorrect XML generation for Colombian e-invoices, leading to validation errors from the DIAN. After PR: -Dedicated logic flow has been added to correctly handle the INC Bolsas tax. -Generated XML now correctly reports this tax in a separate `TaxTotal` block. -It populates the `BaseUnitMeasure` and `PerUnitAmount` fields with the fixed tax rate per bag. Impact: -Colombian e-invoices that include plastic bags tax are now generated correctly. -Ensures compliance with DIAN's specific requirements for this nominal tax. -Prevents validation errors and allows for successful submission of invoices containing this tax. task-5086926 Forward-Port-Of: odoo/enterprise#95311
This update corrects a bug where the Shop Floor view incorrectly reset its default filters when a new work center was added to a production. Now, the system maintains the expected default filters (All MO and My WO) regardless of the work center being accessed, ensuring a consistent and intuitive user experience. This improves workflow efficiency for production managers.
Original PR description
Issue: ---------------------------------- When accessing a work order in a work center not included in the default selection on the shop floor, the system would change the default view by removing…
Issue: ---------------------------------- When accessing a work order in a work center not included in the default selection on the shop floor, the system would change the default view by removing `All MO` and `My WO`, disrupting the expected behavior for users. Steps to reproduce: ---------------------------------- - Open the Shop Floor view and note the default filters like All MO and My WO. - Access a production whose work order is in a work center not included in the current selection, and move it to that work center. - Observe that the view reloads and the default filters are removed, showing only the newly added work center. With this commit: ---------------------------------- The function is fixed to keep default selections like All MO and My WO when adding a new work center. These were previously removed because they aren't stored and weren't re-added. Now, the new work center is added without altering the default view. Task-id: [4392236](https://www.odoo.com/odoo/project/966/tasks/4392236) Forward-Port-Of: odoo/enterprise#76102
This update resolves a critical issue causing export generation failures in the payroll data. The fix corrects a naming mismatch between field references and model definitions, ensuring accurate Prisma code retrieval. A new test suite has been implemented to guarantee the reliability of the export process.
Original PR description
The export generation crashed due to a mismatch between field names — the code was referencing employee_ids, while the model actually defines employee_id. Since the Prisma code is now stored on the employee model, the logic was updated to correctly access the employee_id field and retrieve the related Prisma code. Additionally, a comprehensive test suite was added to validate Prisma code behavior, including: - validation of code length for employees, companies, and work entry types, - handling of codes across different companies, - and the complete Prisma export flow (from work entry creation and validation to export file generation). task-5153727 Forward-Port-Of: odoo/enterprise#96743
This update resolves an issue where archived companies were still visible to administrators within the Documents app. The fix ensures that normal users cannot access documents from archived companies, maintaining data security and privacy. This change was implemented to align with best practices for company archiving and user permissions.
Original PR description
**Steps to reproduce:** - Install Documents app - Create a bunch of companies with their own folders - Archive the companies - Try to open Documents app with admin - Access Error is raised **Issue:** Archived companies not properly taken into account in the search permission. **Fix:** Explicitly check of archived status for the folders company. The behavior is that normal users won't see documents from archived companies but admins still can. From related PR: > Also need to ensure archived companies are not removed from the admin search > domain even if the user has `active_test=False` related: https://github.com/odoo/enterprise/commit/b7e6acba60e50c86627b177a86b357d2bb956cbc opw-5127040 Forward-Port-Of: odoo/enterprise#100133