Daily updates from Odoo
Wednesday, July 1, 2026
115 changes
29 changes
Enhancements to existing features
When users compare report lines against selected lines, the comparison is always shown as a percentage. This update hides the Amount/Percent selector in that case, reducing confusion and simplifying the report setup.
Original PR description
In [^1] support for comparison against user selected lines was added. This is always in percentages, as such, the "Comparison In" option that was added in [^2] is not useful as we would never set it to Amount. In this PR we hide "Comparison In" if the report line is selected. task-6322616 [^1]: odoo/enterprise#116721 [^2]: odoo/enterprise#116480
This change speeds up how Odoo retrieves task activity information by adding a database index for a frequently used query. It reduces the time spent on this lookup, which helps pages and actions that rely on /mail/data load more quickly.
Original PR description
`/mail/data` is called a lot. It spends roughly 33% of its time on the query fetching task activities in `_get_activity_groups` https://github.com/odoo/odoo/blob/a52b277a4db5f14516717738ca962e3bb3c7180f/addons/project_todo/models/res_users.py#L27 This commit adds an index to speed up the query. - before ~25ms https://explain.dalibo.com/plan/72b26edce8448b51 - after <1ms https://explain.dalibo.com/plan/c4g6851e5b4hh702 task-6327159 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272712
Resolved issues and error corrections
This change removes unnecessary product-tracking information from Point of Sale test data and tidies up a couple of automated tests. It also moves stock-related coverage to the stock-specific test area, which makes the test suite easier to maintain and reduces duplicate checks.
Original PR description
*: pos_stock In this commit: --- - Remove the `tracking` field from the HOOT test data. - Remove `test_order_unexisting_lots`, as it is already covered in `pos_stock`. - Move `test_order_existing_lot_gs1_nomenclature` from `point_of_sale` to `pos_stock`, where the stock-related behavior belongs. runbot-941084 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272322
This fix ensures the edit pencil for Suggested Forecasted Demand stays visible even if the Forecasted Stock row is hidden. It prevents an unrelated row filter from affecting access to a forecast adjustment action, making the Master Production Schedule easier to use.
Original PR description
Steps to reproduce:
1. Install Manufacturing.
2. Enable 'Master Production Schedule' in the Settings.
3. Go to [Manufacturing -> Planning -> Master Production Schedule].
4. Ensure 'Demand Forecast' and 'Forecasted Stock' rows are enabled from the dropdown.
5. Observe the edit pencil button next to 'Forecasted Demand' is visible.
6. Hide 'Forecasted Stock' using the rows filter dropdown.
Issue:
The edit pencil button ("Suggest Forecasted Demand") next to the 'Forecasted Demand' row disappears when the 'Forecasted Stock' row is hidden.
Expected behavior:
The edit pencil visibility should not be affected by the 'Forecasted Stock' row.
opw-6240596
Forward-Port-Of: odoo/enterprise#121688
Forward-Port-Of: odoo/enterprise#120208This update prevents a test from failing in environments where the ISO 20022 payment module is not installed. If the required module is absent, the test is now skipped instead of causing an unnecessary failure, improving reliability of automated checks.
Original PR description
The test_batch_payment_deletion test is currently failing when `account_iso20022` is not installed because the sepa_ct payment method doesn't exists. Add a skipTest in case the module is not installed. runbot-940257 Forward-Port-Of: odoo/enterprise#121511
This change adjusts an automated Point of Sale test so it uses a safer setup when more than one company is involved. It helps prevent test failures caused by mixing data from different companies, improving reliability of the test suite.
Original PR description
Making the test only depend on one class setup to avoid potential (already present) multicompany issues. In this case the env.user came from one setup class but was incompatible to use during the setup of the second class that was creating records for another company. By making the test only depend on one of the tests we'll avoid this issue. runbot-939375 Forward-Port-Of: odoo/odoo#268819
This change makes the public chat tour more reliable by ensuring the attachment menu closes before the message is sent. It also corrects a test update so the right conversation is checked between runs, helping prevent flaky test failures and making future debugging easier.
Original PR description
Attempt at fixing the following race condition. It's not clear what causes it, but these changes make the test more robust and might help future investigations. discuss_channel_public_tour opens the composer "More Actions" menu to attach files but feeds the hidden file input directly, so the menu is never closed and is still open when Send is clicked. Close it and wait for it to disappear before sending, to avoid clicking Send while the dropdown is dismissing. Also fix _open_group_page_as_user, which updated the last message body of self.channel instead of self.group between the two tour runs. https://runbot.odoo.com/odoo/error/243436 Forward-Port-Of: odoo/odoo#272606 Forward-Port-Of: odoo/odoo#272425
This update corrects a test in the French PDP module so it no longer expects a payment status that is only available in the Accounting app from the enterprise edition. It helps the build succeed in community setups where only Invoicing is installed.
Original PR description
The `in_payment` state does not exist in community with only the Invoicing module installed. It is added in `enterprise` in the Accounting module. runbot.build.error-939451 Forward-Port-Of: odoo/odoo#267475
The page limit note in the website generator was made more general instead of stating a fixed number. This gives the system more flexibility to adjust page limits on the service side without exposing a specific limit to users.
Original PR description
Page limit note fixed by being more general instead of stating a blatant 200. This gives us more leeway to control the nbr of pages IAP side. Forward-Port-Of: odoo/enterprise#121941 Forward-Port-Of: odoo/enterprise#121671
This fix ensures the editor toolbar closes properly when a selected snippet or text block is deleted from the website builder. It improves the editing experience by preventing a toolbar from staying visible after the content it belongs to has been removed.
Original PR description
Commit 8df8b4f41809de75f9ca220d47274cc3166f1cd5 moved the check for selection inside `[data-prevent-closing-overlay]` to the `closeToolbar` plugin. But when this function is called from `selection_leave_handlers` it should not do that check, as it was done for the focus or click. This commit skips the check based on the selection when `closeToolbar` is called by `selection_leave_handlers`. Steps to reproduce: - Open website builder - Drop "Text Image" snippet - Select some text in the snippet - Click on the trash icon in the sidebar to remove the snippet - Bug: the toolbar is still shown task-6308364 Forward-Port-Of: odoo/odoo#272640 Forward-Port-Of: odoo/odoo#270516
This update corrects a test in the tax reports area so it no longer treats all taxes the same when a fiscal position is applied. It ensures only taxes linked to a fiscal position are removed, while taxes without one remain included, making the test reflect the intended behavior.
Original PR description
map_tax on an empty fiscal position now preserves taxes with no fiscal_position_ids. Filter those out in test_tax_unit_auto_fiscal_position so the assertion only checks that taxes bound to a fiscal position are dropped by the unit FP. comunity PR: https://github.com/odoo/odoo/pull/268273 task-id 623151 Forward-Port-Of: odoo/enterprise#121889 Forward-Port-Of: odoo/enterprise#121525
This update fixes a timing issue in the WhatsApp channel test so the system waits for the connection to subscribe before sending the seen update. It ensures the seen status is received reliably and the indicators display as expected, preventing test failures.
Original PR description
The "Allow SeenIndicators in WhatsApp Channels" test delivers the seen update over the bus with `_sendone`, but nothing waited for the websocket to subscribe to the channel first. When the notification was sent before the subscription landed it was dropped, the member's seen_message_id was never updated client-side and the seen indicators never rendered, so the assertion timed out. The current user is a member of the channel, so it is subscribed at connection time: wait for the subscription together with `start()` (listener registered first) before opening the channel and sending the notification. https://runbot.odoo.com/odoo/error/242021 Forward-Port-Of: odoo/enterprise#121857
A test related to cancelled sales orders was moved to the correct point of the sales flow so it runs in the module that includes stock-related features. This prevents test failures during automated checks and helps keep the POS sales workflow stable.
Original PR description
The test uses `pos_order.picking_ids`, but on saas-19.3 `picking_ids` moved to the `pos_stock` module. `pos_sale` does not depend on `pos_stock`, so the test fails there with AttributeError. Move it to `pos_sale_stock`, which depends on `pos_stock`. Fixing https://runbot.odoo.com/odoo/runbot.build.error/938839 Forward-Port-Of: odoo/odoo#272577
This fix restores the behavior of the hidden column count option in the website layout builder. As a result, templates using the fixed-column class will once again hide the column count control as intended, avoiding unwanted layout changes during editing.
Original PR description
The class 's_nb_column_fixed' was used to hide the column count option, but it got lost during the refactoring and doesn't work since 18.4. This commit restores it. task-6234267 Forward-Port-Of: odoo/odoo#271975 Forward-Port-Of: odoo/odoo#268005
The system now uses the VIES test service when databases have been neutralized, instead of contacting the live production service. This helps avoid unnecessary calls to the real endpoint and reduces the risk of mixing test activity with production checks.
Original PR description
Neutralized databases don't always have demo data, so they talk to production VIES endpoint. With this change, the production endpoint is replaced with the test one. If some database has a custom endpoint, nothing is done. @moduon MT-15142 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272036
This change prevents a warning from being logged for every uploaded document when automatic OCR is turned off. It reduces noise in the logs and makes it easier to spot messages that actually need attention.
Original PR description
The warning "Automatic OCR does not apply to this document" was logged for every upload when automatic OCR isn't enabled, it isn't very useful. opw-[6232122](https://www.odoo.com/odoo/unassigned-tasks/6232122) Forward-Port-Of: odoo/enterprise#120741
This change removes an unnecessary half-second delay from Discuss-related automated tests, making them run much faster again. It restores test performance to previous levels, which helps developers get quicker feedback and reduces wait time in the test pipeline.
Original PR description
Before this commit, discuss tests were very slow. This is a consequence from PR that adds waitUntilSubscribe to mail test helpers's start() [1], for which the wait UntilSubscribe takes about 500ms to resolve. Because of this, tests that take about 200ms were taking 700ms instead. "mail > activity" test suite was taking about 3 sec. but now takes 21sec, so a 700% time increase. The root cause comes from Websocket that has `OUTGOING_BATCH_DELAY` that is at 500ms, which also takes into account the initial sendToServer, therefore the tests using the mail test helpers always had this 500ms delay. This commit fixes the issue by mocking `OUTGOING_BATCH_DELAY` to `0`, so this is basically instantaneous. Tests are back to their prior speed, and activity tests are back to 3 sec., down from 21 sec. [1]: https://github.com/odoo/odoo/issues/270281
This change fixes an unreliable test around retrying message loading in the chat interface. It ensures the test waits for the first loading attempt to be fully in progress before retrying, which better matches real user behavior and prevents false failures in automated checks.
Original PR description
The "Retry loading more messages on failed load more messages" test drove load-more by scrolling (real IntersectionObserver) and failed the fetch synchronously, then clicked retry immediately. The observer could fire the older-fetch twice and leave a second fetch in flight at the retry click, which then no-op'd (fetchMoreMessages bails while a fetch is loading), leaving 30 messages instead of 60. This is a test-timing artifact: a real user retries long after any fetch has settled. Fail the load-more through a Deferred rejected only once the fetch is in flight, like jump_to_present.test.js. While it is pending, duplicate observer fires no-op, so no orphan fetch can race the retry. https://runbot.odoo.com/odoo/error/242113 Forward-Port-Of: odoo/odoo#272942 Forward-Port-Of: odoo/odoo#272430
This change updates the subcontracting landed costs module to depend on the correct related module. It reduces the risk of broken behavior if one of the connected modules is removed, helping keep the feature more reliable.
Original PR description
`mrp_subcontracting_landed_costs` uses template from `mrp_landed_costs` but doesn't depends on it, but rather it's ancestry `stock_landed_costs`. While the module are auto-installed, this could raise issues if the module is uninstalled. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When printing a report, the printer selection popup now correctly respects the printers assigned to the user or document. This prevents users from seeing irrelevant printers and helps ensure reports are sent to the intended device.
Original PR description
This commit fixes the domain for the printer selection popup when printing a report. The assigned printers were not taken into account. task-6332442
Internal notes in Point of Sale now keep the original colors of tagged labels instead of forcing them all to use the same background. This makes colored tags easier to recognize and improves readability, especially in light mode.
Original PR description
Before this commit: ===================== The internal note styling applied a custom background color to all tags, overriding the colors provided by TagsList (o_tag_color_*). As a result, colored tags were displayed with the default background in light mode. After this commit: ====================== The custom background color is applied only to default tags, while tags with an explicit color keep their original TagsList styling. Additionally, demo internal notes were updated with color values to showcase the colored tag behavior. Task:6294250 Forward-Port-Of: odoo/odoo#269746
This update adjusts an automated test for Mexican electronic invoicing so it works correctly whether the Accounting app is installed or not. It prevents test failures caused by a payment moving from “paid” to “in payment” in setups with accounting enabled.
Original PR description
If accountant is installed, payment state of unreconciled payment switch from 'paid' to 'in_payment'. Not having accountant break the test. runbot-939445 Forward-Port-Of: odoo/enterprise#121113
Previously, using the test print option for an Obox POS printer produced no output. This fix makes Obox printers print a test receipt, matching the behavior already available for ePOS printers and helping users verify their setup quickly.
Original PR description
See: https://github.com/odoo/obox/pull/200 Before this commit, attempting to perform a test print for an Obox POS printer would do nothing. After this commit, a test receipt will be printed for the Obox printer just like for ePOS printers. task-6330857
This update ensures test chat messages always have a posting date, so displayed times are consistent during automated testing. It prevents occasional failures where the time shown on a notification could shift by a minute while the test was running.
Original PR description
The hoot test "display the notification message's posting date and time" flakes on loaded runbots: the asserted time ("1:00 PM") sometimes renders a minute later, so the exact :text() match fails.
NotificationMessage shows dateSimpleWithDay, which falls back to the live DateTime.now() when the message has no date. The JS test mock mail.message never defaulted date: the Python fields.Datetime.now default cannot transfer to the mock, so it resolved to false, unlike the real model. hoot's mocked clock is not frozen: now() advances with real wall-clock time, so a slow render drifts past the posting minute.
Default date on the mock so the message carries a posting time, and read that written date back in the tests instead of hardcoding the displayed time: the mocked clock can still advance between mockDate and the (async) create. This covers the six tests that assert a NotificationMessage time.
https://runbot.odoo.com/odoo/error/941202This update ensures Romania-specific stock batch logic is applied only when it should be, instead of affecting all cases. It prevents test and automation failures and keeps the standard stock process stable for other setups.
Original PR description
The Romanian specifics were applied without condition which caused runbot errors. Note that this was revealed later on (saas-19.3) after a change in the generic stock test setup. runbot-241098 Forward-Port-Of: odoo/odoo#271985
## [FIX] base: Fix vat label css With the wrapping div the label lost it's label style. task-6352123 ## [FIX] l10n_*: Fix xpath after multi ID * l10n_br,l10n_my_ubl_pint,l10n_ca,l10n_ph,l10n_in,l10n_rs_edi In the multi ID [1], we completely revamped the UI around the `vat` field. It's now mostly made of: - the VAT field inlined with a "+" button adding additional_identifiers - the additional identifiers that comes below with input-text-like display. The feature should stay in one
Original PR description
## [FIX] base: Fix vat label css With the wrapping div the label lost it's label style. task-6352123 ## [FIX] l10n_*: Fix xpath after multi ID *…
## [FIX] base: Fix vat label css With the wrapping div the label lost it's label style. task-6352123 ## [FIX] l10n_*: Fix xpath after multi ID * l10n_br,l10n_my_ubl_pint,l10n_ca,l10n_ph,l10n_in,l10n_rs_edi In the multi ID [1], we completely revamped the UI around the `vat` field. It's now mostly made of: - the VAT field inlined with a "+" button adding additional_identifiers - the additional identifiers that comes below with input-text-like display. The feature should stay in one block, therefore we added an "identifiers" div wrapping all these fields/buttons/labels. This way other fields can easily xpath before or after the whole block. We also have a vat_div identifiers that is meant for feature needed to be inlined with the vat and the "+". This PR and its Enterprise counterpart fix some xpath that were still incorrect after [1] and [2] in following modules: l10n_br, l10n_my_ubl_pint, l10n_ca, l10n_ph, l10n_in, l10n_rs_edi, l10n_mx_edi_stock [1]: https://github.com/odoo/odoo/pull/262274 [2]: https://github.com/odoo/odoo/pull/271906 task-6352123
In the multi ID [1], we completely revamped the UI around the `vat` field. It's now mostly made of: - the VAT field inlined with a "+" button adding additional_identifiers - the additional identifiers that comes below with input-text-like display. The feature should stay in one block, therefore we added an "identifiers" div wrapping all these fields/buttons/labels. This way other fields can easily xpath before or after the whole block. We also have a vat_div identifiers that is meant for feat
Original PR description
In the multi ID [1], we completely revamped the UI around the `vat` field. It's now mostly made of: - the VAT field inlined with a "+" button adding additional_identifiers - the additional identifiers that comes below with input-text-like display. The feature should stay in one block, therefore we added an "identifiers" div wrapping all these fields/buttons/labels. This way other fields can easily xpath before or after the whole block. We also have a vat_div identifiers that is meant for feature needed to be inlined with the vat and the "+". This PR and its Community counterart fix some xpath that were still incorrect after [1] and [2] in following modules: l10n_br, l10n_my_ubl_pint, l10n_ca, l10n_ph, l10n_in, l10n_rs_edi, l10n_mx_edi_stock [1]: https://github.com/odoo/odoo/pull/262274 [2]: https://github.com/odoo/odoo/pull/271906 task-6352123
Miscellaneous changes
Related: https://github.com/odoo/enterprise/pull/122299 Related: https://github.com/odoo/design-themes/pull/1305
Original PR description
Related: https://github.com/odoo/enterprise/pull/122299 Related: https://github.com/odoo/design-themes/pull/1305
Related: https://github.com/odoo/odoo/pull/273112 Related: https://github.com/odoo/design-themes/pull/1305
Original PR description
Related: https://github.com/odoo/odoo/pull/273112 Related: https://github.com/odoo/design-themes/pull/1305
11 changes
Enhancements to existing features
This update makes sure the label shown for the reconciliation setting is consistent across accounting models. It improves clarity for users by displaying the same updated wording everywhere, avoiding confusion from mixed old and new labels.
Original PR description
Since this PR https://github.com/odoo/odoo/pull/249536 "Allow Reconcilation" became "Payment Reconciliation" This change in labels didn't take effect in the account.move.line model. This commit fixes this issue by ensuring that the label of is_account_reconcile field matches that of the account.account.reconcile field. task-6306159
Resolved issues and error corrections
The restaurant point of sale now only shows the Split action when bill splitting is turned on in the configuration. This avoids confusing staff with an option they cannot use and keeps the Actions menu aligned with the store’s settings.
Original PR description
Previously, the Split action remained available in the restaurant PoS even when bill splitting was disabled in the POS configuration. Steps to reproduce: - Disable the split bill option in the restaurant POS configuration. - Open a restaurant POS session. - Select a table and add multiple products. - Open the Actions menu. - Observe that the Split action is still displayed. This commit ensures that the Split action is only shown when bill splitting is enabled in the PoS configuration. Task-6294276
Internal notes in Point of Sale now keep the original tag colors when a color has been set, instead of forcing every tag to use the same background. This makes colored notes easier to read and helps staff distinguish tags more quickly in light mode.
Original PR description
Before this commit: ===================== The internal note styling applied a custom background color to all tags, overriding the colors provided by TagsList (o_tag_color_*). As a result, colored tags were displayed with the default background in light mode. After this commit: ====================== The custom background color is applied only to default tags, while tags with an explicit color keep their original TagsList styling. Additionally, demo internal notes were updated with color values to showcase the colored tag behavior. Task:6294250 Forward-Port-Of: odoo/odoo#269746
This update fixes an internal testing issue in the Point of Sale and Loyalty areas by making temporary test changes automatically clean themselves up. It helps keep the system’s code checks reliable and prevents false test failures during development and validation.
Original PR description
Avoid polluting the Odoo model registry and failing `test_lint_override_signature` by using `patch.object` instead of manual assignment. This ensures the injected method is properly torn down after the test block, keeping the registry clean and bypassing static analysis failure as the patched method is only used for tests. runbot-939298 Forward-Port-Of: odoo/odoo#273096
This update adjusts an automated test so it works whether the accounting app is installed or not. It matters because the payment status can now be handled correctly in both setups, preventing false test failures during builds.
Original PR description
If accountant is installed, payment state of unreconciled payment switch from 'paid' to 'in_payment'. Not having accountant break the test. runbot-939445 Forward-Port-Of: odoo/enterprise#121113
This update fixes a test issue in the POS Urban Piper module by making sure temporary test changes are removed properly after the test runs. It helps keep the system’s internal checks stable and prevents unnecessary test failures.
Original PR description
Avoid polluting the Odoo model registry and failing `test_lint_override_signature` by using `patch.object` instead of manual assignment. This ensures the injected method is properly torn down after the test block, keeping the registry clean and bypassing static analysis failure as the patched method is only used for tests. runbot-939298 Forward-Port-Of: odoo/enterprise#122283
This change fixes an unreliable automated test in the messaging app. It ensures the retry scenario is checked in a more realistic way, so test results are consistent and do not hide real issues.
Original PR description
The "Retry loading more messages on failed load more messages" test drove load-more by scrolling (real IntersectionObserver) and failed the fetch synchronously, then clicked retry immediately. The observer could fire the older-fetch twice and leave a second fetch in flight at the retry click, which then no-op'd (fetchMoreMessages bails while a fetch is loading), leaving 30 messages instead of 60. This is a test-timing artifact: a real user retries long after any fetch has settled. Fail the load-more through a Deferred rejected only once the fetch is in flight, like jump_to_present.test.js. While it is pending, duplicate observer fires no-op, so no orphan fetch can race the retry. https://runbot.odoo.com/odoo/error/242113 Forward-Port-Of: odoo/odoo#272942 Forward-Port-Of: odoo/odoo#272430
We adjusted an automated test so it always runs from a fixed mid-week date instead of using the current day. This prevents the test from failing on weekends and makes the avatar card tour results reliable for everyone.
Original PR description
The avatar card tours create a time off relative to "today" and assert the "Back on" out-of-office indicator. When the test runs on a Friday or Saturday, today+1 is a weekend, so the leave's date_to lands on that weekend day's 00:00 and the "currently on leave" window closes at midnight. Once the run crosses that boundary the leave is no longer active, the indicator disappears and the tour fails at the "Back on" step, deterministically on that weekday. Freeze setUpClass to a fixed mid-week day so the time off always ends on a working day. https://runbot.odoo.com/odoo/error/242512 Forward-Port-Of: odoo/odoo#273073
When a new file is uploaded in Documents, its available actions are now shown right away. This removes the need to deselect and reselect the file before continuing, making the workflow smoother and faster for users.
Original PR description
Bug === When uploading a new file in documents, it's selected, but the actions are not visible (we need to unselect - select the record to see the actions). Task-5408471 Forward-Port-Of: odoo/enterprise#122102 Forward-Port-Of: odoo/enterprise#114770
When a business card is scanned, the contact’s city is now captured along with the other details. This makes scanned contact records more complete and reduces the need for manual edits.
Original PR description
Previously, when user scans any business card, every information was fetched except for the city name. After this commit the city field will be properly fetched. task-6332914 Forward-Port-Of: odoo/enterprise#121766
This change fixes an issue where the portal homepage flow could get stuck during testing because the page was not fully ready before the next step ran. It helps ensure the portal experience loads reliably and prevents test timeouts.
Original PR description
Since #256698, the `undeterministicTour_doNotCopy` flag was removed. Without this artificial delay, the `portal_load_homepage` tour executes steps faster than the website frontend JavaScript can finish initializing and binding event handlers to the form. Leaving the tour stuck on a blank text screen after Saving and causing a script timeout. Fix this by ensuring the frontend framework is fully initialized before interacting with the form fields. [Runbot-242298](https://runbot.odoo.com/odoo/runbot.build.error/242298) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
12 changes
Enhancements to existing features
The POS now sends buyer address details to Fiskaly only when they are actually available. This avoids transmitting placeholder values like "N/A" and helps ensure the information sent is more accurate and cleaner.
Original PR description
In this commit: ------------------- - Buyer address fields are optional and should only be sent to Fiskaly when they are actually available. - Avoid sending placeholder values like "N/A". If the data is not present, the fields should simply be omitted from the request. task: 6113133 Forward-Port-Of: odoo/enterprise#122188 Forward-Port-Of: odoo/enterprise#113621
This update fills in missing translations for user-facing messages across Point of Sale features. It improves the experience for non-English users by making dialogs, errors, alerts, and warnings easier to understand during day-to-day POS use.
Original PR description
pos* = All POS module In this commit: -------------------------------- Add missing translations for user-visible strings across POS modules. - Translated dialogs, errors, alerts, and other UI-visible messages - Updated Python-side UserError, ValidationError, and warning messages Task-5406947 Related PR-https://github.com/odoo/enterprise/pull/102094 Forward-Port-Of: odoo/odoo#273039 Forward-Port-Of: odoo/odoo#239972
This update fills in missing translations across Point of Sale screens, dialogs, errors, and warnings. It helps users see clearer messages in their language, making the POS easier to use and reducing confusion during daily operations.
Original PR description
pos* = All POS module In this commit: -------------------------------- Add missing translations for user-visible strings across POS modules. - Translated dialogs, errors, alerts, and other UI-visible messages - Updated Python-side UserError, ValidationError, and warning messages Task-5406947 Related PR-https://github.com/odoo/odoo/pull/239972 Forward-Port-Of: odoo/enterprise#122251 Forward-Port-Of: odoo/enterprise#102094
This update adds a new integration point when an activity is marked as done. It makes it easier for other features to automatically link or process the related message, improving consistency across activity-related workflows.
Original PR description
Add a hook in `_action_done` to allow other modules to link/process message for every activity.
Resolved issues and error corrections
Internal notes in Point of Sale now keep the intended colors for tags that were already assigned a specific color. This fixes an issue where all tags were forced to the same background in light mode, making colored tags harder to distinguish.
Original PR description
Before this commit: ===================== The internal note styling applied a custom background color to all tags, overriding the colors provided by TagsList (o_tag_color_*). As a result, colored tags were displayed with the default background in light mode. After this commit: ====================== The custom background color is applied only to default tags, while tags with an explicit color keep their original TagsList styling. Additionally, demo internal notes were updated with color values to showcase the colored tag behavior. Task:6294250 Forward-Port-Of: odoo/odoo#269746
This change updates a test for Mexican electronic invoicing so it correctly handles a payment that is still unreconciled. It matters because the test no longer fails depending on whether the accounting app is installed, making automated checks more reliable.
Original PR description
If accountant is installed, payment state of unreconciled payment switch from 'paid' to 'in_payment'. Not having accountant break the test. runbot-939445 Forward-Port-Of: odoo/enterprise#121113
This update corrects how two guided interactions simulate typing a slash command in Knowledge and Studio. It makes the training flows behave more like real user input, which prevents failures in these guided experiences.
Original PR description
#### Description of the issue: - Since the search powerbox plugin now checks for the actual existence of `/` in the DOM, some knowledge tours were failing because only the input event was dispatched without inserting `/`. - In web_studio, `insertText` was not positioning the selection correctly after insertion and was not dispatching beforeinput event before the DOM insertion. #### After this commit: - Adapt the `openPowerbox` utility in knowledge to insert `/` in the DOM before opening the powerbox. - Dispatch `beforeinput` before DOM insertion and `input` after it in web_studio, and move the selection after the inserted text. Community PR-https://github.com/odoo/odoo/pull/266284 task-6243724
This change fixes an intermittent issue in the Viva.com POS checkout test where the mocked webhook response could arrive before the payment or refund request had finished. As a result, the test could hang; the update makes the test wait at the right moment so the confirmation is always received reliably.
Original PR description
The Viva.com POS tour was failing intermittentely due to the mocked webhook response not waiting for the payment/refund request to finish. This would cause the tour to hang as it missed the webhook confirmation. We fix the issue by changing the `waitingCard` status to only be set after the payment request returns, and wait for this status before sending the fake webhook response. runbot-243758 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When users apply a device-style shape to an image, the image will now be cropped to match that shape instead of always being forced into a square crop first. This preserves more of the original picture and avoids unnecessary cropping, especially for tall images.
Original PR description
Scenario: - insert image with ~ 1:2 ratio (height bigger than width) - set shape "iPhone `#2`" to that image Result: the image should fit without much cropping the 0.46:1 aspect ratio of the shape, but it is cropped 1:1 before being applied to it. Cause: when the image has a set aspect ratio, we are always cropping it to 1:1 aspect ratio in postProcessCroppedCanvas but it should be cropped to the shape aspect ratio as it was done in previous version. Fix: go back to what was done in saas-18.3 and apply the shape aspect ratio and not just square (1:1) aspect ratio. opw-5415137 Forward-Port-Of: odoo/odoo#250922
When a business card is scanned, the city information is now imported correctly along with the other contact details. This reduces manual cleanup and makes newly created contacts more complete right away.
Original PR description
Previously, when user scans any business card, every information was fetched except for the city name. After this commit the city field will be properly fetched. task-6332914 Forward-Port-Of: odoo/enterprise#121766
The disconnect button for French e-invoicing was renamed to use the correct wording instead of referring to Peppol. This makes the interface clearer for users managing French electronic invoicing settings.
Original PR description
The name of the disconnect button for the France e-invoicing was incorrect as it referenced peppol and was fixed in this pr to be called Disconnect French electronic invoicing task-6266337 Forward-Port-Of: odoo/odoo#272654 Forward-Port-Of: odoo/odoo#268536
**Steps to reproduce:** * Install the **l10n_gt_edi** module. * Configure a Guatemalan company with valid Infile credentials in the settings. * Create a product or customer with special characters (e.g. `ñ`, `á`, `é`) in their name. * Create a customer invoice containing this product/customer. * Confirm the invoice to trigger the EDI send to the SAT (Infile). **Observed behavior:** * Infile intermittently rejects the invoice due to validation errors, or accepts it but the resulting cert
Original PR description
**Steps to reproduce:** * Install the **l10n_gt_edi** module. * Configure a Guatemalan company with valid Infile credentials in the settings. * Create a product or customer with special characters…
**Steps to reproduce:**
* Install the **l10n_gt_edi** module.
* Configure a Guatemalan company with valid Infile credentials in the settings.
* Create a product or customer with special characters (e.g. `ñ`, `á`, `é`) in their name.
* Create a customer invoice containing this product/customer.
* Confirm the invoice to trigger the EDI send to the SAT (Infile).
**Observed behavior:**
* Infile intermittently rejects the invoice due to validation errors, or accepts it but the resulting certified XML has truncated or malformed text exactly where the special characters were located.
**Cause:**
* Odoo uses the `requests.post()` library to send the XML payload to Infile. By default, `requests` encodes string payloads using `latin-1` unless told otherwise.
* Because the request was missing the explicit `Content-Type: application/xml` header and the XML string was not explicitly encoded to `utf-8` before sending, Infile parsed the payload using an incorrect encoding. This caused it to drop or misinterpret special characters, leading to validation failures or corrupted XML content.
**Fix:**
* Explicitly include the `'Content-Type': 'application/xml'` header in the request to Infile.
* Explicitly encode the `xml_data` payload to `utf-8` (`xml_data.encode('utf-8')`) before passing it to `requests.post()` to guarantee the correct encoding is sent over the wire.
opw-6315654
Forward-Port-Of: odoo/enterprise#12172911 changes
Enhancements to existing features
This update adds missing translations across Point of Sale screens, alerts, dialogs, and error messages. It helps users see clearer messages in their language, improving usability and reducing confusion during checkout and payment-related workflows.
Original PR description
pos* = All POS module In this commit: -------------------------------- Add missing translations for user-visible strings across POS modules. - Translated dialogs, errors, alerts, and other UI-visible messages - Updated Python-side UserError, ValidationError, and warning messages Task-5406947 Related PR-https://github.com/odoo/enterprise/pull/102094 Forward-Port-Of: odoo/odoo#272392 Forward-Port-Of: odoo/odoo#239972
This update fills in missing translations for user-facing messages across the Point of Sale apps, including dialogs, alerts, warnings, and error messages. It helps staff see clearer information in their language and makes the POS experience more consistent across supported locales.
Original PR description
pos* = All POS module In this commit: -------------------------------- Add missing translations for user-visible strings across POS modules. - Translated dialogs, errors, alerts, and other UI-visible messages - Updated Python-side UserError, ValidationError, and warning messages Task-5406947 Related PR-https://github.com/odoo/odoo/pull/239972 Forward-Port-Of: odoo/enterprise#121908 Forward-Port-Of: odoo/enterprise#102094
This update makes the POS fiscal integration send customer address information only when it is actually available. It avoids using placeholder values like “N/A”, which helps keep submitted data cleaner and reduces the risk of incorrect information being sent to Fiskaly.
Original PR description
In this commit: ------------------- - Buyer address fields are optional and should only be sent to Fiskaly when they are actually available. - Avoid sending placeholder values like "N/A". If the data is not present, the fields should simply be omitted from the request. task: 6113133 Forward-Port-Of: odoo/enterprise#122188 Forward-Port-Of: odoo/enterprise#113621
Resolved issues and error corrections
Point of Sale internal notes now preserve the original colors of tagged items instead of forcing them into a single default background. This makes colored tags easier to recognize and improves readability, especially in light mode.
Original PR description
Before this commit: ===================== The internal note styling applied a custom background color to all tags, overriding the colors provided by TagsList (o_tag_color_*). As a result, colored tags were displayed with the default background in light mode. After this commit: ====================== The custom background color is applied only to default tags, while tags with an explicit color keep their original TagsList styling. Additionally, demo internal notes were updated with color values to showcase the colored tag behavior. Task:6294250 Forward-Port-Of: odoo/odoo#269746
This update ensures Romania-specific stock batch behavior is only applied when it should be. It prevents test and system errors caused by those local rules being enabled unconditionally, improving stability without changing normal business flows.
Original PR description
The Romanian specifics were applied without condition which caused runbot errors. Note that this was revealed later on (saas-19.3) after a change in the generic stock test setup. runbot-241098 Forward-Port-Of: odoo/odoo#271985
The Colombian POS test now accepts any valid document number starting with SETF instead of expecting one exact number. This prevents occasional test failures when the same database is reused and the document counter increases.
Original PR description
**Why the fix:** This step failed from time to time as we did some batch testing on the runbot with the same database, and because of this, the Número de Documento increased, making it SETF990000002 or more. This error existed before 68da209 but by fixing the refund flow in said commit, this error has been appearing way more frequently. As this has already happened a few times in 18.2, it is still the targeted version for this fix. We now use a regex to make sure that we have **Número de Documento: SETF** followed by some numbers, but we do not specify that it should be SETF990000001 anymore. runbot-241997 Forward-Port-Of: odoo/enterprise#121211
This update corrects a failing test in the Mexico electronic invoicing flow when the accounting app is installed. It ensures the test accepts the payment status used in that setup, preventing unnecessary runbot failures and keeping automated checks reliable.
Original PR description
If accountant is installed, payment state of unreconciled payment switch from 'paid' to 'in_payment'. Not having accountant break the test. runbot-939445 Forward-Port-Of: odoo/enterprise#121113
This update makes an automated website test self-sufficient by turning on the required free sign-up setting during the test itself. It removes the need for manual configuration before running the test, helping ensure more reliable test results.
Original PR description
Steps to reproduce: 1. Install any website related module (e.g. `website`, `website_event`). 2. Keep the default configuration and do not manually enable 'Free sign up' in setting. 3. Run `test_auth_forms_warning`. Before this commit: The test did not programmatically enable the 'Free sign up' setting. To make the test pass, a developer had to manually navigate to the setting, As a result, it failed on a unless the setting was manually enabled beforehand. After this commit: This commit makes the test self-contained by enabling the required website configuration during its execution, allowing it to run successfully without any manual setup. runbot-233948 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When the point of sale cannot create a database transaction, it will now show the real underlying error instead of a generic message. This makes it easier for support teams and developers to understand what went wrong and resolve issues faster.
Original PR description
Before this commit the error "Transaction could not be created" was thrown when the transaction could not be created. This commit changes the behavior to throw the actual error that caused the transaction creation to fail, providing more context for debugging.
This change ensures an automated website signup test uses the correct public-facing website mode, so it no longer fails in certain single-app setups. It helps keep test results reliable and prevents false errors during development and validation.
Original PR description
Before this commit this test didn't work properly as the web/signup route returned an error 404 in certain single app tests such as hr_referral. This happens because default setup of websites sets the website to b2b, disabling the web/signup route https://github.com/odoo-dev/odoo/blob/dd1e9c139a30616eccef3cb0d8e5d4e69d001630/addons/auth_signup/controllers/main.py#L43-L44 Since this test is assuming b2c, we can just make the website b2c. Reproduction steps: 1. New db 2. Install hr_referral (./odoo-bin -d oes_referral -i hr_referral -p 8569) 3. Login as admin 4. Visit /web/signup 5. See 404 page not found You could also just run the test (./odoo-bin -d oes_signup -i hr_referral --test-tags /website:TestAuthFormsWarning.test_auth_forms_warning --stop-after-init) **saas-19.1+** Runbot [ticket](https://www.odoo.com/odoo/project/27948/tasks/6324186)
When a business card is scanned, the city field is now imported correctly along with the other contact details. This reduces manual cleanup and helps keep newly created contact records more complete and accurate.
Original PR description
Previously, when user scans any business card, every information was fetched except for the city name. After this commit the city field will be properly fetched. task-6332914 Forward-Port-Of: odoo/enterprise#121766
4 changes
Resolved issues and error corrections
This update fixes a test issue in the Mexico e-invoicing flow when the accounting app is not installed. It ensures the system handles payment status correctly so automated checks no longer fail in this setup.
Original PR description
If accountant is installed, payment state of unreconciled payment switch from 'paid' to 'in_payment'. Not having accountant break the test. runbot-939445 Forward-Port-Of: odoo/enterprise#121113
We updated an automated test so it no longer expects one exact document number, but any valid number starting with the required prefix. This prevents the test from failing when the same database is reused and the number increases over time.
Original PR description
**Why the fix:** This step failed from time to time as we did some batch testing on the runbot with the same database, and because of this, the Número de Documento increased, making it SETF990000002 or more. This error existed before 68da209 but by fixing the refund flow in said commit, this error has been appearing way more frequently. As this has already happened a few times in 18.2, it is still the targeted version for this fix. We now use a regex to make sure that we have **Número de Documento: SETF** followed by some numbers, but we do not specify that it should be SETF990000001 anymore. runbot-241997 Forward-Port-Of: odoo/enterprise#121211
The signature certificate now shows the applicant’s real email address instead of a generic placeholder. This fixes a display error that could cause confusion when reviewing signed recruitment offers.
Original PR description
When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed. ### **Steps to Reproduce:** 1) Install sign, recruitment,…
When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed. ### **Steps to Reproduce:** 1) Install sign, recruitment, hr_contract_salary 2) Create an new application and add basic detail like name and email as (path and `path@test.com`) 3) Generate offer and sign with all the required signer(applicant and Marc Demo). 4) Open the application form view and open the certificate. ### **Observed Behavior:** Email is not set correctly in the generated certificate (appearing as `john@example.com`). ### **Expected Behavior:** The email of the applicant should be correctly set(e.g as `path@test.com`) ### **Root Cause:** When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed. [1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54 [2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59 ### **Fix:** Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time. opw-6280170 Forward-Port-Of: odoo/enterprise#120566
When users scan a business card, the city name is now imported along with the other contact details. This reduces manual cleanup and makes newly created contacts more complete and accurate.
Original PR description
Previously, when user scans any business card, every information was fetched except for the city name. After this commit the city field will be properly fetched. task-6332914 Forward-Port-Of: odoo/enterprise#121766
6 changes
Enhancements to existing features
This change ensures that the unique transaction ID provided by Italy’s SDI is saved not only for sent documents, but also for received vendor bills. It improves traceability and makes it easier to match and audit incoming electronic invoices.
Original PR description
A unique transaction id is provided by the SDI for every document. This transaction id was saved on document sending, but discarded for received one. backport of f2cc23b30dd4 opw-6111186 Forward-Port-Of: odoo/odoo#268508
Resolved issues and error corrections
This update ensures Romania-specific stock batch behavior is applied only when appropriate, instead of affecting all cases. It prevents test and build failures caused by those rules being triggered unconditionally.
Original PR description
The Romanian specifics were applied without condition which caused runbot errors. Note that this was revealed later on (saas-19.3) after a change in the generic stock test setup. runbot-241098 Forward-Port-Of: odoo/odoo#271985
This update corrects a test in the Mexican e-invoicing flow so it works whether the accounting app is installed or not. It prevents false failures caused by a payment status changing from “paid” to “in payment” in certain setups.
Original PR description
If accountant is installed, payment state of unreconciled payment switch from 'paid' to 'in_payment'. Not having accountant break the test. runbot-939445 Forward-Port-Of: odoo/enterprise#121113
We updated the Colombian POS tour check so it no longer expects one exact document number. This prevents the test from failing when document numbers increase during repeated runs, making the validation more stable and reducing false errors.
Original PR description
**Why the fix:** This step failed from time to time as we did some batch testing on the runbot with the same database, and because of this, the Número de Documento increased, making it SETF990000002 or more. This error existed before 68da209 but by fixing the refund flow in said commit, this error has been appearing way more frequently. As this has already happened a few times in 18.2, it is still the targeted version for this fix. We now use a regex to make sure that we have **Número de Documento: SETF** followed by some numbers, but we do not specify that it should be SETF990000001 anymore. runbot-241997 Forward-Port-Of: odoo/enterprise#121211
This update moves a bank account retrieval test into the dedicated invoice import test file and uses a partial XML sample instead of a generated one. It makes the test setup closer to real import data and helps keep the test more stable and maintainable.
Original PR description
Move the partner retrieval bank account number test to the `test_ubl_import_bis3_invoice_be_retrieve_partner.py` file and use a partial XML instead of a generated XML. Forward-Port-Of: odoo/odoo#269995
In a multi-company setup with a website per company, the unsubscribe link in mass mailing emails could send recipients to the login page instead of the unsubscribe confirmation page. ### Steps to reproduce 1. Enable multi-company and create a second company `Company B`. 2. Create two websites with different domains, one per company: - `Website A` on the main company, domain `http://website-a.test` - `Website B` on `Company B`, domain `http://website-b.test` 3. Set the system para
Original PR description
In a multi-company setup with a website per company, the unsubscribe link in mass mailing emails could send recipients to the login page instead of the unsubscribe confirmation page. ### Steps to…
In a multi-company setup with a website per company, the unsubscribe link in mass mailing emails could send recipients to the login page instead of the unsubscribe confirmation page.
### Steps to reproduce
1. Enable multi-company and create a second company `Company B`.
2. Create two websites with different domains, one per company:
- `Website A` on the main company, domain `http://website-a.test`
- `Website B` on `Company B`, domain `http://website-b.test`
3. Set the system parameter `web.base.url` to `http://website-a.test`. System parameters are global, so this value applies to the whole database regardless of the company you switch to.
4. Create a contact and set its `Company` field to `Company B`.
5. In Email Marketing, create a mailing with recipient model `Contact`, target the contact above, pick any template with an unsubscribe link, and send it.
6. Open the email in an incognito window and click the unsubscribe link: you land on the login page instead of the unsubscribe page.
### Cause
Mass mailing builds the unsubscribe link in two steps.
First, each email body is rendered for its recipient. While rendering, relative URLs like `/unsubscribe_from_list` are turned into absolute URLs by prepending a base URL. That base URL comes from the recipient record itself: `recipient.get_base_url()`. The `website` module overrides this so that, when the record has a company, it returns that company's website domain. For a contact in `Company B`, the body ends up with `http://website-b.test/unsubscribe_from_list`.
Second, right before sending, `mail_mail._prepare_outgoing_list` replaces that placeholder URL with a per-recipient signed URL pointing to `/confirm_unsubscribe`. It does this by plain string replacement: it looks for `{base_url}/unsubscribe_from_list` in the body and swaps it. The `base_url` used here came from `self.mailing_id.get_base_url()`. A mailing has no company, so its base URL falls back to the global `web.base.url`, which in our setup is `http://website-a.test`.
The two base URLs no longer match. The body contains the website B URL, but the replacement code searches for the website A URL. The search fails, the placeholder stays in the email, and the recipient clicks a link to `/unsubscribe_from_list`. That route only redirects to `/mailing/my`, which requires being logged in, so the user lands on the login page.
### Fix
Compute the base URL from the recipient record (the same record used when rendering the body) instead of the mailing. The two URLs then agree and the replacement works. Fall back to the mailing's base URL if there is no recipient model on the mail.
opw-4914203
Forward-Port-Of: odoo/odoo#273190
Forward-Port-Of: odoo/odoo#2640553 changes
Resolved issues and error corrections
This update adjusts a test in the Mexican electronic invoicing feature so it works whether the accounting app is installed or not. It prevents false failures in automated testing when a payment is shown as "in_payment" instead of "paid".
Original PR description
If accountant is installed, payment state of unreconciled payment switch from 'paid' to 'in_payment'. Not having accountant break the test. runbot-939445 Forward-Port-Of: odoo/enterprise#121113
The email shown on signature certificates is now taken from the applicant’s own signer information instead of a fallback value. This ensures the certificate displays the correct contact details when recruitment offers are signed.
Original PR description
When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed. ### **Steps to Reproduce:** 1) Install sign, recruitment,…
When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed. ### **Steps to Reproduce:** 1) Install sign, recruitment, hr_contract_salary 2) Create an new application and add basic detail like name and email as (path and `path@test.com`) 3) Generate offer and sign with all the required signer(applicant and Marc Demo). 4) Open the application form view and open the certificate. ### **Observed Behavior:** Email is not set correctly in the generated certificate (appearing as `john@example.com`). ### **Expected Behavior:** The email of the applicant should be correctly set(e.g as `path@test.com`) ### **Root Cause:** When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed. [1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54 [2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59 ### **Fix:** Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time. opw-6280170 Forward-Port-Of: odoo/enterprise#120566
This change fixes a test issue in the Swedish bank payment setup that appeared after an earlier update to how payment details are generated. It ensures the test suite stays reliable when two related accounting add-ons are used together, without changing the intended business behavior.
Original PR description
Here https://github.com/odoo/enterprise/pull/114662 we changed the way the CdtrAgt node is used in the SEPA XML file for Sweden. But this change broke a test when both account_iso20022 & l10n_se_bban are installed, leading to a Non-expected child error. This commit skip the failling test if l10n_se_bban is installed, and add a new one to replace it. runbot-938366 runbot-938367 Forward-Port-Of: odoo/enterprise#121485
7 changes
Enhancements to existing features
The shipping setting formerly called "Batch Shipping" has been renamed to "Multicollo". This makes the wording match Sendcloud’s own terminology and helps avoid confusion for users configuring delivery options.
Original PR description
In order to avoid confusion for the customer, "Use Batch Shipping" was renamed to "Use Multicollo".This way it is consistent with the terminology used by Sendcloud. task-6048477
When the Shopee connector was introduced, Shopee documented `buyer_user_id` as an int32. We therefore store it in an `Integer` field, which maps to a PostgreSQL int32 column. However, feedback showed that Shopee can send ids exceeding the int32 bounds, leading to a traceback when creating new contacts. Shopee has since updated their documentation to confirm the field is actually an int64. This commit changes the `shopee_buyer_identifier` field type to be `Char` and cleans the stable workar
Original PR description
When the Shopee connector was introduced, Shopee documented `buyer_user_id` as an int32. We therefore store it in an `Integer` field, which maps to a PostgreSQL int32 column. However, feedback showed that Shopee can send ids exceeding the int32 bounds, leading to a traceback when creating new contacts. Shopee has since updated their documentation to confirm the field is actually an int64. This commit changes the `shopee_buyer_identifier` field type to be `Char` and cleans the stable workaround. opw-6325948 See also: - stable: https://github.com/odoo/enterprise/pull/121498 - upgrade: https://github.com/odoo/upgrade/pull/10578
For an accountant, the dmfa report is too detailed, he needs a grouped summary. task: 6307733
Original PR description
For an accountant, the dmfa report is too detailed, he needs a grouped summary. task: 6307733
Enable testing of DIMONA declarations without making actual API calls to ONSS by using the sandbox environment in the settings. Go to Payroll → Reporting → Create Declarations From JSON. Here you can create a declaration in the same format received from the government. You can also go to Payroll → Reporting → DIMONA and create any DIMONA declaration without sending real API calls. Create an employee and click the Check DIMONA button. A wizard will appear, allowing you to enter the fake respon
Original PR description
Enable testing of DIMONA declarations without making actual API calls to ONSS by using the sandbox environment in the settings. Go to Payroll → Reporting → Create Declarations From JSON. Here you can create a declaration in the same format received from the government. You can also go to Payroll → Reporting → DIMONA and create any DIMONA declaration without sending real API calls. Create an employee and click the Check DIMONA button. A wizard will appear, allowing you to enter the fake response you need. Task Id: 6069261
Resolved issues and error corrections
This update corrects a test in the Mexican electronic invoicing module so it works whether the accounting app is installed or not. It prevents false test failures caused by a payment changing from “paid” to “in payment” in certain setups.
Original PR description
If accountant is installed, payment state of unreconciled payment switch from 'paid' to 'in_payment'. Not having accountant break the test. runbot-939445 Forward-Port-Of: odoo/enterprise#121113
Issue: The `test_overtime_ruleset_flow` tour test was failing because the `amount_rate` field could not be found. Reason: - Couldn't find the amount_rate field as it was located in the Payroll tab and the tour did not navigate to that tab before interacting with the field. - The tour also used some selectors and values that were no longer valid, causing some steps to fail. Fix: - Open the Payroll tab before interacting with the `amount_rate` field. - Set the overtime leave request dur
Original PR description
Issue: The `test_overtime_ruleset_flow` tour test was failing because the `amount_rate` field could not be found. Reason: - Couldn't find the amount_rate field as it was located in the Payroll tab and the tour did not navigate to that tab before interacting with the field. - The tour also used some selectors and values that were no longer valid, causing some steps to fail. Fix: - Open the Payroll tab before interacting with the `amount_rate` field. - Set the overtime leave request duration type to "Custom Hours". - Replace the unavailable "Salary-exempt" employee type with "Employee". - Use the checkbox input selector to interact with the attendance_based field. - Explicitly open the dropdown before clicking on `action_continue` button. - Remove the unnecessary final `action_continue` step.
Code cleanup and technical improvements
The way conversation threads are calculated in the chatter has been refactored. This helps keep message history organized more reliably and prepares the feature for smoother future improvements.
9 changes
Enhancements to existing features
The shipping setting previously called "Use Batch Shipping" has been renamed to "Use Multicollo". This makes the wording match Sendcloud’s terminology and reduces confusion for users when configuring delivery options.
Original PR description
In order to avoid confusion for the customer, "Use Batch Shipping" was renamed to "Use Multicollo".This way it is consistent with the terminology used by Sendcloud. task-6048477
Resolved issues and error corrections
This update relaxes an automated test so it accepts any valid document number format instead of expecting one exact value. It prevents false failures when the document number increases during repeated testing, making the validation more reliable.
Original PR description
**Why the fix:** This step failed from time to time as we did some batch testing on the runbot with the same database, and because of this, the Número de Documento increased, making it SETF990000002 or more. This error existed before 68da209 but by fixing the refund flow in said commit, this error has been appearing way more frequently. As this has already happened a few times in 18.2, it is still the targeted version for this fix. We now use a regex to make sure that we have **Número de Documento: SETF** followed by some numbers, but we do not specify that it should be SETF990000001 anymore. runbot-241997 Forward-Port-Of: odoo/enterprise#121211
This update corrects a test for Mexican electronic invoicing so it works whether the accounting app is installed or not. It matters because payment statuses can now be recognized consistently, preventing false test failures in automation.
Original PR description
If accountant is installed, payment state of unreconciled payment switch from 'paid' to 'in_payment'. Not having accountant break the test. runbot-939445 Forward-Port-Of: odoo/enterprise#121113
When a business card is scanned, the city information is now imported correctly along with the other contact details. This makes newly created or updated contacts more complete and saves users from entering the city manually.
Original PR description
Previously, when user scans any business card, every information was fetched except for the city name. After this commit the city field will be properly fetched. task-6332914 Forward-Port-Of: odoo/enterprise#121766
When users choose documents to attach or link, the extra action buttons now stay hidden in that selection dialog. This makes the interface less cluttered and helps prevent confusion while picking documents.
Original PR description
When selecting documents for attachment/link, control panel actions were displayed upon selection. The document selection dialog uses the secondary documents view introduced in: https://github.com/odoo/enterprise/pull/89030/changes/f93c159c106d1dde70910ec590f8739e549b19cf Several document management actions were already hidden through the `documents_view_secondary` context, but `DocumentsAction` was still displayed upon selection. Hide `DocumentsAction` in the secondary view. Task-6236888
The Depreciation Schedule report now leaves the account code blank when that information is not available, instead of showing the word “False”. This makes the report clearer and avoids confusing output when multiple companies are selected.
Original PR description
The issue is occur, when multiple companies are selected and the Depreciation Schedule report is opened, report correctly displays the account code for the company selected as the root company.…
The issue is occur, when multiple companies are selected and the Depreciation Schedule report is opened, report correctly displays the account code for the company selected as the root company. However for the other selected companies, the account code is displayed as False To avoid displaying False in the report changed the behavior to pass a null value whenever the account code is not available. For more details, please refer to the attached video. Root Cause The issue occurs because the code field is set to `False` [here](https://github.com/odoo/odoo/blob/ff64328283ee3bcc361fa0604bd4b9da8e62e803/addons/account/models/account_account.py#L337) for companies that are not considered the root company. As a result the report directly displays False instead of leaving the field null Steps to Reproduce 1.create a demo database in 19.0 2. Create two assets, each belonging to a different company. 3. Open the Depreciation Schedule report. 4. Select the first company, then select the second company as well. 5. Notice that the account code is displayed correctly for the root company, while `False` is shown for the other company. OPW-6239737 UPG-4196503 with out fix <img width="1852" height="579" alt="image" src="https://github.com/user-attachments/assets/b99f343d-b624-4d95-b826-6afdd2ebaa4c" /> with fix <img width="1912" height="731" alt="image" src="https://github.com/user-attachments/assets/19112a08-1958-496d-868f-a4091a745842" /> see video https://github.com/user-attachments/assets/ec51bb47-6c64-4cee-b484-7a359ed36ee0
The Journal Audit report now generates PDFs without an extra blank page at the end when certain summary content is missing. This makes the printed report cleaner and avoids confusion for users reviewing or sharing it.
Original PR description
Steps to reproduce: 1. Set the active company as My Company (san francisco) 2. Navigate to Accounting > Review > Journal Audit 3. Remove all journals from the report except Bank and Misc. 4. Use the PDF action button to print the report. 5. The last page of the report is completely empty. https://drive.google.com/file/d/1otpniJgt1UNCe2hrUBwqIK58dGuXpu8T/view?usp=sharing This commit ensures that the Journal Audit report does not have blank pages when the global tax summary section is not present. It uses some features of QWeb outlined in the following docs article: https://www.odoo.com/documentation/19.0/developer/reference/frontend/qweb.html#loops opw-6224670
## **Issue:** When validating a delivery, users with Sales: Own Documents Only and Inventory Administrator access rights can encounter an access error if the delivery belongs to a sale order owned by another salesperson. ## **Steps to reproduce:** - Install sale_subscription_stock. - Create a user with Sales: Own Documents Only and Inventory Administrator access rights. - Create a sale order as another user. - Validate the delivery with the restricted user. ## **Solution:** During _a
Original PR description
## **Issue:** When validating a delivery, users with Sales: Own Documents Only and Inventory Administrator access rights can encounter an access error if the delivery belongs to a sale order owned by…
## **Issue:** When validating a delivery, users with Sales: Own Documents Only and Inventory Administrator access rights can encounter an access error if the delivery belongs to a sale order owned by another salesperson. ## **Steps to reproduce:** - Install sale_subscription_stock. - Create a user with Sales: Own Documents Only and Inventory Administrator access rights. - Create a sale order as another user. - Validate the delivery with the restricted user. ## **Solution:** During _action_done(), [This line](https://github.com/odoo/enterprise/blob/19.0/sale_subscription_stock/models/stock_picking.py#L45) is checking subscription_state. Since the user does not have read access to the sale order, reading this field raises an access error and prevents the delivery from being validated. As the method only needs to read the subscription state, access the field with sudo() to avoid the unnecessary access error while preserving the existing business logic. Runbot Video : [Video](https://drive.google.com/file/d/1d7U2jTCxaaVk2YJcy3bi2SlYuT-yXMsu/view?usp=drive_link) OPW - 6295712
Steps to reproduce =================== - Install documents_hr. - Log in with admin. - Create a new company `Test`. - Go to Document and choose the new company (top right). - Go to `My Drive`: a folder named `Employees - Test` has been created. This new folder should be created in the `Company` root instead of the `My Drive,` which will hold all the employee folders. Technical =========== When the main employee folder is created via `_generate_employee_documents_main_folders` `ow
Original PR description
Steps to reproduce =================== - Install documents_hr. - Log in with admin. - Create a new company `Test`. - Go to Document and choose the new company (top right). - Go to `My Drive`: a folder named `Employees - Test` has been created. This new folder should be created in the `Company` root instead of the `My Drive,` which will hold all the employee folders. Technical =========== When the main employee folder is created via `_generate_employee_documents_main_folders` `owner_id` falls back to the current user, which leads to computing the `user_folder_id` as `My drive,` and so that's why the newly created folder starts appearing there instead of the `Company` root. This PR addresses the issue and sets the `owner_id` to False, which leads to show the main employee folder in the company root. Task-6267352
7 changes
Enhancements to existing features
The customer-facing label “Use Batch Shipping” has been renamed to “Use Multicollo” in the Sendcloud delivery settings. This makes the wording clearer and aligns it with Sendcloud’s own terminology, reducing confusion for users.
Original PR description
In order to avoid confusion for the customer, "Use Batch Shipping" was renamed to "Use Multicollo".This way it is consistent with the terminology used by Sendcloud. task-6048477
Event template questions can now be reordered by dragging and dropping them in the Questions page. This brings the template experience in line with regular events and makes it easier to organize questions in the desired order.
Original PR description
In the even template, on the questions page, we can't drag and change the order of the questions. To fix it, we'll add the sequence field with handle widget to event.type questions list view to enable drag-and-drop reordering matching the behavir in event.event. Steps to reproduce: 1.Go to event templates 2.Select any templates 3.Go to questions page 4.We can't drag and drop questions opw-6260478
Resolved issues and error corrections
This update adjusts the order of elements in the Mexican SAT XML trial balance report so it matches the structure recommended by the tax authority. The report content remains the same, but the generated file now follows the expected layout more closely, reducing the risk of compliance or validation issues.
Original PR description
**Steps to reproduce:** - Install the `l10n_mx_reports` module and switch to a Mexican company. - Navigate to Accounting > Reporting > Trial Balance. - From the dropdown menu, click `SAT (XML)`. -…
**Steps to reproduce:** - Install the `l10n_mx_reports` module and switch to a Mexican company. - Navigate to Accounting > Reporting > Trial Balance. - From the dropdown menu, click `SAT (XML)`. - Open the generated XML file and inspect the `<BCE:Ctas>` nodes. **Observation:** - The generated XML uses the following attribute order: `Debe > NumCta > Haber > SaldoFin > SaldoIni` - However, the SAT-recommended structure is: `NumCta > SaldoIni > Debe > Haber > SaldoFin` **Root Cause:** At [1], the attributes of the `<BCE:Ctas>` node are defined in an order that differs from the SAT-recommended structure. While the XML remains valid, the generated report does not match the layout recommended by the Mexican government specification. **Fix:** This commit reorders the `<BCE:Ctas>` attributes to follow the SAT-recommended structure, aligning the generated XML with the behavior introduced at [2] for `saas-19.3`. backport-of: https://github.com/odoo/enterprise/pull/115374 [1]: https://github.com/odoo/enterprise/blob/cb9c19272309d793379fa4d23145162f72fa5552/l10n_mx_reports/data/templates/cfdibalance.xml#L15-L20 [2]: https://github.com/odoo/enterprise/blob/acf0929a88ec788aecd44f6b4c647e468dc0a319/l10n_mx_reports/data/templates/cfdibalance.xml#L17-L22 opw-6297711 Forward-Port-Of: odoo/enterprise#121440
The VAT field now shows a clearer placeholder to help users know what to enter when VAT does not apply. This reduces confusion and makes company and partner setup easier and more consistent.
Original PR description
Issue: - The placeholder on the VAT field is not proper - The user will be confused about what to write in the VAT field when it is not applicable Fix: - Update the placeholder on the VAT filed - '/' means VAT is not applicable Impact: - improve the user experience so that users know to write '/' when VAT is not applicable Task: 5005896
This update fixes an issue where pages could stretch wider than the screen and create unwanted horizontal scrolling. It improves how content fits on smaller or flexible layouts, making the interface more stable and easier to use without changing features.
Original PR description
Description of the issue/feature this PR addresses: **This PR addresses the horizontal scroll and layout responsiveness issues reported in [GitHub issue #222577](https://github.com/odoo/odoo/issues/222577).** - -Added overflow-x: hidden; to html, body, and #wrapwrap to prevent unwanted horizontal scrolling across the app. - Added max-width: 100%; and box-sizing: border-box; to the children of #wrapwrap to prevent content overflow. - Set width: 100%; and min-width: 0; on the main content section to ensure proper scaling and prevent flexbox overflow issues. - These are minor CSS/SCSS changes aimed at improving frontend layout behavior without breaking any existing features. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change adds an extra step to properly close a popover during automated testing. It prevents a rare cleanup error that could make test runs fail intermittently, improving overall reliability without changing user-facing behavior.
Original PR description
Add an extra step to close the popover and prevent the `Component is destroyed` error[1], which can happen during hoots cleanup, similar to the issue we see when some dialogs perform RPCs as they are being destroyed. [1]: https://runbot.odoo.com/runbot/build/115972540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents a database error in the French PDP process when no start date is available. It makes the update logic handle missing dates safely, improving reliability for companies using this local feature.
Original PR description
Fixes _force_update_l10n_fr_f10_moves(). It would create a SQL query that compares a date to a bool when _pdp_get_flow_10_start_date() returned None.
1 change
Resolved issues and error corrections
Callbacks were changed to use a single shared callback instead of a bunch of callbacks that captured a specific container. Cloudlfare since introduced a change that breaks this change by not making "this" available inside callbacks. We thus go back to the previous implementation that did not rely on implementation details of the external widget. related: 5aa5cf62a9d3f2b0c862b0aab337b22367843fa6
Original PR description
Callbacks were changed to use a single shared callback instead of a bunch of callbacks that captured a specific container. Cloudlfare since introduced a change that breaks this change by not making "this" available inside callbacks. We thus go back to the previous implementation that did not rely on implementation details of the external widget. related: 5aa5cf62a9d3f2b0c862b0aab337b22367843fa6