Sunday, September 20, 2026
10 changes · master
Resolved issues and error corrections
Color choices without a manually selected color now display properly in the Add to Cart popup, matching the product page. This avoids confusing gray swatches and helps shoppers recognize the intended product options before purchasing.
Original PR description
Issue: Color attribute values without an explicit html_color show correctly on the product page but render as a plain gray circle in the "Add to cart" popup / product configurator, even though selecting them still works. Steps to reproduce: 1. Create a Color attribute value without picking a color (leave the Color field unset) and add it to a published product. 2. Open the product page: the swatch shows fine. 3. Click Add to Cart to open the popup: the swatch is a plain gray circle instead. Cause: product_template_attribute_line.xml (sale.ptav_color) used `ptav.html_color` directly with no fallback, producing the invalid CSS "background-color:false" when html_color is unset. Fix: Apply the same `html_color or name` fallback in the configurator's color-swatch template. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288582
Fixes a website editor issue where setting, creating, or deleting a ribbon on a specific product variant could crash the page. This ensures merchandisers can manage variant labels such as “Sold out” reliably without interrupting their workflow.
Original PR description
Steps to reproduce: 1. Open a storable product with variants on the Product Page, in edit mode. 2. In the builder sidebar, select the specific variant (e.g. "Customizable Desk (White, Steel)"). 3.…
Steps to reproduce:
1. Open a storable product with variants on the Product Page, in edit mode.
2. In the builder sidebar, select the specific variant (e.g. "Customizable Desk (White, Steel)").
3. Set its Ribbon to any value (e.g. "Sold out").
Before this pr:
- The selection crashed with: TypeError: Cannot read properties of null (reading 'getAttribute') at SetRibbonAction.apply After this pr:
- The ribbon is set/created/deleted normally on the variant, no crash.
`SetRibbonAction`, `CreateRibbonAction` and `deleteRibbon` looked up the selected variant via
`editingElement.querySelector('[data-oe-model="product.product"]')`. That marker never exists on the product page only `product.template` fields (`product.name`, ...) are rendered with `t-field`, never `product.product` fields, so the selector always returned null and the following `.getAttribute(...)` call crashed.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#288466The Documents action menu now shows the expected visual highlight when users hover over the Action option in the kanban view. This makes the interface feel more responsive and helps users clearly see which menu item they are about to select.
Original PR description
Bug === 1. make sure to have actions pinned on a folder 2. right-click a document in the kanban view 3. hover the "Action" item => there's no hover effect Task-6563359 Forward-Port-Of: odoo/enterprise#132157
Users can once again click "Add a stream" in the Social feed view without encountering an error. This restores a normal workflow for managing social media monitoring streams and avoids disruption for teams using the Social app.
Original PR description
Since 05a073df3bb5fead98702aa59a5c83c5076c7f03 a traceback is raised when clicking on "Add a stream" in the social feed view. Task-6584714 Forward-Port-Of: odoo/enterprise#132152
Project planning now evaluates each dependent task separately when checking assignee availability. If one task cannot be scheduled within the search window, it no longer incorrectly forces other related tasks for the same person into a late fallback slot, making project timelines more reliable.
Original PR description
Steps to reproduce: 1. create three tasks A,B & C with the same assignee 2. make tasks B and C depend on A and start on the `date_deadline` of task A 3. set the duration of task B (processed before C) to be longer than the 53-week search window 4. reschedule task A to end after task C starts Problem: A candidate that couldn't be scheduled was putting its assignee in conflict, subtracting the inspected availability while failing from the shared pool. Consequently, every later candidate sharing that assignee got force-placed into the same forward reschedule fallback that lands near the tail of the 53-week search window instead of the next available slot. Solution: Each candidate should be evaluated on its own ability to fit, and the time it occupies should count against the shared pool. opw-6380163 --- Forward-Port-Of: odoo/enterprise#131430 Forward-Port-Of: odoo/enterprise#129326
Discuss calls now keep participant video tiles stable when the layout changes, preventing videos from restarting or glitching. The call interface also adapts better to speakers, presenters, small screens, and resized windows for a more polished meeting experience.
Original PR description
Before this commit, the call view arranged its cards by rewriting CSS variables. Cards jumped to their new place instead of moving to it, and a rearrangement recreated their elements, so a video…
Before this commit, the call view arranged its cards by rewriting CSS variables. Cards jumped to their new place instead of moving to it, and a rearrangement recreated their elements, so a video glitched and restarted from scratch on every layout change. This commit fixes the issue by computing the rendering outside the component, around three concepts: - the "stage" is the one area a call renders into, shared by the tile grid, the sidebar that reserves its room out of the grid's, and the inset overlaying the first tile; - a "surface" is one entry of that stage, held by a stable identity rather than by its position, so a layout change moves it, media and all, instead of recreating it; - a "profile" is the set of layout knobs a call resolves to, one per place it renders in: Discuss, meeting, chat window, PiP and phone. Four modules carry them: 1. `call_profile.js` resolves the call into a `CallProfile`, the knobs everything else runs on: adding a profile is a new `CALL_PROFILE_TYPE` and a new case, never a branch elsewhere. 2. `stage/surface_manager.js` reconciles the desired surfaces with the live ones, so a video travels grid <-> sidebar <-> spotlight without being torn down. 3. `stage/layout_engine.js` turns the profile, the measured stage and the desired surfaces into rectangles. Deterministic and side-effect free. 4. `stage/geometry_renderer.js` applies those rectangles through the Web Animations API, outside the render loop, so surfaces move on the compositor instead of jumping. This commit also makes these miscellaneous changes: - the spotlight splits its stage between the recent speakers, kept 3s after they stop talking, instead of swapping on every sentence; - cards are ordered by what the stage must not hide: presenters, then speakers in the order they took the floor, then self; - the inset snaps to the nearest corner, stored as a corner rather than pixels, so it survives a resize; - on a small screen the call bar folds everything but the microphone, the camera and their settings into one "More" menu; - "Switch Camera" moves into the quick video settings; - in a chat window, the fullscreen button no longer pulses to nudge the user into it when another participant turns their camera on. task-4781315 Forward-Port-Of: odoo/odoo#282766
The chatter search filters have been renamed and split into clearer options: All, Messages, Notes, Activities, and Changes. This helps users quickly understand which communication items they are viewing, reducing confusion when searching record discussions.
Original PR description
Previously, the chatter filters used generic categories such as 'Conversations' and 'Tracked Changes', which made it unclear which types of messages would be displayed by each filter. This PR makes the filters more intuitive by replacing these generic categories with distinct message types: 'All', 'Messages', 'Notes', 'Activities', and 'Changes'. This makes it clearer which messages each filter will display. part-of-task-6299626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287983
The messaging menu now correctly loads the latest OdooBot welcome message for new users instead of showing an empty conversation placeholder. This ensures users see the right chat preview and can clear the unread notification as expected.
Original PR description
Before this commit, the OdooBot conversation showed "This is the start of your conversation" instead of the last message of OdooBot, and could not be marked as read. Steps to reproduce: - log in as a…
Before this commit, the OdooBot conversation showed "This is the start of your conversation" instead of the last message of OdooBot, and could not be marked as read. Steps to reproduce: - log in as a new internal user, so that the onboarding creates the OdooBot chat and posts its welcome message - open the messaging menu, "Chats" tab - the OdooBot conversation shows no message preview, and marking it as read leaves its unread counter at 1 This happened because the messaging menu excluded from its own fetch every channel already in the store, no matter how it got there. `init_messaging` adds the OdooBot chat without its last message: it only needs the channel itself, to auto-open the chat during onboarding. So the message was never loaded, while both the preview and `markAsRead` needed it client side. This commit fixes the issue by no longer relying on the mere presence of the channel in the store: it is excluded only if its last message has been fetched too, either because the server sent it along the channel (new `lastMessageFetched` flag, set by the routes requesting the last messages of the channels they add to the store), or because the thread has been loaded, in which case its messages necessarily contain the last one. (See the Odoobot notification's message) <img width="396" height="630" alt="before-master" src="https://github.com/user-attachments/assets/c67ce8cf-a363-4fb6-94fa-2ada9ba08e4b" /> <img width="396" height="630" alt="after-fix" src="https://github.com/user-attachments/assets/bb74ee5a-3f5f-4b8a-bfd1-5662d7a52dca" /> Forward-Port-Of: odoo/odoo#287749
Adds test coverage for a case where Avalara tax details are recalculated after an exemption certificate is uploaded. This helps ensure product line tax data stays aligned with the generated tax lines, reducing the risk of incorrect tax reporting or invoice totals.
Original PR description
We removed the explicit tax clearing [1]. It ends up triggering a situation where extra_tax_data on the product lines diverges from the tax lines. This happens when the tax integration writes only extra_tax_data without modifying anything else on the lines (if e.g. you first calculate tax, upload the exemption certificate to Avalara, and then recalculate tax). This tests that exact scenario. opw-6547387 [1] https://github.com/odoo/enterprise/pull/107863 Forward-Port-Of: odoo/enterprise#132083 Forward-Port-Of: odoo/enterprise#131815
This fix ensures accounting documents recalculate tax lines and totals when external tax data changes. It prevents mismatches between invoice lines and tax lines, helping businesses avoid incorrect totals on accounting documents.
Original PR description
The account_external_tax module can modify extra_tax_data without modifying anything else on the lines. This results in: - a desync between the product lines and tax lines, - incorrect totals This makes sure we regenerate the appropriate tax lines and recompute the totals fields. opw-6547387 Forward-Port-Of: odoo/odoo#289088 Forward-Port-Of: odoo/odoo#288717