Daily updates from Odoo
Thursday, November 6, 2025
24 changes · master
Resolved issues and error corrections
This fix prevents a server crash when sending Uruguayan electronic credit or debit notes linked to an original document that is not a valid electronic tax document. Users now receive a clear message explaining what needs to be corrected, helping them resolve the issue without technical support.
Original PR description
### Description of the issue/feature this PR addresses: When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document…
### Description of the issue/feature this PR addresses:
When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document is not a real CFE then will raise a traceback error
### Steps to reproduce:
1. Create an e-invoice and confirm in Odoo (without sending to DGI)
2. Create an e-credit note from the e-invoice created in (1) and confirm
3. Try to send the credit note to DGI
The result is a traceback:
```
RPC_ERROR
Odoo Server Error
Occured on 18.core.odoo.localhost on model account.move.send.wizard on 2025-10-21 20:47:48 GMT
Traceback (most recent call last):
File "/home/odoo/custom/odoo/odoo/http.py", line 2144, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/service/model.py", line 156, in retrying
result = func()
^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2111, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2359, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/api.py", line 535, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/wizard/account_move_send_wizard.py", line 294, in action_send_and_print
attachments = self._generate_and_send_invoices(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 719, in _generate_and_send_invoices
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 620, in _generate_invoice_documents
self._call_web_service_before_invoice_pdf_render(invoices_data_web_service)
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move_send.py", line 88, in _call_web_service_before_invoice_pdf_render
invoice._l10n_uy_edi_send()
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 813, in _l10n_uy_edi_send
request_data = move._l10n_uy_edi_prepare_req_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 787, in _l10n_uy_edi_prepare_req_data
xml_content = self._l10n_uy_edi_get_xml_content()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 773, in _l10n_uy_edi_get_xml_content
"referencia_lines": self._l10n_uy_edi_cfe_F_reference(),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 381, in _l10n_uy_edi_cfe_F_reference
cfe_serie, cfe_number = self.l10n_uy_edi_document_id._get_doc_parts(related_cfe)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/l10n_uy_edi_document.py", line 215, in _get_doc_parts
return re.findall(r"([A-Z]{1,2})[-]*([0-9]{1,8})", record.l10n_latam_document_number)[-1]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^
IndexError: list index out of range
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3162:163)
at XMLHttpRequest.<anonymous> (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3167:13)
```
### Desired behavior after PR is merged:
Now we ensure to show a proper message to the user to fix the problem: the original document should be a electronic one
<img width="1203" height="664" alt="after" src="https://github.com/user-attachments/assets/bb7b105e-12f0-4935-b6bc-37edb3bc3aca" />
References LATAM 1301 / ADHOC Task 54770
Forward-Port-Of: odoo/enterprise#90281This update adjusts automated tests in Knowledge and Studio to match the current editor behavior around table endings and selection placeholders. It helps keep quality checks accurate without changing how business users work in the product.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/225576 task-4129699 Forward-Port-Of: odoo/enterprise#96484
A manufacturing planning test now uses a consistent timezone so demo data does not cause duplicate purchase order lines during replenishment. This reduces false test failures and helps keep quality checks reliable across environments.
Original PR description
The `test_replenish` test was failing with demo data because replenishment created an extra Purchase Order line. The `_run_buy` search domain included `date_planned_mps` with an equality check on a datetime stored in `UTC`. With demo data loaded in a non-UTC timezone (e.g. Europe/Brussels), the forecast date was converted to `2025-07-31 22:00:00 UTC`, which did not match the existing PO at `2025-08-01 00:00:00 UTC`. As a result, no PO was found and a duplicate was created. Changes: Set the test user timezone to `UTC` so that `date_planned_mps` comparisons are stable when using demo data. This ensures replenishment reuses the existing PO instead of creating a duplicate. [runbot-230425](https://runbot.odoo.com/odoo/error/230425) Forward-Port-Of: odoo/enterprise#98268
Customers can no longer cancel self-order orders from “My orders” once they have been sent to the kitchen display. This prevents mismatches where an order is cancelled in the system but still appears active for kitchen staff, reducing operational confusion.
Original PR description
Currently, it is possible to cancel orders that have been sent to the kitchen display. However when doing so, the kitchen displayd does not receive any information about the cancellation. Steps to reproduce: ------------------- - Modify restaurant and enable self ordering - Open self an place an order (not paid but sent to kitchen) - Go back to "My orders" and cancel it > Order is cancelled in backend but not in the kitchen display Why the fix: ------------ When an order is sent to the kitchen the only way to cancel it should be by going to the register. Therefore now, if an order is present on the kitchen display we will not show the cancel button. opw-5030223 Community: https://github.com/odoo/odoo/pull/229039 Forward-Port-Of: odoo/enterprise#98035 Forward-Port-Of: odoo/enterprise#95770
Manufacturing work orders marked as done directly from the status widget now correctly add the related work center cost to the project analytics. This keeps project gross margin calculations accurate even when users skip the start/stop workflow.
Original PR description
This PR fixes the problem of adding the hourly cost of the work center when marking an operation as done from the status widget. To reproduce the bug: 1- Create a work center with an hourly cost > 0. 2- Create an MO with 1 operation in that work center, expected time > 0. 3- Create and set a project on the MO. 4- Make sure that project has an analytic account. 5- Mark the operation as done from the status widget. (click on it and choose done, don't use the start button) 6- Go to the analytic account of the project and check the gross margin. = No cost of the workorder was added. Now, this PR takes into account the duration of the WO first when marking it as done directly from the status widget. Task-5156286 Forward-Port-Of: odoo/enterprise#97253
This fix ensures Australian TPAR reports export correctly by using the proper country name format and adding missing report structure information. Businesses can now generate both TPAR files and PDFs without errors caused by incorrect country data or missing report line details.
Original PR description
Behavior before: Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'})…
Behavior before:
Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'}) instead of plain text, resulting in incorrect line lengths. Additionally, PDF export failed with a KeyError for the missing 'level' key, as dynamically generated report lines did not include a level field, which the QWeb template requires.
Behavior after:
SQL query uses the JSONB text extraction operator (->>) to retrieve only the country name string (e.g., 'Australia'), ensuring correct line lengths during export. All dynamic report lines are assigned 'level': 1 so that PDF export works correctly without errors.
Root cause:
Country names are stored as translatable JSONB fields, and the previous query did not extract the localized text, returning the full JSON structure. Dynamic report lines for partners did not include a level key by default, causing the PDF template rendering to fail.
Ticket [link](https://www.odoo.com/odoo/project.task/5148697)
opw-5148697
Forward-Port-Of: odoo/enterprise#98020
Forward-Port-Of: odoo/enterprise#97990The Czech VIES summary report now uses invoice amounts converted into the company currency, rather than treating foreign-currency values as already converted. This prevents overstated or understated report totals when invoices are issued in a different currency.
Original PR description
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in…
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in incorrect totals in the report. **Steps to Reproduce:** 1. Install the Accounting app and the l10n_cz_reports_2025 module. 2. Go to Accounting > Customers > Invoices. 3. Create a new invoice using a currency other than CZK. 4. Add a product with Code Supply set to Gold and Transaction Code set to 0 Goods. Confirm the invoice. 5. Navigate to Accounting > Reporting > VIES Summary Report. 6. Observe that the total value is not correctly converted to the company currency. **Expected Behavior:** The total amounts in the VIES summary report should be correctly converted to the company currency if the invoice was created in a foreign currency. **Actual Behavior:** Amounts are displayed in the invoice currency without conversion, leading to incorrect totals when the invoice currency differs from the company currency. **Root Cause** The report fetches raw invoice data without handling currency conversion. Specifically, it retrieves the unconverted total value, even when the invoice currency differs from the company’s. **Fix** To solve the issue the balance field is used, which correctly reflects the value in the company currency. opw-4688638 Forward-Port-Of: odoo/enterprise#97894 Forward-Port-Of: odoo/enterprise#82978
Payslip exports now use the fields selected by the user instead of falling back to incorrect defaults. This ensures payroll teams get the expected information in exported files, reducing manual corrections and confusion.
Original PR description
Since the introduction of payslip issues, the optional active fields were not correctly given back to the controller. This resulted in having the wrong default fields inside the export (not the ones selected). This commit fixes the issue by avoid using a proxy. task-5129681 Forward-Port-Of: odoo/enterprise#96707
This fix makes the formula text in accounting report info popovers readable when dark mode is enabled. It improves usability for users reviewing report details in debug mode without changing report data or workflows.
Original PR description
When using the dark mode, the popover available only in debug mode on the account reports (when pressing the info button on the right of each line) used to display the formula with a dark color, making it hard to read. Forward-Port-Of: odoo/enterprise#98905
The Chilean point of sale flow now handles contacts with missing required information properly during order validation. Instead of crashing, the system shows the expected notification and opens the contact edit form so staff can correct the details and continue the sale.
Original PR description
Before this commit, when validating an order, if the selected contact was missing a required field, the PoS would crash instead of displaying the correct notification and opening the partner edit form. opw-5222040 Forward-Port-Of: odoo/enterprise#98757
The tax report settings now refer to this timing field as a deadline instead of a reminder. This makes the label match its actual purpose: calculating the default deadline from the end of a tax return period.
Original PR description
This field is not a reminder anymore and is used to compute the default deadline from the end of the tax return. task-5153900 Forward-Port-Of: odoo/enterprise#96651
This fix corrects uneven vertical spacing on the return type form by using the appropriate inline text element. Users will see a more consistent and polished layout when viewing or editing return types.
Original PR description
The return type form view had an inconsistent vertical spacing due to the use of a paragraph instead of a span. task-5153900 Forward-Port-Of: odoo/enterprise#96711
When someone signs a document while logged in as another user, Odoo no longer automatically uses the other user's saved signature. The signing certificate now clearly notes that the document was signed via another user's account, improving transparency and preventing accidental misuse of stored signatures.
Original PR description
Before this commit, we allow to sign on behalf on another user but we should not fetch his saved signature. We want that when a user is signing from the account of another user: - we don't load the signature of the user (saved in the user profile) - we have a mention in the certificate that the document was signed via another user. task-5223975 Forward-Port-Of: odoo/enterprise#98533
When customers book a table from the website, the phone number field is now filled from the customer record linked to the appointment. This helps staff see the correct contact number while keeping the booking’s phone field as a separate copied value.
Original PR description
Task: [#5005216](https://www.odoo.com/odoo/project/1737/tasks/5005216) --- The phone number field was not being populated correctly when booking a table from the website. It is now properly filled using the phone number of the `res.partner` associated with the appointment. The field remains unlinked to the partner, as it is just a copy. Forward-Port-Of: odoo/enterprise#98041 Forward-Port-Of: odoo/enterprise#92836
Rental-related automated tests were adjusted so they no longer depend on optional demo accounting or stock setup. This helps ensure the rental sales module can be validated consistently across clean test environments, reducing false failures in the release process.
Original PR description
The test was failing in no-demo environments because it relied on accounting and stock configurations that were not present. When the test attempted to set property_valuation = 'real_time' on the product category, it triggered a ValidationError because the related stock accounts had not been properly set up for the test's transaction context. runbot-error-230417 Forward-Port-Of: odoo/enterprise#98798 Forward-Port-Of: odoo/enterprise#92292
Live chat conversations now show the correct channel name when a new member joins, even when some current participant details are unavailable. This helps support teams and visitors keep the right context in the helpdesk live chat sidebar.
Original PR description
…mber join This change introduces the `im_livechat.channel.member.history` model on the client side to properly display the Livechat channel name. In the case of lacking data for current agents or visitors, we use the history records to display the channel name. task-4966319
Subscription invoices that are aligned to the calendar will now keep delivery charges at their full fixed amount instead of reducing them like service fees. This prevents undercharging customers for shipping when prorated invoices are created.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a subscription with delivery product. 2. Select align to calendar in the recurring plan 2. Add shipping method by assigning a delivery product with recurring_invoice. 3. Create an invoice with prorated Issue: - Delivery products are considered service-type products and their price was prorated in invoice. Cause: - The proration logic treated delivery lines like normal recurring service products, instead of keeping their fixed charge. Solution: - Exclude delivery products from proration by setting their period ratio to 1. Co-authored-by: Darshan Patel dvpa@odoo.com Co-authored-by: Federico Braidi brfe@odoo.com task-4662188 Forward-Port-Of: odoo/enterprise#98909 Forward-Port-Of: odoo/enterprise#91133
This fix places a manufacturing work order quality view in the correct module and updates its dependency setup. It helps ensure the related quality features load reliably when manufacturing work orders are installed.
Original PR description
view `quality_point_routing_view_form_inherit_quality_mrp` was supposed to be in the module `quality_mrp_workorder` as it has `quality` and `mrp_workorder` as dependency. And also `quality_mrp_workorder` was supposed to depend on `quality_mrp` not `quality_control`. Forward-Port-Of: odoo/enterprise#97147
The point of sale settlement flow now prevents the same customer invoice from being settled more than once. This avoids duplicate payments or accounting entries and keeps the selected customer in place if a repeat settlement attempt triggers an error.
Original PR description
Steps to reproduce: ------------------------- - Install POS. - Create an invoiced order and pay with customer account. - Settle the created invoices from customers list. - Try to settle the invoice again from the same order. Issue: ------- - The system allows settling the same invoice multiple times. Cause: --------- - There is no check in place to verify whether the invoice has already been under settlement process before settling it again. Fix: ----- - Add a validation step to ensure that if the same invoice is selected again, the system prevents duplication and it will show that already being settled. - Also if error occured due to second try of settlment will not lose the selected partner. task: 5028009 related PR: [227971](https://github.com/odoo/odoo/pull/227971) Forward-Port-Of: odoo/enterprise#98927 Forward-Port-Of: odoo/enterprise#95156
This fix ensures Web Studio saves changes only once when a browser tab is hidden or switched away from. It reduces unnecessary background save activity and helps keep editor behavior consistent without changing how users work.
Original PR description
This commit is the counter part of odoo/odoo#232523. A form editor test had to be adapted as we no longer go through _save in the tested scenario. task~5184626
The appraisal feedback wizard now only considers appraisal survey templates the current user is allowed to access. This prevents users from hitting an access error when asking for feedback if another restricted survey exists in the system.
Original PR description
To reproduce (on runbot): - As 'admin' user: * Create a survey of type 'Appraisals' and name it 'Test No Access' * Set `Restricted to' to 'admin' user only. - As 'demo' user: * Create an appraisal for another employee * Click on "Confirm" button * Click on "Ask Feedback" button * Try to choose an Employee. An exception is raised saying we don't have 'read' access to the survey 'Test No Access'. This commit force computing `survey_template_id` as non-superuser only get survey that the user has access to. Forward-Port-Of: odoo/enterprise#98348
Monthly minimum rental periods now use real calendar months instead of assuming every month has 30 days. This prevents valid rentals in shorter months, such as February, from being incorrectly rejected on the website.
Original PR description
Issue: Currently minimum rental duration uses a hardcoded 30 days. This cause issue for non-30 days month e.g. Feb. which is 28 days. To reproduce: 1- Install `website_sale_renting` 2- From Setting,…
Issue: Currently minimum rental duration uses a hardcoded 30 days. This cause issue for non-30 days month e.g. Feb. which is 28 days. To reproduce: 1- Install `website_sale_renting` 2- From Setting, set `Minimum Rental Duration` to 1 month. 3- Create a rental product and from website, choose the date: - 01/02/2026 - 28/02/2026 4- This fails. The earliest end date it accepts is 03/03/2026. Cause: This is due to hardcoded 30 days: https://github.com/odoo/enterprise/blob/7ffb9f3cb0d818cf3616d6972df424bf0ca251a4/website_sale_renting/static/src/js/renting_mixin.js#L7-L12 https://github.com/odoo/enterprise/blob/7ffb9f3cb0d818cf3616d6972df424bf0ca251a4/website_sale_renting/static/src/js/renting_mixin.js#L47-L53 We can use luxon plus method instead. ```diff + const minEndDate = startDate.plus(Object.fromEntries([[unit, duration]])); ``` In all usages of `msecPerUnit` we can do the same. Also we can keep remove `msecPerUnit` from master. opw-5094534 Forward-Port-Of: odoo/enterprise#98967 Forward-Port-Of: odoo/enterprise#98168
Barcode internal transfers now refresh available stock quantities when the selected product or source location changes. This helps warehouse staff see accurate stock availability while preparing transfers, reducing confusion and operational errors.
Original PR description
Issue: In this bug, stock quants are not being updated when product_id or location_id is updated. To reproduce: 1- Create a db with demo database and barcode installed 2- Enable storage locations 3- Open barcode -> operations -> Internal transfers -> New 4- Add a product -> e.g. Drawer which there are quants in demo 5- As you see quants are not shown Cause and Fix: This is a partial backport of: #55917 `_compute_product_stock_quant_ids` should depend on `product_id` and `parent_location_id` to be recomputed when product or source location is updated. opw-5065624 Forward-Port-Of: odoo/enterprise#98900 Forward-Port-Of: odoo/enterprise#95906
This change prevents certain payment-related tests from running when the required accounting component is not installed. It helps avoid false test failures and keeps validation results reliable without changing customer-facing functionality.
Original PR description
We have tests for payment wihtout journal entries. But these payments can only be generated if accountant in installed. It makes these tests fail if the module is not installed. To avoid making a bridge module only to test these, we add a class that will be skipped if the module is not installed. runbot-232728 Forward-Port-Of: odoo/enterprise#97764