Daily updates from Odoo
Wednesday, August 5, 2026
68 changes · saas-19.4
Resolved issues and error corrections
Bank transaction imports now ignore archived bank account records when automatically identifying the partner. This prevents old or inactive bank details from assigning transactions to the wrong partner, improving reconciliation accuracy.
Original PR description
Steps to reproduce: - Have a partner with a bank account, then archive the res.partner.bank record (keep the partner active). - Import or create a bank transaction (e.g. via bank sync) whose account number matches that archived bank account, and whose label/payment_ref would otherwise match a reconciliation model for a different partner. - Let the transaction go through automatic partner retrieval. => The archived bank account's partner is assigned, even though a normal manual entry (which skips the account-number match) would have used the label instead. Cause of the issue: `AccountBankStatementLine._retrieve_partner()` matches statement lines to partners in batch using raw SQL joining `res_partner_bank`. The query's WHERE clause filters out archived partners (`AND partner.active`) but never filters `res_partner_bank.active`. opw-6340479 Forward-Port-Of: odoo/enterprise#124748 Forward-Port-Of: odoo/enterprise#124537
The Helpdesk unanswered filter now treats automatic acknowledgement messages as already answered. This prevents newly submitted website tickets from being incorrectly flagged as needing a customer response, helping teams focus on genuinely unanswered conversations.
Original PR description
Steps to reproduce: --------- - install website_helpdesk - set an email address on the company partner if it is empty ( it is empty in a database without demo data). - generate a ticket from the website. - apply the Unanswered filter. Issue: ------ system generated acknowledgement message is considered an unanswered customer reply. Fix: -------- system generated acknowledgement messages are now considered answered. task-5138678 Forward-Port-Of: odoo/enterprise#125977
This change corrects test setup data for Belgian POS blackbox modules so automated checks no longer fail with repeated component errors. It improves reliability of internal validation without changing business workflows or user-facing behavior.
Original PR description
### Issue: During RunBot single module tests, some tests caused an error: `Maximum call stack size exceeded` after repeated: `[Owl] Unhandled error. Destroying the root component` ### Affected tests:…
### Issue:
During RunBot single module tests, some tests caused an error: `Maximum call stack size exceeded` after repeated: `[Owl] Unhandled error. Destroying the root component`
### Affected tests:
- `sign_money_in_out.called at right time`
- `sign_drawer_open.called at right time`
- `sign_work_in.called when opening register, setting & resetting cashier`
- `sign_work_in_employee.called from login screen (closed session)`
### Cause:
The tests passed `dialogData: {}` to the component env But `dialogData` must at least define `scrollToOrigin`, which is called automatically in `onWillDestroy`:
https://github.com/odoo/odoo/blob/0042e83fb60353a49d4759a79a3ceb0eee6f74b6/addons/web/static/src/core/dialog/dialog.js#L122-L126
Calling `scrollToOrigin()` on an empty object raises a `TypeError`, which Owl catches and re-throws repeatedly until the call stack is exceeded
The full `dialogData` shape is defined in `makeDialogMockEnv`: https://github.com/odoo/odoo/blob/62c540d96fc49d9e74d8c660019754651cb0e085/addons/web/static/tests/_framework/env_test_helpers.js#L151-L161
### Steps to reproduce:
- Install `l10n_be_pos_blackbox` (fresh `-i`, or `-u` with `web` on an existing db)
- Run the tests in MobileWebSuite
Before the fix, the errors are triggered
runbot-941232
Forward-Port-Of: odoo/enterprise#125474The aged payable and receivable report drill-down now hides fully paid invoices and bills, so users only see items that were actually outstanding. It also respects the selected report date, improving accuracy for historical balance reviews.
Original PR description
Steps to Reproduce: 1. Create a vendor/customer with multiple bills/invoices. 2. Fully pay one or more, leaving at least one still open for the same partner. 3. Open Accounting > Reporting > Partner…
Steps to Reproduce:
1. Create a vendor/customer with multiple bills/invoices.
2. Fully pay one or more, leaving at least one still open for the same partner.
3. Open Accounting > Reporting > Partner Reports > Aged Payable/Receivable.
4. Set to any date and click into an aging bucket for that partner.
Issue:
The drill-down list shows fully settled bills (residual = 0.00) alongside genuinely outstanding ones. Only surfaces when the partner has at least one open balance — if everything is paid, there is no bucket to click into.
Root Cause:
aged_partner_balance_audit builds the drill-down domain filtering only by reconcile flag, journal type, and date range — never checking residual. Additionally it completely overwrites the XML action domain (account.action_amounts_to_settle) which already had ('amount_residual', '!=', 0), losing that protection entirely.
Fix:
Added ('residual_at_date', '!=', 0) to the domain in aged_partner_balance_audit and set recon_limit in the action context so residual_at_date computes as of the report's 'as of' date rather than today's value:
action['context'] = {
'recon_limit': options['date']['date_to'],
}
Without recon_limit, residual_at_date falls back to amount_residual (today's value) which incorrectly excludes bills that were genuinely open on the report date but paid after it.
Result:
The drill-down now correctly shows only genuinely outstanding items regardless of whether the report is run as of today or a historical date.
opw 6333699
Forward-Port-Of: odoo/enterprise#126021Fixed an issue that prevented users from confirming multiple Brazilian customer invoices at once when Avalara Brazil tax mapping was enabled. This removes an error during batch validation, allowing finance teams to process invoices together as expected.
Original PR description
**_Steps to reproduce:_** * Install `l10n_br_avatax` and configure Avalara Brazil. * Create at least two customer invoices. * Ensure the fiscal position is set to **Automatic Tax Mapping (Avalara…
**_Steps to reproduce:_** * Install `l10n_br_avatax` and configure Avalara Brazil. * Create at least two customer invoices. * Ensure the fiscal position is set to **Automatic Tax Mapping (Avalara Brazil)**. * Select the invoices and click **Action → Confirm Entries**. **_Observed behavior:_** * A traceback is raised with `ValueError: Expected singleton: account.move(...)` and the invoices cannot be validated. **_Cause:_** * During tax extraction, `_extract_tax_values_from_l10n_br_avatax_detail` accesses `self.invoice_filter_type_domain` while `self` may contain multiple `account.move` records. * Accessing `invoice_filter_type_domain` on a multi-recordset raises an `Expected singleton` error, preventing the validation of multiple invoices. **_Fix:_** * Build the returned tax values by iterating over each invoice in the recordset and using the corresponding `invoice_filter_type_domain`. * This ensures `_extract_tax_values_from_l10n_br_avatax_detail` correctly handles multiple invoices during validation without raising a singleton error. opw-6334761 Forward-Port-Of: odoo/enterprise#126437 Forward-Port-Of: odoo/enterprise#124993
This fix prevents appraisal survey records from failing when the allowed survey type list is empty or unavailable. It helps ensure appraisal-related survey configuration continues to load reliably, including during upgrades.
Original PR description
Avoid a TypeError in _compute_allowed_survey_types when allowed_survey_types is False by falling back to an empty list before unpacking and appending the appraisal survey type.
```py
File "/home/odoo/src/enterprise/saas-19.3/hr_appraisal_survey/models/survey_survey.py", line 33, in _compute_allowed_survey_types
survey.allowed_survey_types = [*survey.allowed_survey_types, 'appraisal']
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Value after * must be an iterable, not bool
```
Ref: https://github.com/odoo/odoo/pull/268125
Bug introduced in: https://github.com/odoo/enterprise/commit/896f54532338b07265722cb4a4161131d408f58c
upg-[4458975](https://upgrade.odoo.com/odoo/request/4458975?debug=1)
Forward-Port-Of: odoo/enterprise#124417The manufacturing planning tests were adjusted to match how monthly demand now counts the full current day. This helps ensure replenishment planned later on the same day is correctly reflected in forecast suggestions, reducing the risk of planning validation errors.
Original PR description
Updated the forecast suggestion test expectations after monthly demand was updated to count the full current day, so same-day orderpoint replenishment moves scheduled later in the day are also included Community PR: odoo/odoo#262435 TaskID-5490137 Forward-Port-Of: odoo/enterprise#126578 Forward-Port-Of: odoo/enterprise#115944
Rental orders that use a custom make-to-order buying route now correctly generate the expected return transfer alongside the delivery and purchase. This prevents missing return logistics for rental products and helps teams keep rental stock movements accurate.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps Routes and rental transfers - Unarchive the MTO route - Create a rental product P with a buy route and a set vendor - Create a rental…
### Steps to reproduce: - In the settings enable: Multi-Steps Routes and rental transfers - Unarchive the MTO route - Create a rental product P with a buy route and a set vendor - Create a rental order for 1 x P and set the the MTO route on the sol - Confirm the order #### > The delivery as well as the purchase for 1 unit of P was generated but the return was not. ### Cause of the issue: The procurement generated to handle both the delivery and the return rental picking are handled by the `_create_procurements`: https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/sale_stock_renting/models/sale_order_line.py#L353-L374 The `route_ids` set and used is the `mto_route` set on the sol: https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L415-L422 https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L282-L297 However, in the present case, the mto route does not contain any rule with a relevant `location_src_id` in the rental location so that the return will not be generated. opw-6361322 Forward-Port-Of: odoo/enterprise#126410 Forward-Port-Of: odoo/enterprise#124097
Electronic invoices for Peru now use the address structure required by SUNAT’s current UBL 2.1 standard. This helps invoices pass official validation by correctly formatting districts and urban subdivisions.
Original PR description
Update electronic invoicing address nodes to align with current SUNAT requirements. This transitions the geographic data formatting from the legacy UBL 2.0 schema to the standard UBL 2.1 specification, ensuring proper structural validation for districts and urban subdivisions. Documentation used: https://cpe.sunat.gob.pe/sites/default/files/inline-files/guia+xml+factura+version+2-1+1+0+(2)_0+(2).pdf opw-6282314 Forward-Port-Of: odoo/enterprise#126380 Forward-Port-Of: odoo/enterprise#121390
Users can now generate sample timesheet activity data even when ActivityWatch is connected. This helps teams compare or demonstrate sample entries alongside real activity data without disconnecting the ActivityWatch service.
Original PR description
Before this commit, the Generate Sample Data button only worked when the ActivityWatch server was unavailable. When ActivityWatch was running, users could only load real activity data. After this commit, clicking Generate Sample Data while ActivityWatch is connected injects the generated sample events alongside the real ActivityWatch events, allowing both to be displayed together. task-6373606 Forward-Port-Of: odoo/enterprise#125863 Forward-Port-Of: odoo/enterprise#124981
Users can now duplicate several maintenance requests at once without the system showing an error. This removes an interruption in the maintenance workflow and makes bulk record handling more reliable.
Original PR description
Currently, when a user attempts to duplicate multiple maintenance requests simultaneously, the system throws a ValueError (Expected singleton). This PR fixes that. ### How to reproduce the issue: - Install `mrp_maintenance` module; - Open maintenance request list view; - Select multiple records and try to duplicate them using the Action button; - It will throw a traceback stating a singleton error. ### Expected behavior after PR is merged: Now multiple maintenance requests will be copied without raising any errors. Forward-Port-Of: odoo/enterprise#124255
The planning filters for employees and materials now apply the special open-shift logic only when a shift has no assigned resource. This prevents unrelated assigned shifts from being included or excluded incorrectly, helping planners see more accurate scheduling results.
Original PR description
Before this commit, the domain wrongly assumes that we always search on shifts having no role or a role containing resources of types 'user' or 'material' (1). Additionally to the basic domain which searches on the shifts having resources of types 'user' or 'material' (2). After this commit, we add a condition on domain (1) to only apply it for open shifts (shifts having no resource_id). no-task Forward-Port-Of: odoo/enterprise#126616 Forward-Port-Of: odoo/enterprise#126247
Cancelled Mexican CFDI invoices now reprint with their required fiscal details, including QR codes, digital stamps, and fiscal folio information. This helps businesses keep legally relevant invoice records complete even after cancellation.
Original PR description
### Issue before this commit: When an invoice's CFDI cancellation request is confirmed (state moves from sent to cancel), reprinting the invoice PDF no longer displays the fiscal information (QR…
### Issue before this commit: When an invoice's CFDI cancellation request is confirmed (state moves from sent to cancel), reprinting the invoice PDF no longer displays the fiscal information (QR code, digital stamps, fiscal folio/UUID, etc.), even though the signed CFDI attachment is still present on the invoice. ### Steps to reproduce the issue: 1. Download Accounting and l10n_mx 2. Create an invoice and send it to CFDI 3. Select 'Request for cancel' 4. Wait and click retry button in the CFDI tab until the invoice is marked as cancelled 5. Print the invoice again 6. See PDF does not show fiscal information (QR, fiscal folio, etc.) ### Cause of the issue: https://github.com/odoo/enterprise/blob/f6c94d4ca3ef4211a5ab00bf0b39f6a7675c8f79/l10n_mx_edi/models/account_move.py#L904-L909 Once the CFDI is cancelled, the computed field switches to 'cancel', so the condition fails and the method falls back to the generic account.report_invoice_document template, which has no knowledge of CFDI fiscal fields. ### Reason to introduce the fix: A cancelled CFDI invoice is still a legally relevant fiscal document in Mexico and must be reprintable with its fiscal data intact (to prove it was issued and later cancelled). The fix extends the condition to also cover the 'cancel' state, ensuring the CFDI-specific report template is used whenever a valid attachment exists, regardless of whether the CFDI is currently signed or cancelled. opw-6393656 Forward-Port-Of: odoo/enterprise#126466
The timesheet assistant now shows the correct color indicator when comparing recorded time with expected working hours. It highlights totals in green only when hours are below expected time and avoids coloring flexible-hour cases, reducing confusion for users reviewing timesheets.
Original PR description
Fix the wrong color selection of total hours on the timesheet assistant page before: green if total time > working hours after: - green if total time < working hours - no color for flexible hours --- task-6409938 Forward-Port-Of: odoo/enterprise#125915 Forward-Port-Of: odoo/enterprise#125177
The Italian balance sheet reports now use corrected field names in the Italian language version. This improves readability and reduces confusion for users reviewing statutory financial reports in Italy.
Original PR description
### Steps to reproduce the issue: 1. Download Accounting and l10n_it 2. Install and switch to italian language 3. Go to Balance Sheets and select Balance Sheet (IT) 4. Some words are not correct [Here]( https://docs.google.com/spreadsheets/d/1-w83oAHTxDRIi-W_VSJiscNclw-yijzQUHOgMnTq7jE/edit?gid=0#gid=0) the wrong fields with their correct translations. opw-6424609 Forward-Port-Of: odoo/enterprise#126253
Attachments added to employee records and leave requests now create documents in the correct employee-related folders instead of the general Employees root folder. Sick leave attachments also reliably create the expected document, making HR document organization more consistent and easier to manage.
Original PR description
Before this commit, when adding an attachment to a leave or a employee version the mixin was configured to create the document in the root folder of Employees which was not very convenient. In addition, when creating a Sick leave with an attachment, no document was ever created. This commit fix both those bugs. Task-6095811 Forward-Port-Of: odoo/enterprise#121942 Forward-Port-Of: odoo/enterprise#112993
The appointment booking page no longer shows empty months when a minimum booking delay pushes the first available slot into a later month. This ensures customers can reliably see and choose valid appointment times when navigating the calendar.
Original PR description
On the website booking page, moving to a later month can show no available times even though the weekly schedule clearly has some. ### Steps to reproduce - Install Appointments. - Create a recurring…
On the website booking page, moving to a later month can show no available times even though the weekly schedule clearly has some. ### Steps to reproduce - Install Appointments. - Create a recurring appointment type available on a single weekday (say Monday), with a user or resource assigned and a date range spanning a few months. - Set `Allow bookings at least` (the minimum booking delay) so that the current time plus the delay falls after this month's last Monday. Close to the end of a month, a day or two of delay is enough. - Open the booking page: the first month shown is next month, because the delay skipped this month's last slot. - Click the arrow to move forward one more month. => the reached month shows no slots, even though it has Monday availability. ### Cause The calendar computes availability one month at a time. It builds a list of months, and the browser refers to each month by its position in that list (0, 1, 2, ...). Clicking the next arrow sends that position back to the server. The server turns the position into a real month by adding it to a start month, which it computes as `now` plus the minimum booking delay. But the list shown to the visitor does not start there: it starts at the month of the first slot that can actually be booked. These two are usually the same, so the position lines up. They stop matching when the delay moves the earliest bookable time past the last availability day of the current month. In the steps above, `now` plus the delay lands after the month's last Monday, so the first bookable slot is a Monday in the next month. The visitor's list then starts one month later than the server assumes, every position points one month too early, and the server computes availability for a month the visitor is not looking at. The reached month comes back empty. ### Fix Count the visitor's month position from the same first bookable slot the list starts from, instead of from `now` plus the delay. The navigation offset is passed to the slot computation and resolved against that slot, so the filled month always matches the month the visitor sees. opw-6353569 Forward-Port-Of: odoo/enterprise#123994 Forward-Port-Of: odoo/enterprise#122494
Bank statement lines opened from in-app notifications now show the chatter panel. This ensures users can see the comment or mention that brought them to the record, improving follow-up on reconciliation discussions.
Original PR description
Problem: When navigating to a bank statement line through a notification, the chatter doesn't appear. Steps to reproduce: 1. Set in app notifications for one of the users 2. Open Accounting > Bank > To Reconcile 3. Select any bank statement line 4. Tag the user from step 1 in a comment 5. Log in as that user 6. Check notifications and click the new notification 7. Notice how the chatter does not appear on the bank statement line after navigating there Cause: The chatter was not enabled on the bank statement line form view. opw-6410186 Forward-Port-Of: odoo/enterprise#125777
Date and datetime fields now disappear from the pivot popup once all available time breakdowns have already been used. This prevents users from adding duplicate entries, avoiding confusing drag-and-drop behavior and keeping spreadsheet pivots consistent.
Original PR description
Current behavior before PR: - Date and datetime fields remained visible even when all their granularities were already added to the pivot. - Users could add the same field with the same granularity multiple times, creating duplicate IDs and causing unexpected drag and drop behavior. Desired behavior after PR is merged: - Hide date and datetime fields from the popup once all available granularities have already been added to the pivot. - This prevents duplicate field IDs and keeps the popup behavior consistent with spreadsheet pivots during drag-and-drop. Task: [6295794](https://www.odoo.com/odoo/project/2328/tasks/6295794) Forward-Port-Of: odoo/enterprise#126772 Forward-Port-Of: odoo/enterprise#123280
Accrual list reports now remember the user's selected "As of" date when they open a line and return using the breadcrumb. This prevents reports from unexpectedly reverting to today's date, helping accounting teams keep their review context and avoid confusion.
Original PR description
Issue: In accrual list reports (Billed Not Received / Invoiced Not Delivered), selecting an "As of" date, opening a line, and returning with the breadcrumb resets the date filter to the default value…
Issue: In accrual list reports (Billed Not Received / Invoiced Not Delivered), selecting an "As of" date, opening a line, and returning with the breadcrumb resets the date filter to the default value (today's date) Steps to reproduce: 1) Open an accrual list report ( Accounting > Audit > Purchases > Bill to receive / Billed Not Received OR Invoices to be issues / invoiced Not delivered) 2) Pick any "As of" date 3) Open any row 4) Click breadcrumb to return to the accrual list 5) Observe the "As of" date has been reset to today's date To generate some data you could: create a PO, then upload the bill, validate the receipt, then you'll find it in bills received Cause: `AccrualListController.setup()` always initialized state.date with a fresh default date and did not re-put the previously saved `accrual_entry_date` from restored context https://github.com/odoo/enterprise/blob/899f0d45b2ae1dc4e5e06a2e0acb3d006d12d563/account_reports/static/src/views/accrual_list_controller.js#L10-L16 Although `setDate()` stored the selected date in context, `setup()` overwrote the UI state on controller recreation https://github.com/odoo/enterprise/blob/899f0d45b2ae1dc4e5e06a2e0acb3d006d12d563/account_reports/static/src/views/accrual_list_controller.js#L61-L65 Solution: - Persist `accrual_entry_date` in `AccrualListSearchModel` via `exportState()` / `_importState()`, so the date is restored in search context before the list model loads on breadcrumb navigation. - Initialize the date picker through `setDate()` in `onWillStart()` instead of hardcoding `DateTime.now()` in `setup()`, so restoration and user changes share the same code path. - In `setDate()`, reset grouped list caches (`currentGroups` and `groups`) before `root.load()`, because those caches are not keyed on `accrual_entry_date` and would otherwise show stale vendor groups after a date change or breadcrumb restore. opw-6232263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#126371 Forward-Port-Of: odoo/enterprise#118669
When an order from a closed session is invoiced, a misc reversal move is created to "extract" the order from the session closing entry. When the PoS config uses a currency different from the company currency, posting that reversal move could fail with "The entry is not balanced.", making it impossible to invoice the order. Steps to reproduce: - company in currency A, PoS config in currency B, with a conversion rate producing rounding drift (e.g. 0.4007) - sell a product of 20.0 B + 15% t
Original PR description
When an order from a closed session is invoiced, a misc reversal move is created to "extract" the order from the session closing entry. When the PoS config uses a currency different from the company…
When an order from a closed session is invoiced, a misc reversal move is created to "extract" the order from the session closing entry. When the PoS config uses a currency different from the company currency, posting that reversal move could fail with "The entry is not balanced.", making it impossible to invoice the order. Steps to reproduce: - company in currency A, PoS config in currency B, with a conversion rate producing rounding drift (e.g. 0.4007) - sell a product of 20.0 B + 15% tax (23.0 B), paid by bank, without invoicing - close the session - set a partner on the order and invoice it => UserError: "The entry is not balanced." Cause: in `_prepare_aml_values_list_per_nature`, the product and tax lines each get their balance converted and rounded individually (20.0 * 0.4007 -> 8.01, 3.0 * 0.4007 -> 1.20), while the payment term line was converted from the payment total, without rounding (23.0 * 0.4007 -> 9.2161). Per-line rounding does not distribute over the sum, so the balances could differ by a few cents (8.01 + 1.20 != 9.22) and the move could not be posted. The closing entry has the balancing-account wizard as an escape valve for such differences; the reversal move had none. Fix, following what is done for regular invoices (see `account.move._compute_needed_terms`, where the payment term balance is derived from the sum of the already rounded lines): - round the payment term conversions - put the conversion residual on the last payment term line so the payment terms exactly counterbalance the other lines, but only when the amounts in currency are balanced, so it can only absorb rounding drift - include the cash rounding amounts in the accumulated totals - fix the swapped `amount_currency`/`balance` values when merging two non-split payments on the same receivable account opw-6375309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#279874 Forward-Port-Of: odoo/odoo#275673
Before this commit: The info, 'You can choose how you want us to send your invoices, and with which electronic format.' was never visible because `invoice_edi_format` is always None. After this commit: Update condition from `invoice_edi_format` to `invoice_edi_formats` to make condition correct and will display info if there are multiple invoice_sending_methods and at-least one edi format. Forward-Port-Of: odoo/odoo#278870
Original PR description
Before this commit: The info, 'You can choose how you want us to send your invoices, and with which electronic format.' was never visible because `invoice_edi_format` is always None. After this commit: Update condition from `invoice_edi_format` to `invoice_edi_formats` to make condition correct and will display info if there are multiple invoice_sending_methods and at-least one edi format. Forward-Port-Of: odoo/odoo#278870
Issue: Every change of the selected order makes the PoS call `pos.config.update_customer_display`, which publishes the order on the bus for the customer display paired with this browser. The device uuid identifying that pairing is only generated when the customer display dialog is opened, so a PoS whose customer display was never opened sends `device_uuid: null` and the server publishes on `UPDATE_CUSTOMER_DISPLAY-null`, a channel nobody can listen to. Steps to reproduce: Open a PoS session
Original PR description
Issue: Every change of the selected order makes the PoS call `pos.config.update_customer_display`, which publishes the order on the bus for the customer display paired with this browser. The device…
Issue: Every change of the selected order makes the PoS call `pos.config.update_customer_display`, which publishes the order on the bus for the customer display paired with this browser. The device uuid identifying that pairing is only generated when the customer display dialog is opened, so a PoS whose customer display was never opened sends `device_uuid: null` and the server publishes on `UPDATE_CUSTOMER_DISPLAY-null`, a channel nobody can listen to. Steps to reproduce: Open a PoS session, never open the customer display, and add a product to an order. Current behaviour: An rpc is sent for each change of the order, and each of them ends up as a bus notification that no customer display can ever receive. Expected behaviour: Nothing is sent as long as no customer display was ever opened. Solution: Skip the rpc while no device uuid exists. A customer display opened in the same browser as the PoS is served by the BroadcastChannel, which is unaffected. task-6408513 Forward-Port-Of: odoo/odoo#277687
Steps to reproduce: - Install `l10n_sa_edi` and `Accounting`> Change Company - Accounting > Customers > Invoices > Select an invoice > Click `Print` - `ValueError: can only parse strings` When printing a simplified Saudi invoice, the QR code is generated from the invoice XML. If the invoice has no taxes, `_l10n_sa_generate_zatca_template()` returns an error instead of the XML. The QR code generation tried to parse this error as XML, which caused a `ValueError: can only parse strings` an
Original PR description
Steps to reproduce: - Install `l10n_sa_edi` and `Accounting`> Change Company - Accounting > Customers > Invoices > Select an invoice > Click `Print` - `ValueError: can only parse strings` When printing a simplified Saudi invoice, the QR code is generated from the invoice XML. If the invoice has no taxes, `_l10n_sa_generate_zatca_template()` returns an error instead of the XML. The QR code generation tried to parse this error as XML, which caused a `ValueError: can only parse strings` and hid the actual reason for the failure. This commit checks for the error before generating the QR code and raises the original Error so the user sees the correct validation message. opw-6372454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275581
'_getEmptyOrder' could reuse an order whose background sync was still processing; the stale sync response then wiped is_refund and detached the refund line. We now skip orders currently in `syncingOrders` when picking the refund destination so the refund always lands on a clean order and syncs fresh. runbot error : 242604 Forward-Port-Of: odoo/odoo#273703
Original PR description
'_getEmptyOrder' could reuse an order whose background sync was still processing; the stale sync response then wiped is_refund and detached the refund line. We now skip orders currently in `syncingOrders` when picking the refund destination so the refund always lands on a clean order and syncs fresh. runbot error : 242604 Forward-Port-Of: odoo/odoo#273703
As of commit 4588e939, processed transactions are locked to prevent concurrent updates. When these transactions are linked to a source (parent) transaction, `_update_source_transaction_state` might be called during processing without a lock on the source transaction, so a concurrent update (e.g., processing a sibling child transaction) could conflict at commit time. This commit locks the source transaction together with the processed transaction and releases all locks if either cannot be acqu
Original PR description
As of commit 4588e939, processed transactions are locked to prevent concurrent updates. When these transactions are linked to a source (parent) transaction, `_update_source_transaction_state` might be called during processing without a lock on the source transaction, so a concurrent update (e.g., processing a sibling child transaction) could conflict at commit time. This commit locks the source transaction together with the processed transaction and releases all locks if either cannot be acquired. The payment data is skipped and retried on the next run, which aligns with the existing behavior when the processed transaction is locked.
Steps to reproduce: - Open any PoS session - Click on Orders and filter by "Paid" orders - Select an order and click on "Details" - Open the "Payments" tab and click on the "View" button of a payment - Click on the payment method link Traceback: OwlError: The following error occurred in onWillStart: "Cannot find key "pos_payment_provider_cards" in the "view_widgets" registry" Backend views opened from within the PoS UI (order details dialog, drill-down on many2one links, ...) share t
Original PR description
Steps to reproduce: - Open any PoS session - Click on Orders and filter by "Paid" orders - Select an order and click on "Details" - Open the "Payments" tab and click on the "View" button of a payment…
Steps to reproduce: - Open any PoS session - Click on Orders and filter by "Paid" orders - Select an order and click on "Details" - Open the "Payments" tab and click on the "View" button of a payment - Click on the payment method link Traceback: OwlError: The following error occurred in onWillStart: "Cannot find key "pos_payment_provider_cards" in the "view_widgets" registry" Backend views opened from within the PoS UI (order details dialog, drill-down on many2one links, ...) share their arch with the backend, but `point_of_sale._assets_pos` excludes everything under `static/src/backend/`, so widgets defined there (e.g. `pos_payment_provider_cards`, `lna_checklist`, `point_of_sale_test_epos`) are never registered in the PoS UI. Unlike missing field widgets, which fall back to the default widget with a warning, an unknown `<widget>` node makes the whole view crash since `Widget.parseWidgetNode` reads the registry without a fallback. Those widgets are backend configuration helpers that are irrelevant in a PoS session, so instead of bundling each of them (and any future one) in the PoS assets, patch `Widget.parseWidgetNode` in the PoS bundle to skip unknown widgets with a warning, like missing field widgets do. This covers the form, list and kanban arch parsers at once. opw-6382156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#279823 Forward-Port-Of: odoo/odoo#276912
### Steps to reproduce the issue: 1. Download Accounting and l10n_de 2. Set VAT number for DE company and another company you will use for the invoice 3. Switch to german language 4. Create an invoice and send it 5. Download the PDF and upload it on www.portinvoice.com 6. See the following error: the PDF metadata incorrectly states the conformance level as "ERWEITERT" (German), which directly clashes with the correct "EXTENDED" (English) profile declared inside the embedded XML file. ##
Original PR description
### Steps to reproduce the issue: 1. Download Accounting and l10n_de 2. Set VAT number for DE company and another company you will use for the invoice 3. Switch to german language 4. Create an invoice and send it 5. Download the PDF and upload it on www.portinvoice.com 6. See the following error: the PDF metadata incorrectly states the conformance level as "ERWEITERT" (German), which directly clashes with the correct "EXTENDED" (English) profile declared inside the embedded XML file. ### Cause of the issue: Issue comes from this commit 9396790e9cc1ce1c6e5c29b71b5629b31fb16458 where it has been forgotten to disable the translation. ### Reason to introduce the fix: Meet the requirements of the electronic invoice. opw-6023971 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273042
Use "VAT" instead of "TAX" for the default UK tax groups. Also set "Subtotal" as their preceding subtotal label so that it replaces "Untaxed Amount". task-[6413495](https://www.odoo.com/odoo/project/967/tasks/6413495) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#280144 Forward-Port-Of: odoo/odoo#278351
Original PR description
Use "VAT" instead of "TAX" for the default UK tax groups. Also set "Subtotal" as their preceding subtotal label so that it replaces "Untaxed Amount". task-[6413495](https://www.odoo.com/odoo/project/967/tasks/6413495) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#280144 Forward-Port-Of: odoo/odoo#278351
The test for `hr_leave_attendance_report` failed Runbot's faketime tests for two reasons: * The report's view use SQL's reserved syntax `CURRENT_DATE` which always resolves to real system clock, and ignores Odoo's faketime mechanism. * The three tests used hardcoded dates. Since the report is exclusively concerned with the window of last 13 months. Faking the time in a future date further than this led to wrong results. This commit fixes both issues by: 1. Using `now()::date`
Original PR description
The test for `hr_leave_attendance_report` failed Runbot's faketime tests for two reasons: * The report's view use SQL's reserved syntax `CURRENT_DATE` which always resolves to real system clock, and ignores Odoo's faketime mechanism. * The three tests used hardcoded dates. Since the report is exclusively concerned with the window of last 13 months. Faking the time in a future date further than this led to wrong results. This commit fixes both issues by: 1. Using `now()::date` in the view instead of `CURRENT_DATE`. 2. Replacing the hardcoded dates in the tests by dates computed relative to `fields.Date.today()`. Runbot Errors: [1](https://runbot.odoo.com/odoo/runbot.build.error/944585), [2](https://runbot.odoo.com/odoo/runbot.build.error/944585/runbot.build.error/runbot.build.error/944584) Forward-Port-Of: odoo/odoo#280380 Forward-Port-Of: odoo/odoo#279337
*:mrp_subcontracting_purchase Issue before this commit: ======================== - In inter-warehouse transfers with `multi-step delivery` and in multi-step manufacturing flows, demand moves were not correctly counted in the monthly demand. - Also, direct transfers to customer and subcontracting locations generated from `orderpoint` were also not counted correctly (when checked before move scheduled on the same day). This resulted in lower monthly demand values than the actual demand and
Original PR description
*:mrp_subcontracting_purchase Issue before this commit: ======================== - In inter-warehouse transfers with `multi-step delivery` and in multi-step manufacturing flows, demand moves were not…
*:mrp_subcontracting_purchase Issue before this commit: ======================== - In inter-warehouse transfers with `multi-step delivery` and in multi-step manufacturing flows, demand moves were not correctly counted in the monthly demand. - Also, direct transfers to customer and subcontracting locations generated from `orderpoint` were also not counted correctly (when checked before move scheduled on the same day). This resulted in lower monthly demand values than the actual demand and could lead to inaccurate purchase planning. Steps to Reproduce: ========================= - Install `purchase_stock` module and enable multi-step routes. - Set the Outgoing Shipments in the warehouse to 2-step/3-step. - Create a second warehouse and configure it to `resupply from another warehouse`. - Create a storable product and assign a vendor. - Create an orderpoint for the product in the second warehouse, set the route to the warehouse resupply route, and trigger the replenishment. - Go to Purchase → Create RFQ for the vendor and open the catalog. Observation: The replenishment transfer demand is not correctly counted in the monthly demand Cause of the issue: ========================= - In [PR](https://github.com/odoo/odoo/pull/244180), the monthly demand move domain was updated to filter out intermediate customer delivery moves using `move_dest_ids.origin_returned_move_id`. However, inter-warehouse replenishment delivery moves also have `move_dest_ids` linked to receipt moves of the other warehouse, but `origin_returned_move_id is not set` since they are not return move Because of this, these valid demand moves were incorrectly excluded from the monthly demand computation. - Also, in inter-warehouse flows with multi-step delivery, `delivery moves` stay in the `waiting state` since they wait for another operation, so they were also not counted. Additionally, `orderpoint-triggered` moves use a `fixed midday scheduled time`, and since monthly demand was computed using the current timestamp as the limit date, same-day moves could be excluded if checked before midday. After This Commit: ========================= - The monthly demand move domain was updated to correctly count inter-warehouse, manufacturing, and subcontracting resupply demand moves while still avoiding inflated demand from intermediate moves. The move state domain was also updated to `include waiting moves` in multi-step flows, and the limit date now uses the full current day so same day moves are counted correctly. Enterprise PR: odoo/enterprise#115944 TaskID-5490137 Forward-Port-Of: odoo/odoo#280167 Forward-Port-Of: odoo/odoo#262435
owl 3 through an error when title returned as null instead of empty string task-6345714 Forward-Port-Of: odoo/odoo#275321
Original PR description
owl 3 through an error when title returned as null instead of empty string task-6345714 Forward-Port-Of: odoo/odoo#275321
### Problem When mass updating the “Analytic Distribution” field on the lines on Analytic Items the values are not timely reflected on the lines. Steps to reproduce the issue: 1. Accounting > Accounting > Analytic Items. 2. Select multiple records (lines) from the list view. 3. Click on the "Analytic Distribution" column for one of the selected lines to mass-update it. 4. Add or adjust a specific analytic account/tag and click away to apply. 5. Click "Update" on the confirmation pop-up.
Original PR description
### Problem When mass updating the “Analytic Distribution” field on the lines on Analytic Items the values are not timely reflected on the lines. Steps to reproduce the issue: 1. Accounting > Accounting > Analytic Items. 2. Select multiple records (lines) from the list view. 3. Click on the "Analytic Distribution" column for one of the selected lines to mass-update it. 4. Add or adjust a specific analytic account/tag and click away to apply. 5. Click "Update" on the confirmation pop-up. 6. The previously existing analytic distribution tags of other plans disappear, showing only the newly updated account/tag. 7. Refresh the page. 8. The "missing" tags reappear alongside the newly updated one. ### Solution We need to trigger a read of the updated values after they are saved on the server side. opw-6045687 Forward-Port-Of: odoo/odoo#275497 Forward-Port-Of: odoo/odoo#261068
PoS loads product categories from both the PoS configuration and the preparation printers. Before this commit, if a child category was included in the PoS configuration, but its parent was only included in a preparation printer, the parent category was loaded in the frontend without being visible. As a result, the child category was also hidden, even though its products were still available. How to reproduce: - Create a parent category. - Create a child category containing a product. -
Original PR description
PoS loads product categories from both the PoS configuration and the preparation printers. Before this commit, if a child category was included in the PoS configuration, but its parent was only included in a preparation printer, the parent category was loaded in the frontend without being visible. As a result, the child category was also hidden, even though its products were still available. How to reproduce: - Create a parent category. - Create a child category containing a product. - Limit the PoS categories to the child category. - Create a preparation printer and assign the parent category to it. - Open the PoS. - The products are available, but the child category is not visible. opw-6381119 Forward-Port-Of: odoo/odoo#279459 Forward-Port-Of: odoo/odoo#276782
When a format is applied on an unsplittable node, removing it from a wider selection does not dare to touch that format to ensure it won't be split. Because of this, it becomes impossible to remove the format on such nodes. This commit slightly adapts the logic by so that instead of stopping when encountering an unsplittable node, it keeps looking higher in the hierarchy where the format is actually defined. Steps to reproduce: - Go to a "To do" note - Select a word - Apply a style (un
Original PR description
When a format is applied on an unsplittable node, removing it from a wider selection does not dare to touch that format to ensure it won't be split. Because of this, it becomes impossible to remove the format on such nodes. This commit slightly adapts the logic by so that instead of stopping when encountering an unsplittable node, it keeps looking higher in the hierarchy where the format is actually defined. Steps to reproduce: - Go to a "To do" note - Select a word - Apply a style (underscore, strikethrough...) - Type "odoo.com" - Press space to turn it into a link - Select the whole line - Try to remove the style => The style was not removed from the link. task-6322596 Forward-Port-Of: odoo/odoo#280180 Forward-Port-Of: odoo/odoo#273922
Before this commit, the chat window test "mark as read when opening chat window" failed at random on runbot, on the store fetches checked at teardown: 14. [step] unverified steps > Steps: [ "store fetch: /discuss/channel/messages", ] This happens because waitStoreFetch resolves as soon as the mock server serves the request, so the thread can still be loading when the test posts bob's message. As a result the scroll to unread, which only the loaded thread applies, is st
Original PR description
Before this commit, the chat window test "mark as read when opening chat window" failed at random on runbot, on the store fetches checked at teardown:
14. [step] unverified steps
> Steps: [
"store fetch: /discuss/channel/messages",
]
This happens because waitStoreFetch resolves as soon as the mock server serves the request, so the thread can still be loading when the test posts bob's message. As a result the scroll to unread, which only the loaded thread applies, is still pending when the chat window closes, and re-opening it loads around the new message separator: that second fetch is the one no assertion verifies.
This commit waits for the loaded thread before posting the message.
https://runbot.odoo.com/odoo/error/242447
Forward-Port-Of: odoo/odoo#280359Before this commit, test_01_invite_by_email_flow could fail right after a tour that succeeded, on a loaded runbot: ``` AssertionError: res.partner(2417,) not found in res.partner(2416,) ``` This happens because the tour ends on the click on "Invite to Group Chat", which only starts the add_members and invite_by_email calls. The test closes the browser and reads the channel members right after, so under load the calls never reach the server. Note that the tour did wait for the invite p
Original PR description
Before this commit, test_01_invite_by_email_flow could fail right after a tour that succeeded, on a loaded runbot: ``` AssertionError: res.partner(2417,) not found in res.partner(2416,) ``` This happens because the tour ends on the click on "Invite to Group Chat", which only starts the add_members and invite_by_email calls. The test closes the browser and reads the channel members right after, so under load the calls never reach the server. Note that the tour did wait for the invite panel to close, until that panel became a dialog: the step waited for any panel to be gone, and the member list stays open. This commit waits for the invited member in the member list and for the dialog to close, which only happens once both calls are done. https://runbot.odoo.com/odoo/error/944291 Forward-Port-Of: odoo/odoo#280356
Steps to reproduce: --- - Install the Sales module. - Create a new product. - Activate developer mode and try to edit the product image. Issue: --- - A traceback is raised: `OwlError: Invalid component props (CustomMediaDialog)` Root cause: --- - `ImageFieldWithMediaDialog` was missing the required `document` prop when instantiating `CustomMediaDialog`. The base `MediaDialog` class declares `document` as a required prop in `mediaDialogProps`, so omitting it fails Owl's prop validat
Original PR description
Steps to reproduce: --- - Install the Sales module. - Create a new product. - Activate developer mode and try to edit the product image. Issue: --- - A traceback is raised: `OwlError: Invalid component props (CustomMediaDialog)` Root cause: --- - `ImageFieldWithMediaDialog` was missing the required `document` prop when instantiating `CustomMediaDialog`. The base `MediaDialog` class declares `document` as a required prop in `mediaDialogProps`, so omitting it fails Owl's prop validation. Solution: --- - Pass the missing `document` value to `mediaDialogProps`. - A similar fix was applied in [commit]. [commit]: https://github.com/odoo/odoo/commit/404f64519cd9fb6f3c57698770d62d84784813b6 opw-6416905 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Normalize client IPv6 addresses to their /64 network prefix when generating device keys. This prevents the same IPv6 user from being tracked as multiple devices due to changing interface identifiers while preserving IPv4 behavior. This reduces the number of devices in the session while maintaining reliability. The original IP address will be used to determine device location. Task-6397512 Forward-Port-Of: odoo/odoo#277117
Original PR description
Normalize client IPv6 addresses to their /64 network prefix when generating device keys. This prevents the same IPv6 user from being tracked as multiple devices due to changing interface identifiers while preserving IPv4 behavior. This reduces the number of devices in the session while maintaining reliability. The original IP address will be used to determine device location. Task-6397512 Forward-Port-Of: odoo/odoo#277117
A user with own sales permissions won't be able to change the task partner when that task has a timesheet configured. Description of the issue/feature this PR addresses: - With a user with bare sales permissions (own sales) go to a task with timesheets and a sale order linked to it - Try to change the Customer for the task and save Current behavior before PR: <img width="1148" height="308" alt="image" src="https://github.com/user-attachments/assets/f0ccd25c-757b-455f-be36-68599de18c
Original PR description
A user with own sales permissions won't be able to change the task partner when that task has a timesheet configured. Description of the issue/feature this PR addresses: - With a user with bare sales permissions (own sales) go to a task with timesheets and a sale order linked to it - Try to change the Customer for the task and save Current behavior before PR: <img width="1148" height="308" alt="image" src="https://github.com/user-attachments/assets/f0ccd25c-757b-455f-be36-68599de18cd3" /> Desired behavior after PR is merged: No access error cc @moduon MT-15215 OPW-6364376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273916
### Steps to reproduce: - Open CRM app (or any model with chatter) - Open any record (e.g., an Opportunity) - Click "Log note" - Type some text into the input box - Click the "Full composer" icon to open the mail composition wizard - Log the note - Click "Log Note" again > The note is logged successfully, but the text remains visible inside the small inline chatter input box as if it was never sent. (Doesn't happen everytime) ### Cause of Issue: Composer drafts are auto-saved to I
Original PR description
### Steps to reproduce: - Open CRM app (or any model with chatter) - Open any record (e.g., an Opportunity) - Click "Log note" - Type some text into the input box - Click the "Full composer" icon to…
### Steps to reproduce: - Open CRM app (or any model with chatter) - Open any record (e.g., an Opportunity) - Click "Log note" - Type some text into the input box - Click the "Full composer" icon to open the mail composition wizard - Log the note - Click "Log Note" again > The note is logged successfully, but the text remains visible inside the small inline chatter input box as if it was never sent. (Doesn't happen everytime) ### Cause of Issue: Composer drafts are auto-saved to IndexedDB via the debounced saveContent() https://github.com/odoo/odoo/blob/ac2d15c1132af16f00f8955d1be9b43a8626d9bd/addons/mail/static/src/core/common/composer.js#L986-L1003 `clear()`, called from the Full Composer's `onClose` handler after logging a note, only resets in-memory composer state and removes a `localStorage` key — it never deletes the corresponding `IndexedDB` entry. ### Fix: Have `clear()` also delete the persisted IndexedDB draft via the helper used after a normal chatter post in `_sendMessage()`, so `clear()` fully tears down both in-memory and persisted state. opw-6354149 Forward-Port-Of: odoo/odoo#275999
During the FWP, the inherit has been mistakingly inverted. PINT_EU should inherit PINT and EN16931 as dictated in the pint documentation. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#280321
Original PR description
During the FWP, the inherit has been mistakingly inverted. PINT_EU should inherit PINT and EN16931 as dictated in the pint documentation. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#280321
Currently, a transfer is marked as 'Printed' only when the 'Picking Operations' report is printed using the Print button in the 'ready' state. If the same report is printed from the actions (gear) menu, the transfer is not marked as printed. This PR ensures that printing the 'Picking Operations' report from the actions menu also marks the transfer as 'Printed'. **Steps to reproduce:** - Install the stock module. - Open the Transfers list view. - Add custom group for 'Printed'. - Open a
Original PR description
Currently, a transfer is marked as 'Printed' only when the 'Picking Operations' report is printed using the Print button in the 'ready' state. If the same report is printed from the actions (gear)…
Currently, a transfer is marked as 'Printed' only when the 'Picking Operations' report is printed using the Print button in the 'ready' state. If the same report is printed from the actions (gear) menu, the transfer is not marked as printed. This PR ensures that printing the 'Picking Operations' report from the actions menu also marks the transfer as 'Printed'. **Steps to reproduce:** - Install the stock module. - Open the Transfers list view. - Add custom group for 'Printed'. - Open a transfer in the 'ready' state and print the 'Picking Operations' report using the Print button. Notice that the transfer is marked as 'Printed'. - Open another transfer in the 'ready' state and print the 'Picking Operations' report from the actions menu. - Observe that the transfer is not marked as Printed. The same issue occurs when printing it from list view. **Expected behavior:** A transfer in the 'ready' state should be marked as Printed whenever the 'Picking Operations' report is printed, regardless of whether it is triggered from the 'Print' button or the actions menu. close #235129 Forward-Port-Of: odoo/odoo#276582
Allow to add the district node for the peruvian electronic invoicing. opw-6282314 Forward-Port-Of: odoo/odoo#279784 Forward-Port-Of: odoo/odoo#271364
Original PR description
Allow to add the district node for the peruvian electronic invoicing. opw-6282314 Forward-Port-Of: odoo/odoo#279784 Forward-Port-Of: odoo/odoo#271364
This commit fix the regex used in `street_split` to be more complient. Before: address format was "street_name street_number - street_number2" Now, street_number can be in front of street_name. Format is also less strict, allowing multiple numbers in the street_name without skipping the building number. Linked: https://github.com/odoo/enterprise/pull/121674 task-6317758 Forward-Port-Of: odoo/odoo#280081 Forward-Port-Of: odoo/odoo#271855
Original PR description
This commit fix the regex used in `street_split` to be more complient. Before: address format was "street_name street_number - street_number2" Now, street_number can be in front of street_name. Format is also less strict, allowing multiple numbers in the street_name without skipping the building number. Linked: https://github.com/odoo/enterprise/pull/121674 task-6317758 Forward-Port-Of: odoo/odoo#280081 Forward-Port-Of: odoo/odoo#271855
**Problem:** When creating a new task, the Customer does not follow the project the user selects: once a first project has filled it, selecting another project keeps the previous project's customer. **Steps to reproduce:** 1. Create a new task and select a project that has a customer. 2. The Customer is set to that project's customer. 3. Select another project configured with a different customer. 4. Observe the Customer keeps the first project's customer. **Current behavior:** The C
Original PR description
**Problem:** When creating a new task, the Customer does not follow the project the user selects: once a first project has filled it, selecting another project keeps the previous project's customer.…
**Problem:** When creating a new task, the Customer does not follow the project the user selects: once a first project has filled it, selecting another project keeps the previous project's customer. **Steps to reproduce:** 1. Create a new task and select a project that has a customer. 2. The Customer is set to that project's customer. 3. Select another project configured with a different customer. 4. Observe the Customer keeps the first project's customer. **Current behavior:** The Customer keeps the first selected project's customer. **Expected behavior:** The Customer follows the selected project and shows its customer. **Cause of the issue:** partner_id is filled by _compute_partner_id, which only assigns a partner while the field is empty. Once a project has filled it, selecting another project no longer refreshes the now non-empty Customer. **Fix:** Refresh the Customer from the project on project_id change, but only while the task is new (no _origin). An existing task's customer is left untouched, since it may already carry sale order lines, timesheets, materials or worksheets that must not be reset when the project changes. opw-6315902 Forward-Port-Of: odoo/odoo#279356 Forward-Port-Of: odoo/odoo#276211
bug: configurator_missing_industry raised an uncaught RPC_ERROR when the IAP website API was unreachable, breaking the color palette step of the website configurator. fix: Wrap the IAP call in a try/except for RequestException/AccessError, matching the other configurator IAP calls in the same file. This call only reports an unrecognized industry name for logging; it should never block or error out the configurator flow. task-6325919
Original PR description
bug: configurator_missing_industry raised an uncaught RPC_ERROR when the IAP website API was unreachable, breaking the color palette step of the website configurator. fix: Wrap the IAP call in a try/except for RequestException/AccessError, matching the other configurator IAP calls in the same file. This call only reports an unrecognized industry name for logging; it should never block or error out the configurator flow. task-6325919
The `Message shows up even if channel data is incomplete` is sometimes failing. The test uses `forceUpdateChannels` and `waitUntilSubscribe` to wait for the newly created channel to be registered by the bus. However, `runAllTimers()` is called before `waitUntilSubscribe`. As a result, the subscription can happen before the helper is called, making the test fail. runbot-941199 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after
Original PR description
The `Message shows up even if channel data is incomplete` is sometimes failing. The test uses `forceUpdateChannels` and `waitUntilSubscribe` to wait for the newly created channel to be registered by the bus. However, `runAllTimers()` is called before `waitUntilSubscribe`. As a result, the subscription can happen before the helper is called, making the test fail. runbot-941199 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
## Problem `pttExtensionHookService` registers a global `window.addEventListener("message", ...)` handler that reads `data.from` without checking that `data` is defined first: ```js browser.addEventListener("message", ({ data, origin, source }) => { const rtc = env.services["discuss.rtc"]; if ( source !== window || origin !== location.origin || data.from !== "discuss-push-to-talk" || // <- crashes if data is undefined (!rtc && data.type !== "answer-is-
Original PR description
## Problem `pttExtensionHookService` registers a global `window.addEventListener("message", ...)` handler that reads `data.from` without checking that `data` is defined first: ```js…
## Problem
`pttExtensionHookService` registers a global `window.addEventListener("message", ...)`
handler that reads `data.from` without checking that `data` is defined first:
```js
browser.addEventListener("message", ({ data, origin, source }) => {
const rtc = env.services["discuss.rtc"];
if (
source !== window ||
origin !== location.origin ||
data.from !== "discuss-push-to-talk" || // <- crashes if data is undefined
(!rtc && data.type !== "answer-is-enabled")
) {
return;
}
...
```
Any same-window, same-origin `postMessage` sent by an unrelated browser
extension (a common content-script <-> injected-script pattern) can carry
`data === undefined`. The `source !== window` and `origin !== location.origin`
checks only filter out cross-window/cross-origin messages, so a same-origin
message from any other extension reaches this handler and crashes with:
```
TypeError: Cannot read properties of undefined (reading 'from')
```
This surfaces as an uncaught client error on any page with Discuss loaded,
after some time, unrelated to what the user is doing. The Discuss
push-to-talk extension itself does not need to be installed to trigger it,
since the crash happens before checking whether the message actually
originated from that extension.
## Solution
Use optional chaining (`data?.from`) so unrelated same-origin messages with
no `data` are safely ignored instead of crashing.
## Verification
- Reproduced against the live production `web.assets_web.min.js` bundle
(traceback matches exactly).
- Confirmed the bug is still present in the latest `18.0` of both `OCA/OCB`
and `odoo/odoo` (no newer commit touches this file since
`dc58ef1ad904`, which fixes an unrelated issue).
Forward-Port-Of: odoo/odoo#280079
Forward-Port-Of: odoo/odoo#279476By default event notifications are configured with positive integers to state how many minutes/hours/days they should be triggered before an event starts. This works fine in within Odoo. But in an ICS file a TRIGGER with such positive integer means it starts after the event. For example ICS file generated by Odoo contains TRIGGER;related=START:PT15M but it should be negative: TRIGGER;related=START:-PT15M (note the minus) in order to trigger before the event. See [here](https://icalendar.org/iCal
Original PR description
By default event notifications are configured with positive integers to state how many minutes/hours/days they should be triggered before an event starts. This works fine in within Odoo. But in an ICS file a TRIGGER with such positive integer means it starts after the event. For example ICS file generated by Odoo contains TRIGGER;related=START:PT15M but it should be negative: TRIGGER;related=START:-PT15M (note the minus) in order to trigger before the event. See [here](https://icalendar.org/iCalendar-RFC-5545/3-8-6-3-trigger.html) for reference. Current behavior before PR: The reminder is triggered AFTER the event start Desired behavior after PR is merged: The reminder is triggered BEFORE the event start Closes #245052. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274744
**Description of the issue/feature this PR addresses:** When adding a product with an analytic distribution to a Sales Order that is already linked to a project, the product's analytic distribution is not automatically applied to the order line. This occurs due to a previous commit that attempted to protect manually entered analytic distributions from being overwritten when an SO is confirmed and a project is generated. To do this, the old code filtered out any non-empty project lines and
Original PR description
**Description of the issue/feature this PR addresses:** When adding a product with an analytic distribution to a Sales Order that is already linked to a project, the product's analytic distribution…
**Description of the issue/feature this PR addresses:** When adding a product with an analytic distribution to a Sales Order that is already linked to a project, the product's analytic distribution is not automatically applied to the order line. This occurs due to a previous commit that attempted to protect manually entered analytic distributions from being overwritten when an SO is confirmed and a project is generated. To do this, the old code filtered out any non-empty project lines and bypassed calling `super()` on them. Consequently, if a line already had an analytic distribution (such as inheriting the project's), the system would skip computing the product's specific distribution rules entirely. This commit resolves the issue by reverting that change, ensuring the base compute method is always called so product-based rules execute correctly. While this means manual analytic entries added before the compute trigger might be overwritten, there is no perfect solution to prevent losing both manual and product distributions. As concluded with the Product Owner in a similar PR for Purchase Orders, we prioritize keeping the product's automated distribution, as it is much harder to manually reconstruct after its removal. The corresponding test is also reverted to its original state to reflect this expected behavior. A small test is added to ensure that the analytic distribution results are unchanged when adding a project to the SO. opw-6279406 **Steps to Reproduce:** - Accounting > Configuration > Settings > Analytics > enable Analytic Accounting - Accounting > Configuration > Analytic Accounting > Analytic Distribution Models - Create a new model with any product (e.g. “Bolt”) and any Analytic Distribution (e.g. “Production”) - Create SO, enable “Analytic Distribution” in filters - Add any customer, add the above product (e.g. “Bolt”), save - Observe that the “Production” Analytic Distribution is automatically populated - On the same SO > Other Info> Project > add (e.g. “Home Construction”) - Then go back to Order Lines and remove the previous SOL and create a new one with the same product > save - Observe that the “Production” Analytic Distribution is not added (although “Home Construction” is) **Current behavior before PR:** - Product analytic distributions are not automatically applied when the Sales Order is already linked to a project **Desired behavior after PR is merged:** - Product analytic distributions are automatically applied even when the Sales Order is linked to a project **Note:** This commit basically ports a fix/revert (https://github.com/odoo/odoo/commit/54852978617cfb2d8c5afdcf80adbf6c0605093c) introduced to the project_purchase module for the same issue. Their commit message is quite detailed in explaining the issue. To quote: >However, due to the agency of the code, we cannot prevent losing *both* manually added analytic distributions and product analytic distribution. After consulting the product owner, we concluded that there was no perfect solution in this case, but we'd rather keep the product analytic distribution, as it is much harder to add it again after its removal. Therefore, this commit reverts the previously mentioned commit, while keeping the refactor it introduced. The referenced initial commit is here: https://github.com/odoo/odoo/commit/3dfa98bd3b9d5ababe3a7548d604e22350023799 Forward-Port-Of: odoo/odoo#274893
## Steps to Reproduce: - Install `website_sale` with demo data. - Activate the "Mercado Pago" payment provider. - Website > Shop > Add a product > Go to cart and proceed to Checkout. - Select the "Card" payment method and proceed. ## Error: `AttributeError: 'bool' object has no attribute 'lower'` ## Cause: Before commit https://github.com/odoo/odoo/commit/1ef1b73ee2ec3c1adfdffe32c34bb441b97dfbec, the availability of a payment provider was controlled by the `state` field ('disabled',
Original PR description
## Steps to Reproduce: - Install `website_sale` with demo data. - Activate the "Mercado Pago" payment provider. - Website > Shop > Add a product > Go to cart and proceed to Checkout. - Select the…
## Steps to Reproduce:
- Install `website_sale` with demo data.
- Activate the "Mercado Pago" payment provider.
- Website > Shop > Add a product > Go to cart and proceed to Checkout.
- Select the "Card" payment method and proceed.
## Error:
`AttributeError: 'bool' object has no attribute 'lower'`
## Cause:
Before commit https://github.com/odoo/odoo/commit/1ef1b73ee2ec3c1adfdffe32c34bb441b97dfbec, the availability of a payment provider was controlled by the `state` field ('disabled', 'enabled', 'test'). To use Mercado Pago in test mode, users first had to configure an account country (`mercado_pago_account_country_id`).
But after this commit, the `state` field has been replaced by `is_live`. By default, providers are available in test mode when `is_live` is disabled, allowing users to make a test payment. - [1]
During payment processing, the missing account country leads to an error.
## Fix:
Before processing a payment, ensure that an account country is configured and raise a validation error if it is missing.
We have same validation check on account onboarding (Ref): https://github.com/odoo/odoo/blob/ada769dac1deda7dbd89596153f97c6f5887f57a/addons/payment_mercado_pago/models/payment_provider.py#L154-L157
[1] - https://github.com/odoo/odoo/blob/ada769dac1deda7dbd89596153f97c6f5887f57a/addons/payment/models/payment_provider.py#L38-L43
sentry-7638271109Until now, the `domain` field of a `website` record has been allowed to hold potentially invalid domains. Between 19.3 and 19.4, there was a refactoring that reworked how websites where matched to domains and which introduced the use of `parse_url` from `urllib3` instead of `url_parse` from a patched copy of `werkzeug` we maintain. `parse_url` is stricter and rejects domains that have invalid IDNA labels. 19.3 would accept and try to match on a domain like `ó doo.com`, even though nobody woul
Original PR description
Until now, the `domain` field of a `website` record has been allowed to hold potentially invalid domains. Between 19.3 and 19.4, there was a refactoring that reworked how websites where matched to domains and which introduced the use of `parse_url` from `urllib3` instead of `url_parse` from a patched copy of `werkzeug` we maintain. `parse_url` is stricter and rejects domains that have invalid IDNA labels. 19.3 would accept and try to match on a domain like `ó doo.com`, even though nobody would be able to reach it. In 19.4, if a user configures an invalid domain for their website, this results in a traceback on every request while trying to match the domain, effectively making the database inaccessible. Since it doesn't make sense to try and match on an invalid domain, this fix makes domains that `parse_url` fails to parse not match on anything. opw-6439606
…F fetch Nilvera PDF retrieval (the manual "Get PDF" action and the scheduled "retrieve sale PDFs" cron) hardcoded the "Sale" document category. That is correct for e-invoices (/einvoice/Sale/{uuid}/pdf) but wrong for e-archive documents, whose resource is "Invoices". For e-archive invoices it produced GET /earchive/Sale/{uuid}/pdf, which Nilvera answers with 404, surfacing to the user as "Odoo could not perform this action at the moment... Not Found - 404" and making the cron raise on every
Original PR description
…F fetch
Nilvera PDF retrieval (the manual "Get PDF" action and the scheduled "retrieve sale PDFs" cron) hardcoded the "Sale" document category. That is correct for e-invoices (/einvoice/Sale/{uuid}/pdf) but wrong for e-archive documents, whose resource is "Invoices". For e-archive invoices it produced GET /earchive/Sale/{uuid}/pdf, which Nilvera answers with 404, surfacing to the user as "Odoo could not perform this action at the moment... Not Found - 404" and making the cron raise on every run.
Derive the document category from the invoice channel so e-archive resolves to /earchive/invoices/{uuid}/pdf while e-invoice keeps using /einvoice/sale/{uuid}/pdf.
OPW-6311661
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#279543
Forward-Port-Of: odoo/odoo#278796Issue: --- Adding a rating with a message on website is causing TB as the portal user doesn't have the access to send rating message. opw-6316142 Forward-Port-Of: odoo/odoo#279772 Forward-Port-Of: odoo/odoo#271833
Original PR description
Issue: --- Adding a rating with a message on website is causing TB as the portal user doesn't have the access to send rating message. opw-6316142 Forward-Port-Of: odoo/odoo#279772 Forward-Port-Of: odoo/odoo#271833
Problem: The `product_label_section_and_note_field` widget ignores the `no_open` option in list views. The `m2oProps` getter overrides the framework's native `p.canOpen` property, hardcoding the clickable state based purely on readonly status. Purpose: Ensure the widget respects standard framework options by the `p.canOpen` with the business logic, restoring the ability to disable record navigation. Steps to Reproduce on Runbot: - Go to Purchase app and open a quotation. - Open Odoo St
Original PR description
Problem: The `product_label_section_and_note_field` widget ignores the `no_open` option in list views. The `m2oProps` getter overrides the framework's native `p.canOpen` property, hardcoding the clickable state based purely on readonly status. Purpose: Ensure the widget respects standard framework options by the `p.canOpen` with the business logic, restoring the ability to disable record navigation. Steps to Reproduce on Runbot: - Go to Purchase app and open a quotation. - Open Odoo Studio. - Click on the product table and select "Edit list view". - Click on the product column. - On the sidebar, go to properties and activate "Disable opening". - Close Studio and click the product name on a line. - The form view action is triggered. opw-6422065 Forward-Port-Of: odoo/odoo#279221
Description of the issue/feature this PR addresses: Mail server ports are identifiers rather than quantities. The incoming and outgoing mail server views use the unsupported `format` option, so locale-based integer formatting remains enabled. Steps to reproduce: 1. Enable developer mode. 2. Go to Settings > Technical > Email > Outgoing Mail Servers. 3. Create a server and set SMTP Port to `8069`. 4. Move focus away from the field. 5. The same issue occurs on an Incomin
Original PR description
Description of the issue/feature this PR addresses: Mail server ports are identifiers rather than quantities. The incoming and outgoing mail server views use the unsupported `format` option, so…
Description of the issue/feature this PR addresses: Mail server ports are identifiers rather than quantities. The incoming and outgoing mail server views use the unsupported `format` option, so locale-based integer formatting remains enabled. Steps to reproduce: 1. Enable developer mode. 2. Go to Settings > Technical > Email > Outgoing Mail Servers. 3. Create a server and set SMTP Port to `8069`. 4. Move focus away from the field. 5. The same issue occurs on an Incoming Mail Server with a port such as `10143`. Current behavior before PR: Ports are displayed with thousands separators, e.g. `8,069` and `10,143`. Desired behavior after PR is merged: Mail server ports remain unformatted, e.g. `8069` and `10143`. Fixes #275937 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr "As a recent Computer Engineering graduate, I made my first open-source contribution to Odoo." :) Forward-Port-Of: odoo/odoo#278329
Before this commit, the user's presence was not sent to the server when another device reported this user as away/offline while this device was online. `ImStatusMixin` reacts to `presence_status` and correct the user's presence on the server when needed (e.g. locally online while away was received). Since [1], the check on the presence being the one of the current user is wrong (comparing `store.self` to the presence user record). The tests only pass because of the initial presence upda
Original PR description
Before this commit, the user's presence was not sent to the server when another device reported this user as away/offline while this device was online. `ImStatusMixin` reacts to `presence_status` and correct the user's presence on the server when needed (e.g. locally online while away was received). Since [1], the check on the presence being the one of the current user is wrong (comparing `store.self` to the presence user record). The tests only pass because of the initial presence update. This commit fixes the issue and ensures the initial update is not confused by the correction. [1]: https://github.com/odoo/odoo/pull/248168 runbot-944282 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#280314
- removed traceback when probe fails on `l10n_ke_edi` driver, - filtered logs from custom drivers (not sending them to sentry anymore - fixed session_id request for websocket, failing on 303 - updated exception_logger so that it catches exceptions as a whole instead of line by line. task-6445199
Original PR description
- removed traceback when probe fails on `l10n_ke_edi` driver, - filtered logs from custom drivers (not sending them to sentry anymore - fixed session_id request for websocket, failing on 303 - updated exception_logger so that it catches exceptions as a whole instead of line by line. task-6445199
# How to reproduce - Create a SO - Add a Section with a multi-line description - Add any product - Confirm & Create an invoice - Go to the invoice # The issue The Section's description is squished on a single line # The problem Since [this commit](https://github.com/odoo/odoo/commit/95c36bcd241b30e6e2d4a2915d38118ddb7556e0) it is now possible to add a multi-line description to a SO. They allowed this by changing the corresponding widgets. The issue is that the widget for the Sect
Original PR description
# How to reproduce - Create a SO - Add a Section with a multi-line description - Add any product - Confirm & Create an invoice - Go to the invoice # The issue The Section's description is squished on a single line # The problem Since [this commit](https://github.com/odoo/odoo/commit/95c36bcd241b30e6e2d4a2915d38118ddb7556e0) it is now possible to add a multi-line description to a SO. They allowed this by changing the corresponding widgets. The issue is that the widget for the Section description in the Invoice view does not handle multi-line content opw-6357044
Previously, we did not prevent FRCTC from registering through Peppol, even though FRCTC is not supported in Peppol. French companies could attempt to register in Peppol with FRCTC, which caused many errors. task-6421930 Forward-Port-Of: odoo/odoo#278782
Original PR description
Previously, we did not prevent FRCTC from registering through Peppol, even though FRCTC is not supported in Peppol. French companies could attempt to register in Peppol with FRCTC, which caused many errors. task-6421930 Forward-Port-Of: odoo/odoo#278782
Before this commit, opening a live chat in Discuss crashes as soon as the visitor is a contact with an open lead, and the agent can no longer post in that conversation: TypeError: can't access property "length", ctx.templateParams.info_records is undefined This happens because the "Open leads" block reads the visitor member on the channel to decide whether to show itself, and on the thread, which holds none, to pass the leads. It therefore calls info_links with no record, and info
Original PR description
Before this commit, opening a live chat in Discuss crashes as soon as the visitor is a contact with an open lead, and the agent can no longer post in that conversation:
TypeError: can't access property "length",
ctx.templateParams.info_records is undefined
This happens because the "Open leads" block reads the visitor member on the channel to decide whether to show itself, and on the thread, which holds none, to pass the leads. It therefore calls info_links with no record, and info_links reads their length. The panel opens by default in Discuss, so the crash takes the composer with it.
This commit reads the visitor member on the channel to pass the leads, and drops the condition of the caller, so that info_links alone decides whether it has something to show.
https://github.com/odoo/enterprise/pull/126715
Forward-Port-Of: odoo/odoo#280430When running `ŧest_free_reservation`, it could happen on very rare occasions that both moves would be created at a different second. In such cases, the test would fail. Since we want to test the case with *exact* same dates, we can't use `assertAlmostEqual` which is usually better for dates. Instead, we freeze the time for the duration of the creation / assignation. runbot-944453 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of:
Original PR description
When running `ŧest_free_reservation`, it could happen on very rare occasions that both moves would be created at a different second. In such cases, the test would fail. Since we want to test the case with *exact* same dates, we can't use `assertAlmostEqual` which is usually better for dates. Instead, we freeze the time for the duration of the creation / assignation. runbot-944453 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#279954 Forward-Port-Of: odoo/odoo#278103
Ensure combo prices are computed in the backend. Forward-Port-Of: odoo/odoo#279919 Forward-Port-Of: odoo/odoo#279652
Original PR description
Ensure combo prices are computed in the backend. Forward-Port-Of: odoo/odoo#279919 Forward-Port-Of: odoo/odoo#279652
As of commit 4588e939, transactions are processed asynchronously by a dedicated cron, so they're still in the `draft` state right after a call to `_charge_with_token`. Posting just created `account.payment` records based on the transaction state was no longer relevant, and running their post-processing immediately after made the problem worse: the transactions were flagged as post-processed while still `draft`, so the post-processing cron later skipped them, and the payments were directly cancel
Original PR description
As of commit 4588e939, transactions are processed asynchronously by a dedicated cron, so they're still in the `draft` state right after a call to `_charge_with_token`. Posting just created `account.payment` records based on the transaction state was no longer relevant, and running their post-processing immediately after made the problem worse: the transactions were flagged as post-processed while still `draft`, so the post-processing cron later skipped them, and the payments were directly canceled due to the transaction not being already in the `done` state. This commit defers both the posting and the cancellation of payments to the post-processing step. Just like the post-processing used to cancel payments for `cancel` transactions, it now cancels all those whose transaction didn't reach a "paid" (`authorized` or `done`) state, so that both declined token charges and API request errors now result in a cancellation of the payment.
Before this commit, this test was failing non-deterministically on on some machines: ``` show banner for new message after thread was read from another device ``` With the following error: ``` Error: Failed to find 1 of ".o-mail-Thread-banner:has(:text('1 new message'))" (Timeout of 3 seconds). Found 0 instead. ``` This happens because while the message list has 20 messages, each message is 1-line long. That means on many monitors the bottom of conversation is visible and thus it c
Original PR description
Before this commit, this test was failing non-deterministically on on some machines:
```
show banner for new message after thread was read from another device
```
With the following error:
```
Error: Failed to find 1 of ".o-mail-Thread-banner:has(:text('1 new message'))" (Timeout of 3 seconds). Found 0 instead.
```
This happens because while the message list has 20 messages, each message is 1-line long. That means on many monitors the bottom of conversation is visible and thus it can mark as read automatically the conversation. When this happens the banner is removed, thus the last step would fail.
This commit fixes the issue by making each message body bigger, so that this is very unlikely to see the bottom of message list, therefore avoiding the auto-mark as read from reaching the bottom of conversation.
Forward-Port-Of: odoo/odoo#280103Repro steps: 1) Create an invoice 2) Activate auto post (monthly for example) 3) Confirm the invoice, a new draft invoice will be created 4) Reset to draft 5) Confirm again Problem: A second draft would be created, and next period, 2 invoices would be confirmed Fix: This commit deletes the next auto post recurrence of an invoice, if that next recurrence is in draft, and the invoice is being set to draft. It also prevents creating a recurrence at a date if there is already an exi
Original PR description
Repro steps: 1) Create an invoice 2) Activate auto post (monthly for example) 3) Confirm the invoice, a new draft invoice will be created 4) Reset to draft 5) Confirm again Problem: A second draft would be created, and next period, 2 invoices would be confirmed Fix: This commit deletes the next auto post recurrence of an invoice, if that next recurrence is in draft, and the invoice is being set to draft. It also prevents creating a recurrence at a date if there is already an existing recurrent move on that date. task-6311219 Forward-Port-Of: odoo/odoo#280570 Forward-Port-Of: odoo/odoo#279159
Before this commit, turning the camera on during a call could leave the camera off in every member's UI, including the local user's own tile, while the video was already being sent. This happens because toggleVideo awaits network.updateUpload before updateAndBroadcast, and updateUpload waits on the ready promise of every peer. A single member whose handshake never completes holds isCameraOn and isScreenSharingOn for everyone. This commit fixes the issue by broadcasting the state first and
Original PR description
Before this commit, turning the camera on during a call could leave the camera off in every member's UI, including the local user's own tile, while the video was already being sent. This happens because toggleVideo awaits network.updateUpload before updateAndBroadcast, and updateUpload waits on the ready promise of every peer. A single member whose handshake never completes holds isCameraOn and isScreenSharingOn for everyone. This commit fixes the issue by broadcasting the state first and awaiting the upload after. Note that updateUpload sends its info snapshot to the peers synchronously, so they still learn the new track. Back-port of https://github.com/odoo/odoo/pull/279106 Forward-Port-Of: odoo/odoo#280492 Forward-Port-Of: odoo/odoo#280014