Monday, January 5, 2026
39 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue where users joining meetings via mobile invitation links would sometimes experience crashes due to accessing incorrect inbox data. The fix ensures the mobile UI handles message access safely, preventing these crashes and improving the meeting experience for all users.
Original PR description
**Steps to Reproduce:** - Log in with User A. - Start a meeting. - Send the invitation link to User B. - Log in as User B/Guest and join the call from a mobile device. Before this PR, joining the call from the public invitation page on mobile could crash due to accessing undefined inbox messages. This PR fixes the issue by safely handling the messages access, ensuring the UI no longer crashes in this scenario. task-[5428778](https://www.odoo.com/odoo/project/1519/tasks/5428778) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241868
This update fixes an issue where assigned values in project properties would disappear after saving. The root cause was a flaw in how the system handled data retrieval for Many2one fields, specifically related to displaying contact names. The fix ensures that property values are correctly saved and remain visible after modifications.
Original PR description
**Steps to produce:** - Install project module. - Go to project > Open any project > Open any task > Click on gear icon. - Click on Add properies > Set Field type as `Many2one` and Model as…
**Steps to produce:** - Install project module. - Go to project > Open any project > Open any task > Click on gear icon. - Click on Add properies > Set Field type as `Many2one` and Model as `Contact`. - Now assign value to Property 1 > Click on `External button` > Click on `Save & Close`. **Issue:** - The assigned value disappears after saving. **Root cause:** - At [1], since `id` is not an active field (see [2]), it is not present in record.data, which is expected. However, record.data is then passed to m2oTupleFromData, which assumes that the data includes an id because it is normally used on data coming directly from the ORM. - Additionally, since display_name is also not present, m2oTupleFromData falls back to record.data.name, which is not proper. **Solution:** - Use an ORM read to retrieve the proper display_name of the record before constructing the Many2one tuple. [1]: https://github.com/odoo-dev/odoo/blob/24ccc3faf14ade70b21bf253af16a534df726fc8/addons/web/static/src/views/fields/properties/property_value.js#L87-L89 [2]: https://github.com/odoo/odoo/blob/369ca1e5a154235e80b9ea6af7b3f10442c0939f/addons/web/static/src/model/relational_model/record.js#L793-L795 Before: <img width="589" height="68" alt="bef" src="https://github.com/user-attachments/assets/b2aeba0c-1c52-4663-9f94-5c7808a882db" /> After: <img width="613" height="81" alt="after1" src="https://github.com/user-attachments/assets/a3b3d733-929d-4a24-9e17-c73d9569e9b7" /> **opw-5257819** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240443 Forward-Port-Of: odoo/odoo#238052
This update fixes an issue where complex custom groupbys in reports were incorrectly formatted with excessive indentation. The change ensures reports handle more intricate domain conditions accurately, improving readability and preventing formatting problems. This enhancement was identified and resolved in the latest version of Odoo Enterprise.
Original PR description
When a custom groupby defined a domain with more than one element in it (typically, conditions on multiple fields, possibly with '|' or '&' operations), if groupby lines needed to be generated for subsequent groupby, the generated groupby lines had a too high level, and ended up being over-indented.
This was because the groupby expansion computed the number of higher-level groupby lines as the length of the domain needed to restrict their content. This was too naïve, and won't work well with custom groupbys, which can define longer (or even empty) domains.
This was spotted in master (19.1), with the refactored EC Sales list, which now uses a custom engine and a specific custom groupby map.
Forward-Port-Of: odoo/enterprise#102240This update fixes an issue where clicking 'Join Call' from a call invitation didn't automatically open the related chat thread. Now, clicking 'Join Call' opens the correct thread in both the chat window and the discuss app, and clicking the invitation avatar focuses the composer within the chat window. This improves the user experience when scheduling and participating in calls.
Original PR description
**Description of the issue this PR addresses:** Clicking on join call does not open the corresponding thread, neither in the discuss app nor in the chat window. **Steps to Reproduce:** - Log in with…
**Description of the issue this PR addresses:** Clicking on join call does not open the corresponding thread, neither in the discuss app nor in the chat window. **Steps to Reproduce:** - Log in with Admin and Demo user - From the Demo side, open the chat window/discuss app and call Mitchell Admin - On the Admin Side, click Join the call from the call invitation preview - Chatwindow/Discuss app does not open the corresponding thread automatically Additionally, clicking on the `invitation avatar` does not focuses the composer as expected in the chat window. **Desired behavior after PR is merged:** - Clicking join call now opens the corresponding thread in both discuss and chat window, with the composer focused in the `chat window`. - Clicking the avatar on a call invitation now focuses the composer when opened inside a chat window. task-[5367781](https://www.odoo.com/odoo/project/1519/tasks/5367781) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239450
This update resolves an issue where the 'Use compact format' option within Odoo charts was visually present but not functioning correctly. The fix ensures that this option now correctly controls the display of charts, improving user experience and data visualization. This change was driven by a task to address a reported bug.
Original PR description
The checkbox to toggle the `Use compact format` option in the chart side panel was present for odoo charts, but did nothing. Task: [5405064](https://www.odoo.com/web#id=5405064&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#240251
This update resolves an issue where the 'Use compact format' option in the chart side panel was visually present but not working correctly. The fix ensures this setting now functions as intended, providing users with the desired chart display. This improves the overall usability of the chart feature.
Original PR description
The checkbox to toggle the `Use compact format` option in the chart side panel was present for odoo charts, but did nothing. Task: [5405064](https://www.odoo.com/web#id=5405064&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#102263
This update resolves an issue where the 'Position' column in German Sale Order reports was blank, causing formatting problems. The fix corrects a calculation error in the report template, ensuring accurate sequential numbering (1, 2, etc.) and proper table display. This improves the accuracy and readability of sales reports.
Original PR description
Before this commit, when printing a Sale Order using the German localization, the "Position" column in the PDF report was empty. Additionally, the table formatting was broken due to this missing data. This issue occurred because the index variable used to calculate the line number in the report template (QWeb) was incorrect. This commit fixes the index logic in the report template. Now, the "Position" column correctly displays sequential numbers (1, 2, etc.), and the table formatting renders correctly. ticket-5225647 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#240714 Forward-Port-Of: odoo/odoo#240243
This update resolves a rare technical issue that could occasionally cause problems when opening a parent channel within Odoo. The fix prevents a traceback error, ensuring a smoother and more reliable experience for users. This improves overall system stability.
Original PR description
This commit fixes a rare traceback that could occur when opening a parent channel from a thread that has been deleted. task-5355205 Forward-Port-Of: odoo/odoo#241266
This update fixes an issue where Point of Sale prices were incorrectly calculated when using a currency different from the company's default. The change ensures that product prices are accurately converted to the configured currency, preventing inflated or deflated prices during transactions. This improves the reliability of the Point of Sale functionality.
Original PR description
Behavior: When using a Point of Sale configured with a different currency than the current company's currency. The price conversion is inverted. This occurs when loading the data when accessing PoS, each product should have its currency converted to the config's currency from the company's, however this is currently inverted. https://github.com/odoo/odoo/blob/e9656230e60fee23cf399f0c6bdefbcedef86768/addons/point_of_sale/models/product_product.py#L36-L40 Steps to reproduce: - Activate another currency than the initial one and indicate a conversion rate - Create a new point of sale - Create new journals for the PoS with the new currency. - When opening the PoS and adding any product the price will be a lot higher or lower than the expected price. opw-5266359 Forward-Port-Of: odoo/odoo#238376
This update fixes a visual issue where carousel navigation arrows displayed incorrectly when the website was configured for Right-to-Left languages like Arabic. The fix ensures that the arrows align correctly regardless of the website's language setting, providing a consistent user experience for all customers. This was caused by a previous change that inadvertently removed RTL-specific styling.
Original PR description
Steps to reproduce: =================== - Install an RTL language (e.g., Arabic) on the website. - Go to website & Edit mode - Drop product snippet `s_dynamic_snippet_products`. ->When the website is…
Steps to reproduce: =================== - Install an RTL language (e.g., Arabic) on the website. - Go to website & Edit mode - Drop product snippet `s_dynamic_snippet_products`. ->When the website is viewed in an RTL language, the navigation arrows in the snippet are displayed in the wrong direction. Cause: ====== A previous commit [1] applied a specific `transform` to arrows to adjust their visual style, By defining a new transformation for the snippet, the default generic transform for RTL language was overwritten. https://github.com/odoo/odoo/blob/e0a5e68e861363378ecd184711bc9356fe0376ff/addons/web/static/lib/odoo_ui_icons/style.css#L105 Consequently, the arrows lost their RTL-specific orientation. Solution: ========= The CSS has been updated to explicitly handle the RTL context. [1]: https://github.com/odoo/odoo/commit/d9ea6d1ebabf64dac434e0d2a7c2535bbfff5c71 opw-5440273 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241541
This update removes a confusing and unnecessary warning message that appeared when setting up pricelists for event products. The warning was poorly designed and didn't provide useful information, creating a frustrating user experience. This change simplifies the process for managing pricing for events.
Original PR description
* Remove the warning shown when creating pricelist rules for event products. * The warning is noisy, not well localized, and appears for every rule, resulting in a poor user experience with little practical value for most users opw-5441138 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug that caused calls to unexpectedly end when users joined from multiple browser tabs. The change ensures stability and prevents crashes during multi-tab call scenarios, improving the overall meeting experience for our users. This resolves an issue where the RTC session would become unavailable, leading to call interruptions.
Original PR description
**Steps to reproduce:** - Start a meeting with user A - Share the invitation link with user B - Login with user B and join the call - Open another browser tab/window with the same user B - Join the same call in that tab using the invitation link - The call ends for that user as the RTC session is terminated - **_TAB1_**: join the call again - **_TAB2_**: error **Current behavior before PR:** When the same user joined the same call from another tab or during RTC renegotiation, selfSession could temporarily be undefined. **Desired behavior after PR is merged:** This PR ensures that no crash happens when dealing with the RTC Session in a `multi-tab` scenario. task-[5263097](https://www.odoo.com/odoo/project/1519/tasks/5263097) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241801 Forward-Port-Of: odoo/odoo#240881
This update ensures timers stop correctly, even when switching between different companies within the Odoo system. Previously, a technical issue with the industry_fsm module prevented timers from being properly stopped when working in a different company, leading to errors. This fix resolves this problem, guaranteeing consistent timer behavior regardless of the company context.
Original PR description
Before this commit, when the user starts another timer from another company, the existing timer should be stopped before starting a new one. However, if industry_fsm module is installed and the…
Before this commit, when the user starts another timer from another company, the existing timer should be stopped before starting a new one. However, if industry_fsm module is installed and the previous timer is running from another company, the user could have an Access Error because he cannot read the task/ticket linked to the timesheet with the timer to stop. This commit makes sure the timer is correctly stopped without any issue even if the record linked is inside another company. Steps to reproduce the issue: ============================ 1. Install industry_fsm module 2. Create a task from a timesheetable project and start a timer from that new task. 3. Create a new company and go inside that company 4. Create a new timesheetable project and a new task inside it 5. Start a new timer from that new task. Expected Behavior: ----------------- The timer form the first task created should be stopped and a timer for the newest task should be running. Actual Behavior: --------------- An access error is raised because the user cannot access to the task linked to the timer to stop. task-5076633 Forward-Port-Of: odoo/enterprise#96411
This update ensures that users are prevented from adding rental products to their cart when a resource is unavailable during the selected rental period. Previously, the system didn't check availability if the ‘website_sale_renting_stock’ module wasn't installed. This change improves the user experience by preventing incorrect bookings.
Original PR description
Before this commit, when the user goes to the webshop to take a rental service with rental service unavailable at a certain period, the system does not block the user when the resource is not available during 2 hours in the period chosen by the user. The reason is because the hours are not checked when website_sale_renting_stock is not installed. This commit moves the code checking the time of the rental period made in website_sale_renting_stock in website_sale_renting to be able to have that verification for rental service used with planning to make sure the system will prevent the user to add the product in his cart when the resource is unavailable. task-5123239 Forward-Port-Of: odoo/enterprise#102071 Forward-Port-Of: odoo/enterprise#96241
This update to the account module's testing utilities prevents unnecessary invoice line creation during tests. This improves test stability and reduces potential errors, ensuring more reliable test results. The change focuses on optimizing the test setup process.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/102632
This update fixes a bug where deferred accounting for misc entries wasn't correctly identifying the appropriate account type. The change now analyzes the individual line's account type instead of relying on the overall move type, ensuring accurate deferral calculations for revenue and expense transactions. This improves the reliability of financial reporting.
Original PR description
The commit 42f823d6b8aa3d1cd171ae1603549ee95fc9d0f0 allows to use deferred on misc entries. However, there are many places in the code that were not updated. Usually they were in the form of `if move_type is sale, then deferred_type = income, else expense`. However we cannot rely on the move_type anymore for misc entries, because it will always take the `else` branch of the condition. Instead, if we have a misc entry, we should rely on the account type of the line that is being deferred, so we have more granularity. For this, we now compute the deferral account/journal for each line, and not per move. The logic inside the computation remains the same. Steps to reproduce: 1. Create a misc entry with two deferred lines (one expense, one revenue) 2. Post it 3. Check the generated deferrals, they all use the same deferred account and journal even though we have different account types opw-5194305 Forward-Port-Of: odoo/enterprise#100295
This update resolves a bug where loyalty program pricing wasn't correctly displayed in the POS system. The fix ensures the system properly loads the pricelist ID, allowing loyalty discounts to apply accurately. This improves the customer experience and ensures correct pricing calculations.
Original PR description
Task: [#4974070](https://www.odoo.com/odoo/my-tasks/4974070) Runbot build error: [#229672](https://runbot.odoo.com/odoo/runbot.build.error/229672) --- ## Error FAILED: [12/46] Tour…
Task: [#4974070](https://www.odoo.com/odoo/my-tasks/4974070)
Runbot build error: [#229672](https://runbot.odoo.com/odoo/runbot.build.error/229672)
---
## Error
FAILED: [12/46] Tour test_refund_does_not_decrease_points → Step selection popup has '$ 1 per point on your order' (trigger: .selection-item:contains("$ 1 per point on your order")).
## Qualifiers
{
"module": "pos_loyalty",
"test_path": "/pos_loyalty/tests/test_frontend.py",
"tour_name": "test_refund_does_not_decrease_points",
"tour_step": ".selection-item:contains(\"$ 1 per point on your order\")",
"test_class": "TestUi",
"test_method": "test_refund_does_not_decrease_points",
"test_module": "pos_loyalty"
}
## Fix
In some cases, the POS config's `pricelist_id` was not available in the frontend, causing loyalty program conditions to be skipped when checking for a matching pricelist.
By explicitly setting `use_pricelist` to True on the POS config, we ensure that `config.pricelist_id` is properly loaded and available at runtime, allowing loyalty programs with pricelist conditions to behave as expected.
Forward-Port-Of: odoo/odoo#221921This update corrects an issue with the padding within Gantt chart popovers, ensuring a more visually consistent and professional presentation. The change was necessary to address a design flaw identified in a previous development cycle, improving the overall user experience.
Original PR description
This commit fixes wrong padding inside gantt popovers body introduced in #101482. task-5166940
This update fixes a security vulnerability where portal users with existing invoices or sales orders could modify their country information. Previously, this restriction was only enforced through the main website portal. Now, the system prevents users from changing their country details when an invoice or sale order is associated with their account, ensuring data integrity.
Original PR description
Steps to reproduce: 1. Install website_forum, website_sale. 2. Confirm a Sale Order for a portal user. 3. Log in as the portal user, go to My Account -> Edit Information. 4. Country is in readonly. 5. Go to Forum -> Profile -> Edit 6. Edit the country 7. Nothing stops the user from doing so. --- Description of the issue this commit addresses: If there is already an invoice or a sale order for a partner, we restrict the edition of some of its values to system administrators. This is already enforced on the edition of the profile via /my/home route but not via the /profile/user. --- Desired behavior after the commit is merged: When an invoice or a sale order is set for a partner with portal access, he can't edit his country via the /profile/user route anymore. --- task-5331916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241528 Forward-Port-Of: odoo/odoo#237781
This update adjusts how preset options are displayed in the self-order mode, ensuring that available presets are shown only when appropriate. Specifically, 'Dine In' presets now appear correctly on kiosks and mobile menus when a table identifier isn't present, requiring a slight configuration change if needed.
Original PR description
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset…
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset was not available in self, this preset was used as the default one. But now, it's not the case anymore. We only use it if, and only if, it is available in self. The second thing was to fix the "Dine In" preset availability in the eating location choices. A dine-in preset is a preset which have service_at == table as attribute. If this preset (is `available_in_self`) and has `service_at === table`, we only show it when there is a table_identifier in the URL or when we are in the kiosk. In all other cases, it'll never be shown. If user wants to see this preset in the kiosk or in the mobile menu without table_identifier, user needs to change the `service_at` field at `counter` (or `delivery`) and put the product as `available in self` as well. task-id: 5190541 enterprise pr:https://github.com/odoo/enterprise/pull/103063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234522
This update fixes an issue where certain POS presets weren't correctly displayed in self-service modes (kiosk and mobile). Now, presets are only shown if they're available in self-service and meet specific criteria, like being associated with a table. Users may need to adjust product settings to see these presets in the kiosk or mobile menu.
Original PR description
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset…
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset was not available in self, this preset was used as the default one. But now, it's not the case anymore. We only use it if, and only if, it is available in self. The second thing was to fix the "Dine In" preset availability in the eating location choices. A dine-in preset is a preset which have service_at == table as attribute. If this preset (is `available_in_self`) and has `service_at === table`, we only show it when there is a table_identifier in the URL or when we are in the kiosk. In all other cases, it'll never be shown. If user wants to see this preset in the kiosk or in the mobile menu without table_identifier, user needs to change the `service_at` field at `counter` (or `delivery`) and put the product as `available in self` as well. task-id: 5190541 community pr:https://github.com/odoo/odoo/pull/234522 Forward-Port-Of: odoo/enterprise#103063
This update resolves an issue where the attendance app would crash when an employee didn't have a linked calendar. The fix ensures the app handles employees with flexible attendance schedules properly, preventing errors and improving overall usability.
Original PR description
Steps to reproduce: - Create an employee - Remove the calendar to have fully flex - Open the attendance app -> traceback When an employee has no resource calendar (resource_calendar_id=False), the _gantt_unavailability method would crash with a TypeError when trying to create a ZoneInfo from calendar.tz (which is False/None). This fix adds a check to skip calendar periods where the calendar is not set, consistent with how flexible calendars are already handled. task-5462208
This update fixes an issue where customers weren't correctly returning to the splitting order screen after making a payment when automatic receipt printing and skipping the preview screen were enabled. The change ensures a smooth transition back to the splitting workflow, improving the customer experience during multi-item purchases. This update is a bug fix.
Original PR description
Ensure FeedbackScreen uses a unified `goNext()` flow and restore the splitting workflow when `Automatic receipt printing` + `Skip preview screen` are enabled. Paying part of a splitted orders now correctly return to the splitting screen instead of the floor plan by delegating the logic to `pos.continueSplitting()` / `pos.isContinueSplitting()` (shared with ReceiptScreen). task-id: 5405595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239532
This pull request updates the .weblate.json files, which contain the translations for Odoo. These updates reflect the addition of new modules to the system, ensuring that all users see the application in their preferred language. This maintenance ensures accurate and consistent translations across the Odoo platform.
This update resolves an issue where products without categories weren't shown correctly when grouping by category in the POS. It also ensures that products with multiple categories are displayed only once when filtering, improving the user experience and accuracy of product listings.
Original PR description
[FIX] point_of_sale: fix group by category feature Task: [#5369658](https://www.odoo.com/odoo/project/1737/tasks/5369658) --- If we check the setting "Group products by category" in POS settings and we don't restrict the categories available in POS, products without category were not shown in the product list. Also when filtering by category, one product with multiple categories was shown multiple times. One time per category it belonged to. This commit fixes the issue by adding products without category at the end of the product list and by only showing products once when filtering by category. If no category is selected, the products will still be shown several times if they belong to multiple categories. Forward-Port-Of: odoo/odoo#238156
This update fixes an issue where the source origin of multiple moves within a picking was being duplicated, leading to inaccurate inventory tracking. The change ensures that each origin is recorded only once, improving the reliability of stock data. This resolves a reporting discrepancy identified in the Odoo system.
Original PR description
### Behavior: #### Current: During the assignment of a picking, if several of its moves have the same origin, it will repeat that origin in its own origin. #### Expected: Only have one time each…
### Behavior: #### Current: During the assignment of a picking, if several of its moves have the same origin, it will repeat that origin in its own origin. #### Expected: Only have one time each origin. ### Steps to reproduce: From Inventory * Enable two step transfer for the warehouse From Barcode * create and validate new receipts with "Product A" * create and validate a second new receipts with "Product A" and other products From Inventory/Operations/Transfers/Receipts * Open the corresponding receipts * In "source Document" (Field: origin, Model : stock.picking) we can see that the reference from second receipts is repeated. ### Observation: In the case of already existing origins it will not duplicate them but it's missing if several item comes from the same origin. https://github.com/odoo/odoo/commit/0caa44ca97d9d197811a03ad2ff227df68d4437a#diff-55c6314416a6a400da6acd5018d161a55eeeb0e3008fec8828121e3dd12be0ebR1410 opw-4970159 Forward-Port-Of: odoo/odoo#232579 Forward-Port-Of: odoo/odoo#223251
This update resolves a visual issue that occasionally appeared when using the cookies bar with a Bootstrap modal open. The fix prevents a Bootstrap setting from causing a brief UI glitch, ensuring the cookies bar displays correctly for all users. This improves the overall user experience.
Original PR description
When pressing `Escape` with a Bootstrap modal open, even if the config key `keyboard` is set to `false` (preventing escape from closing the modal), Bootstrap sets a class `modal-static` on the modal element and removes it shortly after. This causes a UI glitch in the case of the cookies bar. Stopping the event propagation prevents it from happening. task-5421993 Forward-Port-Of: odoo/odoo#241215 Forward-Port-Of: odoo/odoo#240269
This update resolves an issue where Australian BAS W2 reports were displaying incorrect negative signs due to a technical change in how tax signs were handled. The fix ensures the correct sign is applied to W2 lines, preventing double sign inversions and ensuring accurate reporting. This update impacts the generation of Australian tax reports.
Original PR description
Since 19.0, sign handling was moved out of tax tags. In community commit 9f55bc242e71e96260edc425d227409775b6b096, the sign was removed from tax tags, but for BAS line W2 a negative sign was mistakenly kept at the tag level, while the report aggregation already applies a negative sign. This resulted in a double sign inversion. This commit fixes W2 by applying the correct sign. enterprise pr -https://github.com/odoo/enterprise/pull/102114 task- [5416350](https://www.odoo.com/odoo/project.task/5416350) Forward-Port-Of: odoo/odoo#239999
This update enhances the usability of the 'Picture-in-picture' and 'Fullscreen' buttons within Odoo's discuss calls. By adding a subtle hover effect, users can now easily identify and click these buttons, improving the overall user experience. This simple change makes the application more intuitive and efficient.
Original PR description
Before this commit, when in a discuss call, the buttons "Picture-in-picture" and "Fullscreen" in the bottom right had no mouse hover effect. As these buttons are visually just icons, the lack of hover effect makes it hard to tell which button is hovered thus making the click harder than it should. This commit reduces slightly the opacity of items, so that on mouse hover the opacity is removed. This acts as a small hover effect that makes it easier to click on these buttons reliably.  Forward-Port-Of: odoo/odoo#241873
This update fixes an issue where customer information was incorrectly displayed as the author of refund transaction messages. Previously, the logged-in user wasn't properly identified. Now, the correct user who initiated the refund is accurately recorded, ensuring accurate transaction tracking and reporting.
Original PR description
Currently, the customer, who did not perform the operation, is set as the author of the refund, capture, and void transaction messages. **Steps to reproduce:** - Install the `sale_management` module…
Currently, the customer, who did not perform the operation, is set as the author of the refund, capture, and void transaction messages. **Steps to reproduce:** - Install the `sale_management` module and enable the `demo` payment provider. - Create a new quotation and from the `gear` icon, select `Mark Quotation as Sent`. - From the `gear` icon, choose `Generate a Payment Link`, and copy the link. - Open the link in an incognito window, and complete the payment. - Return to the original tab and open the payment transaction from the chatter. - Click `Refund` > `Refund` and observe the `author` of the messages in the chatter. **Observation:** The refund messages entry shows the customer as the author instead of the logged-in user who executed the refund. **Root Cause:** At [1] and [2], when the logged-in user is not a superuser, the code assigns the customer (`self.partner_id`) as the author, even during `refund`, `capture`, and `void transactions`, resulting in an incorrect message author. **Fix:** This commit ensures that during refund, capture, and void transactions, the message author is set to the logged-in user instead of the customer. [1]: https://github.com/odoo/odoo/blob/bbf3bd7b0e1d3e015350f9c959fad056384e2318/addons/account_payment/models/payment_transaction.py#L223 [2]: https://github.com/odoo/odoo/blob/5cf325dfff1ffbc1c4b4d0bcfc44ac9f55ea7c51/addons/sale/models/payment_transaction.py#L110 **Before:** <img width="1910" height="624" alt="5379376_before" src="https://github.com/user-attachments/assets/decdd620-d741-488e-9dec-e5c8c9bafc48" /> **After:** <img width="1917" height="622" alt="5379376_after" src="https://github.com/user-attachments/assets/5f38f3c3-fd2c-489e-afc9-d7a356fde23a" /> opw-5379376 Forward-Port-Of: odoo/odoo#241951 Forward-Port-Of: odoo/odoo#239224
This update corrects a minor issue where the placement of the grade ID field in the partnership module was unintentionally altered. The change restores the field to its original location, ensuring data is displayed and organized correctly. This fix improves the user experience and data integrity.
Original PR description
The following commit [1] modified the position of the VAT field, which caused the grade_id field to be shifted. So this commit updates the xpath to restore grade_id to its original location. [1]: https://github.com/odoo/odoo/commit/3a56f59d466e72b3bf99f241c479cd3130173b41 task-5461569
This update streamlines the planning process by automatically notifying managers when employee work emails are missing. Instead of being blocked in a wizard, users receive a list of affected employees, allowing them to quickly address the issue or escalate to HR. This reduces delays and improves overall planning efficiency.
Original PR description
Before this commit, when the planning manager wants to send the planning and for some employees the work email is missing, the user is blocked on the wizard to fill the work email on those employees if he does not edit access to employee model. This commit makes sure the wizard to fill in the missing work email is not displayed if the user cannot edit the information of the employees. It also displays a notification listing the employees for which the work email is missing. By doing that, the user can easily remove those employees to continue his flow or ask to HR user or the employees concerned to complete the missing information. task-5090163 Forward-Port-Of: odoo/enterprise#102819 Forward-Port-Of: odoo/enterprise#96111
This update corrects a technical issue that prevented the Quality IoT module from functioning correctly when installed alongside the MRP Workorder module. The fix involves relocating a component to ensure proper dependency management, resolving a JavaScript error related to missing module definitions.
Original PR description
### Issue: The QualityCheck component is defined in the `mrp_workorder` module:…
### Issue: The QualityCheck component is defined in the `mrp_workorder` module: https://github.com/odoo/enterprise/blob/7c64908258d5a0fb9adecd6dd2760e255e46314b/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L7 which is not a dependency (even indirectly) of the `quality_iot` module. Hence, if you install the `quality_iot` and enable debug mode, you will raise a JS [error](https://github.com/odoo/odoo/blob/a1583d0564552007a3d5f12d967c2c0036e05e44/addons/web/static/src/module_loader.js#L164-L169) because of missing dependencies: > The following modules are needed by other modules but have not been defined, they may not be present in the correct asset bundle. This happens because commit a13e38006d3cba6cab4565de2b014d294d2c0af3 added a patch of the QualityCheck component in the `quality_iot` https://github.com/odoo/enterprise/blob/eda93203ec8da207768357ae91132a49881a2978/quality_iot/static/src/mrp_display/quality_check.js#L4 https://github.com/odoo/enterprise/blob/eda93203ec8da207768357ae91132a49881a2978/quality_iot/static/src/mrp_display/quality_check.js#L17 opw-5353986 Forward-Port-Of: odoo/enterprise#100899
This update resolves an issue where employees were incorrectly receiving duplicate deductions on their CFDI payslips in Mexico. By removing a specific CFDI concept, the payroll system now accurately accounts for existing deductions, ensuring compliance with Mexican tax regulations. This change impacts the ‘l10n_mx_hr_payroll_account_edi’ module.
Original PR description
Avoid duplicate employee deductions on the CFDI payslip by eliminating the CFDI concept that is currently generating a second retention already accounted for in the “IMSS Total (Employee)” payroll rule. target: 19.0 task-5436851 Forward-Port-Of: odoo/enterprise#102730
This update corrects a minor bug in the live chat feature, ensuring that conversation descriptions now function correctly. The issue stemmed from a subtle code difference that was missed during testing. Adding new tests resolves this problem and improves the reliability of the live chat experience.
Original PR description
*: im_livechat Accidental regression from https://github.com/odoo/odoo/pull/237749 The code had getter named `allowDescriptionsTypes` and the patch was `allowDescriptionTypes`. While this looks the same at a glance, there's is a "s" in "description(s)" that differs. This subtle change was not caught due to lack of test coverage, which this commit adds.
This update resolves an issue where Studio was incorrectly loading POS views as default, even when they weren't fully supported in the backend. A new mechanism allows modules to control which views are considered as defaults, ensuring Studio consistently loads the correct views for Studio users. This improves Studio's reliability and user experience.
Original PR description
Task: [#5191154](https://www.odoo.com/odoo/project/1737/tasks/5191154) --- When activating some views with Studio, we could end up loading a POS view because it has a lower sequence. As a result, Studio selects this view. However, these POS views may not be loaded in the backend bundle (`web.assets_backend`), and thus are missing at runtime. Example: "Cannot find key 'pos_kanban' in the 'views' registry". This commit creates a hook to get the domain used to fetch default views (`_get_default_view_domain()`). This way, modules can override the domain of `_get_default_view_domain()` method in order to exclude some views from being selected as default ones no matter the sequence. Forward-Port-Of: odoo/odoo#237122
This update resolves a problem where Studio was incorrectly loading POS views as default, leading to errors. The change prevents these POS views from being selected by default, ensuring the backend operates with the intended views and improving stability.
Original PR description
..., appointment, l10n_ke_edi_oscu_pos Task: [#5191154](https://www.odoo.com/odoo/project/1737/tasks/5191154) --- When activating some views with Studio, we could end up loading a POS view because it has a lower sequence. As a result, Studio selects this view. However, these POS views may not be loaded in the backend bundle (`web.assets_backend`), and thus are missing at runtime. Example: "Cannot find key 'pos_kanban' in the 'views' registry". This commit edit the domain of `_get_default_view_domain()` method in order to exclude these POS views from being selected as default ones. Forward-Port-Of: odoo/enterprise#98764
This change corrects a display inconsistency in loyalty promotions. Previously, users could inadvertently link promotion descriptions to discount products, leading to inaccurate discount information. This fix removes the ability to modify this technical field, ensuring consistent discount descriptions are shown to customers.
Original PR description
### Issue: Due to this issue, users can change the technical field `discount product` which cause inconsistency in discount description. #### To reproduce: 1- Create a promotion called `AAA`: -…
### Issue: Due to this issue, users can change the technical field `discount product` which cause inconsistency in discount description. #### To reproduce: 1- Create a promotion called `AAA`: - Rules: If minimum 50.0 spent grant 1 point per order - Rewards: 10% discount per order in exchange of 1 point 2- Using debug mode, in promotion's reward view, change the `Description on order` to `AAA 10%`. Save the promotion and you can see the `Discount product`'s name is set to the same description. 3- Create another promotion called `BBB`: - Rules: If minimum 50.0 spent grant 1 point per order - Rewards: 10% discount per order in exchange of 1000 points. 4- In promotion reward's view change the `Discount product` to `AAA 10%` which is promotion `AAA`'s discount product. 5- Change the `Description on order` to `BBB 10%` and save. 6- You can see the name of `Discount product` is changed as well. 7- In promotion `AAA` and you can see the description and the name of `Discount product` mismatch. 8- Navigate to shop, and add a product to cart with a price of more than 50. 9. You can see after applying promotion `AAA` the description from promotion `BBB` is shown. ### Cause: The technical field `Discount product` is never meant to be changed, and this field is introduced for reporting purposes and showing the discount applied in cart. However, this field is added to view in #132857. This is done as a hack to find the `Discount product` created for the promotion, as a workaround for an accounting issue due to adding account to `Discount product`, and originally `discount_line_product_id` was not supposed to be shown or changed through form. After discussion with PO, we decided this field should be removed from the view. Also removing this field will not undo the main fix of #132857, and that workaround was introduced only to find the `Discount product` for that specific client's use case. However, in stable, it is kept for customization compatibility. It's set invisible in order to prevent the issue. opw-5229633 Forward-Port-Of: odoo/odoo#240684
This update corrects a technical issue where the Swedish blackbox feature in Odoo experienced tracebacks when receiving non-UTF-8 characters from serial devices. The fix involves gracefully handling these errors during decoding, ensuring stable operation and preventing disruptions to data collection.
Original PR description
If a non utf-8 chracter is returned by a serial-connected device, the supported method of the swedish bb raises a traceback.