Sunday, August 30, 2026
4 changes · saas-19.4
Resolved issues and error corrections
This update brings the spreadsheet component to its latest version with several fixes that improve usability and visual consistency. Users benefit from clearer focus indicators, correct sheet names in find-and-replace, better handling of long validation messages, and more accurate dashboard and chart colors.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d7a0f18af4 [REL] 19.4.10 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d7a0f18af4 [REL] 19.4.10 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/934355f30c [FIX] radio_selection: add focus style [Task: 6384097](https://www.odoo.com/odoo/2328/tasks/6384097) https://github.com/odoo/o-spreadsheet/commit/a97f09bc1c [FIX] find and replace: sheets name [Task: 6475881](https://www.odoo.com/odoo/2328/tasks/6475881) https://github.com/odoo/o-spreadsheet/commit/70cd9dd8f7 [FIX] validation message: long message are truncated [Task: 6475881](https://www.odoo.com/odoo/2328/tasks/6475881) https://github.com/odoo/o-spreadsheet/commit/05dfcb70f6 [FIX] session: fix part of the command squisher [Task: 6462247](https://www.odoo.com/odoo/2328/tasks/6462247) https://github.com/odoo/o-spreadsheet/commit/b9af757026 [FIX] commands: add `UPDATE_COLOR_SCHEME` to readonly commands [Task: 6497278](https://www.odoo.com/odoo/2328/tasks/6497278) https://github.com/odoo/o-spreadsheet/commit/27eade4b55 [FIX] dashboard: fix background color [Task: 6497278](https://www.odoo.com/odoo/2328/tasks/6497278) https://github.com/odoo/o-spreadsheet/commit/e099b0f63e [FIX] chart: set point color for radar charts [Task: 6474893](https://www.odoo.com/odoo/2328/tasks/6474893) https://github.com/odoo/o-spreadsheet/commit/2ab37ae185 [IMP] package: update owl to latest version [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) 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>
Point of Sale loyalty offers such as “Buy 2, Take 1” now correctly add the free product when the cashier changes quantity directly, not only when items are added one by one. This ensures customers receive eligible promotions consistently and reduces cashier confusion at checkout.
Original PR description
Steps to reproduce: - create a "Buy 2 Take 1" program whose rule and reward both target a product tag containing several products - in the PoS, add one of the tagged products to the order - set its…
Steps to reproduce: - create a "Buy 2 Take 1" program whose rule and reward both target a product tag containing several products - in the PoS, add one of the tagged products to the order - set its quantity to 3 with the numpad Issue: The free product is not given. Clicking the product a third time instead of typing the quantity does give it, and so does a program whose reward is a single product. Cause: A reward whose products come from a tag is multi_product, so getClaimableRewards never computes its unclaimed quantity and the auto claim of updateRewards skips it: which product to give out is unknown. The only place claiming such a reward is addLineToCurrentOrder, which resolves it with the product that was just added. Setting a quantity does not go through it, hence the difference. Fix: Resolve the reward product the same way when auto claiming: the product of the line being worked on, or, failing that, the only reward product the order contains. The reward then follows the quantity of any of the tagged products, not only of the first one added, and the cashier is still asked when the order does not settle the choice. opw-6430385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284777
This fix stops Odoo from rebuilding an entire recurring Outlook calendar series when only the first event's start time changes. It prevents changes meant for one occurrence, such as adding an attendee, from being incorrectly applied to every event in the series.
Original PR description
The stored rrule of a recurrence embeds a DTSTART line based on the recurrence dtstart (the smallest start among its events). When the first occurrence is moved in Outlook, the Odoo dtstart no longer…
The stored rrule of a recurrence embeds a DTSTART line based on the recurrence dtstart (the smallest start among its events). When the first occurrence is moved in Outlook, the Odoo dtstart no longer matches that DTSTART, but the stored rrule is not recomputed at that point (it only depends on the pattern fields). On a later sync touching the seriesMaster (e.g. after adding an attendee to the moved occurrence), the recurrence values are written again and the rrule is reserialized with a DTSTART based on the moved occurrence. _write_from_microsoft() took this new rrule string as a pattern change and reapplied the recurrence: all occurrences were deleted and recreated as copies of the moved one, spreading its specific data (e.g. the newly added attendee) to the whole series. Ignore the DTSTART line when comparing the rrule before and after the write: a DTSTART-only difference does not reflect any pattern change in Outlook. An actual pattern change (FREQ, UNTIL, INTERVAL, ...) still reapplies the recurrence as before. Steps to reproduce: 1. In Outlook, create a recurring event 2. In Odoo, run the calendar sync 3. In Outlook, move the first occurrence of the recurrence (shift its start and stop time by 30 minutes) 4. In Odoo, run the sync 5. In Outlook, add an attendee to that same first occurrence 6. In Odoo, run the sync All the occurrences are deleted and recreated as copies of the first one, and the attendee ends up on every occurrence instead of one. opw-5129848 Forward-Port-Of: odoo/odoo#284747 Forward-Port-Of: odoo/odoo#269549
This fix prevents duplicate calendar entries when a meeting that was already synced with Outlook is changed into a recurring series in Outlook. Odoo now removes the old single event because it is represented by the new recurring series, keeping calendars cleaner and avoiding confusion.
Original PR description
When a single event already synced with Outlook is turned into a recurring event directly in Outlook, Microsoft reuses the event in place: the seriesMaster keeps the iCalUId of the former single event, while each occurrence gets a fresh id/iCalUId. On resync, a seriesMaster is only matched against calendar.recurrence, never against calendar.event. As no recurrence exists yet, it is handled as a brand new recurrence whose occurrences are created from scratch. The original single event, which shares the master's iCalUId and the first occurrence's timeslot, is then left untouched. Drop that pre-existing single event when building a new recurrence from an inbound seriesMaster, since it is now represented by the recurrence itself. opw-5129848 Forward-Port-Of: odoo/odoo#285196 Forward-Port-Of: odoo/odoo#271787