Daily updates from Odoo
Wednesday, April 22, 2026
294 changes
7 changes
Enhancements to existing features
This update improves how work entry source values are merged in the HR work entry process. It helps ensure work entry data is combined more reliably, reducing the risk of inconsistencies in payroll-related records.
Original PR description
Task: 6119891 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
The Moves Analysis report now shows the date of each stock move directly in the list view, instead of hiding it behind debug mode. This makes it easier for users to review movement timing and understand inventory activity at a glance.
Original PR description
The date of the move is a basic and important information. Show it on the 'Moves Analysis' report list view, previously was only displayed in debug mode. task-5380628 Forward-Port-Of: odoo/odoo#254999
Resolved issues and error corrections
This update corrects how Premium Pay is calculated in Belgian payroll so payments stay within the proper limits. It helps prevent incorrect pay amounts and improves payroll accuracy for affected employees.
Original PR description
add premium pay caps Task: 6119891
This change restores the expected format for translated HTML content when it is exported. It prevents the export file from becoming invalid in cases where quoted text appears in HTML translations, helping ensure translations can be shared and imported correctly.
Original PR description
Refactor odoo/odoo#246357 made get_translation_dictionary return Markup-wrapped keys and values for translate=True HTML fields. When polib.POEntry is given Markup, double quotes in .po output are not escaped as expected, which can produce invalid PO files. Keep dict[str, dict[str, str]] for those entries so export stays correct without special-casing each writer path. for solving problem <img width="812" height="254" alt="image" src="https://github.com/user-attachments/assets/6901865a-4dd9-49a7-ba1c-f90dbb346976" /> 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
This change restores the expected workflow when submitting the French tax filing package. It ensures the normal processing step still runs, preventing a test failure and keeping the report status updated correctly.
Original PR description
When merging the sending of the liasse fiscale, super() wasn't called anymore in action_submit and led to an assertError in test_state_progression() test
```
FAIL: Subtest TestAccountReturn.test_state_progression (return_type=account.return.type(186,))
Traceback (most recent call last):
File "/data/build/enterprise/account_reports/tests/test_account_returns.py", line 2087, in test_state_progression
self.assertEqual(account_return.state, 'paid')
AssertionError: False != 'paid'
```
runbot-275061This update makes domain validation catch invalid data types more reliably, such as entering text where a number is expected. It helps prevent incorrect filters from passing validation and reduces errors later when the system builds database queries.
Original PR description
`Domain([('num_field', '=', 'dfd')]).validate(model)` should raise an exception because 'dfd' is not a valid number. Currently, the optimization does not check the data types for all operators, but these are checked during SQL generation. Let's generate the SQL to validate the domain.
task-6132976
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#260102This change fixes how translated HTML content is prepared for export, so translation files are generated in a valid format again. It prevents broken quotation handling in exported .po files, which helps avoid issues when translating and re-importing content.
Original PR description
Refactor odoo/odoo#246357 made ``get_translation_dictionary`` return Markup-wrapped keys and values for `field.translate is True` HTML fields. When polib.POEntry is given Markup, double quotes in .po output are not escaped as expected, which can produce invalid PO files. Keep ``dict[str, dict[str, str]]`` for those entries so export stays correct without special-casing each writer path. Also revert the support for ``field.get_trans_terms()`` when ``field.translate is True``. for solving problem <img width="812" height="254" alt="image" src="https://github.com/user-attachments/assets/6901865a-4dd9-49a7-ba1c-f90dbb346976" /> 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
33 changes
Enhancements to existing features
The website’s video snippet preview now uses a lightweight SVG illustration instead of an embedded video. This reduces ongoing maintenance and makes the preview more reliable over time.
Original PR description
Prior to this PR, the `s_video` inner snippet was using a video as placeholder, which implied maintenance to ensure the video is always available. To avoid maintenance and ensuring long term effectiveness, we replace this video with a `SVG` placeholder, similarly to what has been done for the `s_image`. task-5441285 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260042
The wording of the Invoicing Switch Threshold help text was clarified to better explain which entries are ignored. This reduces the risk of misunderstanding when setting the switch date and helps users make the right accounting decision.
Original PR description
The previous "Invoicing Switch Threshold" explanation was misleading as it said only invoices prior to the threshold date is not taken into account. The explanation is updated to state that all entries created by Invoicing before the threshold date will be ignored. task-5940144 Forward-Port-Of: odoo/enterprise#113635
The Moves Analysis report now displays the date of each stock move directly in the list view. This makes the report easier to read and helps users review movement timing without needing debug mode.
Original PR description
The date of the move is a basic and important information. Show it on the 'Moves Analysis' report list view, previously was only displayed in debug mode. task-5380628 Forward-Port-Of: odoo/odoo#254999
This update lets users split a manufacturing order into multiple smaller orders when generating serial numbers. It makes it possible to assign one serial number to each sub-order in a single workflow, which simplifies production for items tracked by serial number.
Original PR description
Since 4bb4e08066449, producing multiple serial that have been generated is only doable on one mo. We can split mo. we can generate serial number but we cannot do both at the same time. This commit adds a new button into the generate serial wizard to split the main mo into the number of serial wanted and attribute one for each sub mo. 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#257694 Forward-Port-Of: odoo/odoo#255577
Resolved issues and error corrections
Fixed an issue in the Time Off Gantt multi-create flow where the Time Off Type dropdown could appear empty after selecting multiple dates. The form now correctly refreshes its fields, so users can choose the right time off type and create requests smoothly.
Original PR description
**Steps to Reproduce:** 1. Open Time Off App->Management->Time Off->Gantt View 2. Highlight multiple dates/cells to trigger the multi-create popover, then click "Set". 3. Open the "Time Off Type"…
**Steps to Reproduce:**
1. Open Time Off App->Management->Time Off->Gantt View
2. Highlight multiple dates/cells to trigger the multi-create popover, then click "Set".
3. Open the "Time Off Type" dropdown. The dropdown appears empty.
**Bug Cause:**
When forceFullDuration is true and request_duration is pre-populated in initial values, the form detects no field changes and skips triggering onchange. This prevents computed fields like allowed_work_entry_type_ids from being evaluated, resulting in an empty domain filter ('id', 'in', []).
**Solution:**
Remove the pre-population of request_duration in initial values when forceFullDuration is true. The context value force_full_duration is sufficient to filter the request_duration field to show only "full" option.
By not pre-setting the value, the form detects a field change and properly triggers onchange, allowing computed fields to evaluate and populate the Remove the pre-population of request_duration in initial values when forceFullDuration is true. The context value force_full_duration is sufficient to filter the request_duration field to show only "full" option. By not pre-setting the value, the form detects a field change and properly triggers onchange, allowing computed fields to evaluate and populate the allowed_work_entry_type_ids correctly.
**Task:** 6109569This update corrects how Belgian NISS "bis" numbers are read when deriving an employee’s birth date. It prevents invalid dates from being generated, which helps payroll data stay accurate and avoids errors during processing.
Original PR description
…fset) in birthday parsing The NISS month field can be increased by 20 or 40 for "numéros bis". This caused invalid date parsing. Use modulo 20 to normalize the month before constructing the birthday. task-6144297
Copying a helpdesk ticket no longer fails for users who do not have stock permissions. The system now avoids carrying over a stock-related product when duplicating the ticket, so business users can duplicate records normally.
Original PR description
Steps to reproduce: - Install helpdesk_sale_timesheet. - Create a Helpdesk Ticket and set its sale_line_id. - Log in as a user without stock.group_stock_user access. - Try to duplicate the ticket. Issue: Duplicating a ticket raises an AccessError because the user lacks stock rights required when copying the product_id. Fix: Set `product_id` to False during duplication for non-stock users. Reference: https://github.com/odoo/enterprise/pull/9100 task-5356318 Forward-Port-Of: odoo/enterprise#114266 Forward-Port-Of: odoo/enterprise#101338
When users type an email address in the editor, it now automatically becomes a clickable email link as soon as they add a space. This makes it easier to create correctly formatted contact links without extra manual steps.
Original PR description
Before this commit: when typing an email address, it's not converted to a mailto link after spacing. After this commit: the mailto link is created after spacing. task- 6053993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258736 Forward-Port-Of: odoo/odoo#257497
This update prevents loyalty points from being incorrectly rounded down when a company uses a currency with a large rounding factor. As a result, point-based reward programs will work as expected and rewards will remain claimable, while money-based programs still use currency rounding where appropriate.
Original PR description
`_get_real_points_for_coupon` was unconditionally rounding points using `coupon.currency_id.round()`, which uses the currency's rounding factor as a precision unit. For point-based programs (e.g. 1 point per order), a currency with a large rounding factor (e.g. 10) would round 1 point down to 0, making all rewards unclaimable. Currency rounding is only semantically correct when points represent monetary amounts, which is the case when `reward_point_mode == 'money'` (gift_card, ewallet, and money-mode loyalty programs). For all other programs, points are dimensionless and should not be subject to currency precision rules. opw-6111622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259660
This change stabilizes an automated test in the HTML editor so it no longer fails unpredictably. It helps ensure more reliable quality checks without changing the user-facing editor behavior.
Original PR description
My last desperate fix attempt did not fix the issue so here is yet another desperate fix attempt. I have seen issues related to the use of `setContent` just to set the selection in the past so I hope it might be that. It's the only noticeable change between this test and the others, be it icon tests or color selector ones. runbot-242333 Forward-Port-Of: odoo/odoo#259978 Forward-Port-Of: odoo/odoo#259544
This update fixes an unstable automated test in the HTML editor by waiting based on elapsed time instead of a fixed animation frame. It makes the test more dependable on slower systems and reduces false failures without changing the product’s behavior.
Original PR description
Waiting for a full animation frame is too dangerous. In the general case, an animation frame happens every 16ms, in which case the power buttons haven't been updated yet since they have a debouncing timeout of 30ms. However, when the runbot is slow, more than 30ms may very well have elapsed between two animation frames. When that is the case, the power buttons are displayed and the test fails. This commit changes the forced awaiting of an animation frame to a waiting pased on the time passed. In the general case, an animation frame will have happened in 20ms, so the test will still catch a regression. When the runbot is slow however, more time might have passed, but not necessarily an animation frame, so the power buttons should still be invisible, making this test more reliable. runbot-242466 Forward-Port-Of: odoo/odoo#259854 Forward-Port-Of: odoo/odoo#259654
This change reverts a previous adjustment that affected how child contact names were shown. It helps ensure invoices and related documents display contact information in the expected way, reducing confusion for customers and internal teams.
Original PR description
This reverts commit 0ef4c1d06fdf999ad5cdad696069aec8f2f943c5. opw-5900567 Forward-Port-Of: odoo/odoo#260186 Forward-Port-Of: odoo/odoo#260065
Imported XML attachments are now kept linked in a safer way so they can still be opened when needed. This prevents access errors when users view bills created from email imports, especially in Mexican e-invoicing flows.
Original PR description
When importing files (manually or from email alias), we unattach the xml files, it can lead to access error in some flows like with l10n_mx_edi Steps to reproduce the flow that triggered the bug: - Install l10n_mx_edi and select MX company - Create an email alias for purchase journal - Receive email with xml file - Create a user with 'group_user' role, 'Administrator' accounting access rights - Login with this user and open the created bill -> Access Error This is because we unattach xml attachmentss when importing them, by setting `res_id` to 0 and `res_model` to False. The mx edi flow adds the `l10n_mx_edi_cfdi_attachment_id` via `_get_mail_thread_data_attachments` which lead to an access error during the `fetch` method opw-5953578 Forward-Port-Of: odoo/odoo#260127 Forward-Port-Of: odoo/odoo#259095
This update corrects the appearance of contract-related buttons on the employee form. It keeps the "New Contract" label from wrapping on narrow screens and makes the contract template button match the surrounding interface more closely.
Original PR description
- Add `text-nowrap` to the "New Contract" button to prevent text from splitting at narrow viewport widths - Fix contract template button styling: remove incorrect classes and align font-size and border with the surrounding UI task-6068488 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#256017
When a packed item is scanned with GS1 information, the system now correctly keeps the due date instead of defaulting to today. This ensures newly created lots carry the right expiration information, reducing manual corrections and avoiding mistakes in shipping and inventory records.
Original PR description
Issue
-----
Scanning a GS1 barcode containing:
- packaging
- lot
- due date
disregards the due date when creating the new lot.
Steps to reproduce
-----
- Enable GS1 nomenclature & packagings
- Create a product
- barcode 23456789012344
- packaging with barcode 01234567890128
- some on hand quantity
- Create a delivery for a full packaging of the product
- Open the delivery in barcode
- Scan 02 01234567890128 15 270101 10 LOT1
- Validate
- Open the lot
> Expiration date is set to today
Cause
-----
The code expects the product be scanned, there is no logic to retrieve it from the packaging when missing.
-----
Ticket:
opw-6073489
Forward-Port-Of: odoo/enterprise#114327
Forward-Port-Of: odoo/enterprise#112490The button used to manage contract templates on the employee form now matches the surrounding interface better. This fixes inconsistent spacing and border styling so the page looks cleaner and more polished for users.
Original PR description
Fix contract template button styling: remove incorrect classes and align font-size and border with the surrounding UI task-6068488 Forward-Port-Of: odoo/enterprise#112113
This update adjusts an internal compatibility check so it recognizes the newer milestone for lxml 6.1. It helps keep accessibility-related HTML handling aligned with the updated library behavior and prevents the patch from being treated as outdated too early.
Original PR description
Whitelisting of ARIA attributes is now part of the milestone for LXML 6.1. This commit updates monkey patch's obsolescence detection accordingly. Forward-Port-Of: odoo/odoo#258910
This change prevents dropdown text from spilling out of bottom sheet panels or overlapping the selected checkmark. It also keeps long device names in voice and video settings from causing horizontal scrolling on small screens, improving the experience on mobile devices.
Original PR description
**Purpose of this PR:** Before this commit, in the bottom sheet, dropdown labels could overflow their active container or overlap with the checkmark icon when selected. In voice/video settings, long…
**Purpose of this PR:**
Before this commit, in the bottom sheet, dropdown labels could overflow their active container or overlap with the checkmark icon when selected. In voice/video settings, long selected device names could cause horizontal
scrolling on small screens.
This commit:
- Allows dropdown labels in bottom sheets to wrap on small screens.
- Reserves space for the checkmark icon in all bottom sheet dropdowns if any item is selected, ensuring consistent alignment.
- Constrains the selected device label within the available space voice/video settings to prevent layout overflow.
<table>
<tr>
<td><b>Before</b></td>
<td><b>After</b></td>
</tr>
<tr>
<td><img src="https://github.com/user-attachments/assets/8f347abc-fe26-427a-95ec-97ace3a0c5a2" width="300"/></td>
<td><img src="https://github.com/user-attachments/assets/6d6104b5-46c3-404b-be09-1cfa55209a96" width="300"/></td>
</tr>
</table>
task-[6095602](https://www.odoo.com/odoo/project/1519/tasks/6095602)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects inventory valuation so that quantities and values are computed properly when a specific end date is selected, regardless of the user's time zone. It prevents stock reports from showing missing or zero stock for items received on the selected day.
Original PR description
**Issue** While performing stock valuation, when a `to_date` is selected, the resulting valuation may be incorrect depending on the user's timezone. **Steps to reproduce** - Set the user timezone to…
**Issue** While performing stock valuation, when a `to_date` is selected, the resulting valuation may be incorrect depending on the user's timezone. **Steps to reproduce** - Set the user timezone to UTC+1 - Create a storable product with: - quantity: 10 (created today) - unit cost: 5 - valuation method: AVCO - Go to Accounting > Review > Inventory > Inventory Valuation - Select today's date - Click on "Ending Stock" -> The total value and quantity in stock are 0 instead of respectively 50 and 10. **Cause** When selecting a date (e.g. 12/04), the `to_date` is initially set at 00:00 in the user's timezone. An attempt is then made to convert it to 23:59 to avoid excluding quantities created during that day: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150 However, this conversion is performed on a naive UTC datetime. For a user in UTC+1, this results in the following situation: - 12/04 00:00 (user timezone) -> 11/04 23:00 UTC - Converted to 23:59 UTC -> 12/04 00:59 in user timezone As a consequence, most of the quantities created on 12/04 are excluded from the valuation. This issue impacts AVCO (and FIFO as well), as `at_date` is used during cost computation: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150 In addition, `at_date` is added to the context, while `qty_available` relies on `to_date` instead: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock/models/product.py#L151-L153 This inconsistency leads to incorrect quantities and valuation results. opw-5491743 Forward-Port-Of: odoo/odoo#253438 Forward-Port-Of: odoo/odoo#246163
The call menu now includes the Picture-in-Picture action, making it easier to keep a call visible while switching to another conversation or chatter. It also corrects the visual styling of Fullscreen and Picture-in-Picture in the menu so they display at normal opacity.
Original PR description
Before this commit, Call Menu did not have the "Picture-in-Picture" action. This is unfortunate because this is one of the most valuable action to have it available there, as a frequent usage of…
Before this commit, Call Menu did not have the "Picture-in-Picture" action. This is unfortunate because this is one of the most valuable action to have it available there, as a frequent usage of Discuss is to join a call, switch to another conversation or chatter, and then wanting to keep an overlay of the call. Without the "Picture-in-Picture" in Call Menu, this forces user to access the Discuss conversation again and then click on "Picture-in-Picture" there, when clicking on the call menu would be faster. This commit adds the "Picture-in-Picture" action in the call menu to ease using this feature. Also fixes an issue where "Fullscreen" and "Picture-in-Picture" actions have reduced opacity in the Call Menu. This comes from opacity hover effect that should be limited to their inline visual in the Call view but was mistakenly also present in the dropdown. Before / After <img width="440" height="369" alt="Screenshot 2026-04-17 at 14 15 58" src="https://github.com/user-attachments/assets/2accb779-28f5-4930-a101-db5e52b029b7" /> Forward-Port-Of: odoo/odoo#260416 Forward-Port-Of: odoo/odoo#259866
This change keeps message text readable when users click into a communication box in Helpdesk and related areas. It ensures the text color stays correct even after the field gains focus, which prevents white text from appearing on a white background in dark-themed websites.
Original PR description
# Setup Edit the theme of the website : in the Light & Dark section, set the first color to black. The main background color of the website should be black and the text should be in white. # How to…
# Setup Edit the theme of the website : in the Light & Dark section, set the first color to black. The main background color of the website should be black and the text should be in white. # How to reproduce - Install the Helpdesk app - Go to Website > Help - Submit a ticket (the ticket's information is not important) - Click the ticket link shown when the ticket is submitted - Start writing a message in the Communication History. # The problem As long as the text bubble is focused, the text is white even though the bubble is also white, making the text unreadable. Note : the same problem is present for product reviews in the eCommerce application. These text bubbles seems to be intended to stay white even in a dark main background color, so the text should be black : https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/mail/static/src/core/common/composer.scss#L103 # Cause The textarea (text bubble) has a the `.form-control` css class coming from bootstrap that applies `color: var(--bs-body-color)` : https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L2115-L2131 In our case, it sets `color` to #FFF (I'm not 100% sure where this value is coming from since I did not find any instance where --bs-body-color or --body-color are ever set to that value). Anywyay, this value is overidden by `.o-discuss-text-body`: https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/mail/static/src/core/common/core.scss#L99-L101 But the value is overriden again when the textarea is focused by the `form-control:focus` css class that sets back the color to #FFF: https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L2143-L2149 The issue was caused by this commit that changed the class used to define the color for the discuss messages : https://github.com/odoo/odoo/commit/3557de4232ebc307c8861379f6573d7b36cd8db6 Because `.o-discuss-text-body` is overriden by `form-control:focus` while `.text-body` is not. This is most probably due to the order in which the stylesheets are applied. # Proposed solution Add `, .o-discuss-text-body:focus` to make sure the rule is also applied when the text bubble is focused opw-6063961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258142
The grouped list pager now uses the actual total number of records when that total is already known, instead of falling back to the configured display limit. This makes record counts more accurate and avoids confusing users when browsing grouped lists with many records.
Original PR description
When a pager is needed in a grouped list view and if the total number of record is greater than the `count_limit` (by default equal to 10000); opening the group or pressing the "Next" button will display the `count_limit` in the Pager.
This behavior can be optimized since the `web_read_group` call already computed the total count.
This commit allow the grouped list pager to display the total record count if it was already computed.
Steps to reproduce:
in a list view with 10 records, all in the same group for simplicity:
```xml
<list limit="2" count_limit="8">
<field name="foo"/>
</list>
```
- group the view by "foo" => The pager displays: `"1-2 / 10"`
- click on the 'next' button of the pager => The pager displays: `"3-4 / 8"`
8, the `count_limit` is shown instead of 10, the number of records in the group.
task-6053705
Forward-Port-Of: odoo/odoo#259858
Forward-Port-Of: odoo/odoo#259562This update prevents an error that could occur when the Purchase app is installed after Accounting on older database versions. It makes the purchase invoice view more resilient so users can continue installing and using modules without the setup failing.
Original PR description
c5ac4867fb708c56aa74e38508347660f1875dd3 added back the computed fields `invoice_vendor_bill_id` and `purchase_vendor_bill_id` on `account.move` in stable. The issue is that the view on purchase expects the view on account to have `invoice_vendor_bill_id` in it. But if a user already had `account` installed before the commit, then install `purchase` after, the purchase view will raise an exception as it expects `invoice_vendor_bill_id` in the view of account. The fix here is to not reference `invoice_vendor_bill_id` in the purchase view and compute its visibility with a non-stored computed field.
This change fixes an error that could happen when opening account report information. It ensures the report uses the correct way to update internal report data, so users can view reports without interruption.
Original PR description
Currently, an error occurs when retrieving account report information. ``` File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1475, in _create_hierarchy…
Currently, an error occurs when retrieving account report information.
```
File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1475, in _create_hierarchy
render_lines(root_account_groups, current_level, root_line_id, skip_no_group=False)
File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1373, in render_lines
child_line.update
^^^^^^^^^^^^^^^^^
AttributeError: 'AccountReportLineData' object has no attribute 'update'
```
After the [recent commit], all lines, columns, format_params, and annotations are converted into custom objects (AccountReportLineData). However, the code still attempts to use the update() method on these objects, which raises an error [1] since AccountReportLineData does not have an update method.
This commit ensures that the update_value() method is used to update AccountReportLineData objects, as intended, like here [2].
[recent commit]: https://github.com/odoo/enterprise/commit/6608d5c21a7fb9d57786c2a7618b878e244bd420
[1]- https://github.com/odoo/enterprise/blob/cde4e05de82476655764f8c9fe8734416d4a35bf/account_reports/models/account_report.py#L1373-L1377
[2]- https://github.com/odoo/enterprise/blob/cde4e05de82476655764f8c9fe8734416d4a35bf/account_reports/models/account_report.py#L6565
sentry-7403925422Discuss now correctly displays complex emoji combinations as a single symbol instead of splitting them into parts. This improves message readability and prevents emoji from appearing incorrectly in chat conversations.
Original PR description
Prior to this commit, emoji sequences were rendered incorrectly in Discuss. The existing regex failed to match multi-codepoint sequences, splitting complex emojis (like ❤️🔥) into separate individual emojis (❤️ and 🔥). Steps to reproduce: 1. Post a message in Discuss containing "🤷♂️" 2. Notice the message displays "🤷♂" instead This commit refines `EMOJI_REGEX` to match complete emoji sequences. [Task-6128638](https://www.odoo.com/odoo/project/1519/tasks/6128638)
This update corrects a typo and improves the dashboard’s styling for a cleaner user experience. It does not change how the feature works, but it helps make the interface look more polished and consistent.
Original PR description
task-6132220
This update makes AI chat messages easier to read by reducing oversized headings and cleaning up table borders in the chat layout. It also fixes a formatting issue that could cause stray asterisks to appear in AI responses, making the content display more consistently for users.
Original PR description
- The font-size of h1/h2 headers is large given the small size of chat channels which makes it harder to read the rest of the text. So, the font-size of h1/h2 headers is reduced in ai chat channels. - This commit removes the double border at the bottom of tables and updates the table borders by using table-bordered bootstrap class instead of border. - This commit also fixes an error where markdown2 2.4.11 doesn't detect the boundaries of bold markup properly causing asterisks to appear randomly inside AI responses. For example, "The **dog**, the **cat** and the **rat**" becomes "The <strong>dog<em>*, the *</em>cat<em>* and the *</em>rat</strong>" where it should only use <strong>dog/cat/rat</strong> task-6109286
Resupply pickings for subcontracted products now correctly display the source purchase order, even when the replenishment route uses the alternate stock-based flow. This makes it easier to trace where the resupply came from and reduces confusion for users managing subcontracting operations.
Original PR description
### Steps to reproduce: - In the settings enable: Subcontracting, Multi-Step Routes - Inventory > Configuration > Warehouse Management > Routes - Edit the 'Resupply Subcontractor on Order' route,…
### Steps to reproduce: - In the settings enable: Subcontracting, Multi-Step Routes - Inventory > Configuration > Warehouse Management > Routes - Edit the 'Resupply Subcontractor on Order' route, rules supply method to: Take from stock, if unavailable, trigger another rule (mtso) - Create a subcontracted bom For a product P with a component COMP - Create and confirm a PO for 1 unit of P with your subcontractor - Use the Resupply smart button to access the resupply picking #### > The resupply picking does not refer to the source PO ### Cause of the issue: The link is currently computed based on `move_dest_ids` which are only set for mto moves. However, moves created from mtso rules are `make_to_stock`. ### Fix: Since 19.0 2713876dbc70d3984e584a9037a2206dcda4e84a, we can rely on references to rebuild the link between the resupply picking and the source PO even in mtso. Note that this will also add the source PO link to each other picking of the reference. opw-6079680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256689
This update improves how the editor handles content inside inline code. It prevents formatting tools from appearing when text is fully inside code, and makes pasted content inside code insert as plain text so the result stays consistent. When a selection includes both code and normal text, formatting is now applied only to the normal text, reducing unexpected changes while editing.
Original PR description
### Purpose of this commit: - Prevent the powerbox and toolbar from opening when the selection is fully inside inline code. When the selection spans inline code and regular text, keep the toolbar visible but ensure formatting commands are applied only to the non-inline-code content. - Ensure that pasted external and editor HTML is converted to plain text when inserted inside inline code. task-5502939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258781 Forward-Port-Of: odoo/odoo#250911
This fix ensures product prices are converted from each product’s own currency to the Point of Sale currency, instead of assuming they were always in the company currency. As a result, prices shown and charged in multi-currency setups will be more accurate and consistent at checkout and on receipts.
Original PR description
Before this commit, in a multi-currency environment, the company currency was used to convert the prices, while it was a wrong assumption that the product prices were in the company currency. The products have a currency_id field, and the price should be converted from that currency to the PoS config currency. opw-6065969 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257324
Downloading receipts for kiosk self-order POS orders could fail with an error in some cases. This fix prevents that error so receipts can be opened and downloaded normally.
Original PR description
Currently an error occurs when the user tries to `Download Receipt` of self-orders as the following steps: - Install the pos_self_order module - Create a new POS shop with `Self Ordering` as `Kiosk` - Add Online `Payment Methods` on the above POS shop - Make an order from kiosk mode - Go to Point of Sale > Orders > Orders - Open the recent order which was created from the kiosk. - Click `Download Receipt` > Error Error: `QWebError:Error while rendering the template: AttributeError: 'bool' obje...` This issue occurs because, while rendering pos_order_receipt_header`, the `preset` value is `False`. Attempting to call `.get()` on a falsy value leads to an error. This commit fixes the issue by accessing `preset` only when it is available, preventing errors during rendering. sentry-7402711985
This update corrects an automated performance test so it matches the current demo data setup. It helps keep test results reliable and prevents false failures during validation.
Original PR description
Query counts were updated for demo data. runbot-242325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260297
This change filters out characters that are not accepted by the Swiss QR-bill standard before generating QR codes. It helps prevent bank rejections caused by unsupported Unicode characters in payment references or addresses.
Original PR description
**Description of the issue/feature this PR addresses:** QR code is rejected by the bank, when it contains an invalid character `U+202F`. **Current behavior before PR:** Unauthorized Unicode characters are encoded in the QR-Bill, and it is rejected on the receiving part. **Desired behavior after PR is merged:** Any Unicode codepoint which is not in the subset of 324 allowed codepoints has to be filtered out. > spec of QR-bill allows only a subset of characters, a precise list of 324 Unicode codepoints (section 4.1.1, page 30 of the Swiss Implementation Guidelines for the QR-bill) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258680 Forward-Port-Of: odoo/odoo#254980
18 changes
Enhancements to existing features
The explanation for the Invoicing Switch Threshold has been clarified to better describe which entries are ignored. This helps users understand that all entries created by Invoicing before the threshold date are excluded, avoiding confusion and incorrect expectations.
Original PR description
The previous "Invoicing Switch Threshold" explanation was misleading as it said only invoices prior to the threshold date is not taken into account. The explanation is updated to state that all entries created by Invoicing before the threshold date will be ignored. task-5940144 Forward-Port-Of: odoo/enterprise#113635
After databases are synchronized from Odoo.com, the system now tries to create a local API key for each database that does not already have one. This reduces an extra validation step against the global key, which makes database access faster and can save about half a second per database in some cases.
Original PR description
Before this commit, databases fetched from Odoo's SaaS were contacted using the global API key, which is more costly than using a key local to each database. Avoiding the call from the server to Odoo to check the foreign API key can spare about 500ms on each database where this key is not in the LRU. With this commit, after the synchronization with Odoo.com, we try to generate an API key on each database that doesn't have one yet. To do so, it relies on the API introduced by odoo/odoo#246118. Forward-Port-Of: odoo/enterprise#106372
The Moves Analysis report now shows the date of each stock move directly in the list view. This makes the report easier to read and removes the need to switch to debug mode to see this basic information.
Original PR description
The date of the move is a basic and important information. Show it on the 'Moves Analysis' report list view, previously was only displayed in debug mode. task-5380628 Forward-Port-Of: odoo/odoo#254999
Resolved issues and error corrections
Imported XML files are now kept attached in a safer way so they can still be accessed by related invoice flows. This prevents access errors when opening bills created from email aliases or manual imports, especially for Mexican electronic invoicing cases.
Original PR description
When importing files (manually or from email alias), we unattach the xml files, it can lead to access error in some flows like with l10n_mx_edi Steps to reproduce the flow that triggered the bug: - Install l10n_mx_edi and select MX company - Create an email alias for purchase journal - Receive email with xml file - Create a user with 'group_user' role, 'Administrator' accounting access rights - Login with this user and open the created bill -> Access Error This is because we unattach xml attachmentss when importing them, by setting `res_id` to 0 and `res_model` to False. The mx edi flow adds the `l10n_mx_edi_cfdi_attachment_id` via `_get_mail_thread_data_attachments` which lead to an access error during the `fetch` method opw-5953578 Forward-Port-Of: odoo/odoo#260127 Forward-Port-Of: odoo/odoo#259095
This change corrects how child contact names are shown again, restoring the expected display for related contacts. It helps ensure invoices and customer records use the right names, reducing confusion in day-to-day business operations.
Original PR description
This reverts commit 0ef4c1d06fdf999ad5cdad696069aec8f2f943c5. opw-5900567 Forward-Port-Of: odoo/odoo#260186 Forward-Port-Of: odoo/odoo#260065
This change prevents loyalty points from being rounded as if they were currency when the program is not money-based. As a result, point-based rewards will no longer be accidentally reduced to zero in currencies with large rounding steps, so customers can claim their rewards normally.
Original PR description
`_get_real_points_for_coupon` was unconditionally rounding points using `coupon.currency_id.round()`, which uses the currency's rounding factor as a precision unit. For point-based programs (e.g. 1 point per order), a currency with a large rounding factor (e.g. 10) would round 1 point down to 0, making all rewards unclaimable. Currency rounding is only semantically correct when points represent monetary amounts, which is the case when `reward_point_mode == 'money'` (gift_card, ewallet, and money-mode loyalty programs). For all other programs, points are dimensionless and should not be subject to currency precision rules. opw-6111622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259660
This update automatically removes Timesheets assistant suggestions older than 30 days. It prevents unused data from piling up in the browser storage, helping keep the feature lightweight and reliable over time.
Original PR description
In the Timesheets assistant, we store the suggested events taken or dismissed by the user to avoid suggesting them again. However, there is no mechanism to remove them from the localstorage, so it currently grows infinitely. With this PR, we now delete events older than 30 days, to avoid filling the localstorage with useless data. Task-6131640
This update prevents an error that could appear when using the Project app on mobile and adding a dependency in the “Blocked by” section. It ensures the page opens correctly, improving reliability for users working on tasks from their phone.
Original PR description
Steps to reproduce: - Install Project - Create a project and a task and enable task dependencies - In mobile view, go to the "Blocked by" tab and click "Add" Issue: A traceback occurs in the mobile view. Cause: In this pr https://github.com/odoo/odoo/pull/230738 parent_id was moved inside anchor element. Fix: Update the XPath to correctly replace the element containing parent_id. task-6009997
The attendance Gantt view now shows the expected hours correctly for employees with flexible working schedules. This prevents the hours bar from disappearing or showing the wrong value on longer date ranges, making planning and attendance tracking more reliable.
Original PR description
For employees having a `resource_calendar_id` with `flexible_hours`, the max hours displayed in the gantt view were incorrectly `days * hours_per_day`. This fixes it by taking the most relevant data between `days * hours_per_day`, `weeks * hours_per_week`, both, or nothing if the range is more than a month. The new calculation is `(weeks * hours_per_week) + min((days * hours_per_day), (hours_per_week))` task 5075953
This update fixes a typo in time-related text shown on website and mass mailing snippets, changing the wording from “am” to “pm” where appropriate. It helps ensure opening hours and scheduled times are displayed correctly and avoids confusion for customers.
Original PR description
am to pm
Point of Sale now converts product prices from the product’s own currency to the PoS currency, instead of incorrectly assuming all prices were in the company currency. This ensures customers are charged the correct amounts in multi-currency setups.
Original PR description
Before this commit, in a multi-currency environment, the company currency was used to convert the prices, while it was a wrong assumption that the product prices were in the company currency. The products have a currency_id field, and the price should be converted from that currency to the PoS config currency. opw-6065969 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257324
The website now correctly allows the quantity of combo products to be increased up to the available stock for their options. This fixes an issue where some combo products were incorrectly capped at 1, even when more units could be sold.
Original PR description
You cannot increase the quantity of a combo product that has options with Sell when Out-of-Stock disabled Steps to reproduce: 1. Install Inventory and eCommerce 2. Go to Website > eCommerce > Products and create a new product "Combo" 3. Set the Product Type to Combo, create and edit a Combo Choice "test" with two options "test 1" and "test 2". Both have Track Inventory enabled, 5 Quantity On Hand and Sell when Out-of-Stock disabled 4. Publish product "Combo" to the website 5. Click on smart button "Go to Website" to open the shop page of product "Combo" 6. Try to increase the quantity 7. The quantity is limited to 1 Solution: Always set the quantity input's maximum when `has_max_combo_quantity` is true Issue: We only set the quantity input's maximum if `allow_out_of_stock_order` is false This error was introduced in https://github.com/odoo/odoo/commit/0247538efe788a9ff9a4d58f64470325348a4eaa opw-6050876 Forward-Port-Of: odoo/odoo#257386
When a packaging barcode is scanned together with a lot and due date, the system now correctly keeps the due date instead of defaulting to today. This ensures expiration information is recorded accurately when products are handled by packaging rather than by product barcode alone.
Original PR description
Issue
-----
Scanning a GS1 barcode containing:
- packaging
- lot
- due date
disregards the due date when creating the new lot.
Steps to reproduce
-----
- Enable GS1 nomenclature & packagings
- Create a product
- barcode 23456789012344
- packaging with barcode 01234567890128
- some on hand quantity
- Create a delivery for a full packaging of the product
- Open the delivery in barcode
- Scan 02 01234567890128 15 270101 10 LOT1
- Validate
- Open the lot
> Expiration date is set to today
Cause
-----
The code expects the product be scanned, there is no logic to retrieve it from the packaging when missing.
-----
Ticket:
opw-6073489
Forward-Port-Of: odoo/enterprise#114327
Forward-Port-Of: odoo/enterprise#112490This update fixes a display issue in the bank reconciliation screen on small devices. After an entry is reconciled, the Reconcile button now disappears as expected, preventing users from clicking an action that would cause an error.
Original PR description
From saas-19.1, the reconciliation widget on small screens still shows the Reconcile button even after the entry is reconciled. Steps to reproduce: 1. Dashboard > Bank > Transactions. 2. Set a partner and reconcile an entry. 3. The Reconcile button is still visible on small screens. 4. Clicking it raises an error. The issue was caused by the button visibility still relying on `checked`, which has been replaced by `review_state`. This fix updates the condition so the buttons are correctly hidden for reconciled entries.
A bug in payroll could trigger an error while editing salary adjustments. The fix prevents the system from processing an empty start date, which avoids the traceback and makes the form behave normally.
Original PR description
This task guard against falsy date_start in _compute_estimated_end to avoid adding a relativedelta to False, fixing a traceback appearing during onchange. task-6139538
The system now only fills in supported document information when a partner is actually a valid Nemhandel participant. This avoids unnecessary processing and prevents test failures caused by running the lookup when no Nemhandel setup exists.
Original PR description
The method to fill the supported documents of a partner was called even if it was not a valid Nemhandel participant. This would cause some test to fail as the call was unexpectedly done on tests without any setup for it. Forward-Port-Of: odoo/odoo#259117 Forward-Port-Of: odoo/odoo#258704
This update corrects how roles are tagged in the full message composer. It ensures messages and links point to the right recipients, preventing missed notifications or incorrect addresses from being used.
Original PR description
There is an issue when tagging a role using the full composer: 1. Emails are sent to the wrong address or sometimes no address at all 2. The displayed URL is not correct This commit fixes the issue by correctly rendering the mention block for roles in the full composer, using the correct configuration. task-6139162 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260094
This fix ensures that a unit of measure set for one supplier and one specific product variant cannot accidentally be selected for other variants of the same product template. It helps avoid wrong purchase quantities and keeps supplier settings consistent across variants.
Original PR description
Make sure any UoM defined on a supplierinfo having a specific variant cannot be used by other variant of the same product template Task: 6042382 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#259213
4 changes
Resolved issues and error corrections
This update adds an Odoo partner key to Sendcloud requests so Sendcloud can recognize traffic coming from Odoo and continue supporting the older API during their transition. It helps keep shipping integrations working smoothly for new and existing customers while Sendcloud completes its API changes.
Original PR description
Sendcloud pass their api v2 to maintenance and only provide new api V3 key to the new customers. In order to make a smooth transition for the user we add the partner key, so they know that the customer are coming from odoo and they use the v2 api. Future work will be done to upgrade our module and support the v3. API key. Forward-Port-Of: odoo/enterprise#114441
This update corrects a test for Mexican electronic invoices so it matches the current rounding behavior again. It helps keep invoice validation reliable after the rounding mode was changed back to mixed.
Original PR description
https://github.com/odoo/odoo/pull/255574 change the rounding mode back to mixed. This break the test modified in this PR. opw-5963855 Forward-Port-Of: odoo/enterprise#114081
The tax return list opened from the Accounting dashboard now expands all expected groups, instead of stopping after the first few and showing blank sections. This makes the list easier to read and ensures users can review all tax return entries from the dashboard view.
Original PR description
When navigating to the tax return list view from the accounting dashboard, only the first few groups were expanded, leaving subsequent groups appearing empty with only a date header visible. Steps to reproduce: - Generate several tax returns. - Open the main Accounting dashboard. - On a Tax Return card, click one of the generated buttons. - Scroll down the resulting list view. Issue: After 10 groups, following sections appear empty, showing only the header Analysis: By default, the web client limits the number of automatically opened groups. This change adds 'max_number_opened_groups' to the buttons context, aligning the behavior with the primary 'Tax Return' button action. https://github.com/odoo/enterprise/blob/1a2afda205c41773747ed5f174d75843effbbe9f/account_reports/views/account_return_views.xml#L183 opw-5769978
This fix corrects how activity filters are combined in Studio-created apps. Previously, selecting “My Activities” together with “Late Activities” could return too many records; now the filters work together as intended, making the list view more accurate.
Original PR description
Follow-up of 475a9efe0bde7515c9d5bf6ec6c8aefd4c71975e Steps to reproduce ================== - Create an app with studio and use_mail - Create three records, one with an activity in the past, one today and one in the future - Click on the clock status icon in the top right - There should be a section with the new model - Click on 1 Late => every records is displayed The filters "My Activities" is combined with "Late Activities" with and OR. It should use the AND operator. Solution ======== Add a separator after the "My Activities" filter. The same is done in xml for standard models. opw-6069150 Forward-Port-Of: odoo/enterprise#114347
12 changes
Resolved issues and error corrections
When users type an email address in the editor and then press space, it is now automatically turned into a clickable email link. This makes it easier to create contact links quickly and helps keep content formatting consistent.
Original PR description
Before this commit: when typing an email address, it's not converted to a mailto link after spacing. After this commit: the mailto link is created after spacing. task- 6053993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258736 Forward-Port-Of: odoo/odoo#257497
When a vendor bill is created from a UBL XML file, the chatter now shows the proper import message instead of displaying an empty or incorrect entry. This makes the document history clearer and helps users understand how the invoice was imported.
Original PR description
[FIX] account_edi_ubl_cii: Print right message in chatter at import When a UBL XML invoice is imported in vendor bills and no logs are collected, a message 'None' is printed in the chatter and the message 'Format used to import the invoice: ...' is not printed This commit fixes both issues no-task 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#260374
This change updates the Windows packaging setup to include optional dependencies that were missing before. It helps ensure Windows installations have the needed components available, reducing setup issues for users on that platform.
Original PR description
Forward-Port-Of: odoo/odoo#258320 Forward-Port-Of: odoo/odoo#258128
This change adds a partner identifier to Sendcloud requests so Sendcloud can recognize Odoo customers and continue accepting the older API version for them. It helps avoid service disruptions while Sendcloud transitions to a new API, and it supports a smoother migration for users.
Original PR description
Sendcloud pass their api v2 to maintenance and only provide new api V3 key to the new customers. In order to make a smooth transition for the user we add the partner key, so they know that the customer are coming from odoo and they use the v2 api. Future work will be done to upgrade our module and support the v3. API key. Forward-Port-Of: odoo/enterprise#114441
This change fixes an unstable automated test for shared activity updates across browser tabs. It prevents an internal data route from interfering with the test, making the test results more reliable and reducing false failures in development and CI.
Original PR description
The `@mail/activity/activity/activity updates are shared between tabs` fails in a non-deterministic fashion. It occurs because the `/mail/data` route can interfere with the test. runbot-242616 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#260265
This fix ensures sales orders and invoices show the correct untaxed amount when an early payment discount is used with tax-included prices. It prevents a small rounding error that could make totals display incorrectly and improves accuracy in pricing and tax summaries.
Original PR description
Steps to produce: --- - Install the `Sales` module. - Go to `Invoicing > Configuration > Payment Terms`. - Open `Immediate Payment` and enable Early Discount. - Set `Reduced Tax` to `Always (upon…
Steps to produce: --- - Install the `Sales` module. - Go to `Invoicing > Configuration > Payment Terms`. - Open `Immediate Payment` and enable Early Discount. - Set `Reduced Tax` to `Always (upon invoice)`. - Go to Invoicing > Configuration > Taxes. - Create a 21% tax with `Tax included`. - Create a product with a sale price of 7.50 and assign the tax. - Create a Sale Order with this product > Set Immediate Payment as payment term. Issue: --- - The untaxed amount is computed as 6.22 instead of 6.20. Root cause: --- - At [1], in `_add_base_lines_for_early_payment_discount`, the base lines generated for early payment discount were missing the `special_mode='total_excluded'`. - Consequently, the tax engine interpreted these amounts as tax-included and attempted to recompute the untaxed base, resulting in an incorrect untaxed amount. Solution: --- - Add `special_mode='total_excluded'` to the base lines created for early payment discount computation. - This ensures the discount amounts are treated as already tax-excluded. [1]https://github.com/odoo/odoo/blob/a2b4f618328f3ce3f654fd2c1ee4410365706a7e/addons/sale/models/sale_order.py#L515-L550 opw-6023472 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260189 Forward-Port-Of: odoo/odoo#255724
This fix stops users from updating a manufacturing order with a bill of materials that no longer matches the selected product. It prevents a divide-by-zero error during unbuild operations and avoids a confusing traceback for users.
Original PR description
Currently, an error occurs if a user changes the product in a BoM, updates the manufacturing order (MO) based on that BoM, and then attempts to unbuild the order. ## Steps to replicate: - Install…
Currently, an error occurs if a user changes the product in a BoM, updates the manufacturing order (MO) based on that BoM, and then attempts to unbuild the order.
## Steps to replicate:
- Install Manufacturing without demo data
- Settings > Enable Variants
- Create the following products:
- Car with (Red and Blue Color attributes)
- Red Paint
- Create a BoM for Car and product variant set to Red Car and have Red paint as the component.
- Create and Confirm manufacturing order for Red Car
- Click on Bill of Material > Set Paint required to 2 > Save
- Set product variant in BoM to Blue and save again.
- Go back to MO > Update BoM > Produce All
- Unbuild qty 1 > Confirm
## Observed Behavior:
ZeroDivisionError: float division by zero
## Root cause:
This issue occurs because the Update BoM button remains visible on the Manufacturing Order (MO) even after the product has been changed.
The problem starts when a user initially updates the required paint quantity from 1 to 2. At that point, the function [1] marks the BoM as outdated for all linked MOs, which makes the Update BoM button appear. However, if the user later changes the product template or variant, the BoM is still considered outdated. This incorrectly allows the user to update the MO using a BoM that no longer matches the selected product.
**Why this causes a traceback when unbuilding?**
When the user clicks Update BoM, it triggers the `action_update_bom function` [2], which calls `_link_bom`. This process recomputes several fields to align the MO with the updated BoM. One of the methods triggered during this recomputation is `_compute_move_finished_ids` [3]. Since the production is already confirmed, the logic skips adding the production to `production_with_move_finished_ids_to_unlink_ids`, meaning no new finished moves are created for that updated product.
As a result, although the MO is updated, its finished product (`move_finished_ids.product_id`) still refers to the original product (for example, Red Car), instead of the newly selected one.
Later, when the user attempts to unbuild the product, the `action_unbuild` function [4] is executed, which calls `_generate_consume_moves` [5] During this step, the system tries to compute a factor that depends on `unbuild.mo_id.quantity_produced`.
However, because the finished moves still reference the old product and do not match the MO’s current product, the computed total becomes zero at [6] This leads to a division by zero error at [5], which ultimately causes the traceback.
[1]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_bom.py#L432-L447 [2]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L1044-L1048 [3]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L771-L800
[4]:
https://github.com/odoo/odoo/blob/97b60952d59a57aba12b048cb4da4f41d85d2ea2/addons/mrp/models/mrp_unbuild.py#L153-L164
[5]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_unbuild.py#L225-L232 [6]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L641-L647
## Solution:
This change prevents users from updating a Bill of Materials (BoM) after the main product or its template has been modified, by ensuring the BoM is not marked as outdated.
This approach make sense because, once a manufacturing order (MO) is confirmed, all raw materials are physically reserved before production begins. While it makes sense to update BoM components in response to an Engineering Change Order (ECO) or last-minute specification changes, it does not make sense to allow changes to the final product itself on existing confirmed MOs. Doing so could lead to operational errors, since materials have already been procured and reserved for a specific product.
This fix ensures that if the product variant or product template is updated in the BoM, users cannot update the MO based on that BoM. This also prevents potential divide-by-zero errors when attempting to unbuild the product in the MO.
Reference commit which also suggests this behavior for the `Update BoM` button: [commit](https://github.com/odoo/odoo/commit/d7392829c769ef50456a7bc93d4482072b329463#:~:text=An%20exception%20however%3A%20if%20the%20MO%20is%20confirmed%20and%20the%20BoM%27s%20product%20was%0Achanged%2C%20the%20MO%20shouldn%27t%20have%20the%20%22Update%20BoM%22%20button%20displayed.%0AOtherwise%2C%20it%20would%20change%20the%20finished%20product%20of%20a%20confirmed%20MO.)
opw-6044754
Forward-Port-Of: odoo/odoo#255981The tax group for the 12% I tax has been updated from “Capital 12%” to “VAT 12%”. This helps ensure the Philippine sales tax report classifies transactions correctly and avoids reporting inconsistencies.
Original PR description
In this commit: - We change the group of tax '12% I', from 'Capital 12%' to 'VAT 12%' task-6092566 X-original-commit: b613d8fd242272456dbc7d52ea01a1b7125b2548
This update corrects the placement of the power buttons in Knowledge so they appear next to the intended content block. It improves the visual layout and makes the editor behave more consistently for users.
Original PR description
Current behavior before PR: - In knowledge, the power buttons were displayed at the wrong position. They were displayed before the block hint instead of after it. Desired behavior after PR is merged: - In knowledge, the editable has a margin applied to it. As a result, the block does not start at the editable's left position but slightly inside it, causing the power buttons to be displayed at the wrong position. Now, the power buttons' position is set using the block's left position so that they are displayed correctly. task-6102944
This update corrects a rounding issue in Mexican invoicing so totals stay accurate when multiple included taxes are applied. It prevents invoices from showing a small extra cent amount, improving billing accuracy and reducing confusion for users.
Original PR description
**STEP TO REPRODUCE** 1. Install l10n_mx. 2. Change the included in price settings to 'Tax included' for a 16% tax and a 53% tax. 3. Create a invoice with a product with a unit price of 360, add the 53% tax and then the 16% tax. 4. Notice the total of the invoice is 360.01 instead of 360. The issue was discussed with (las), l10n_mx_edi should no longer require to override the rounding mode for taxes. opw-5963855 Forward-Port-Of: odoo/odoo#255574
This update corrects an automated test for Mexico electronic invoices after the rounding behavior was changed back to the expected mode. It helps ensure the system continues to validate invoice totals properly and avoids test failures during maintenance and future updates.
Original PR description
https://github.com/odoo/odoo/pull/255574 change the rounding mode back to mixed. This break the test modified in this PR. opw-5963855 Forward-Port-Of: odoo/enterprise#114081
Miscellaneous changes
Forward-Port-Of: odoo/odoo#260319
Original PR description
Forward-Port-Of: odoo/odoo#260319
4 changes
Resolved issues and error corrections
The Sendcloud delivery tests were reclassified so they now run in regular automated checks instead of only nightly testing. This helps catch issues earlier and makes the delivery integration more reliable. A related test was also adjusted to match the current package-weight behavior.
Original PR description
Test class was tagged as external although calls are mocked. This means errors were only caught in nightly and not by CI. Removing the tag requires fixing some of the tests. For `test_multicollo`, we send the average weight of packages instead of the total since 97f82442c9fee7dcb3e8c5e9bacddcd6bb864e11. Forward-Port-Of: odoo/enterprise#111660
This update removes the transaction ID shown next to payment amounts in Point of Sale for Worldline transactions. It helps avoid confusion for cashiers, since the ID could look like a negative amount, while removing information they do not need.
Original PR description
This PR removes the transaction id shown next to the amount in point of sale for transactions used with Worldline. The transaction id preceded by a "-" was confusing for some cashiers and interpreted as a negative amount. Since the transaction id isn't useful for cashiers it's removed from the xml. Before: <img width="705" height="422" alt="image" src="https://github.com/user-attachments/assets/19ebfe49-e16d-45ea-b770-e445fe8b473d" /> After this PR: <img width="1182" height="353" alt="image" src="https://github.com/user-attachments/assets/f7cd1b7c-75fa-4fe9-ae20-7c5e6d834488" /> opw-6085975 Forward-Port-Of: odoo/enterprise#113782
This fix ensures that already scanned packages continue to display the correct demanded quantity when a delivery is reopened. It prevents package lines from showing an incorrect value, improving clarity and avoiding confusion for warehouse users.
Original PR description
Issue ----- When using full packaging in barcode, leaving the operation and opening it again shows incorrect quantity for already scanned packages. Steps to reproduce ----- - Enable packages - Create…
Issue ----- When using full packaging in barcode, leaving the operation and opening it again shows incorrect quantity for already scanned packages. Steps to reproduce ----- - Enable packages - Create a product with one package in stock - Operation Types > Delivery Orders, set Move Entire Packages to true - Create a delivery for a package - Scan the package barcode - Exit the delivery - Re-enter the delivery > Quantity for the line is 1/false Cause ----- The line is picked, so it is considered as not reserved https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L288-L289 when doing https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L812-L813 This leads to `qtyDemand` returning false instead of 1 https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/components/package_line.js#L17-L18 ----- Ticket: opw-5960629 Forward-Port-Of: odoo/enterprise#113816
Miscellaneous changes
Forward-Port-Of: odoo/enterprise#114395 Forward-Port-Of: odoo/enterprise#114366
Original PR description
Forward-Port-Of: odoo/enterprise#114395 Forward-Port-Of: odoo/enterprise#114366
14 changes
Resolved issues and error corrections
Website menus with URLs that include spaces now correctly point to newly created pages instead of staying on a 404 page. The menu editor also warns users when a URL contains spaces, helping prevent confusion while still allowing the entry.
Original PR description
When a menu item URL contains a space and has no leading slash (e.g., "some url"), creating a page from its 404 screen does not link the menu to the newly created page. The menu keeps pointing to a…
When a menu item URL contains a space and has no leading slash (e.g., "some url"), creating a page from its 404 screen does not link the menu to the newly created page. The menu keeps pointing to a 404. **Steps to reproduce**: 1. Create a menu item with a URL containing spaces and no leading slash (e.g., "some url"). 2. Click the menu item -> a 404 page is displayed (expected). 3. Click "Create Page" -> the page is created and saved. 4. Click the menu item again -> it still returns a 404 (unexpected). **Issue**: During page creation, the path is slugified (e.g., "some url" -> "/some-url"). The controller then tries to link the menu to the new page by setting `page_id`. However, `pagenew()` only searches for menu URLs with a leading slash, so a menu saved as "some url" is not found when searching for "/some url". As a result, `page_id` is never set, and `_clean_url()` keeps resolving the menu to "/some url" instead of the page's actual URL "/some-url". Menus without spaces (e.g., "mypage") have the same issue where `page_id` is not set, but since `_clean_url()` prepends "/" and renders "/mypage", which matches the new page URL, the menu still resolves correctly. **Fix**: Match both URL formats (with and without leading slash) when linking a menu to a newly created page. Additionally, a warning is now shown in the menu editor when a URL contains spaces, since spaces are slugified during page creation, which could cause confusion. (Note: this is only a warning - URLs with spaces are still allowed.) task-[5095646](https://www.odoo.com/odoo/project/974/tasks/5095646) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248967
This fix prevents timesheet errors when a public holiday or time off is updated after an employee has been archived. Archived employees’ leave records are now ignored during timesheet recalculation, so holiday deletions can complete normally without affecting current operations.
Original PR description
[FIX] project_timesheet_holidays: Exclude archived employees from time-off # Description of the issue/feature this PR addresses: ## Steps to Reproduce: 1. Create a time off for Employee A (it should…
[FIX] project_timesheet_holidays: Exclude archived employees from time-off # Description of the issue/feature this PR addresses: ## Steps to Reproduce: 1. Create a time off for Employee A (it should affect the timesheets). 2. Create a new public holiday (global time off) that overlaps with Employee A’s time off. 3. Archive Employee A. 4. Delete the public holiday created in step 2. 5. An error related to timesheet generation appears. ## Expected Behavior: - The public holiday / global time off should be deleted without any error. # Desired behavior after PR is merged: ## Fix (Implemented): When regenerating timesheets due to changes in holidays or time off, leaves related to archived employees should not be taken into account. A check was added inside the `_generate_timesheets` function in `project_timesheet_holidays/models/hr_holidays.py` to exclude leaves belonging to archived employees. ## Alternative Fix (Not Implemented): Instead of filtering out leaves linked to archived employees, we could delete those leaves when an employee is archived. However, this approach is not ideal, as archived employees may be reactivated later and would still need their previously requested time off to be preserved. ## Version: This bug appears in both version 17.0 and 19.0. I assumed that it also appears in 18.0 but didn't directly test ## Task: [5474038](https://www.odoo.com/odoo/project/4105/tasks/5474038) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244203
This change adds Odoo’s partner identification to requests sent to Sendcloud. It helps Sendcloud recognize Odoo customers and keeps shipping integrations working smoothly while their older API remains in transition.
Original PR description
Sendcloud pass their api v2 to maintenance and only provide new api V3 key to the new customers. In order to make a smooth transition for the user we add the partner key, so they know that the customer are coming from odoo and they use the v2 api. Future work will be done to upgrade our module and support the v3. API key. Forward-Port-Of: odoo/enterprise#114441
This update adjusts an internal test check so it correctly handles new Python 3.14 class attributes introduced by lazy annotation evaluation. It prevents false failures in the test suite and helps keep Odoo compatible with the latest Python version.
Original PR description
Since Python 3.14 (PEP 649), class annotations are evaluated lazily. This introduces two new internal attributes to the class namespace: - `__annotate_func__`: The function that computes the annotations. - `__annotations_cache__`: The cache for the computed annotations. This commit adds these attributes to the TransactionCase's ignored internal attributes checker. Note: this PR is a follow-up of https://github.com/odoo/odoo/pull/247151 Reference: - https://peps.python.org/pep-0649/
This fix prevents a manufacturing order from being updated with a Bill of Materials that no longer matches the selected product. It removes a path that could lead to an error when users try to unbuild the finished product, improving reliability in manufacturing workflows.
Original PR description
Currently, an error occurs if a user changes the product in a BoM, updates the manufacturing order (MO) based on that BoM, and then attempts to unbuild the order. ## Steps to replicate: - Install…
Currently, an error occurs if a user changes the product in a BoM, updates the manufacturing order (MO) based on that BoM, and then attempts to unbuild the order.
## Steps to replicate:
- Install Manufacturing without demo data
- Settings > Enable Variants
- Create the following products:
- Car with (Red and Blue Color attributes)
- Red Paint
- Create a BoM for Car and product variant set to Red Car and have Red paint as the component.
- Create and Confirm manufacturing order for Red Car
- Click on Bill of Material > Set Paint required to 2 > Save
- Set product variant in BoM to Blue and save again.
- Go back to MO > Update BoM > Produce All
- Unbuild qty 1 > Confirm
## Observed Behavior:
ZeroDivisionError: float division by zero
## Root cause:
This issue occurs because the Update BoM button remains visible on the Manufacturing Order (MO) even after the product has been changed.
The problem starts when a user initially updates the required paint quantity from 1 to 2. At that point, the function [1] marks the BoM as outdated for all linked MOs, which makes the Update BoM button appear. However, if the user later changes the product template or variant, the BoM is still considered outdated. This incorrectly allows the user to update the MO using a BoM that no longer matches the selected product.
**Why this causes a traceback when unbuilding?**
When the user clicks Update BoM, it triggers the `action_update_bom function` [2], which calls `_link_bom`. This process recomputes several fields to align the MO with the updated BoM. One of the methods triggered during this recomputation is `_compute_move_finished_ids` [3]. Since the production is already confirmed, the logic skips adding the production to `production_with_move_finished_ids_to_unlink_ids`, meaning no new finished moves are created for that updated product.
As a result, although the MO is updated, its finished product (`move_finished_ids.product_id`) still refers to the original product (for example, Red Car), instead of the newly selected one.
Later, when the user attempts to unbuild the product, the `action_unbuild` function [4] is executed, which calls `_generate_consume_moves` [5] During this step, the system tries to compute a factor that depends on `unbuild.mo_id.quantity_produced`.
However, because the finished moves still reference the old product and do not match the MO’s current product, the computed total becomes zero at [6] This leads to a division by zero error at [5], which ultimately causes the traceback.
[1]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_bom.py#L432-L447 [2]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L1044-L1048 [3]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L771-L800
[4]:
https://github.com/odoo/odoo/blob/97b60952d59a57aba12b048cb4da4f41d85d2ea2/addons/mrp/models/mrp_unbuild.py#L153-L164
[5]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_unbuild.py#L225-L232 [6]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L641-L647
## Solution:
This change prevents users from updating a Bill of Materials (BoM) after the main product or its template has been modified, by ensuring the BoM is not marked as outdated.
This approach make sense because, once a manufacturing order (MO) is confirmed, all raw materials are physically reserved before production begins. While it makes sense to update BoM components in response to an Engineering Change Order (ECO) or last-minute specification changes, it does not make sense to allow changes to the final product itself on existing confirmed MOs. Doing so could lead to operational errors, since materials have already been procured and reserved for a specific product.
This fix ensures that if the product variant or product template is updated in the BoM, users cannot update the MO based on that BoM. This also prevents potential divide-by-zero errors when attempting to unbuild the product in the MO.
Reference commit which also suggests this behavior for the `Update BoM` button: [commit](https://github.com/odoo/odoo/commit/d7392829c769ef50456a7bc93d4482072b329463#:~:text=An%20exception%20however%3A%20if%20the%20MO%20is%20confirmed%20and%20the%20BoM%27s%20product%20was%0Achanged%2C%20the%20MO%20shouldn%27t%20have%20the%20%22Update%20BoM%22%20button%20displayed.%0AOtherwise%2C%20it%20would%20change%20the%20finished%20product%20of%20a%20confirmed%20MO.)
opw-6044754
Forward-Port-Of: odoo/odoo#255981This update fixes a small wording typo in the website opening hours snippet, changing "am" to "pm" where appropriate. It improves the accuracy and professionalism of the information shown to visitors.
Original PR description
am to pm
This change stops linked Sales Order status updates from automatically creating chatter messages on Projects and Tasks. It helps keep the activity history cleaner and avoids extra notifications that were not adding business value.
Original PR description
Before this commit: - The chatter on the Project record tracked and logged changes to the linked Sales Order's status. After this commit: - Explicitly set `tracking=False` on the related `sale_order_state` field in `project.project`, `project.task` models. - Status updates to linked SOs will no longer automatically post tracking messages in chatter. task-6079809
The contact list view now shows child contact type labels in the user’s language instead of English. This brings it in line with the Kanban view and improves readability for multilingual users.
Original PR description
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view. Steps to reproduce: 1. Install the Contacts app. 2. Create a contact or go to an existing contact 3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address) 4. Change the user language to any language other than English 5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view. Cause: The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated. Solution: Use the 'display_name' field instead of 'complete_name' in the list view. opw-5947987
This change updates a manufacturing test so it no longer depends on an Enterprise-only feature. It helps ensure the test suite runs correctly in community installations, reducing false failures during validation.
Original PR description
The test `test_multi_lot_component_consumption` relies on `move_raw_line_ids`, which is initialized by the `stock_barcode_mrp` module. This module is only available in enterprise, causing the test to fail in community setups. https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/mrp/tests/test_consume_component.py#L481 runbot-242612
Helpdesk tickets will no longer automatically post chatter messages when the linked Sales Order status changes. This reduces unnecessary message noise and helps teams focus on updates that are directly relevant to the ticket.
Original PR description
Before this commit: - The chatter on Helpdesk Tickets tracked and logged changes to the linked Sales Order's status. After this commit: - Explicitly set `tracking=False` on the related `sale_order_state` field in `helpdesk.ticket`. - Status updates to linked SOs will no longer automatically post tracking messages in chatter. task-6079809
This change prevents invoice taxes from being recalculated unnecessarily when the analytic distribution is edited on imported invoices. It helps avoid small rounding differences, keeping tax amounts consistent and more reliable for accounting users.
Original PR description
When modifying the analytic distribution on an imported invoice line, the tax synchronization mechanism recalculate taxes from scratch, causing rounding discrepancies Task id - [6030615](https://www.odoo.com/odoo/project/967/tasks/6030615) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes an issue where checking available stock could fail for some users, especially when Manufacturing is installed. It keeps the original access rights intact during the calculation, avoiding permission errors in flows like online payment processing or POS operations.
Original PR description
Computing qty_available with sudo(False) drops superuser privileges, causing an AccessError on mrp.bom when the mrp module is installed. This happens because _compute_quantities_dict calls _bom_find, which performs an access check on mrp.bom that the current user (e.g. a POS session during online payment processing) may not pass. Removing sudo(False) preserves the calling environment's access rights, which is sufficient and avoids the permission error. opw-5975248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents a rare crash that could happen when one drag action was interrupted by another started almost immediately afterward. It improves the stability of the web interface during fast user interactions.
Original PR description
### [FIX] web: fix crash when cancelling drag sequence Before this commit: drag sequences could be aborted by new drag sequences; the way this worked is that a new sequence would register its "cancel" callback in a global variable, and when another sequence is started, it calls that variable to cancel the previous one. The issue was that the variable was assigned too early; before the actual "cancel" callback was available. This means that in edge cases where 2 sequences would be triggered in less than (effectively) a resolved promise, the callback would not be available and a crash would occur. This commit moves the variable assignment *after* the "cancel" callback is made available, ensuring there is no crash. Runbot [243113](https://runbot.odoo.com/odoo/error/243113) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update changes how signed PDFs are created so the original document is duplicated first, then signature overlays are added on top. This helps preserve the full PDF structure and settings, reducing the risk of losing bookmarks, metadata, or other document details during signing.
Original PR description
Instead of rebuilding the PDF by copying content, metadata, and bookmarks, we now duplicate the original document first and then apply the signature overlays. This ensures the full structure and settings are preserved without loss. task-6083291
8 changes
Enhancements to existing features
This update changes the sender address used in an automated CRM email from iap@odoo.com to noreply@odoo.com. It helps prevent customers from replying to messages that are meant to be automatic notifications, reducing confusion and unnecessary incoming responses.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556
The automatic email sent by the extraction feature now uses a no-reply address instead of a regular inbox. This prevents customers or other systems from replying to messages that are meant to be automated, reducing confusion and unwanted responses.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556
This update strengthens the automated test for Spain’s Mod347 BOE export by making sure invoices above the legal cash-payment threshold are correctly included. It helps prevent regressions in reporting and gives more confidence that the export matches expected tax rules.
Original PR description
This commit improves the test for cash payments in the Mod347 BOE export by ensuring that a Spanish partner with an invoice amount greater than 3,005.06 € is included in the export. opw-5960226 Forward-Port-Of: odoo/enterprise#110947
Resolved issues and error corrections
This update fixes an issue in the online shop where long category names could push buttons off the page on smaller screens. Category names are now shortened when needed, keeping the layout usable and avoiding horizontal scrolling.
Original PR description
Scenario: - go to /shop - click on long category (eg. Furnitures) - reduce browser width (might need to use developer tools mobile size) - horizontal scroll to the right Result: the buttons are overflowing the page with Cause: from 17.0 to saas-18.2 (after which the category name is removed from the filter button line) the category name is a fixed min-size with overflow:visible, so that and being flex-nowrap, it overflows the page width if it doesn't fit. Fix: truncate category name if it is too long opw-6065145
This fix ensures string-based report values are sorted by date when the "most recent" option is used. It prevents values from appearing in the wrong order, especially in reports covering the full history of data.
Original PR description
Ensure string-type external values are correctly sorted by date when using the "most_recent" formula. This resolves an issue where values appeared unordered, especially for expressions using the "From the very start" period. task-5951888
This update fixes an issue on mobile devices where swiping between app settings could show a blank page. It now waits for the next settings page to finish loading before completing the swipe, making navigation smoother and more reliable.
Original PR description
Before this commit, swiping between settings for different apps on mobile devices would often result in a blank page. This occurred because the swipe method did not wait for the target page to render completely before completing the transition. This commit ensures the swipe action waits for the rendering process, preventing the blank state during app navigation.
The Time Remaining value in shared project views now matches the warning color shown on its label when the remaining hours are below zero. This makes it easier for users to quickly spot overdue time and understand project status at a glance.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** In hr_timesheet, the remaining_hours field has a decoration-danger applied In sale_timesheet_enterprise, this field is overridden as portal_remaining_hours So, Added the corresponding decoration-danger on portal_remaining_hours. task-5404009
This update makes the Time Remaining value in shared project forms display in red when it is negative. It improves visibility so users can quickly spot overdue time at a glance.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** - Adjusted the logic to ensure the Time Remaining value is highlighted in red when value is negative **Task-id: 5404009**