Wednesday, July 1, 2026
37 changes · saas-19.4
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
This change corrects a display label in the accounting interface so it matches the updated wording used elsewhere. It helps keep the product terminology consistent and avoids confusion for users working with reconciliation settings.
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 Forward-Port-Of: odoo/odoo#273339
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
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
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
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 da
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
Currently, an error occurs on an invoice when user selects a payment term and removes the currency. Steps to replicate: - Install account - Turn on multiple currencies - Open invoices. - Create a new invoice - Add a line - Add a customer - Save - Select payment term as `30% Now, Balance 60 Days` - Remove the currency. Error: ``` ValueError: Expected singleton: res.currency() ``` Cause: - This error only occurs when the selected payment term contains at least two due term l
Original PR description
Currently, an error occurs on an invoice when user selects a payment term and removes the currency. Steps to replicate: - Install account - Turn on multiple currencies - Open invoices. - Create a new…
Currently, an error occurs on an invoice when user selects a payment term and removes the currency. Steps to replicate: - Install account - Turn on multiple currencies - Open invoices. - Create a new invoice - Add a line - Add a customer - Save - Select payment term as `30% Now, Balance 60 Days` - Remove the currency. Error: ``` ValueError: Expected singleton: res.currency() ``` Cause: - This error only occurs when the selected payment term contains at least two due term lines [1]. - When the selected payment term has atleast two lines the check [1] assigns `on_balance_line` as false and the `else` block is evaluated where currency being an empty recordset (as the user removed it) causes the error from [line] when trying to perform `round()` on an empty res.currency recordset. Solution: - As the currency is a required field, user will not be able to save the record until a currency is assigned. - Used journal's currency or company's currency as a fallback when computing payment terms if the current currency is empty. [1]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L229 [line]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L240 sentry-7569922293 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272073
**Current behavior before PR,** Computing `main_user_id` of a partner involved filtering active users within a loop. To avoid losing the prefetching, we manually forced all partner users to be kept in the prefetch during each iteration. This caused performance issues as the recordset grew large (e.g., during auto-subscription). **Desired behavior after PR is merged,** All partner users are prefetched and filtered once, removing the need for a repetitive manual prefetch. **Benchmark,*
Original PR description
**Current behavior before PR,** Computing `main_user_id` of a partner involved filtering active users within a loop. To avoid losing the prefetching, we manually forced all partner users to be kept…
**Current behavior before PR,** Computing `main_user_id` of a partner involved filtering active users within a loop. To avoid losing the prefetching, we manually forced all partner users to be kept in the prefetch during each iteration. This caused performance issues as the recordset grew large (e.g., during auto-subscription). **Desired behavior after PR is merged,** All partner users are prefetched and filtered once, removing the need for a repetitive manual prefetch. **Benchmark,** The following observations were recorded when auto-subscribing users to a discuss channel at different scales. The _Before_ and _After_ results represent the max values from three consecutive tests. | Records | Before | After | | :--------| -------: | ---------: | | 3k | ~2.3s | <90ms | | 5k | ~3.8s | <160ms | | 10k | ~7.6s | <300ms | part of task-6116079 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271549
Issue: ---------------------------------------- When changing multiple times the hours of a slot to include out-of-schedule time. Steps to reproduce: ---------------------------------------- - Have planning_field_service installed - Have an employee with a schedule from 7am to 3pm - In planning view, create a new slot for this employee from 7am to 3pm (8h) - Change the starting hour to 6am (8h + 1h of break time) - Change it back to 7am - The slot shows 7h07 of allocated hours and 53
Original PR description
Issue: ---------------------------------------- When changing multiple times the hours of a slot to include out-of-schedule time. Steps to reproduce: ---------------------------------------- - Have…
Issue: ---------------------------------------- When changing multiple times the hours of a slot to include out-of-schedule time. Steps to reproduce: ---------------------------------------- - Have planning_field_service installed - Have an employee with a schedule from 7am to 3pm - In planning view, create a new slot for this employee from 7am to 3pm (8h) - Change the starting hour to 6am (8h + 1h of break time) - Change it back to 7am - The slot shows 7h07 of allocated hours and 53 minutes of break time Cause: ---------------------------------------- Since 8ca9faabfdf7d15883ba52da47bd8c562cf601de the compute of `allocated_percentage` is overriden in `planning_field_service`. The new compute uses `break_time` to recompute `allocated_percentage`. `break_time` is the not work time over the whole duration of the slot, including hours out of schedule. But the definition of `allocated_percentage` in `planning` is: the percentage of slot hours in schedule which are actually worked. So when changing the start to 6am `allocated_percentage` is still supposed ot be 100% because the employee is working 100% of the hours he is supposed to work considering its schedule. With the actual code `allocated_percentage` is actually computed as 8/9 = 0.88888... because it will take into account the hours out of schedule. As `allocated_percentage` is not recomputed if `allocated_hours` or `break_time` aren't modified by the user. It is then used [here](https://github.com/odoo/enterprise/blob/ae5008bdaf1b87269083f82280c7df44390129ff/planning/models/planning_slot.py#L2865-L2867) to compute the allocated_hours and the number of hours in schedule is divided base onthe percentage. Solution: ---------------------------------------- We only consider the hours in schedule to recompute `allocated_percentage`. `allocated_percentage` was used in `_onchange_break_time()` to get the previous ratio and calculate the allocated hours from which we deduct the break time. We cannot do this now so we also need to compute the working hours. ----------------------------------------- # [FIX] planning_field_service: handle input of negative break_time Issue: ---------------------------------------- When inputting negative break_time for a slot, it's possible to get a traceback. Steps to reproduce: ---------------------------------------- - Have planning_field_service installed - Have an employee with a schedule from 7am to 3pm - In planning view, create a new slot for this employee from 7am to 3pm (8h) - Input 9h of break time - Input -1h of break time - Traceback Cause: ---------------------------------------- When `slot.allocated_hours` is 0 and we input a negative value in `break_time`, the code in `_onchange_break_time()` will give `allocated_hours` the positive value of `break_time` making them opposite. Then in [`_compute_allocated_percentage()`](https://github.com/odoo/enterprise/blob/188dcc5078be7c7fee1a52f86505144d3b6309cf/planning_field_service/models/planning_slot.py#L98) we divide by their sum, which equals 0. Solution: ---------------------------------------- We compute the divider part and check if it's zero in `_compute_allocated_percentage()`. Also add a `max()` in `_onchange_break_time()` to convert the negative break time in allocated hours and resets `break_time` to zero. This ensures the same behavior as inputting negative values in `allocated_hours`. opw-6273559 Forward-Port-Of: odoo/enterprise#122209 Forward-Port-Of: odoo/enterprise#121168
The following error is raised in the POS when paying with an Adyen terminal: ``` TypeError: Cannot read properties of undefined (reading 'uuid') at Proxy.handleAdyenStatusResponse ``` Adyen delivers webhook notifications at-least-once, so the ADYEN_LATEST_RESPONSE event can fire several times for a single payment, running handleAdyenStatusResponse concurrently. After the await on get_latest_adyen_status, a previous (duplicate) notification may already have resolved the payment line, so ge
Original PR description
The following error is raised in the POS when paying with an Adyen terminal: ``` TypeError: Cannot read properties of undefined (reading 'uuid') at Proxy.handleAdyenStatusResponse ``` Adyen delivers…
The following error is raised in the POS when paying with an Adyen terminal: ``` TypeError: Cannot read properties of undefined (reading 'uuid') at Proxy.handleAdyenStatusResponse ``` Adyen delivers webhook notifications at-least-once, so the ADYEN_LATEST_RESPONSE event can fire several times for a single payment, running handleAdyenStatusResponse concurrently. After the await on get_latest_adyen_status, a previous (duplicate) notification may already have resolved the payment line, so getPendingPaymentLine no longer returns it and the subsequent line.uuid dereference crashes. opw-6237987 patched the same root cause on a single line by adding an optional chaining operator in isPaymentSuccessful, which only moved the crash to the next dereference. Fetch the pending line once at the start of handleAdyenStatusResponse and bail out when it is gone, so every dereference below is safe. The same guard is added to the remaining branches of _adyen_handle_response for consistency with the existing Reject branch. opw-6237987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271181 Forward-Port-Of: odoo/odoo#269720
Images placed inside device-style shapes are now cropped to match the shape’s proportions instead of always being forced into a square crop first. This reduces unnecessary cutting of the image and makes previews look more natural and accurate.
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 name was previously left out even though the other details were captured. This fix makes the city field import correctly, so contact records are 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
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