Daily updates from Odoo
Navigate
Branch
Friday, June 6, 2025
60 changes
1 change
Enhancements to existing features
Receipt printing through connected POS hardware now has a more reliable backup connection method, reducing the chance of failed prints. The update also fixes an issue where Belgian blackbox setups without a configured device could block receipt printing.
Original PR description
As for the blackbox, we now use the websocket as fallback to longpolling to print receipt. This commit also fixes an issue regarding the module `pos_blackbox_be`: if the module was installed, but no blackbox was configured, we could not print a receipt as no signature was provided. Task: 4824066
29 changes
Enhancements to existing features
Updates were made to WhatsApp-related security tests to keep them aligned with recent platform changes. This helps maintain reliable quality checks without changing the user-facing WhatsApp experience.
Original PR description
PR community: https://github.com/odoo/odoo/pull/212074 task-4675777
Knowledge article rows now only show the expand caret when an article has child pages. This reduces visual clutter and helps users understand which articles can be expanded.
Original PR description
Hide the caret icon when the article has no children. task-4830534
The manufacturing work order tests were adjusted after shared test data was reorganized. This keeps the test coverage aligned with recent community changes without affecting day-to-day user workflows.
Original PR description
Some data was removed from the commons and moved to the two specific test classes using those.
The bank statement OFX import feature now loads its parsing tools only when they are actually needed. This can slightly improve system startup time while keeping the import process unchanged for users.
Original PR description
Parsing is often not needed during startup and only used during the related business processes. Therefore, we load it lazily. ofxparser depends on bs4 and both of them can take 100ms to import. odoo/odoo#212408
This update strengthens internal mail performance tests so they better reflect real-world messaging scenarios, including followers, push notifications, and tracking details. It also prevents test runs from making external notification requests and fixes a small issue in mention detection, helping maintain messaging quality with lower release risk.
Original PR description
Improve post performance tests so that
* it effectively includes followers (having a subtype_id);
* it sends push notifications (creating devices and using 'comment'
message type);
* it includes tracking values;
Add mock for push notifications, to avoid VERBOTEN external requests.
Update counters accordingly.
Prepares Task-4845982Appointment website snippets now take configured country availability into account when showing appointment options. This helps visitors see more relevant appointment choices while preserving the existing setup behavior for online appointment configuration.
Original PR description
Take into account the country domain for the appointment snippet. This is not applied to the option of s_appointment_online as it could prevent user to configure the website correctly. task-4461289
Internal test-only helper tools were moved into the testing area to reduce the chance they are used incorrectly in production code. This keeps business features unchanged while improving code organization and long-term reliability across affected test suites.
Original PR description
The `DotDict` class can produce unexpected behaviour if used incorrectly. This commit moves this class so that it is only used in tests. The `MockRequest` context manager uses the `DotDict`. As we cannot import objects from the test framework and `MockRequest` is only used in tests, it makes sense to move it to `odoo.addons.web.tests.utils`. task-4822364
The test setup was simplified so that post-installation tests run by default, removing the need to mark them individually. This reduces maintenance work and helps keep quality checks consistent across Odoo's enterprise accounting modules.
Original PR description
https://github.com/odoo/odoo/pull/143757 https://github.com/odoo/design-themes/pull/764 https://github.com/odoo/documentation/pull/6670
Resolved issues and error corrections
Search tests for appointments and knowledge articles have been updated to work with the redesigned website builder. This helps ensure those website search experiences remain reliable after layout changes.
Original PR description
*= appointment, knowledge The ```test_searchbar_within_appointments, test_searchbar_within_knowledge_articles``` tour was previously broken due to DOM structure changes introduced by the new website builder and was consequently disabled. This commit updates the tour steps to align with the new DOM and re-enables the associated test.
QR codes on localized invoices and delivery documents now handle the quiet mode setting consistently, adding the expected white border by default. This improves barcode readability but may slightly change the visual layout of documents that include QR codes, so affected teams should verify printed and digital reports.
Original PR description
Before the fix: - method documentation outdated - quiet mode for QR Code was inverted and only add white border when disabled. After the fix: - method documentation aligned with the code - quiet mode works for QR code like other type Notice that this change, can have an impact for all usage of QR type as the default format has now the white border. Need to be checked with PO and team using barcode (stock, accounting) Odoo: https://github.com/odoo/odoo/pull/209386 opw-4785714
Code cleanup and technical improvements
Spreadsheet filter data has been streamlined to align with related platform changes. This helps keep enterprise spreadsheet features consistent and easier to maintain, with minimal direct impact for business users.
Original PR description
This commit adapts the enterprise codebase to the changes made in https://github.com/odoo/odoo/pull/212961
This change reorganizes a testing helper so it lives with other test utilities instead of production-facing code. It should not affect day-to-day users, but it helps keep the codebase cleaner and easier to maintain across modules that rely on tests.
Original PR description
The `MockRequest` context manager is only used in tests. Move it to `odoo.addons.web.tests.utils.py`. task-4822364
Miscellaneous changes
The `MoveArticleDialog` component uses the display name to indicate which article will be moved. However, this field is not loaded on the record object, resulting in an undefined value. As a result, the modal incorrectly displays the article as untitled. Steps to reproduce the issue: 1. Open an article in Knowledge 2. Make sure that the article has a title 3. Click on the "Move To" option from the kebab menu => The modal says "Move the untitled article under:" TO BE: The modal should
Original PR description
The `MoveArticleDialog` component uses the display name to indicate which article will be moved. However, this field is not loaded on the record object, resulting in an undefined value. As a result, the modal incorrectly displays the article as untitled. Steps to reproduce the issue: 1. Open an article in Knowledge 2. Make sure that the article has a title 3. Click on the "Move To" option from the kebab menu => The modal says "Move the untitled article under:" TO BE: The modal should say: "Move <display_name> under:" To fix the issue, we will add the `display_name` field to the field dependencies of the `KnowledgeTopbar` component. Task-4636494 Forward-Port-Of: odoo/enterprise#87135 Forward-Port-Of: odoo/enterprise#86059
In this commit: ========== - We will display the provider's order ID in the order receipt header. Before this commit: ----------  After this commit: ----------  task-4840924 Forward-Port-Of: odoo/enterprise#87128 Forward-Port-Of: odoo/enterprise#86790
Original PR description
In this commit: ========== - We will display the provider's order ID in the order receipt header. Before this commit: ----------  After this commit: ----------  task-4840924 Forward-Port-Of: odoo/enterprise#87128 Forward-Port-Of: odoo/enterprise#86790
In this commit: - We are replacing the XPath class `o_portal_details` to `o_customer_address_fill` according to changes in the related community PR. task-4649241 Related PR: - Community: https://github.com/odoo/odoo/pull/201995 Forward-Port-Of: odoo/enterprise#87087 Forward-Port-Of: odoo/enterprise#81639
Original PR description
In this commit: - We are replacing the XPath class `o_portal_details` to `o_customer_address_fill` according to changes in the related community PR. task-4649241 Related PR: - Community: https://github.com/odoo/odoo/pull/201995 Forward-Port-Of: odoo/enterprise#87087 Forward-Port-Of: odoo/enterprise#81639
Before when we would open the return kanban, it would set for every other kanban the variable MAX_NUMBER_OPENED_GROUPS to max integer. This is not what we want, we only weant to restrict that to the Return Kanban Model only not every relational model. Forward-Port-Of: odoo/enterprise#87189
Original PR description
Before when we would open the return kanban, it would set for every other kanban the variable MAX_NUMBER_OPENED_GROUPS to max integer. This is not what we want, we only weant to restrict that to the Return Kanban Model only not every relational model. Forward-Port-Of: odoo/enterprise#87189
This commit moves the 3 first reco models, present in the dropdown menu, to the button list of statement line. If the user has more than 3 matching models, the other ones will remain in the dropdown menu. This is only for desktop views, nothing changed in mobile. Also few style and layout changes, see related commits. task-4804584 Forward-Port-Of: odoo/enterprise#86783
Original PR description
This commit moves the 3 first reco models, present in the dropdown menu, to the button list of statement line. If the user has more than 3 matching models, the other ones will remain in the dropdown menu. This is only for desktop views, nothing changed in mobile. Also few style and layout changes, see related commits. task-4804584 Forward-Port-Of: odoo/enterprise#86783
We added back the amount of devices connected to an IoT Box on the IoT Box card. We also added the pairing date on the card, for a user to spot faster an IoT Box. If an IoT Box is linked to a PoS, the PoS configs where devices are linked are now listed on the IoT Box cards. Some elements have been moved, and some sentences have been rephrased on the wizards to pair an IoT Box. Task: 4585446 Forward-Port-Of: odoo/enterprise#84543
Original PR description
We added back the amount of devices connected to an IoT Box on the IoT Box card. We also added the pairing date on the card, for a user to spot faster an IoT Box. If an IoT Box is linked to a PoS, the PoS configs where devices are linked are now listed on the IoT Box cards. Some elements have been moved, and some sentences have been rephrased on the wizards to pair an IoT Box. Task: 4585446 Forward-Port-Of: odoo/enterprise#84543
Before this commit, selecting a contact of type "company" on the payment screen would result in the following error: `TypeError: Cannot read properties of undefined (reading 'name')` This occurred because selecting a company contact automatically set the order to be invoiced, even if the required fields were not filled in. To prevent this error, the process now checks that all necessary fields are completed before setting the order to invoice. opw-4773831 Forward-Port-Of: odoo/en
Original PR description
Before this commit, selecting a contact of type "company" on the payment screen would result in the following error: `TypeError: Cannot read properties of undefined (reading 'name')` This occurred because selecting a company contact automatically set the order to be invoiced, even if the required fields were not filled in. To prevent this error, the process now checks that all necessary fields are completed before setting the order to invoice. opw-4773831 Forward-Port-Of: odoo/enterprise#86512 Forward-Port-Of: odoo/enterprise#85123
Before this commit, validating an order from the mobile menu caused an error because the 'name' field was removed from the order in the process_order method of self order. Since the 'pos_reference' field exists and is correct to use (unlike 'name', which may be '/'), the code has been updated to use 'pos_reference' instead. opw-4758288 Forward-Port-Of: odoo/enterprise#85266
Original PR description
Before this commit, validating an order from the mobile menu caused an error because the 'name' field was removed from the order in the process_order method of self order. Since the 'pos_reference' field exists and is correct to use (unlike 'name', which may be '/'), the code has been updated to use 'pos_reference' instead. opw-4758288 Forward-Port-Of: odoo/enterprise#85266
### Issue: When trying to upload the video for a Youtube post, we are getting a traceback with "UncaughtPromiseError > TypeError", caused by not having the `youtube_video_category_id` field properly loaded, at the time where we are trying to evaluate `_preprocessReferenceChanges` we try to access the type of the field as `this.fields[fieldName].type === "reference"` where `fieldName` is `youtube_video_category_id`, but the field is not loaded yet (this.fields[fieldName] is undefined), so we get
Original PR description
### Issue: When trying to upload the video for a Youtube post, we are getting a traceback with "UncaughtPromiseError > TypeError", caused by not having the `youtube_video_category_id` field properly loaded, at the time where we are trying to evaluate `_preprocessReferenceChanges` we try to access the type of the field as `this.fields[fieldName].type === "reference"` where `fieldName` is `youtube_video_category_id`, but the field is not loaded yet (this.fields[fieldName] is undefined), so we get an error. ### Solution: This commit adds this field as a field dependecy for the `YoutubeUploadField` widget, so that it is loaded when we try to access it. opw-4646432 Forward-Port-Of: odoo/enterprise#83571
Description of the issue this commit addresses: Since the new Tax Returns features in saas-18.3, a method that was used by the method that was generating the xml export of the italian periodic vat report was replaced by one of a different name. The one used by the xml export system has not been modified and therefore tries to call a method that doesn't exist leading to a traceback. --- Steps to reproduce: 1. Install l10n_it_xml_export. 2. Using an Italian company, go to the montly v
Original PR description
Description of the issue this commit addresses: Since the new Tax Returns features in saas-18.3, a method that was used by the method that was generating the xml export of the italian periodic vat report was replaced by one of a different name. The one used by the xml export system has not been modified and therefore tries to call a method that doesn't exist leading to a traceback. --- Steps to reproduce: 1. Install l10n_it_xml_export. 2. Using an Italian company, go to the montly vat report. 3. Create the closing entry and post it. 4. A traceback shows up. --- Desired behavior after this commit is merged: No traceback shows up during the xml export of the italian periodic vat report closing entry posting process. --- task-4825706 Forward-Port-Of: odoo/enterprise#86518
A previous fix removed one column without updating the colspan of the custom header. https://github.com/odoo/enterprise/commit/78265a864fafd789df10c0f75590aaa605547b33 Forward-Port-Of: odoo/enterprise#87124
Original PR description
A previous fix removed one column without updating the colspan of the custom header. https://github.com/odoo/enterprise/commit/78265a864fafd789df10c0f75590aaa605547b33 Forward-Port-Of: odoo/enterprise#87124
Before this commit the opening balance in the iras audit export was always at 0. This was caused because it would call _query_values which was not returning the initial balances. The fix was to instead call _get_initial_balance_values. With this we could finally get the opening balances. task-4826744 Forward-Port-Of: odoo/enterprise#86907 Forward-Port-Of: odoo/enterprise#86600
Original PR description
Before this commit the opening balance in the iras audit export was always at 0. This was caused because it would call _query_values which was not returning the initial balances. The fix was to instead call _get_initial_balance_values. With this we could finally get the opening balances. task-4826744 Forward-Port-Of: odoo/enterprise#86907 Forward-Port-Of: odoo/enterprise#86600
**PROBLEM** When confirming an invoice, the payment policy of the invoice was overridden by the payment policy assigned to the partner, and the user had to reselect the correct policy. **STEP TO REPRODUCE** 1. On a fresh database, install the l10n_mx_edi module. 2. Select the "ZAPATERIA URTADO ÑERI" as your company (demo mexican company). 3. Set a payment policy on a client. 4. Create an invoice with this client, and set the payment policy equal to a different policy than the client. 5.
Original PR description
**PROBLEM** When confirming an invoice, the payment policy of the invoice was overridden by the payment policy assigned to the partner, and the user had to reselect the correct policy. **STEP TO…
**PROBLEM** When confirming an invoice, the payment policy of the invoice was overridden by the payment policy assigned to the partner, and the user had to reselect the correct policy. **STEP TO REPRODUCE** 1. On a fresh database, install the l10n_mx_edi module. 2. Select the "ZAPATERIA URTADO ÑERI" as your company (demo mexican company). 3. Set a payment policy on a client. 4. Create an invoice with this client, and set the payment policy equal to a different policy than the client. 5. Confirm the invoice, the payment policy field will take the value of the client policy, overriding what we set in the invoice. **CAUSE** https://github.com/odoo/enterprise/blob/3f42e4322dbd684d9431a172c11a369090b21c0c/l10n_mx_edi/models/account_move.py#L615-L620 The payment policy compute method is incorrect, we should select the partner policy as a last resort to avoid overriding what the user chose. **FIX** Reorder the fallback: If the invoice is a refund, payment policy should be PUE. Else, if the user set a payment policy in the invoice form, we should keep it. Finally, if the partner has a payment policy, select it. opw-4820139 Forward-Port-Of: odoo/enterprise#86918
Before this commit, when several achievements were done on the same period for the same record, they would share the same id and therefore could not be properly processed in the interface. In order to fix this, we decide to use the achievement date to compute the id. As a result, for achievement based on MRR (subscription), if two sale.order.log corresponds to the same order, on the same date, we will end up with a duplicated id too. It happens because the related_res_model and related_res_i
Original PR description
Before this commit, when several achievements were done on the same period for the same record, they would share the same id and therefore could not be properly processed in the interface. In order…
Before this commit, when several achievements were done on the same period for the same record, they would share the same id and therefore could not be properly processed in the interface. In order to fix this, we decide to use the achievement date to compute the id. As a result, for achievement based on MRR (subscription), if two sale.order.log corresponds to the same order, on the same date, we will end up with a duplicated id too. It happens because the related_res_model and related_res_id of achievement based on MRR is the order linked to the sale.order.log. To avoid this issue, we introduce another source of entropy in the computation of the achievement's id: the write date of the record. In that case, we are free to use the write_date of the sale.order.log and therefore they should be different. Same apply for sale.order and account.move for other kind of achievements because of the UNION ALL. taskid: 4845096 Forward-Port-Of: odoo/enterprise#87001 Forward-Port-Of: odoo/enterprise#86644
Reproduce: Check the front page of an appointment type with no resources or staff users. This commit avoids duplicating the ‘No slot’ message on the front page of appointment types for which there is no slot available. related: odoo/enterprise@36da382fceba76f3de69306e24c9c6fa018cde9f Task-4750234 Forward-Port-Of: odoo/enterprise#84246
Original PR description
Reproduce: Check the front page of an appointment type with no resources or staff users. This commit avoids duplicating the ‘No slot’ message on the front page of appointment types for which there is no slot available. related: odoo/enterprise@36da382fceba76f3de69306e24c9c6fa018cde9f Task-4750234 Forward-Port-Of: odoo/enterprise#84246
When the user opens the chatter and expands the sidebar, the chatter's topbar overlaps the sidebar. This overlap disrupts the layout and can be frustrating, as it may hide some article links. To fix this, we'll update the sidebar's z-index so it sits above regular elements but remains below modals. Task-4636494 Forward-Port-Of: odoo/enterprise#86462
Original PR description
When the user opens the chatter and expands the sidebar, the chatter's topbar overlaps the sidebar. This overlap disrupts the layout and can be frustrating, as it may hide some article links. To fix this, we'll update the sidebar's z-index so it sits above regular elements but remains below modals. Task-4636494 Forward-Port-Of: odoo/enterprise#86462
Related to odoo/odoo#209846 Forward-Port-Of: odoo/enterprise#86585 Forward-Port-Of: odoo/enterprise#85454
Original PR description
Related to odoo/odoo#209846 Forward-Port-Of: odoo/enterprise#86585 Forward-Port-Of: odoo/enterprise#85454
30 changes
New functionality added to Odoo
This adds support for using KPay payment terminals directly from Odoo Point of Sale. Businesses can process sales and cancellations through compatible terminals over Wi-Fi, making checkout operations more integrated and streamlined.
Original PR description
This commit introduces the `pos_kpay` module, enabling integration with KPay payment terminals in the Point of Sale system. Key features include: - KPay terminal communication via wifi network - Integration with existing POS payment method infrastructure. - Support for sales and cancellation operations. task-4402887
Enhancements to existing features
This change adds a customization point before sales orders are updated from electronic UBL documents. It makes it easier for businesses with custom workflows to adjust order details without duplicating updates or adding extra processing steps.
Original PR description
**Description of the issue/feature this PR addresses:** There's no hook to manipulate order values before write. **Current behavior before PR:** You cannot add custom logic easily w/o writing again on the order **Desired behavior after PR is merged:** Ease custom logic implementation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Copying large documents now avoids an unnecessary page-count check that was consuming significant memory. This improves performance when duplicating multiple large PDFs, reducing memory use in the benchmark by about 27%.
Original PR description
Description ----------- When copying a document, a new attachment is created and linked to the copied document. Since `documents.document.is_multipage` depends on `documents.document.datas`, which is related to `attachment_id.datas`, and `attachment_id` was just written to, `_compute_is_multipage` will be recomputed during flushing before commit, as it's a compute stored field. This is problematic when copying multiple large documents, since this compute reads the entire binary data to determine if it's more than one page. This commits explictly writes on `is_multipage` to implicitly add it to the protected fields, which will prevent its' recomputation when flushing. Benchmark --------- Copying 5 documents (PDF) of 50MB each takes in total: | Before | After | Diff | |--------|--------|--------| | 1.61GB | 1.17GB | -27.3% | Reference --------- opw-4829372
Resolved issues and error corrections
Tasks created from service products now use the product name unless the sales order line description was manually customized. This prevents standard sales descriptions from incorrectly becoming task names, keeping project records clearer for users.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a service product that creates a task on order confirmation; 2. give it a sales description; 3. add it to an order and confirm. Issue ----- The task is named using the sales description. Cause ----- Commits 47d223759f07 & c3877b2acd74 attempted to restore previous task/display name behavior by using the second line of the SOL description as the task/display name. This behavior only happened in previous versions when the line description was manually modified. Solution -------- Only use the new behavior if the line name isn't the same as the default. opw-4634149
This change removes a previously introduced US tax report variant because it caused crashes during deployment. The revert keeps the stable version reliable while the underlying dependency issue is addressed in a future release.
Original PR description
This reverts commit 6d0d0e58b9f2c4ee2519e8e960e156c7e7be9841. The deployment of the reverted commit revealed an error: l10n_us_reports does not depend on l10n_us_account (only l10n_us), so it can't override the US tax report in data and crashes. We sadly cannot fix that in stable ; we'll do it in master.
This update brings the embedded spreadsheet component up to its latest maintenance version. It fixes issues with waterfall chart values, find-and-replace navigation, moved row or column ranges, clipboard handling, and touch scrolling, making spreadsheet work more reliable for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bef1e2bd5 [REL] 18.0.32 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bef1e2bd5 [REL] 18.0.32 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/9ebffc594 [FIX] waterfall: wrong show value for waterfall chart [Task: 4812692](https://www.odoo.com/odoo/2328/tasks/4812692) https://github.com/odoo/o-spreadsheet/commit/fd13ed000 [FIX] Find&Replace: target correct next match [Task: 4817971](https://www.odoo.com/odoo/2328/tasks/4817971) https://github.com/odoo/o-spreadsheet/commit/a2ec5297a [FIX] clipboard: remove empty code [Task: 4743039](https://www.odoo.com/odoo/2328/tasks/4743039) https://github.com/odoo/o-spreadsheet/commit/8eebf6d8b [FIX] MOVE_COLUMNS_ROWS: adapt range on col/row move [Task: 4743039](https://www.odoo.com/odoo/2328/tasks/4743039) https://github.com/odoo/o-spreadsheet/commit/a00a9aaf7 [FIX] Spreadsheet: Fix touch scroll [Task: 4829283](https://www.odoo.com/odoo/2328/tasks/4829283) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This change standardizes how tab width values are written in HTML editor tests so they match the way browsers format them. It helps prevent avoidable test failures without changing user-facing editor behavior.
Original PR description
Description of the issue this PR addresses: - Trailing zeros in tab width styles cause test mismatches with browser-normalized values. Current behavior before PR: - Tests may use widths like "24.0px" which differ from browser output "24px". Desired behavior after PR is merged: - Tab widths use Number() conversion to match browser formatting and avoid test mismatches. task-4853029 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the editor from accidentally recording link popover changes in the undo history when users press Ctrl+Z in Chrome. It keeps undo behavior predictable and avoids confusing link changes appearing or disappearing after the popover is closed.
Original PR description
Problem: In Chrome, when focused on the first input inside the link popover, pressing `Ctrl+Z` (undo) triggers `beforeinput` and `input` events on the editable element, even though the selection is…
Problem: In Chrome, when focused on the first input inside the link popover, pressing `Ctrl+Z` (undo) triggers `beforeinput` and `input` events on the editable element, even though the selection is within the popover input, not the editable area. This leads to `addStep` being incorrectly triggered, adding DOM changes like the `a` tag to the history stack and resulting in unintended undo behavior. Note: This issue doesn't occur in saas-18.2+ where the `a` tag is only added upon confirming the change, thus no mutation is pushed to history while editing. Solution: Intercept the `beforeinput` event on the editable and call `preventDefault()` if the selection is not currently within the editable, thereby stopping history pollution. Steps to reproduce: 1. Type `/Link` and open the link popover. 2. Focus is automatically set on the first input. 3. Press `Ctrl+Z`. 4. Click on the editable area to close the popover. 5. Repeatedly press `Ctrl+Z` → the `a` tag is added/removed, corrupting undo history. opw-4800278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Date and date-time columns in list views now get a little extra space when shown in bold. This prevents values from being cut off with ellipses, making records easier to read across languages and systems.
Original PR description
This commit is a followup of [1] where we compute the minimum required width for date and datetime fields in list views. However, it didn't take into account decorations that could be applied to list views, in particular `decoration-bf`, which may, for certain fonts, increase the width of date values. We tested all languages, on different systems (thus different standard fonts), and an increase of 5% of the computed width is enough on those systems to display date and datetimes without an ellipsis, even in bold. [1] odoo/odoo#210584 No task, issue reported on our prod 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
Manufacturing users can now clear the End Date on productivity loss records without triggering an error. This prevents an avoidable form crash and keeps work center loss tracking smoother when dates are edited or removed.
Original PR description
If the `End Date` is already defined and the user removes that date in the form view of productivity losses, an error is generated. Steps to reproduce: --- - Install the `mrp` module - Manufacturing > Configuration > Work Centers > Open any of the Work Centers - In the form view of Work Center, click on the `Lost` stat button - Open a new Productivity Loss form, set a future date in `End Date`, click elsewhere, then clear the `End Date` Traceback: --- `TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.timedelta'` If the end date is missing, we will return from the method sentry-6641245276 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores Demo express checkout in eCommerce by correctly reading the available delivery methods after an internal API change. Customers using the demo payment flow should no longer be incorrectly blocked with a message that no delivery method is available.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable Demo express checkout; 2. pay with Demo Express checkout in eCommerce. Issue ----- Validation error: No delivery method is available. Cause ----- Commit bf8d08cd22b5 changed the express checkout delivery method RPC API. Instead of an array, `availableCarriers` is now an object with a `delivery_methods` attribute. Because it checks the length of an object, which is `undefined`, Demo express checkout incorrectly believes no delivery methods are available. Solution -------- Check the length of `delivery_methods` instead of `availableCarriers`.
Fixed an issue where links from email notifications could lose their access token or send users to the wrong destination after login. Internal users, portal users, and visitors are now routed to the right place more reliably, improving access to shared records and reducing confusing redirects.
Original PR description
Global purpose is to make mail/view controller more resilient by improving redirections when not having access to the record. Notably * correctly route internal users to discuss, portal users to /my and unlogged users to login; * keep original mail/view route when performing redirection after login so that we try the routing again; * fix various issues in redirect computation, such as lost access token parameter or partial reconstruction of URLs; Improve test coverage. Task-
A test related to refund orders with delayed shipping costs in Point of Sale was corrected. This helps ensure future updates do not break refund cost calculations, with no direct impact on daily users.
Original PR description
…talcost this commit fixes the test test_pos_order_refund_ship_delay_totalcost from PR https://github.com/odoo/odoo/pull/210868 opw-4614503
This update fixes an internal automated test for point of sale refunds involving shipping delays and total cost calculations. It helps keep quality checks reliable so future changes to the point of sale flow can be validated with greater confidence.
Original PR description
this commit fixes the test test_pos_order_refund_ship_delay_totalcost from PR #210868 opw-4614503
The EC Sales List report now checks for duplicate VAT numbers only among partners included in the selected reporting period. This prevents misleading warnings caused by customers or vendors that are outside the report scope.
Original PR description
- Fixed the computation of `is_vat_duplicated` to only consider partners within the selected reporting period. - Moved the duplicate VAT detection logic to the backend to ensure only records relevant to the report are checked. - This avoids false positives by excluding VATs from partners not shown in the report. no-task
Users outside the Mexican localization who try to use the Mexico global invoicing action now receive a clear explanation instead of a generic validation error. This reduces confusion when the action appears for non-Mexican companies because of shared localization setup.
Original PR description
Currently, there is an button related to the MX localization that can be accessed outside the localization if `l10n_mx` is installed. Steps to reproduce: ------------------- * Install `l10n_mx` * With company other than MX, go to the pos orders * Select multiple pos orders, select the button **Actions** > Observation: The action `Create Global Invoice` is visible * Select the action `Create GLobal Invoice` > Validation error, Selected orders are not eligible for CFDI Why the fix: ------------ This is an `ir.actions.server` which is introduced in the `l10n_mx` localization. It does not look possible to add `invisible` on the xml for the action. https://github.com/odoo/odoo/blob/2540155b5e00a6547fcceee4af4b83f385dcd4ad/odoo/addons/base/models/ir_actions.py#L179-L215 What we can do instead is to throw a more explicit error when trying to use the action outside the MX loca. opw-4805257
This change rolls back a recent US tax reporting update because it caused crashes during deployment. It keeps the stable version working while the underlying dependency issue is addressed in a future release.
Original PR description
This reverts commit 1e8f79bd0a5e53f34cd8dfaea0a4d3e199aca0c7. The deployment of the reverted commit revealed an error: l10n_us_reports does not depend on l10n_us_account (only l10n_us), so it can't override the US tax report in data and crashes. We sadly cannot fix that in stable ; we'll do it in master.
Swedish point of sale orders no longer incorrectly show an invalid tax warning when products use approved tax rates. This prevents unnecessary checkout interruptions for businesses using the Swedish Fiscal Data Module.
Original PR description
Steps: ----------- - Install the pos_l10n_se module. - Open a POS session with the Swedish Fiscal Data Module configured in the IoT Box settings. - Add a product to the order. Issue: ------------- - An error popup states: "Product has an invalid tax amount. Only 25%, 12%, 6% and 0% are allowed." even when the product is correctly configured with one of these tax rates. Cause: ---------- - The validation logic incorrectly applies conditions for displaying the error popup, mistakenly rejecting valid tax rates when the PoS receipt label is set. FIX: ----------- - Updated the tax validation conditions to handle products correctly, allowing tax rates, and preventing false error messages. task-4687156
Swiss ISO20022 payment exports now correctly handle SEPA and ISO20022 payment types used within the Swiss standard. This helps Swiss businesses generate compliant bank payment files and avoids rejected or incomplete payment instructions.
Original PR description
Following page 35 of the documentation here https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps2024-2.1.1-en.pdf In Switzerland, SEPA and ISO20022 are considered as subsets of the Swiss standard, and it is hence possible to include within the Swiss file nodes that are generated following these formats. We didn't support that before this commit. To allow that, we also remove the ability to force the value of the ChrgBr node when using SEPA ; other values as SLEV are not supported by that format anyway. opw-4535542
Belgian Intrastat Goods exports now correctly include only goods and exclude service products. This prevents inaccurate XML or CSV reporting for companies submitting Intrastat goods declarations.
Original PR description
**Steps to reproduce:** - Install accountant and l10n_be_intrastat - Switch to a Belgian company (e.g. BE Company CoA) - Create a "Goods" product: * Product Type: Goods * Commodity Code: [any] *…
**Steps to reproduce:**
- Install accountant and l10n_be_intrastat
- Switch to a Belgian company (e.g. BE Company CoA)
- Create a "Goods" product:
* Product Type: Goods
* Commodity Code: [any]
* Country of Origin: [any]
- Create a "Service" product:
* Product Type: Service
* Commodity Code: [any]
* Country of Origin: [any]
- Create an invoice:
* Customer: [an European customer (not from Belgium)]
* Invoice Lines: 1 line with the goods and 1 line with the service
- Confirm the invoice
- Go to "Accounting / Reporting / Audit Reports / Intrastat Reports"
- Select "Intrastat (Goods)" as Report
- Select the correct date to display the created invoice
- Click on the "XML" or "CSV" button to export the report
**Issue:**
In the exported file, the service product is also included. Only the goods should be in the exported file.
**Cause:**
Since a previous fix for "l10n_be_intrastat", "product_type_condition" condition is overridden with `SQL("AND (account_move_line.product_id IS NOT NULL)")` (https://github.com/odoo/enterprise/commit/1108467dcaedfacc28bf1751f6f8f4fc10f84043)
The original condition was:
`SQL("AND (account_move_line.product_id IS NULL OR prodt.type != 'service')")`
The part excluding the service products is removed by the overriding condition.
opw-4824257Fixed an issue where messages linked to deleted records without an active discussion thread were not cleaned up correctly. This helps keep related communication data consistent and prevents leftover messages from deleted business records.
Original PR description
https://github.com/odoo/odoo/pull/209644
This fixes unwanted extra spaces in product or service descriptions on Uruguayan electronic invoice documents. It helps keep customer-facing invoice details cleaner and more consistent without changing business workflows.
The Documents search panel now shows folder hierarchies correctly when users open documents from other apps such as Fleet or Project. The “All” folder is also consistently available, making it easier for users to browse and find the right documents.
Original PR description
Backport of #84244 Issues: i) When coming from another app (Fleet, Project, etc.), the search panel does not correctly display the subfolders. ii) The “All” folder should always be displayed. Technical Reason: i) Correctly set folder_id as False for documents whose parent folder is inaccessible, ensuring a clean and accurate folder hierarchy in the search panel. ii) It was intended, add a condition when coming from other modules 'All' should not display. After this commit: i) Correctly display folders in hierarchy in a search panel when coming from other modules. ii) 'All' folder should always be displayed. Follow up of 4669259 Task-4836554
Miscellaneous changes
Steps to reproduce ================== - Open the JS unit test page - Enable the "Mid-tier mobile" option in the devtools in order to have a 4X CPU slowdown - Run the test "url should not use the record last updated date when the field is related" => It fails Cause of the issue ================== We check that a timestamp generated after a patchDate is at most 100ms after. When we have a high CPU usage or a slow CPU, it can happen that the value is more than 100ms after. Soluti
Original PR description
Steps to reproduce ================== - Open the JS unit test page - Enable the "Mid-tier mobile" option in the devtools in order to have a 4X CPU slowdown - Run the test "url should not use the record last updated date when the field is related" => It fails Cause of the issue ================== We check that a timestamp generated after a patchDate is at most 100ms after. When we have a high CPU usage or a slow CPU, it can happen that the value is more than 100ms after. Solution ======== The test simply needs to check that the date is either the `2017-02-06` or the `2017-02-09`. We can use the luxon function `a.hasSame(b, "days")` runbot-115469 Forward-Port-Of: odoo/odoo#212608 Forward-Port-Of: odoo/odoo#212515
After this PR - transporter gst number is not required while submitting ewaybill if vehicle number is present and mode of transportation is by road - vehicle number can be left empty if transportation document no is set however transporter gst is required for that case task-4807693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211088
Original PR description
After this PR - transporter gst number is not required while submitting ewaybill if vehicle number is present and mode of transportation is by road - vehicle number can be left empty if transportation document no is set however transporter gst is required for that case task-4807693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211088
Problem: When trying to align a separator to the left or right in the email editor using `ms-auto` or `me-auto`, it remains centered instead of aligning as intended. Cause: A global `margin: auto` rule was applied to all `hr` elements, overriding the directional margin utilities (`ms-auto`, `me-auto`), preventing correct alignment. Solution: Restrict `margin: auto` to only apply on `hr` elements that do *not* have `ms-auto` or `me-auto` classes. This preserves default centering while al
Original PR description
Problem: When trying to align a separator to the left or right in the email editor using `ms-auto` or `me-auto`, it remains centered instead of aligning as intended. Cause: A global `margin: auto` rule was applied to all `hr` elements, overriding the directional margin utilities (`ms-auto`, `me-auto`), preventing correct alignment. Solution: Restrict `margin: auto` to only apply on `hr` elements that do *not* have `ms-auto` or `me-auto` classes. This preserves default centering while allowing explicit left or right alignment. Steps to reproduce: - Open Email Marketing and add a "Separator" to an email. - Try to align the separator to the left or right. → The separator remains centered instead of aligning properly. opw-4805194 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212496
When trying to send a vendor bill that uses a tax with l10n_es_type 'sujeto_agricultura' with TicketBAI using the agency bizkaia, we are faced with an error code. This is due to the amount of these taxes being different than what is allowed (10.5% and 12%). The two 'sujeto_agricultura' taxes are actually part of a special regime and should be exempted when sent [reference](https://sede.agenciatributaria.gob.es/Sede/iva/regimenes-tributacion-iva/regimen-especial-agricultura-ganaderia-pesca.htm
Original PR description
When trying to send a vendor bill that uses a tax with l10n_es_type 'sujeto_agricultura' with TicketBAI using the agency bizkaia, we are faced with an error code. This is due to the amount of these taxes being different than what is allowed (10.5% and 12%). The two 'sujeto_agricultura' taxes are actually part of a special regime and should be exempted when sent [reference](https://sede.agenciatributaria.gob.es/Sede/iva/regimenes-tributacion-iva/regimen-especial-agricultura-ganaderia-pesca.html) This PR adapts the data sent to Bizkaia, in a similar manner as https://github.com/odoo/odoo/pull/196017 did for SII, by setting `ClaveRegimenIvaOpTrascendencia` to `02` and `TipoFactura` to `06` if we have a 'sujeto_agricultura' tax. [reference](https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/Validaciones_ErroresSII_v1.1.pdf) opw-4781267 Forward-Port-Of: odoo/odoo#211065 Forward-Port-Of: odoo/odoo#210141
Fixed onboarding document tours which was not working properly. Task-4210376 Forward-Port-Of: odoo/enterprise#72639 Forward-Port-Of: odoo/enterprise#70900
Original PR description
Fixed onboarding document tours which was not working properly. Task-4210376 Forward-Port-Of: odoo/enterprise#72639 Forward-Port-Of: odoo/enterprise#70900
Before this commit:- - In GST Return Return Period 'Push to GSTN' button triggers a cron to send GSTR-1 data, but on UI there is no information about whether the cron is running in backend or not? After this commit:- - Raise ValidationError if that required cron is disabled. - Show acknowledgement notification(ir.actions.client) after the cron is triggered. task-4653538 Forward-Port-Of: odoo/enterprise#84125
Original PR description
Before this commit:- - In GST Return Return Period 'Push to GSTN' button triggers a cron to send GSTR-1 data, but on UI there is no information about whether the cron is running in backend or not? After this commit:- - Raise ValidationError if that required cron is disabled. - Show acknowledgement notification(ir.actions.client) after the cron is triggered. task-4653538 Forward-Port-Of: odoo/enterprise#84125
Currently, if there is an error while generation print reports the use of the IoT will return the generic error `Failed to send to printer' which does not lead to understand there is a hidden issue to begin with. Steps to reproduce: ------------------- 1. Set up the iot and like the product labels report to a zebra printer 2. Modify the view of the product labels (`label_product_product_view`) to ensure there is an error during rendering (mistype a field name) 3. Go to a product and print
Original PR description
Currently, if there is an error while generation print reports the use of the IoT will return the generic error `Failed to send to printer' which does not lead to understand there is a hidden issue…
Currently, if there is an error while generation print reports the use of the IoT will return the generic error `Failed to send to printer' which does not lead to understand there is a hidden issue to begin with. Steps to reproduce: ------------------- 1. Set up the iot and like the product labels report to a zebra printer 2. Modify the view of the product labels (`label_product_product_view`) to ensure there is an error during rendering (mistype a field name) 3. Go to a product and print labels > Observation: Notification: Failed to send to printer Why the fix: ------------ In the example given an error occurs when trying to render the label here: https://github.com/odoo/enterprise/blob/968bf16c65a67791efd5fb94f5c95eaf09a47107/iot/static/src/iot_report_action.js#L50-L57 Technically the error makes it so that we fall into this catch block https://github.com/odoo/enterprise/blob/968bf16c65a67791efd5fb94f5c95eaf09a47107/iot/static/src/iot_report_action.js#L81-L88 We will now make a distinction between the RPC error and generic iot related error. If any error occur while making the RPC call we will now show the traceback. This should help anyone debugging. opw-4571350 Forward-Port-Of: odoo/enterprise#84589