Daily updates from Odoo
Thursday, February 6, 2025
55 changes · 18.0
New functionality added to Odoo
Odoo can now connect sales products to Gelato templates, automatically creating matching product variants from Gelato attributes. When customers order those variants, Odoo can forward the order to Gelato for printing and dropshipping, reducing manual fulfillment work.
Original PR description
This commit adds the possibility to fetch attributes of a template configured on Gelato to automatically create the corresponding variants in Odoo. When such variant is included in a sales order, the order is forwarded to Gelato to trigger the printing and dropshipping of the product. task-3935688 See also: - https://github.com/odoo/enterprise/pull/77839 - https://github.com/odoo/documentation/pull/11823
Odoo now automatically suggests the correct Dutch VAT payment reference when users pay VAT settlements from the dashboard. This reduces manual lookup work for accounting firms and helps ensure payments use the expected reference for each return.
Original PR description
…nt reference for Dutch users The VAT payment reference in the Netherlands changes with each return and can be computed using a specific formula. This commit enables Odoo to automatically generate and propose the correct reference by default when users pay their VAT settlement from the dashboard. This feature streamlines the process for accounting firms, reducing the need to repeatedly log in to the Dutch Tax Authorities portal. task-4063832
Enhancements to existing features
Translate this new module. Translations were provided by MADI. task-4298921
Original PR description
Translate this new module. Translations were provided by MADI. task-4298921
Resolved issues and error corrections
This update fixes Spanish tax configuration by adding a missing 0% VAT export tax for goods, correcting an incorrect fiscal position, and reactivating taxes that were previously disabled. This helps businesses using Spanish localization apply the right tax treatment and reduce compliance or invoicing errors.
Original PR description
This commit : - adds missing VAT 0% export (goods) tax - correct erroneous fiscal position - reactivate taxes that were deactivated with https://github.com/odoo/odoo/commit/401a961258e991151370899d4b61809879d5a5a8 after reconsideration Task: 4453629
The French accounting upgrade now avoids assigning standard identifiers to bank records with unusual custom BIC codes. This prevents custom bank data from being mistaken for official module-provided records during migrations.
Original PR description
The upgrade script is supposed to create xmlids for french banks that were already created from csv, if it matches custom records that have unusual bic, it is better to skip the whole record. Standard BIC format is a capital alphanumeric only. Replacing the spaces or unsupported characters in the xmlid will result in custom records looking like they come from standard module. alternate fix for https://github.com/odoo/odoo/pull/191970 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale users can once again filter products by category while using search. This restores expected behavior from earlier versions, making it easier and faster for cashiers to find the right products during checkout.
Original PR description
Before this commit, it wasn't possible to filter products by category when searching. This functionality was available in previous versions but was removed during refactoring. opw-4439314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Partner Autocomplete now avoids browser caching issues when used from different Odoo subdomains. This prevents failed company suggestion lookups and makes partner data entry more dependable for users on hosted Odoo databases.
Original PR description
The Partner Autocomplete service was unreliable when used on a database hosted under a subdomain of odoo.com (i.e. from *.odoo.com). This was caused by a combination of the CORS policy of the Autocomplete API of Clearbit and the caching of the browser. If the user performed a first request with search query "Odoo" from https://a.odoo.com, the browser would cache the results, including the `Access-Control-Allow-Origin` header set to `https://a.odoo.com`. The same request performed from https://b.odoo.com would lead to a CORS policy error as the browser would use the cached response from earlier request. This commit addresses the issue by disabling the caching of the requests made to the Clearbit Autocomplete API.
Invoices linked to sales orders with multiple partial down payments can now be sent to the Italian tax agency without triggering an error. This prevents failed invoice validation/printing in that scenario and keeps the Italian electronic invoicing workflow reliable.
Original PR description
- Create a sale order and confirm it
- Create two partial down payments for that sale order and confirm them
- Create a invoice for the remaining amount and confirm it
- Send and print the invoice (with Send to Tax Agency selected)
- Traceback
<a/>
File "addons/account/models/account_tax.py", line 2475, in _dispatch_negative_lines
line.setdefault('discount_amount', line['discount_amount_before_dispatching'])
KeyError: 'discount_amount_before_dispatching'
bbe04fb62916ae326c830e89b2664dfd32b62b75 removes elements from base_list while looping over it.
In `17.0` this doesn't cause this error because we have two loops; one that sets 'discount_amount_before_dispatching' and after that one that remove downpayment from base_lines. But the fix should still be backported because it works by chance.
Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4496310)
opw-4496310This fixes an accounting issue where tax reporting tags from a bill or invoice base line could be incorrectly copied onto a tax line when a tax has multiple tax distribution lines. The correction helps keep journal items and tax reports accurate for affected purchase or sales taxes.
Original PR description
**Steps to reproduce:** - Install Accounting - Create a tax with the following configuration: * Tax Type: Purchases (also reproducible with Sales) * Included in Price: [any] * Affect Base of…
**Steps to reproduce:**
- Install Accounting
- Create a tax with the following configuration:
* Tax Type: Purchases (also reproducible with Sales)
* Included in Price: [any]
* Affect Base of Subsequent Taxes (include_base_amount): [checked]
* Base Affected by Previous Taxes (is_base_affected): [checked]
* Distribution:
| % | Based On | Account | Tax Grids |
| ------ | ------------- | ------------ | -------------- |
| | Base | | +Tag_1 +Tag_2 |
| 100.00 | of tax | Account X | +Tag_3 |
| -100.00 | of tax | Account Y | -Tag_4 |
(Or FR localization and "20% EU G" purchase tax can be used)
- Create a bill
- Add a line with the created tax
- Check journal items
**Issue:**
The tax tags of the base line are also added to first tax line.
**Cause:**
When a tax is "include_base_amount", the tags of its base line is propagated to the tax lines of the following taxes. However in this case, as there are several tax lines for the same tax, the system propagate the tags to the second one as if it was coming from another tax.
**Solution:**
Check if the tags are coming from another tax before adding them.
opw-4510882
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prHTML content saved from templates is now cleaned up before being shown or edited, preventing browsers from misreading self-closing elements and changing the page structure. This helps preserve the intended layout and behavior of rich text content across editor and viewer screens.
Original PR description
HTML content is often saved as XML (i.e. through templates) and saved as such in the database. This introduces issues when elements are written under their `self-closing` format (i.e. `<a/>` or…
HTML content is often saved as XML (i.e. through templates) and saved as such in the database. This introduces issues when elements are written under their `self-closing` format (i.e. `<a/>` or `<br/>`) as browsers will incorrectly parse these values as HTML by adding a closing tag at an arbitrary position which may modify the initial nodes configuration. This can be prevented by post-processing untrusted content before the html parsing. This commit is an overhaul of: https://github.com/odoo/odoo/commit/26b922ef5cad42da7e188195e919e54878d472fc https://github.com/odoo/odoo/commit/1a8a943d8373864165cb513b3767b866d626fad8 https://github.com/odoo/odoo/commit/4e547b24a323f8e59a11c5b78cbea38effc37938 in order to apply the conversion at critical entry points for editor assets: - HtmlField is an entry point for data coming from the server, stored on the record. Every access of the record data should not be trusted and go through the post-processing. - HtmlViewer is an entry point as it can be used as a standalone (see `website_knowledge`, or the HistoryDialog) for data coming from the server. - Editor is an entry point as it was developed to be useable as a standalone. task-4547973
Sending an invoice a second time now reuses the already generated PDF instead of trying to create or modify it again. This prevents an audit-trail error in German invoicing flows and makes repeated invoice sending more reliable.
Original PR description
Steps to reproduce: [l10n_de] - create an invoice - confirm the invoice - send the invoice - send the invoice again Issue: You will get an error "You cannot remove parts of the audit trail. Archive…
Steps to reproduce: [l10n_de] - create an invoice - confirm the invoice - send the invoice - send the invoice again Issue: You will get an error "You cannot remove parts of the audit trail. Archive the record instead." Cause: We don't prevent entering the hook if there is already a generated pdf. During the hook, we want to "generate a Factur-X and embed it inside the PDF for inter-portability" https://github.com/odoo/odoo/blob/84a0b81a258262e3bb9dbaa9c9f37796303a9dad/addons/account_edi_ubl_cii/models/account_move_send.py#L124-L128 In the German loca, while trying to write on the attachment, we'll check that the move has not been already posted. In which case it will raise the error https://github.com/odoo/odoo/blob/5215428114842c606202e7b1c69f5f597a977f92/addons/l10n_de/models/ir_attachment.py#L13-L34 solution: Prevent entering the hook if there is already a pdf as it is done a few lines before https://github.com/odoo/odoo/blob/9f65f1a3b0b6b893f230729c56f287f5aff6af35/addons/account/models/account_move_send.py#L607 opw-4471377
This change fixes a failing automated check related to the restaurant point-of-sale tip screen. It helps keep the restaurant POS workflow stable and prevents build failures from blocking future updates.
Original PR description
Error runbot: 111972
This fixes an error in Spanish TicketBAI invoice XML where invoices with multiple tax types on one line could show an inflated total. The correction helps ensure submitted electronic invoices match the real invoice amount and avoids reporting discrepancies.
Original PR description
Steps to reproduce: ------------------- - In a Spanish company, make sure l10n_es_edi_tbai is installed. - Create an invoice with one product and add 2 taxes for that line (for example, the 21% goods…
Steps to reproduce: ------------------- - In a Spanish company, make sure l10n_es_edi_tbai is installed. - Create an invoice with one product and add 2 taxes for that line (for example, the 21% goods and the 5.2 ES tax). - Confirm and send the invoice with TBAI. - In the TBAI xml you will find the total amount wrong as the base amount was calculated twice, one time for each tax. Cause: ----- Since (#180062), the tax details calculation process was reworked. the total amount is calculated inside a loop with this formula ``` for values in values_per_grouping_key.values(): total_amount += values['base_amount'] + values['tax_amount'] ``` In case one invoice line has 2 taxes of different tax groups, this code will add the base_amount twice in the total_amount calculation. Fix --- Move the base amount addition in a separate loop with a new aggregation (with no grouping) to add the base amount to the total. opw-4501051 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The GSTIN status button and update action now appear only when the user is working with Indian companies. This prevents incorrect GSTIN status checks in multi-company setups and helps ensure the right tax environment is used.
Original PR description
This commit fixes a few issues in multi-company context: - only show the GSTIN status/update button when user has at least one IN companies selected - only allow the update when user's active company is an IN company (to ensure we correctly determine the EDI test/production status) opw-4367302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could stop users from attaching files by URL when the external response did not include expected file type information. The change makes the editor handle that missing detail safely, improving reliability when adding linked attachments.
Original PR description
This error occurs when ``content-type`` is not found in the response when attaching any file with the type ``URL``. Traceback: --- ``` KeyError: 'content-type' File "odoo/http.py", line 2366, in…
This error occurs when ``content-type`` is not found in the response when attaching any file with the type ``URL``.
Traceback:
---
```
KeyError: 'content-type'
File "odoo/http.py", line 2366, in __call__
response = request._serve_db()
File "odoo/http.py", line 1894, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1957, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1924, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2171, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/html_editor/controllers/main.py", line 355, in add_url
attachment = self._attachment_create(url=url, res_id=res_id, res_model=res_model)
File "addons/html_editor/controllers/main.py", line 256, in _attachment_create
mime_type = response.headers['content-type']
File "requests/structures.py", line 52, in __getitem__
return self._store[key.lower()][1]
```
https://github.com/odoo/odoo/blob/2fe55ae592e5812c5ee5e39ed1e8332bde608cb2/addons/html_editor/controllers/main.py#L257
sentry-6015024235
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSwiss invoices generated with the “PDF without payments” action no longer produce an extra blank page. The fix ensures the special invoice PDF is recognized for required payment QR-code processing without making it appear as a standard invoice template in other workflows.
Original PR description
Steps to reproduce: - Install "l10n_ch" and switch to a Swiss company - Create a new invoice with a Swiss customer - Confirm - In the actions, select "PDF without payments" - The generated PDF has a…
Steps to reproduce: - Install "l10n_ch" and switch to a Swiss company - Create a new invoice with a Swiss customer - Confirm - In the actions, select "PDF without payments" - The generated PDF has a blank page at the end Cause: Some computation looks for report applicable to invoices. PDF without payment (`report_invoice_with_payments`) is a special case of such report. We don't want it to be used as an official report template for invoices, but we want to allow the Swiss case where the payment QR code should be possible to add. The bug appears after this commit which modified the `_is_invoice_report` method to only validate report with is_invoice_report=True. https://github.com/odoo/odoo/commit/bb60952c944db27d71d7fe32ead2dff05c3fe922#diff-b6e108b605fbefba066e3b20f8e030ea78881bbed816f8ac5cb38e745c542739R50 Solution: Fix the method _is_invoice_report to recognize PDF without payment, without setting the latter to is_invoice_report=True (which triggers undesirable behaviors surch as showing multiple templates in the Print & Send wizard). opw-4467250
Egyptian electronic invoice files now calculate net and total amounts correctly when one invoice line has more than one tax type. This prevents duplicated base amounts in ETA submissions, reducing the risk of rejected or inaccurate tax reporting.
Original PR description
Currently, when multiple taxes type are applied to the same invoice line, the netAmount and totalAmount fields in the ETA file are incorrectly calculated. Steps to reproduce: 1. Install the module l10n_eg_edi_eta. 2. Create a new invoice with multiple tax types applied to the same product. 3. Generate the ETA JSON file. Issue: The resulting file contains incorrect values for netAmount and totalAmount because these amounts were calculated by summing the base_amount from values_per_grouping_key. However, since grouping is done by tax type, the base_amount is duplicated (once per tax type), leading to incorrect totals. This fix ensure that base_amount is not counted multiple times. See official documentation for more details: https://sdk.invoicing.eta.gov.eg/document-validation-rules/#validation-on-level-of-invoice opw-4457780
The SMS option is no longer shown in general settings because users could misunderstand it and accidentally trigger removal of installed apps. Removing the checkbox helps prevent costly database recovery situations and keeps settings safer to use.
Original PR description
This commit removes the module_sms field from the settings view. When it was present unchecking it could potentially remove all the apps installed on a DB. Depending on what was installed. The main issue was that user misinterpreted the use of this checkbox leading to situation where the DB needed to be restarted from a backup. To fix this issue it was decided for now to remove the checkbox from the settings view. This will prevent these situations to happen again in the future. task-4526115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes Spanish localization tax data by restoring price-inclusion override settings that were removed by mistake. It helps ensure Spanish tax calculations keep the intended behavior for affected accounting setups.
Original PR description
On https://github.com/odoo/odoo/commit/06d3ef5853aa0a93ac2de1642fd11ea191a3bbd3 price_include_override were erroneously removed
This fixes an issue where completed recruitment surveys showed no participants in the Participations section. Recruiters and HR teams can now see candidate survey responses where expected, improving visibility during hiring workflows.
Original PR description
**Issue** Recruitment-type surveys do not appear in the Participations section, even when participants have completed the survey. Steps to Reproduce: 1. Install hr_recruitment_survey module 2. Open…
**Issue** Recruitment-type surveys do not appear in the Participations section, even when participants have completed the survey. Steps to Reproduce: 1. Install hr_recruitment_survey module 2. Open the Surveys app. 3. Create a new survey or open an existing one. 4. Set the survey type to Recruitment. 5. Click on the Participations smart button. Expected behavior: Participants who completed the survey should be listed. Actual behavior: No participants are shown. **Root Cause** https://github.com/odoo/odoo/blob/de935a1b3ad96e24b5fd1bd317c73c12e9b3a08f/addons/survey/models/survey_survey.py#L1090-L1096 Once the smart button is clicked, the action variable is populated through the following record https://github.com/odoo/odoo/blob/de935a1b3ad96e24b5fd1bd317c73c12e9b3a08f/addons/survey/views/survey_user_views.xml#L153-L168 The record includes a domain filter that restricts the displayed results to specific survey types. Since "recruitment" is not listed among the accepted survey types, it fails the check and is excluded from the results. **Fix** Overriding the action_survey_user_input action template in XML to extend the domain was impractical because it replaced the existing domain rather than extending it. This prevented seamless integration with other modules, limiting flexibility. Instead, we opted to extend the domain within the action's returned values, ensuring better modularity and maintainability. opw-4516112 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where users could not print checks when the payment account did not allow reconciliation and the payment was immediately marked as paid. Check printing is now allowed in this case, preserving prior behavior, while voiding or rejecting these paid checks remains blocked.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Accounting / Journals" - Open "Bank" Journal - Go to "Outgoing Payments" tab - Set a check layout - For "Checks"…
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Accounting / Journals" - Open "Bank" Journal - Go to "Outgoing Payments" tab - Set a check layout - For "Checks" line, set "101401 Bank" (i.e. an account that doesn't allow reconciliation) as outstanding payments account - Create a vendor bill and confirm it - Pay the bill with "Checks" as payment method => The bill is directly marked as "PAID" and not "IN PAYMENT" because the "Bank" account doesn't allow reconciliation - Go the the check payment **Issue:** It is not possible to print it. The same configuration allows to print the check in previous versions. **Cause:** As the check payment is using an account that doesn't allow reconciliation, the payment is set in "Paid" state directly, but the printing is disabled for checks in that state. **Solution:** As it should be harmless to allow to print the check even if it is already paid, we will allow to print it to keep a consistent behavior with previous versions. Only printing the check will be allowed. Voiding or rejecting will still be impossible. opw-4498446 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the point of sale Self Order flow from trying to subscribe to a missing or undefined communication channel. It helps avoid avoidable errors and improves reliability for customers using self-ordering.
Original PR description
Prevent subscription to undefined channel name in Self Order.
This fix corrects a few mislabeled Peppol electronic address scheme names that were introduced in a prior update. It helps users select the right invoicing identifiers and reduces confusion when configuring electronic invoicing partners.
Original PR description
Previous commit ([1]) tried to simplify with less technical names the Peppol EAS but introduced small errors. [1]: https://github.com/odoo/odoo/commit/5c7eefed412e676c6ddf67f62bce514e5bade44c task-no
This fix ensures stock-related actions triggered by subscriptions, rentals, and field service sales pass quantity information consistently. It reduces the risk of order processing errors and also avoids an access issue for project users working with field service sales orders.
Original PR description
The override of `_action_launch_stock_rule` was passing its `previous_product_uom_qty` keyword argument as a positional parameter to the `super` call, preventing other overrides from passing it with its key name. This commit ensures that the argument is now passed correctly with its key name. It also makes the override kwargs-agnostic by packing and unpacking them with `**`, thus preventing future issues related to signature changes in the parent method. See also: - https://github.com/odoo/enterprise/pull/77839 - https://github.com/odoo/documentation/pull/11823
Fixed an issue where loading more Intrastat report lines could repeatedly fetch the same records, causing duplicate entries and a client-side error. The report now loads additional lines in the correct order, improving stability when reviewing larger Intrastat reports.
Original PR description
The issue occurs because the query does not apply an offset or limit, causing the same lines to be loaded repeatedly. This results in duplicate keys on the client side. To fix this, we add a query tail and mimic the ordering of account_move_line, ensuring consistency when loading additional lines. This fix is related to an earlier patch in older versions, but due to the refactoring of the Intrastat report, it had to be implemented differently. Old Fix: https://github.com/odoo/enterprise/pull/76543
This update ensures Knowledge content saved from templates displays as intended when opened in the browser. It prevents formatting and layout problems caused by self-closing HTML elements being interpreted incorrectly.
Original PR description
HTML content is often saved as XML (i.e. through templates) and saved as such in the database. This introduces issues when elements are written under their `self-closing` format (i.e. `<a/>` or `<br/>`) as browsers will incorrectly parse these values as HTML by adding a closing tag at an arbitrary position which may modify the initial nodes configuration. This can be prevented by post-processing untrusted content before the html parsing. Check this commit community counterparts, which place the conversion responsibility in the `html_viewer` instead of the `html_upgrade_manager`. task-4547973
French companies can now send their VAT return even when the setting to add totals below report sections is enabled. The fix prevents extra total lines from being included in the electronic submission formatting, avoiding an error that blocked filing with the French government.
Original PR description
**Current behavior:** When a user wants to upload its VAT return to the French Government, they receive the following error message: ``` report_line_code = report_lines_code_per_id[report_line_id]…
**Current behavior:**
When a user wants to upload its VAT return to the French Government, they receive the following error message:
```
report_line_code = report_lines_code_per_id[report_line_id]
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
KeyError: None
```
**Expected behavior:**
The user should be able to upload their VAT return without any error message.
**Steps to reproduce:**
1. Create a French company, using French Accounting. (`l10n_fr_reports`, `l10n_fr_account`).
2. In the Settings, activate the Analytics option "Add totals below sections".
3. Go to Tax reports > Actions > EDI TVA > Send Report
**Cause of the issue:**
When the "Add totals below sections" parameter is enabled, the system will add new total lines on the report for each group of report lines. In the case of the Standard French VAT report, a single total line is added.
The issue is that before sending the report, the values are formatted by `_get_formatted_edi_values`. Each line to format is mapped to its corresponding line ID in line [255](https://github.com/odoo/enterprise/blob/0c32410b50b0edc2bc68c3199f741756b49600a2/l10n_fr_reports/wizard/l10n_fr_send_vat_report.py#L255): `report_line_id = self.report_id._get_model_info_from_id(line['id'])[-1]` Alas, for the new total lines, the line ID and its corresponding model are both None, which leads to an error on the next line. In version 17.0, there was a check for the model of the line, which was removed in version 18.0.
**Fix:**
- Add a check on the model of the line before formatting its values, to prevent the total lines from being formatted and sent.
opw-4496692The Overdue Invoices button on a partner now shows only sales-related documents, rather than including unrelated miscellaneous accounting entries. This helps users focus on the invoices that actually need follow-up and avoids confusion in customer account reviews.
Original PR description
When opening the Invoice Overdue through the partner form: 1 - Create over due MISC entries (through deferred entries for example) 2 - Open a partner 3 - Go the the Accounting tab 4 - Click the Overdue Invoices button -> Some MISC entries show while we only want to view sale document. This commit fixes that by adding a filter on the domain to reduce the search scope to only sale documents. task-4523037
Confirmed subscription sales orders no longer trigger an error when the Start Date or Next Invoice Date is changed or removed. This helps sales teams update subscription timing without interruptions.
Original PR description
This error occurs when attempting to change the ``Start Date`` or ``Next Invoice Date`` after the Sales Order has been confirmed. Steps to reproduce: --- - Install ``sale_subscription_stock`` module - Create a ``New`` Sale Order and fill in the required fields and order line - Now add ``Recurring Plan`` and in ``Other Info`` add ``Start Date`` > Confirm - Remove ``Start Date`` Traceback: --- ``TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'`` At [1] this commit resolves the issue by verifying the presence of the ``Start Date`` and ``Next Invoice Date``. [1]- https://github.com/odoo/enterprise/blob/68fa2f5ea8c42ccb66823efb847d230fe3994527/sale_subscription_stock/models/sale_order.py#L21 sentry-6220852935
Miscellaneous changes
Since HS Code field is now also used in USPS connector, the help text of `hs_code` field on `product_template` needs to be updated. Also the POT file containing module titles and descriptions is updated. Task-3759325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196518 Forward-Port-Of: odoo/odoo#187405
Original PR description
Since HS Code field is now also used in USPS connector, the help text of `hs_code` field on `product_template` needs to be updated. Also the POT file containing module titles and descriptions is updated. Task-3759325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196518 Forward-Port-Of: odoo/odoo#187405
Current behavior: The previous closing amount is used instead of the cash opening when printing the session report so the expected cash amount is wrong. Steps to reproduce: Open a PoS session with 100€ in the cash register and close it. Reopen the session and enter 50€ in the cash register. Make a sale for 10€, using cash payment. Close the session and print the session report. The expected cash amount will be 110€ when it should be 60€. Fixes opw-4497263 Forward-Port-Of: odoo/odoo#
Original PR description
Current behavior: The previous closing amount is used instead of the cash opening when printing the session report so the expected cash amount is wrong. Steps to reproduce: Open a PoS session with 100€ in the cash register and close it. Reopen the session and enter 50€ in the cash register. Make a sale for 10€, using cash payment. Close the session and print the session report. The expected cash amount will be 110€ when it should be 60€. Fixes opw-4497263 Forward-Port-Of: odoo/odoo#196395
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform. This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform. Authentication: the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFa
Original PR description
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform. This commit implements a way to gather all…
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform.
This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform.
Authentication:
the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFactura PR](https://github.com/odoo/odoo/pull/144061)
eTransport flow:
- Add the necessary eTransport data to a delivery
- send the eTransport document to ANAF
- the document gets processed by ANAF
- Fetch the status of the document:
- which can result in an error, in which case the flow starts again from the beginning with the corrected data
- or in a success
task-id: 3810735
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#194858
Forward-Port-Of: odoo/odoo#170080Running the “test_workcenter_with_resource_calendar_from_another_company” without demo data occurs an error because the resource calendar. Forward-Port-Of: odoo/odoo#196656
Original PR description
Running the “test_workcenter_with_resource_calendar_from_another_company” without demo data occurs an error because the resource calendar. Forward-Port-Of: odoo/odoo#196656
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entr
Original PR description
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today,…
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entries which have simply not been posted yet. Reconciliation should be deferred until these moves are no longer in draft. **Steps to reproduce:** 1. Activate another currency, define some rate for today and another (different) rate for tomorrow 2. Create a product with FIFO and real-time costing & valuation 3. Create an initial purchase for the product, receive then bill normally 4. Create another purchase order and receive the product 5. Create the invoice, set the invoie date for tomorrow 6. Post the invoice -> Open the `Exchange Difference` journal to see the entries which should not have been generated **Cause of the issue:** After creating the AMLs which represent the difference in reception/bill unit price of the product, they are caught here: https://github.com/odoo/odoo/blob/971400771a31c05641a8672f6b1d85afaa9c4a19/addons/account/models/account_move.py#L3575 and designated as future moves, not to be posted at this time. At the end of the `_post()` stack: https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L229 where there would normally be some `correction_amls`, they weren't created here because the AMLs for the price diff were not posted- so the price diff entry is generated. **Fix:** Wait for pending (`state == 'draft'`) AMLs that are part of some `AccountMove`'s valuation to be no longer in draft before allowing reconciliation with a currency exchange difference. opw-4266652 Forward-Port-Of: odoo/odoo#196140 Forward-Port-Of: odoo/odoo#193971
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
Original PR description
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
Original PR description
@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#196451 Forward-Port-Of: odoo/odoo#193008
Original PR description
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#196451 Forward-Port-Of: odoo/odoo#193008
When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings. To reproduce: - `-i sale_stock,sale_management` - Create a storable product (I) with 30 qty on hand - Create and confirm an internal transfer to put the product I in a pack (P) - Create and confirm two SO : - Sell 10 I - Sell 20 I - Check the 2 SO delivery pickings (D): - Each are r
Original PR description
When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings. To reproduce: - `-i sale_stock,sale_management` - Create a storable product (I) with 30 qty on hand - Create and confirm an internal transfer to put the product I in a pack (P) - Create and confirm two SO : - Sell 10 I - Sell 20 I - Check the 2 SO delivery pickings (D): - Each are reserved from pack P - They don't have any 'Destination Package' [Expected] - From the picking list view, by selecting the 2 pickings D : - 'Unreserve' them both - 'Check Availability' them both - Check the pickings D: - Each are reserved from pack P - Each have 'Destination Package' P [Faulty] opw-4272573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193745
Versions -------- - 17.0+ Steps ----- 1. Enable Adyen as payment provider in test mode; 2. do an eCommerce checkout; 3. select Adyen as payment option; 4. use the following card details[^1]: - card number: 4111111111111111 - expiry: 03/30 - cvc: 737 - name on card: CARD_EXPIRED 5. click Pay Now; 6. check order chatter on the backend. Issue ----- > Error: Adyen: Received data with invalid payment state: Refused Refusal shouldn't be an invalid payment state.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Enable Adyen as payment provider in test mode;
2. do an eCommerce checkout;
3. select Adyen as payment option;
4. use the following card details[^1]:
- card number: 4111111111111111
- expiry: 03/30
- cvc: 737
- name on card: CARD_EXPIRED
5. click Pay Now;
6. check order chatter on the backend.
Issue
-----
> Error: Adyen: Received data with invalid payment state: Refused
Refusal shouldn't be an invalid payment state.
Cause
-----
Commit 04f75728fd3e accidentally removed an `elif` branch that was added by commit 4d340a330462e specifically to handle refused payments.
Solution
--------
Re-add the `elif` branch.
opw-4481602
[^1]: https://docs.adyen.com/development-resources/testing/result-codes#values-for-testing-result-reasons
Forward-Port-Of: odoo/odoo#196394Before this commit: 1. Install `ressource` module 2. In debug, open "Run unit tests" debug menu 3. Error pop-up: ```js Global Error: stack trace available in the console Missing dependencies: @mail/../tests/mail_test_helpers ``` After this commit: No error and units tests can proceed Related runbot task: https://runbot.odoo.com/odoo/runbot.build.error/72187 Forward-Port-Of: odoo/odoo#196488 Forward-Port-Of: odoo/odoo#195824
Original PR description
Before this commit: 1. Install `ressource` module 2. In debug, open "Run unit tests" debug menu 3. Error pop-up: ```js Global Error: stack trace available in the console Missing dependencies: @mail/../tests/mail_test_helpers ``` After this commit: No error and units tests can proceed Related runbot task: https://runbot.odoo.com/odoo/runbot.build.error/72187 Forward-Port-Of: odoo/odoo#196488 Forward-Port-Of: odoo/odoo#195824
Steps to reproduce: - Go to the "/blog" page. - Click on "Configuration > Blogs" in the main navbar. - Create at least 15 new blogs with "Astronomy" as the name. - Go back to the "/blog" page. - Bug: The navbar overflows the page to the right, causing a horizontal scrollbar to appear. After this commit, the navbar no longer overflows, and the list items are displayed on multiple lines. [opw-4507558](https://www.odoo.com/web#id=4507558&cids=1&menu_id=4720&action=333&active_id=1695&
Original PR description
Steps to reproduce: - Go to the "/blog" page. - Click on "Configuration > Blogs" in the main navbar. - Create at least 15 new blogs with "Astronomy" as the name. - Go back to the "/blog" page. - Bug: The navbar overflows the page to the right, causing a horizontal scrollbar to appear. After this commit, the navbar no longer overflows, and the list items are displayed on multiple lines. [opw-4507558](https://www.odoo.com/web#id=4507558&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#196452 Forward-Port-Of: odoo/odoo#195859
**Issue:** Users are able to delete timesheets associated with public holidays, unlike regular time off requests **Steps to Reproduce:** - Ensure "Time Off" is enabled in the Timesheet settings. - Time Off > Configurations > Public Holidays. - Create a new public holiday. - Timesheet > My Timesheet (list view). - Attempt to delete the timesheet entry corresponding to the public holiday. The entry is deleted without any warning. opw-4464411 --- I confirm I have s
Original PR description
**Issue:** Users are able to delete timesheets associated with public holidays, unlike regular time off requests **Steps to Reproduce:** - Ensure "Time Off" is enabled in the Timesheet settings. - Time Off > Configurations > Public Holidays. - Create a new public holiday. - Timesheet > My Timesheet (list view). - Attempt to delete the timesheet entry corresponding to the public holiday. The entry is deleted without any warning. opw-4464411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196506 Forward-Port-Of: odoo/odoo#195379
Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Fo
Original PR description
Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Forward-Port-Of: odoo/odoo#196486 Forward-Port-Of: odoo/odoo#196433
Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319 Forward-Port-Of: odoo/odoo#196456
Original PR description
Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319 Forward-Port-Of: odoo/odoo#196456
Steps to reproduce the bug: - Create two delivery transfers. - Add them to a single batch transfer. - Assign a responsible person to the batch transfer. - The assigned responsible person will automatically be updated in all related transfers. - Now, remove the responsible person from the batch transfer. Problem: When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible
Original PR description
Steps to reproduce the bug: - Create two delivery transfers. - Add them to a single batch transfer. - Assign a responsible person to the batch transfer. - The assigned responsible person will automatically be updated in all related transfers. - Now, remove the responsible person from the batch transfer. Problem: When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible person is removed from the batch transfer, this change is not applied to the individual transfers linked to it. opw-4519994 Forward-Port-Of: odoo/odoo#196487 Forward-Port-Of: odoo/odoo#196333
**Problem**: Removing spaces impacts composed values like (`padding: 10px 20px` → `padding: 10px20px`), making them invalid. **Solution**: Replace multiple spaces with a single space instead of removing them, to ensure composed values remain intact. **Steps to Reproduce**: 1. Open Email Templates > any template. 2. Add `padding: 10px 20px` to a `tr` element. 3. Save the template. 4. Observe that padding is not applied. --- I confirm I have signed the CLA and read the PR guidelin
Original PR description
**Problem**: Removing spaces impacts composed values like (`padding: 10px 20px` → `padding: 10px20px`), making them invalid. **Solution**: Replace multiple spaces with a single space instead of removing them, to ensure composed values remain intact. **Steps to Reproduce**: 1. Open Email Templates > any template. 2. Add `padding: 10px 20px` to a `tr` element. 3. Save the template. 4. Observe that padding is not applied. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196564 Forward-Port-Of: odoo/odoo#196376
Previously, the Mail Failure icon was a .JPG, which lacked transparency. While this was not noticeable in Odoo Light Mode, it resulted in a visible white background in Dark Mode. This commit replaces the JPG with an SVG, ensuring proper transparency. | Current (17.0) | Fix | |--------|--------| |  |  | |  |  | |  |  | task-4531425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196400
Description of the issue/feature this PR addresses: - After an internal user (without Live Chat application access) interacted with chatbot from website, he will not be able to click on the Messages icon on the top-right menu anymore:  - Cause: Internal user without Live Chat application access cannot read on model `chatbot.script.step`, so when system calls `mail_channel.chatbot_current_step_id`, securit
Original PR description
Description of the issue/feature this PR addresses: - After an internal user (without Live Chat application access) interacted with chatbot from website, he will not be able to click on the Messages icon on the top-right menu anymore:  - Cause: Internal user without Live Chat application access cannot read on model `chatbot.script.step`, so when system calls `mail_channel.chatbot_current_step_id`, security error occurs. - Solution: Use `sudo` on `mail_channel` variable to avoid security error. 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#190201 Forward-Port-Of: odoo/odoo#174611
This new module should replace the existing implementation for USPS integration which uses XML which is not the recommended API currently by USPS. The new integration uses USPS's latest RESTful APIs: https://developer.usps.com/apis. Task-3759325 Forward-Port-Of: odoo/enterprise#78560 Forward-Port-Of: odoo/enterprise#73906
Original PR description
This new module should replace the existing implementation for USPS integration which uses XML which is not the recommended API currently by USPS. The new integration uses USPS's latest RESTful APIs: https://developer.usps.com/apis. Task-3759325 Forward-Port-Of: odoo/enterprise#78560 Forward-Port-Of: odoo/enterprise#73906
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current behavior before PR: If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-". Desired behavior after PR is merged: If an electronic invoice is sent to DGI with a line without product id but with a lab
Original PR description
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current…
Description of the issue/feature this PR addresses:
This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label.
Current behavior before PR:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-".
Desired behavior after PR is merged:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with the product description.
Steps to reproduce the issue:
- Create an electronic invoice on an uruguayan company.
- Add a line without a product and add a label, a unit price, quantity and tax.
- Confirm the invoice and create CFE.
- Check that the field "NomItem" is field with a "-" instead of the product label like this:
```
<Item>
<NroLinDet>4</NroLinDet>
<IndFact>2</IndFact>
<NomItem>-</NomItem>
<DscItem>PRODUCT X</DscItem>
<Cantidad>1.000</Cantidad>
<UniMed>N/A</UniMed>
<PrecioUnitario>20.000000</PrecioUnitario>
<MontoItem>20.00</MontoItem>
</Item>
```
Forward-Port-Of: odoo/enterprise#78551Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115
Original PR description
Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root': ``` 2025-02-05 10:29:03,827 4815 ERR
Original PR description
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and…
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box.
However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them
This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root':
```
2025-02-05 10:29:03,827 4815 ERROR ? odoo.addons.hw_drivers.tools.helpers: Failed to delete old IoT handlers
Traceback (most recent call last):
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 435, in delete_iot_handlers
unlink_file(*filenames)
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 534, in unlink_file
path.unlink()
File "/usr/lib/python3.11/pathlib.py", line 1148, in unlink
os.unlink(self)
PermissionError: [Errno 13] Permission denied: '/home/pi/odoo/addons/hw_drivers/iot_handlers/lib/ctep/libeasyctep.so'
```
This PR runs Worldline related script under user "odoo" which fixes the ownership/access issues and allows Odoo service to delete the files.
task-4527243
Forward-Port-Of: odoo/enterprise#78544See commits task-4497852 Forward-Port-Of: odoo/enterprise#78627 Forward-Port-Of: odoo/enterprise#77738
Original PR description
See commits task-4497852 Forward-Port-Of: odoo/enterprise#78627 Forward-Port-Of: odoo/enterprise#77738
The following `response` was being returned when checking the CFDI status: ``` (Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None} ``` Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is h
Original PR description
The following `response` was being returned when checking the CFDI status:
```
(Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa
proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No
Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None}
```
Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is handled correctly.
Forward-Port-Of: odoo/enterprise#78552This commit add a new way to deal with eTIms in the pos application. Before this commit, the only way of sending sales to etims was to generate the invoice at the same time then the pos order, then deal with the invoice later on. Now, everything is automated in the pos order directly, that means when the user post a pos order, she's directly send to etims and all the information returned are displayed on the receipt and the order view. In case the eTims process got an error, the user can s
Original PR description
This commit add a new way to deal with eTIms in the pos application. Before this commit, the only way of sending sales to etims was to generate the invoice at the same time then the pos order, then deal with the invoice later on. Now, everything is automated in the pos order directly, that means when the user post a pos order, she's directly send to etims and all the information returned are displayed on the receipt and the order view. In case the eTims process got an error, the user can still send the order to eTims from the pos_order view. Stock moves are also send at the same time thanks to the l10n_ke_edi_oscu_stock module. Backport of: https://github.com/odoo/enterprise/pull/76247 task-3876855 Forward-Port-Of: odoo/enterprise#78505 Forward-Port-Of: odoo/enterprise#69583