Daily updates from Odoo
Navigate
Branch
Thursday, March 19, 2026
248 changes
11 changes
Resolved issues and error corrections
This update corrects a technical issue in the Account Avatax module, ensuring it correctly identifies the company it's associated with within the system's settings. Previously, a key piece of information was missing, which has now been added to improve data accuracy and functionality. This ensures proper tax calculations and reporting.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. Followup of odoo/odoo#254242 task-none Forward-Port-Of: odoo/enterprise#110983
This update resolves an error that prevented users from accessing the Timesheets Assistant feature. The issue stemmed from a missing employee record, causing a technical error. This fix ensures the Timesheets Assistant functions correctly for all users, regardless of whether they have linked employee records.
Original PR description
Currently, an error occurs when user opens the Timesheets Assistant. **Steps to Reproduce:** - Install the `timesheet_grid` module without demo data. - Go to `Settings` > Enable `Timesheets Assistant (BETA)`. - Now go to `Timesheets` > `Assistance`. **Error:** `KeyError: False` This error occurs because the current user does not have any linked employee record. As a result, the employee is empty [1], and accessing False in the work days data batch [2] raises the error. This commit ensures that if no employee record is linked to the user, working_hours is set to False. [1]: https://github.com/odoo/enterprise/blob/9d4424088bfda7e89d454a8bd642715a9281913d/timesheet_grid/models/account_analytic_line.py#L392 [2]: https://github.com/odoo/enterprise/blob/9d4424088bfda7e89d454a8bd642715a9281913d/timesheet_grid/models/account_analytic_line.py#L399 sentry-7323160235
A recent update to the document layout, including VAT information, caused a test to fail. This fix addresses a problem where the test's selection process was disrupted by the layout change. The update now correctly resets the editor selection, ensuring the test runs successfully.
Original PR description
Issue The test `test_edit_header_only_company` was failing after updating the document layout to include the VAT block in the company address section. Cause Adding the VAT line modified the DOM structure of the header layout. The tour step inserting the placeholder span no longer correctly set the editor selection, preventing the powerbox from opening and causing the test to fail. Solution Update the tour to explicitly reset the editor selection after inserting the span so that the powerbox can open correctly. opw-5373374 Related Community PR : https://github.com/odoo/odoo/pull/249225 Forward-Port-Of: odoo/enterprise#109924
This update fixes a bug preventing the upload of call recordings with transcriptions. The original code bypassed Odoo's data management system, leading to incorrect data values and a security error. The fix ensures correct data handling and allows recordings with transcriptions to be successfully uploaded.
Original PR description
Diagnosis --- Incoming calls use a raw SQL INSERT in 'get_or_create' to create voip calls Since this bypasses the Odoo ORM, fields added by other modules like 'transcription_status' in voip_ai don't get their Python-level default values. Instead, they are stored as NULL in the database, which is read as False in Python. When the softphone tries to upload the recording at the end of the call, the controller's security check for 'no_audio' fails because it finds False instead, triggering a 403 Forbidden error and preventing the transcription. Solution --- This fix overrides 'get_or_create' in voip_ai to manually apply the 'no_audio' default if the field is empty. It also relaxes the controller check to accept both 'no_audio' and False to handle any existing records defenfively. task-6036473
This update ensures that PIN codes are now displayed for both physical and virtual expense cards. Previously, users were blocked from completing transactions using virtual cards (through digital wallets) because they couldn't access their PIN. This change improves the user experience and allows for seamless transactions using all card types.
Original PR description
Before this commit: - Currently, we show the PIN code for physical expense cards only, not for virtual cards. - In some case transactions are made via virtual cards (through digital wallets) also requires a PIN. The users will be blocked because they currently can't access this information. After this commit: - Now we show the PIN code for both physical and virtual cards. task-5926462 Forward-Port-Of: odoo/enterprise#107231
This update fixes a potential issue with portal messages. Specifically, it adds a test case to ensure that avatar access tokens are correctly handled when a user who authored a message is deleted. This prevents incorrect message formatting and improves data consistency.
Original PR description
For PR https://github.com/odoo/odoo/pull/254175; This commit adds a test case to verify that the portal message formatting behaves correctly when the message author is deleted. The test ensures that the avatar access token is returned when the author exists, and is omitted when the related user and partner are deleted. Error: `ValueError - Expected singleton: res.partner()` sentry-7337698605
This update resolves an issue that prevented Dutch companies from correctly setting accounting periods. The fix corrects a mistake in how tax reporting data was accessed, which was causing a technical error. This ensures that users can now reliably create and manage accounting periods for their Dutch clients.
Original PR description
Creating an accounting period for a Dutch company raises a traceback. Steps to reproduce the error: - Install ``l10n_nl_reports`` and ``accountant`` module with demo data - Switch to NL Company - Go to Accounting > In Tax Returns > Click Set Periods > Set Opening Date > Apply Traceback: ```py 'l10n_nl_reports.ec.sales.report.handler' object has no attribute '_get_tax_tags_for_nl_sales_report' ``` https://github.com/odoo/enterprise/blob/f23c592a933d7e5e5745aea60d0dcc5738249580/l10n_nl_reports/models/account_return.py#L20 In commit [1], Here, ``_get_tax_tags_for_nl_sales_report()`` method is called instead of ``_get_ec_sales_tax_tags()``. which leads to the above traceback. [1]:https://github.com/odoo/enterprise/commit/0a0fa0dae918ec5198a019a3e5be71a919f0e7c6 sentry-7340518330
This update resolves a problem where the system incorrectly flagged invoices for EC Sales List compliance when customers were located within the EU. The fix ensures that the 'Only intra-EU customers' check accurately identifies invoices that violate EU regulations, improving data accuracy for tax reporting.
Original PR description
The EC Sales List return check "Only intra-EU customers" is reviewed when an invoice that match the condition for the warning same_country is present. To Reproduce: - Create a company in Belgium - Create a customer in Belgium with "Intra-Community" as a Fiscal Position - Create an invoice with this customer (in the previous month of the current month, for example February if the current date is in March - Open the Tax Returns - Open the EC Sales List Return - The Only intra-EU customers check is reviewed when it should show an anomaly. Forward-Port-Of: odoo/enterprise#107137
This update fixes an issue where cancelled vendor bills were incorrectly included in the Sweden accounting SIE export. The fix ensures that cancelled transactions are properly excluded, aligning the export with the general ledger's balance. This prevents inaccurate reporting and maintains data integrity.
Original PR description
Steps to reproduce: - Install l10n_se (Sweden - Accounting). - Create a Vendor Bill with a line using Account 4000 (Cost of goods) for any amount (e.g., 10,000 SEK). - Confirm/Post the bill. - Cancel the bill. - Go to Accounting > Reporting > SIE Export and generate the export for the current year. - Open the downloaded .se file and locate the #RES line for Account 4000. Expected: The balance should be 0.00 (cancelled entries must be ignored, matching the GL). Actual: The cancelled amount (10,000) is incorrectly summed into the exported balance. opw-5901999 Forward-Port-Of: odoo/enterprise#110612 Forward-Port-Of: odoo/enterprise#108767
This update corrects a technical issue that caused incorrect decimal values to be generated in intrastat XML reports for French companies. The fix resolves a problem with how the system processed invoice data, ensuring accurate reporting of intrastat transactions. This improves the reliability of our international trade reporting.
Original PR description
Steps to reproduce: - Select a French company and activate intrastat - Create an invoice with a 100% discount to a european partner and provide intrastat values such as intrastat code, product commodity code, ... and most importantly a weight with a decimal amount. - Create at least one other invoice to a european partner that has a date earlier than the first one (but on the same month) - Go to intrastat report and export the XML (DEBWEB2) and select EMEBI and then Departures. -> Issue: The line that got processed after the one with a 0 value is not properly post-process regarding the integer conversion because we used to iterate on a list that was modified at the same time. opw-5973832 Forward-Port-Of: odoo/enterprise#110971
This update resolves a problem with the tour (guided tutorial) feature within the industry_fsm_report module. The fix ensures that the tour is correctly displayed and functioning as intended, improving the user experience for accessing and understanding this specific reporting functionality. This addresses a minor usability issue.
Original PR description
task-4489657 Forward-Port-Of: odoo/enterprise#111099 Forward-Port-Of: odoo/enterprise#81823
10 changes
New functionality added to Odoo
This update introduces a new report for Polish businesses to generate the JPK_FA XML report. This report is required for businesses choosing not to use the KSeF online platform for B2C invoicing, ensuring compliance with Polish tax regulations. It simplifies the process of fulfilling reporting obligations.
Original PR description
In Poland, if a business chooses to keep B2C invoicing outside of KSeF (online platform), the JPK_FA obligation remains. It is a XML report that lists all the invoices and the invoice lines that have not been validated by KSeF during a desired period of time. The report follows the JPK-FA(4) norms. task-5166047 Forward-Port-Of: odoo/enterprise#103000
This update enables direct electronic invoicing for POS sales and returns in Colombia, streamlining the process for businesses. It adapts existing DIAN EDI functionality to work within the POS store, eliminating the need to manage invoices in the Accounting App. This improves efficiency and compliance with Colombian regulations.
Original PR description
In Colombia, all POS Sales/Returns must be supported by an Electronic Document. Currently, the only way to connect the DIAN EDI and POS flows is to manage invoices directly in the Accounting App.…
In Colombia, all POS Sales/Returns must be supported by an Electronic Document. Currently, the only way to connect the DIAN EDI and POS flows is to manage invoices directly in the Accounting App. This pr adds the possibility to generate and send the electronic documents directly to DIAN without leaving the POS store. This pr will not create intermediate invoices/credit notes that are supposed to be sent to DIAN, instead we adapted the already existing ubl-generation implementation (in `l10n_co_dian`) to be able to generate the correct files using data from `pos.order` models (implementation can be found in `models/account_edi_xml_ubl_dian.py`). During this process we created some 'common' functions that generate data for the ubl file independent of what model is used (`account.move` or `pos.order`), these common functions are a first step for the future refactoring of the ubl models. An important thing to note here is that the common functions are only used for the pos orders, generating documents for invoices is still done using the original implementation. Another important feature of this implementation is the possibility to share a single sequence, defined on the journal, between pos orders and account moves. This was implemented because in Colombia (and other latam countries) the sequence gets assigned to a company by the government, and can therefore be expensive. Important to note is that sharing a sequence is only possible if the company has never sent documents to DIAN before (~ no existing edi documents). task-4038651 Forward-Port-Of: odoo/enterprise#78742
Enhancements to existing features
This update simplifies the l10n Taiwan reports module by using the standard Odoo localization icon instead of a country flag. Adding a 'countries' key to the module's manifest enhances its organization and filtering within the Odoo platform, making it easier to find and manage.
Original PR description
Update the module icon to use the standard localization icon (l10n.png) instead of the country flag, and add the 'countries' key to the manifest to improve module categorization and filtering within the Odoo ecosystem. Task-6007589 CE PR: https://github.com/odoo/odoo/pull/252923
Resolved issues and error corrections
This update corrects a bug in the DIAN invoice processing workflow. Previously, the system could unintentionally delete original invoices, leading to data loss. The fix ensures the correct invoice document is protected during the update process, maintaining data integrity.
Original PR description
**PROBLEM** In some configurations, `_l10n_co_dian_cron_update_event_status()` would delete the original document of the invoice. **CAUSE** The logic that tried to exclude the original document from the code that unlinks duplicated documents is wrong. It protect the oldest document of `self` instead of `move`. So the document of the move we are currently working on is not protected, and could be deleted. **STEP TO REPRODUCE** 1. Setup DIAN. 2. Create multiples invoices and send them to DIAN. 3. Run _l10n_co_dian_cron_update_event_status() If the original document of the invoice have the same commercial_status as some other document, it could be destroyed. opw-5447147 Forward-Port-Of: odoo/enterprise#110455
This update resolves a technical issue where Odoo could experience errors when communicating with Sendcloud, specifically when Sendcloud didn't return expected shipping price data. The fix prevents a system crash caused by attempting to access missing data, ensuring smoother delivery processing.
Original PR description
Sendcloud sometimes doesn't respod when asking for `shipping-price`. So when we try to retrieve the first element of the response, we raise an `IndexError`. ----- Ticket: opw-5951749 Forward-Port-Of: odoo/enterprise#109252
This update fixes an issue where bank statement reconciliations in foreign currency journals were incorrectly using the invoice currency instead of the payment currency. This resulted in inaccurate balance conversions during batch reconciliation processes. The fix ensures correct currency conversion for improved financial reporting accuracy.
Original PR description
When reconciling a batch payment in a foreign currency journal where payments do not have outstanding accounts, the resulting bank statement lines could use the wrong currency for balance conversion. Steps to reproduce: - Create a journal in a foreign currency (e.g., CHF) - Create two invoices in company currency (e.g., EUR) - Pay both invoices using the foreign journal - Create a batch payment for these payments. - Reconcile a bank statement line against this batch payment. Issue: Reconciliation make use of the payments amount in the wrong currency. Analysis: During the reconciliation of a batch payment, the system creates new amls from the payment values. However, the currency of the computed amount should be the source payment currency, and not the invoice line currency. opw-5887218 Forward-Port-Of: odoo/enterprise#108745
This update fixes a bug in the Odoo Studio report editor that prevented power buttons from appearing in reports. The change ensures the Studio instance correctly defines the necessary configuration, resolving a previous issue where table menu positioning was incorrect. This improves the overall usability of the Studio report editor.
Original PR description
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own…
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu position calculation when the table cell is inside an iframe. Also Before localOverlayContainers was not defined in studio, so power buttons did not appear in studio reports. Now that localOverlayContainers is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250503 Forward-Port-Of: https://github.com/odoo/enterprise/pull/108724 Forward-Port-Of: odoo/enterprise#109506 Forward-Port-Of: odoo/enterprise#109012
This update resolves an issue that prevented users from copying spreadsheets within the Odoo Enterprise system. The fix corrects a technical error that disabled the copy button, ensuring users can now seamlessly duplicate spreadsheets as needed. This restores a key functionality for managing and sharing data.
Original PR description
Fix error which disabled the copy button. Forward-Port-Of: odoo/enterprise#110700 Forward-Port-Of: odoo/enterprise#110086
Previously, when users uploaded multiple files to a WhatsApp Discuss channel, only the first file was delivered. This update fixes a bug where the WhatsApp API limitation was silently discarding subsequent attachments. The change ensures all uploaded files are sent, improving the reliability of file sharing within WhatsApp.
Original PR description
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a…
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a WhatsApp Discuss channel. 2. Send the message. -> Odoo shows all files, but only the first reaches the destination. ### Cause WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest. ### Fix Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss. opw-5889035 Forward-Port-Of: odoo/enterprise#110657 Forward-Port-Of: odoo/enterprise#107424
This update resolves an issue where the batch view in the quality control process displayed multiple 'Validate' buttons. The fix ensures that only one 'Validate' button is visible, streamlining the workflow for users creating and managing quality batches. This improves user experience and reduces potential confusion.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/enterprise#109911 Forward-Port-Of: odoo/enterprise#107993
3 changes
Resolved issues and error corrections
This update corrects a technical detail in the Account Avatax module, ensuring it properly identifies the company it's associated with. Previously, a key setting was missing, which has now been added to improve data accuracy and functionality. This ensures Account Avatax operates correctly within the Odoo Enterprise system.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. Followup of odoo/odoo#254242 task-none Forward-Port-Of: odoo/enterprise#110983
This update resolves a bug where subscriptions were incorrectly marked as ‘In Progress’ after a credit note payment was processed. The fix prevents the reopening of churned subscriptions when a credit note payment (specifically refunds) is made, ensuring subscription status accurately reflects the customer’s account. This improves data accuracy and prevents potential disruptions to subscription management.
Original PR description
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and…
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and ensure the invoice is in the Paid state. 4. Go back to the subscription and close it with any reason 5. Open the related invoice. * Create and Confirm Credit Note. * Register a payment for the credit note. 6. Go back to subscription Observation: ------------------------------ The subscription is automatically set back to `In Progress` even though it was previously churned. Issue: ------------------------------ The method `_reopen_paid_churned_subscription` reopens churned subscriptions when an invoice is set to `in_payment` or `paid`. There was no check to exclude refund moves (`move_type = 'out_refund'`), causing the subscription to be reopened when a credit note is paid. Solution: ------------------------------ Add a condition to exclude refund invoices from the reopening logic opw-5947999 Forward-Port-Of: odoo/enterprise#108487
This update resolves an issue where links within Helpdesk email templates were incorrectly identified as links instead of buttons. The change ensures buttons function as intended, allowing users to properly interact with ticket information. This improves the overall usability of the Helpdesk system.
Original PR description
Without the `btn` class, buttons are identified as links by the editor. This commit adjusts the buttons inside the mail templates so that they are properly handled by the editor. Steps to reproduce: - Have demo data - Turn on developer mode - Go to Helpdesk > Customer Care - Open ticket "Where can I download a catalog?" - In the debug menu, go to Messages - Open the first template - Click on the "View Ticket" button - Edit the link => The link popover recognized it as a link instead of a button. As of saas-18.2, the style is replaced by a plain link style when changing the URL. task-5948539 Forward-Port-Of: odoo/enterprise#110797 Forward-Port-Of: odoo/enterprise#107888
10 changes
Enhancements to existing features
This update enhances the visibility of full-size popups on websites with transparent backgrounds. By adding a margin and a white background, the popup content is now more distinct and easier to read, improving the user experience. This change ensures popups are consistently clear and effective.
Original PR description
The full-size option for popups could be misleading when using transparent backgrounds, as the dialog content could visually merge with the page and become hard to read. This change keeps the same…
The full-size option for popups could be misleading when using transparent backgrounds, as the dialog content could visually merge with the page and become hard to read. This change keeps the same behavior as other popup sizes while adding a 10px margin on both sides of the snippet. It also applies a default white background in full-size mode, ensuring better visual separation and improved readability. | Before | After | | ------------- | ------------- | | <img width="1646" height="456" alt="image" src="https://github.com/user-attachments/assets/122b266d-8391-45fe-a6be-08177b97f99c" /> | <img width="1659" height="466" alt="image" src="https://github.com/user-attachments/assets/df4e09de-850e-4735-9169-5115465c1372" /> | | <img width="1641" height="707" alt="image" src="https://github.com/user-attachments/assets/51d549f8-f7ff-42de-aba1-52ab0b4adaf0" /> | <img width="1655" height="687" alt="image" src="https://github.com/user-attachments/assets/2085b8ec-f318-4f04-a9ed-af8ecb0d6fa8" /> | task-5435802
Resolved issues and error corrections
This update corrects a technical issue that prevented multiple expenses linked to a single payment from being correctly processed. The fix ensures that the system handles multiple expenses associated with a payment action smoothly, addressing a potential problem that arose during previous upgrades. This improves the reliability of expense tracking.
Original PR description
**Description:** In previous versions, a single move could have multiple payments linked to it, and that move could also be linked to multiple expenses. When opening expenses from the payment action,…
**Description:**
In previous versions, a single move could have multiple payments linked to it, and that move could also be linked to multiple
expenses. When opening expenses from the payment action, which caused a singleton error when multiple expenses were linked.
This situation can occur during upgrades because older versions https://github.com/odoo/upgrade/pull/9685/changes here is identified allowed creating such records. However, after the removal of expense reports [^1], this type of record can no longer be created in newer versions.
**To fix the issue**
the code now handles multiple expenses instead of assuming a singleton.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2283, in _serve_db
return service_model.retrying(serve_func, env=self.env)
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 185, in retrying
result = func()
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2338, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2553, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 355, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 794, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/19.0/addons/web/controllers/dataset.py", line 38, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 94, in call_kw
result = method(recs, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/addons/hr_expense/models/account_payment.py", line 37, in action_open_expense
'name': self.expense_ids.name,
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5940, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.expense(22, 21)
```
opw-5494047
upg-3974547
[^1]: https://github.com/odoo/odoo/pull/189701
Forward-Port-Of: odoo/odoo#254167This update corrects a technical detail in the Account Avatax module, ensuring it correctly identifies the company it's associated with. Previously, a key setting was missing, which has now been added to improve data accuracy and functionality. This ensures Account Avatax operates effectively within the Odoo Enterprise system.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. Followup of odoo/odoo#254242 task-none Forward-Port-Of: odoo/enterprise#110983
This update corrects an issue where QR codes generated for self-ordering pickup orders included incorrect URLs with table identifiers. The fix ensures QR codes are generated correctly for 'pickup zone' ordering modes, preventing errors in downloaded PDFs and improving the customer ordering experience. This resolves a previous bug impacting order accuracy.
Original PR description
Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right…
Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right there below these configs) Observation: - in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be. - QRs do not have table_id Cause: - there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone" Fix: - we only use table_id when ordering_mode = 'table'. **Before:** <img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" /> **After** <img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" /> opw-5095607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251759 Forward-Port-Of: odoo/odoo#247184
This update resolves a bug where subscriptions were incorrectly reopened after a credit note payment. The fix prevents the system from reopening subscriptions when a payment is made on a refund invoice, ensuring subscriptions remain in the correct churned state. This improves subscription management accuracy.
Original PR description
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and…
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and ensure the invoice is in the Paid state. 4. Go back to the subscription and close it with any reason 5. Open the related invoice. * Create and Confirm Credit Note. * Register a payment for the credit note. 6. Go back to subscription Observation: ------------------------------ The subscription is automatically set back to `In Progress` even though it was previously churned. Issue: ------------------------------ The method `_reopen_paid_churned_subscription` reopens churned subscriptions when an invoice is set to `in_payment` or `paid`. There was no check to exclude refund moves (`move_type = 'out_refund'`), causing the subscription to be reopened when a credit note is paid. Solution: ------------------------------ Add a condition to exclude refund invoices from the reopening logic opw-5947999 Forward-Port-Of: odoo/enterprise#108487
This update corrects a technical error in how images are displayed within Odoo reports. Specifically, a problem with the way image URLs were handled has been resolved, ensuring images are now correctly rendered. This improves the overall visual quality and reliability of reports.
Original PR description
Forward-Port-Of: odoo/odoo#254633
This update resolves a problem where header border widths were incorrectly set to full widths due to an input field accepting multiple values. The change ensures consistent border widths for standard headers while still allowing full borders for specific header templates. This improves the visual consistency of website headers.
Original PR description
Previously, the border width input for headers allowed multiple values. This was required for specific header templates (e.g. rounded box) that use a full border. However, most headers only apply a border on the bottom. When the input had multiple values, the scss would break, resulting in full border. This change ensures that, for headers without the .o_full_border class, only the first value of the saved border width is used. As a result, the input behaves like a single-value field (similar to font size inputs) for standard headers, while still supporting multiple values for templates that require a full border. Steps to reproduce the issue: - Go to Edit mode - Click on the Header - In the Border option, enter "1 2" and leave the input to validate => The input display "3" and the header has a full border. task-5500516 Forward-Port-Of: odoo/odoo#254483 Forward-Port-Of: odoo/odoo#244415
This update fixes a bug that prevented users from creating backorders when using batch transfers with specific picking configurations. The issue stemmed from an 'incompatible types' error during batch validation. Now, users can successfully create backorders without encountering this error, ensuring smoother batch transfer workflows.
Original PR description
Scenario: - Create two pickings with same partner with at least two moves each, the picking type should have auto_group and auto_confirm - Add to a batch transfer - Change the quantity on a move line, unlink the other - Validate the batch ### Before this PR - Clicking "create backorder" the "incompatible types" error appear because tries to assign the batch currently validating to the backorder picking ### After this PR - No error appear --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251952
This update resolves a memory issue that occurred when propagating deliveries across multiple lots, particularly those with a large number of associated picking IDs. The fix ensures the system handles large datasets efficiently, preventing crashes and improving performance for users with extensive inventory.
Original PR description
- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents. - Updating parent sets in a single operation caused a MemoryError for large datasets. ```sql…
- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents.
- Updating parent sets in a single operation caused a MemoryError for large datasets.
```sql
Traceback (most recent call last):
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 149, in _compute_delivery_ids
delivery_ids_by_lot = self._find_delivery_ids_by_lot_iterative()
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 385, in _find_delivery_ids_by_lot_iterative
delivery_by_lot[parent_id].update(delivery_by_lot[lot_id])
MemoryError
(Pdb)len(all_lot_ids)
22166
(Pdb)len(barren_lines)
9682
(Pdb)len(lots_to_propagate)
9682
Lot_id 11412: delivery_by_lot size = 7420, parents = 3
Lot_id 11753: delivery_by_lot size = 0, parents = 7
Lot_id 12845: delivery_by_lot size = 11, parents = 5
Lot_id 14646: delivery_by_lot size = 12, parents = 2
Lot_id 15801: delivery_by_lot size = 1700, parents = 3
Lot_id 19817: delivery_by_lot size = 0, parents = 4
Lot_id 22370: delivery_by_lot size = 0, parents = 1
Lot_id 25072: delivery_by_lot size = 6827, parents = 2
Lot_id 25134: delivery_by_lot size = 3, parents = 2
Lot_id 25135: delivery_by_lot size = 1, parents = 2
```
- Previous fix adds all child deliveries, even if some already exist, but this new patch adds only the missing ones
UPG - 3869661
OPW - 5900313
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#248826This update resolves a problem where invoices with specific fixed tax configurations (related to 'vidange/consigne' returns) were failing Peppol validation checks. The fix adjusts how tax exemptions are handled during invoice generation, ensuring compliance with Peppol standards and allowing invoices to pass validation.
Original PR description
**PROBLEM** Here is the client use case: The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the…
**PROBLEM** Here is the client use case: The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the 'consigne/vidange'. When returning the 'consigne', you would create an invoice line, with a product with a price of 0, negative quantity,a 0% tax and the fixed tax for the 'consigne'. When an invoice contains such lines, it fails peppol validations. **STEP TO REPRODUCE** 1. Create a fixed tax used for 'vidange/consigne'. 2. Create an invoice, with a line with unit price of 0, negative quantity, a 0% tax and the fixed tax for the 'consigne'. 3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08]. **CAUSE** Fixed tax (like the one used for vidange) are aggregated in new invoice lines by the function `_ubl_turn_emptying_taxes_as_new_base_lines()`. Let say we have the following invoice: line 1: qty=2, unit_price=3, taxes: 21% & vidange(fixed tax of 1). line 2: qty=-1, unit_price=0, taxes: 0% & vidange. After calling `_ubl_turn_emptying_taxes_as_new_base_lines()`, we got: line 1: qty=2, unit_price=3, taxes: 21%. line 2: qty=-1, unit_price=0, taxes: 0%. line 3: qty=1, unit_price=1(amount of the fixed tax), taxes:None. When generating the VAT breakdown, we have 2 line will end up being tax exempted (line 2 and 3). Because the `tax_exemption_reason` differs, they will not be merged in the same entry in the breakdown, which break the constraint of peppol saying we can only have one VAT breakdown with code 'Exempt from tax'. Line 2 reason comes from: https://github.com/odoo-dev/odoo/blob/de22093ee225df499b2de80e1f07dd281ac686bc/addons/account_edi_ubl_cii/models/account_edi_common.py#L271-L274 opw-5912986 Forward-Port-Of: odoo/odoo#250413
2 changes
Resolved issues and error corrections
This update corrects a technical issue in the Account Avatax module, ensuring it accurately identifies the company it's associated with within the Odoo settings. Previously, a key setting was missing, which has now been implemented to improve data accuracy and functionality. This ensures proper tax calculations and reporting.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. Followup of odoo/odoo#254242 task-none Forward-Port-Of: odoo/enterprise#110983
This update resolves a bug where subscriptions were incorrectly reopened after a credit note payment. The fix prevents the system from reopening subscriptions when a 'refund' payment is processed, ensuring subscriptions remain in the correct churned state. This improves subscription management accuracy and prevents potential billing errors.
Original PR description
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and…
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and ensure the invoice is in the Paid state. 4. Go back to the subscription and close it with any reason 5. Open the related invoice. * Create and Confirm Credit Note. * Register a payment for the credit note. 6. Go back to subscription Observation: ------------------------------ The subscription is automatically set back to `In Progress` even though it was previously churned. Issue: ------------------------------ The method `_reopen_paid_churned_subscription` reopens churned subscriptions when an invoice is set to `in_payment` or `paid`. There was no check to exclude refund moves (`move_type = 'out_refund'`), causing the subscription to be reopened when a credit note is paid. Solution: ------------------------------ Add a condition to exclude refund invoices from the reopening logic opw-5947999 Forward-Port-Of: odoo/enterprise#108487
1 change
Resolved issues and error corrections
The web testing framework now handles parent-child record lookups without getting stuck in an endless loop. This makes automated tests more reliable and faster, reducing the risk of development delays caused by frozen test runs.
Original PR description
Problem: Triggering the `child_of` operator in the testing framework caused an infinite loop that froze Odoo. This occurred because the framework attempted to fetch all children of the root operand without accounting for already visited nodes, resulting in children being added indefinitely.. Additionally, the original implementation had a O(n²) time complexity. Solution: Implemented a proper Depth-First Search (DFS) to retrieve all children and prevent duplicate traversal in O(n) time.
36 changes
New functionality added to Odoo
This update adds the necessary reports (2033-A) to support the creation of the French 'liasse fiscale' – a key tax filing requirement. The changes include XML files defining the simplified balance sheet report format. This ensures compliance with French tax regulations.
Original PR description
In order to create the liasse fiscale we need to create the rpeorts 2033-A simplified balance sheet task-5417361
This update adds comprehensive data for Joint Committees within Odoo Enterprise, addressing a previous issue where incorrect combinations of Joint Committee and Employer Category could lead to errors. The changes ensure accurate data encoding and provide a clearer system for managing these important employee details. This improves data integrity and reduces potential user errors.
Original PR description
In order to avoid encoding mistakes, we need to warn user if he encoded a wrong combination of Joint Committee and Employer Category (L10N Be Employer Category). So we need to have all the Joint Committee data encoded into out system - Add all the missing committee - update the committee display name Task: 6018469
This update introduces a voicemail button within the Odoo softphone interface. When a VoIP provider is configured with a voicemail code, a button appears on the keypad, allowing users to easily access voicemail. This improves the user experience by providing a direct dialing option for voicemail services.
Original PR description
This commit allows the configuration of a voicemail code for VoIP providers. When a provider has a voicemail code configured, a voicemail icon is displayed on the "1" key. A long press on this key will dial the voicemail code. Task-[5977620](https://www.odoo.com/odoo/5778/tasks/5977620)
This update allows users to create Documents records directly from files uploaded through employee forms. Previously, this feature was blocked for attachments with a specific field setting. This change improves the process of managing employee files within the Documents system, streamlining document creation and storage.
Original PR description
POC for comparison with #103818. task-5454615
Enhancements to existing features
This update enhances the appearance and functionality of pivot and list views within Odoo's spreadsheet feature. It also resolves an issue with border styling, ensuring a consistent and polished user experience. This change improves the overall usability of the spreadsheet tool.
Original PR description
## Task Description This PR aims to improve the pivot/list design when inserted into a spreadsheet. This also fix the command used to set the pivot/list border according to the new SET_ZONE_BORDERS command from o-spreadsheet ## Related Task/PRs: - https://github.com/odoo/odoo/pull/121118
This update enhances the account reports debug popover by allowing users to view the specific code associated with each line item. This provides more detailed information for troubleshooting and understanding report data, improving accuracy and efficiency.
Original PR description
Would be nice to be able to get the codes of lines in the debug popover. No task ID
This update optimizes how Odoo handles file uploads, reducing memory usage and improving performance. Previously, Odoo loaded entire files into memory, which was inefficient for larger files like videos. This change introduces a more memory-friendly method for saving files to the file store, ensuring smoother operation.
Original PR description
File upload to Odoo always loads the entire file in memory (sometimes even in base64!) in order to save it as attachment. Most controllers use the default upload limit of 120MiB (web.max_file_upload_size), requests bigger than this limit are rejected. In most cases, using 120MiB of memory is fine, the limit is much smaller than the typical available memory of a production server. 120MiB is more than enough for documents and images, but too small for videos or uncompressed audio. We never intended that our file-store would store bigger files as Odoo is not a content-delivery system. Still, the ``--x-sendfile`` option makes for an easy/cheap alternative to cloud storage, and there are situations (not limited to HTTP upload) where we want to load bigger files in the filestore. This new utility offers a memory-efficient way to save a file inside the filestore, it basically is like `create`-single, but with a file object given instead of `raw` bytes.
This update streamlines the timesheet assistant across Helpdesk, Sale, and Project modules, making it easier for users to record time. Key changes include simplified labels, improved suggestions, and a more intuitive user interface, while also enhancing the underlying data storage for better efficiency and accuracy.
Original PR description
[IMP] {helpdesk,sale,project}_timesheet_{,enterprise,forecast}: timesheet assistant generic improvements
In this Commit,
- Assistant Form > "Billable" boolean hidden for users without Sales access rights
- Assistant Form > Labels updated:
- "Project Name" → "Project"
- "Task Name" → "Task"
- "Time Spent" → "Time"
- "Save Changes" → "Save"
- Assistant Form UI Improved by applying same changes done in master,
REF: https://github.com/odoo/enterprise/pull/104347
- Assistant Form > create and edit option removed for projects
- Suggestions logic reviewed for better results
- Correct time calculation for chronological grouping
- Unmatched project display issues resolved in both suggestions and local config
- Local Config List view aligned with Odoo UI views
- Local Config Storage limited to project/task/ticket IDs instead of `display_name`
and `id`
task-5902077
Forward-Port-Of: odoo/enterprise#110708
Forward-Port-Of: odoo/enterprise#108360Resolved issues and error corrections
This update fixes a technical issue preventing users from correctly selecting suggestions within the Timesheets app. The problem stemmed from an unnecessary addition of '.this' to template variables, causing errors when accessing data. This change removes the '.this' element, ensuring the Timesheets app functions smoothly.
Original PR description
[FIX] {helpdesk,sale}_timesheet_{,enterprise}: remove .this with t-slot-scope
Steps to reproduce:
- Timesheets app > Assistant > select a suggestion => TypeError: Cannot read properties of undefined (reading 'record')
Source:
The following commit: https://github.com/odoo/enterprise/commit/426dce738f2513fb47af7a927599c0a77e6bdf66 added `.this` to template variables that are targeting the component, but `data` variable defined by the t-slot-scope directive should not be precedded by `.this`
Fix:
Remove `.this`This update fixes a technical issue preventing users from checking in/out through the systray attendance menu. The problem stemmed from a migration script incorrectly referencing data, leading to an error. The fix removes a problematic reference to ensure correct data access.
Original PR description
steps to reproduce: - install `hr_attendance` and `helpdesk_timesheet` - try to check-in/out through systray attendance menu - notice there is a traceback cause: - the OWL 3 migration script (here: https://github.com/odoo/enterprise/pull/109943) added `this.` to `data` which is not component-scoped variable; and hence will result into `undefined` then `record` cannot be read from `undefined` fix: - remove `this.` to avoid trying to access `data` from the component. [task#6040452](https://www.odoo.com/odoo/project.task/6040452)
This update resolves a technical issue preventing the automatic download of employee data (EMPF) from the Hong Kong payroll module. The fix ensures the download functionality continues to operate correctly, avoiding errors and maintaining accurate payroll processing. This change is a critical fix to ensure seamless operations.
Original PR description
The downloading logic was not properly updated following https://github.com/odoo/odoo/commit/41fe2ebdb9cc37341362d7af829c087a5f72f9f1 . This causes the button to fail downloading with an errors 500, so we need to update it to ensure the feature keeps working. Task 6046824
This update ensures users can now see the PIN associated with virtual expense cards, which are increasingly used through digital wallets. Previously, this PIN was only visible for physical cards, causing potential transaction blocks for users. This change improves the user experience and ensures seamless payments.
Original PR description
Before this commit: - Currently, we show the PIN code for physical expense cards only, not for virtual cards. - In some case transactions are made via virtual cards (through digital wallets) also requires a PIN. The users will be blocked because they currently can't access this information. After this commit: - Now we show the PIN code for both physical and virtual cards. task-5926462 Forward-Port-Of: odoo/enterprise#107231
This update resolves an issue where users on Firefox couldn't hear incoming calls through their softphones. The fix ensures that incoming call tracks are processed immediately, regardless of the session's establishment status, restoring full functionality. This impacts Odoo Enterprise versions 19.1 and 19.2.
Original PR description
Steps to reproduce the bug: - Install voip and open the Odoo backend on Firefox - Setup your voip settings - Call your softphone number, thanks to your smartphone - Once the softphone opens with the…
Steps to reproduce the bug: - Install voip and open the Odoo backend on Firefox - Setup your voip settings - Call your softphone number, thanks to your smartphone - Once the softphone opens with the call, answer => The caller can hear you but you cannot hear the caller. This happens since [1]. Before that commit, we had something like "when the session is established, listen to tracks being added to the call and also set up the audio". After that commit, this became "when the session is established *or is establishing*, listen to tracks being added to the call... *but don't set up the audio otherwise*". The problem is that on Firefox, the timing is such as the tracks of incoming calls are being added just before the session is establishing (or established), meaning we listen to tracks being added too late. Note that commit [1] was further diluted afterwards by commits like [2] (doing stuff with the audio before establishing) and [3] (which simply removed the "established" part, relying on "establishing" being done). Later on, commit [4] prepared some other work by moving and improving things around and it actually fixed this issue here by chance. What did the trick is listening to tracks being added from the start: as soon as SIP.js notifies that the remote stream exists. This commit fixes the issue in impacted versions (19.1 and 19.2) by backporting the relevant part: listening to tracks being added as soon as possible and not once establishing/established. A test was added. [1]: https://github.com/odoo/enterprise/commit/d24d7f3406ca47e7ac529d69957b0ad481d553bf [2]: https://github.com/odoo/enterprise/commit/71d78810ae7f6c9169912276da18e04ad4f7bef0 [3]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e [4]: https://github.com/odoo/enterprise/commit/33fc327c1c74ee874d546a98879dbbf468809850 task-5902700 Forward-Port-Of: odoo/enterprise#111025 Forward-Port-Of: odoo/enterprise#110833
This update adds a crucial test to ensure the correct formatting of payment data within the Odoo Enterprise system. A previous oversight during a software update caused a reliance on a now-missing field, and this fix prevents potential errors in payment processing. This ensures data integrity and reliable payment functionality.
Original PR description
This commit safeguards the `_prepare_payment_data` method. Reason: We were using a field that no longer exists due to an oversight during a FW and having no tests to catch it. Fix here https://github.com/odoo/enterprise/pull/110266 No task ID Forward-Port-Of: odoo/enterprise#110338
This update optimizes the Point of Sale system to use less memory, particularly when handling large product catalogs. The changes result in a significant reduction in memory consumption across browsers (Chrome, Safari, Firefox) when loading a large number of products, leading to a smoother and more responsive user experience.
Original PR description
This commit reduces memory consumption in the POS, especially when loading a large number of products. Reactivity usage has been optimized, particularly for product data. Additional optimizations were implemented to handle large product sets more efficiently. Metrics 5,000 products • Chrome: 440 MB → 75 MB • Safari / Firefox: 1 GB → 250 MB 20,000 products • Chrome: 1.5 GB → 135 MB • Safari / Firefox: 4 GB → 300 MB Community PR: https://github.com/odoo/odoo/pull/249542 Forward-Port-Of: odoo/enterprise#110223 Forward-Port-Of: odoo/enterprise#107978
This update resolves a problem preventing invoices generated with the l10n_gt_edi module from being correctly sent to the tax agency. The issue stemmed from incorrect encoding of data transmitted as XML, which was restricted. This fix ensures invoices are successfully submitted, improving compliance and preventing potential delays in tax reporting.
Original PR description
With l10n_gt_edi and the credentials: - Create an invoice and try to send it to the tax agency. You will get the following traceback: Only base64 data is allowed (after 41fe2eb) opw-6043140
This update corrects a bug preventing the system from accurately checking if invoices meet EC Sales List requirements for intra-EU customers. The fix ensures that warnings are triggered correctly when invoices with 'Intra-Community' fiscal positions are issued, improving compliance and reporting accuracy. This impacts how sales data is reported for European customers.
Original PR description
The EC Sales List return check "Only intra-EU customers" is reviewed when an invoice that match the condition for the warning same_country is present. To Reproduce: - Create a company in Belgium - Create a customer in Belgium with "Intra-Community" as a Fiscal Position - Create an invoice with this customer (in the previous month of the current month, for example February if the current date is in March - Open the Tax Returns - Open the EC Sales List Return - The Only intra-EU customers check is reviewed when it should show an anomaly. Forward-Port-Of: odoo/enterprise#107137
This update resolves an error that occurred when users attempted to modify the employee associated with a salary simulation. The fix ensures the system correctly handles versioning of salary data, preventing a runtime error. This improves the stability and usability of the salary simulation feature.
Original PR description
Currently, an error occurs when user tries to change simulation employee in salary simulation. Steps to replicate: - Install `hr_contract_salary_payroll` with demo. - Open any employee (e.g.- Abigail…
Currently, an error occurs when user tries to change simulation employee in salary simulation.
Steps to replicate:
- Install `hr_contract_salary_payroll` with demo.
- Open any employee (e.g.- Abigail Peterson).
- Click `Simulation` > Change `Yearly Employer Cost` to `Gross Per Month`.
- Try to change the Employee, error will occur.
Error:
```
File '/home/odoo/odoo19/enterprise/hr_contract_salary_payroll/models/hr_contract_salary_offer.py', line 157, in _compute_offer_values_from_template
version = offer._get_version()
^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo19/enterprise/hr_contract_salary/utils/hr_version.py', line 39, in hr_version_context_wrapper
raise RuntimeError(
RuntimeError: Method '_get_version' must be called within a savepoint context. Use `hr_version_context(...)` context manager before calling this method.
```
Cause:
- The method `_get_version()` has the decorator `@requires_hr_version_context()` which makes the method to be callable within a savepoint context for `hr.version` [1] i.e. it can only be called within a `hr_version_context()` block.
- As here the method was not called under the `hr_version_context()`it raises an error from [here].
Solution:
- Used the `hr_version_context()`block instead of savepoint (similar to [this]).
[this]: https://github.com/odoo/enterprise/pull/108005/changes#diff-97aeb940d5058abc95cb617e5a2015320c37e8d50a15cffc2c08eac1839ac16dL98-R100
[here]: https://github.com/odoo/enterprise/blob/626598abe4fdbc8391a428928e197e7735cbb298/hr_contract_salary/utils/hr_version.py#L39-L42
[1]: https://github.com/odoo/enterprise/blob/626598abe4fdbc8391a428928e197e7735cbb298/hr_contract_salary/utils/hr_version.py#L14-L17
sentry-7335824597
Forward-Port-Of: odoo/enterprise#111090This update fixes an issue where cancelled vendor bills were incorrectly included in the Sweden accounting SIE export. The change ensures that cancelled transactions are properly excluded, aligning the export with the general ledger's accounting records. This prevents inaccurate reporting and maintains data integrity.
Original PR description
Steps to reproduce: - Install l10n_se (Sweden - Accounting). - Create a Vendor Bill with a line using Account 4000 (Cost of goods) for any amount (e.g., 10,000 SEK). - Confirm/Post the bill. - Cancel the bill. - Go to Accounting > Reporting > SIE Export and generate the export for the current year. - Open the downloaded .se file and locate the #RES line for Account 4000. Expected: The balance should be 0.00 (cancelled entries must be ignored, matching the GL). Actual: The cancelled amount (10,000) is incorrectly summed into the exported balance. opw-5901999 Forward-Port-Of: odoo/enterprise#110612 Forward-Port-Of: odoo/enterprise#108767
This update corrects a bug that was causing incorrect decimal values to be generated in Intrastat XML reports for French companies. The issue stemmed from how the system processed invoice data, specifically when dealing with weight values. This fix ensures accurate reporting for cross-border trade data.
Original PR description
Steps to reproduce: - Select a French company and activate intrastat - Create an invoice with a 100% discount to a european partner and provide intrastat values such as intrastat code, product commodity code, ... and most importantly a weight with a decimal amount. - Create at least one other invoice to a european partner that has a date earlier than the first one (but on the same month) - Go to intrastat report and export the XML (DEBWEB2) and select EMEBI and then Departures. -> Issue: The line that got processed after the one with a 0 value is not properly post-process regarding the integer conversion because we used to iterate on a list that was modified at the same time. opw-5973832 Forward-Port-Of: odoo/enterprise#110971
This update resolves an issue where the Documents Activity view became unusable after exiting Studio, preventing users from filtering or adding new activities. The fix ensures the view correctly loads necessary data, restoring full functionality and preventing frustrating user experiences.
Original PR description
Problem: When returning to the Documents Activity view after closing Studio, the view becomes unusable with an error that `folderId` is `undefined`. Users are forced to refresh the page or switch…
Problem: When returning to the Documents Activity view after closing Studio, the view becomes unusable with an error that `folderId` is `undefined`. Users are forced to refresh the page or switch views to fix it. Specifically: - Filters can no longer be selected. - Adding new activities throws UI errors (even if technically successful). Cause: The `getSelectedFolder` method returned undefined because the `searchPanel` logic was skipped. The Activity view does not display the `searchPanel`, so the model failed to run `_fetchSections` which retrieves the data used by `getSelectedFolder`. Under normal circumstances, the view relies on data already loaded by the Kanban or List views, but that data is unavailable here. Solution: - Force the search model to load the data explicitly, ensuring the view initializes correctly regardless of the `searchPanel` visibility. We kept the dependency upon `_fetchSections` rather than removing it, as it is required by the `search_model` to maintain other features like `breadcrumbs`. - Add a test to verify the fix and prevent regression. Co-authored-by: Pierre-Yves Dufays <pydu@odoo.com> Co-authored-by: Charlier Florian <flch@odoo.com> Forward-Port-Of: odoo/enterprise#110471
This update resolves an issue where the Odoo payroll system would generate errors if only the core payroll module was installed. The fix ensures that salary rules correctly utilize a key field, preventing these errors and improving stability. This change primarily impacts Mexican payroll functionality.
Original PR description
The `l10n_mx_min_wage_zone` field is used in `l10n_mx_hr_payroll`, but it was originally defined in `l10n_mx_hr_payroll_account_edi`. This causes errors when a user only installs the `l10n_mx_hr_payroll` module, as the field is missing. Fix salary rules in `l10n_mx_hr_payroll` to use the `zsmg` value and avoid tracebacks when the EDI module is missing. In `l10n_mx_hr_payroll_account_edi`, override these rules to use the `l10n_mx_min_wage_zone` field instead. Related commit: https://github.com/odoo/enterprise/commit/11bb6db4884083b3f48582b749c01ae75a09cf66 target: saas-19.2 task-6047772 Forward-Port-Of: odoo/enterprise#110985
This update corrects a technical issue that was preventing the VSME/CSRD report from generating correctly. The fix involved updating a reference to the correct employee type within the Odoo system, ensuring accurate reporting data. This resolves a potential error and improves report reliability.
Original PR description
Before this PR, there was a typo related to employee types after a recent change (https://github.com/odoo/enterprise/pull/103118) , which was 'your_module.employee_type_employee'. We change it to 'hr.contract_type_employee' to avoid a traceback when printing the VSME/CSRD report.
This update addresses a potential issue in testing where the system's transaction state wasn't properly managed after operations. The changes ensure that transactions are reliably handled, preventing unexpected behavior and improving test stability. This primarily impacts the accounting and payroll modules.
Original PR description
https://github.com/odoo/odoo/pull/253929
This update resolves a bug where subscriptions were incorrectly reopening after a credit note payment. The fix prevents the system from reopening subscriptions when a credit note payment (specifically 'out_refund' invoices) is processed, ensuring subscriptions remain in the correct churned state. This improves subscription management accuracy.
Original PR description
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and…
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and ensure the invoice is in the Paid state. 4. Go back to the subscription and close it with any reason 5. Open the related invoice. * Create and Confirm Credit Note. * Register a payment for the credit note. 6. Go back to subscription Observation: ------------------------------ The subscription is automatically set back to `In Progress` even though it was previously churned. Issue: ------------------------------ The method `_reopen_paid_churned_subscription` reopens churned subscriptions when an invoice is set to `in_payment` or `paid`. There was no check to exclude refund moves (`move_type = 'out_refund'`), causing the subscription to be reopened when a credit note is paid. Solution: ------------------------------ Add a condition to exclude refund invoices from the reopening logic opw-5947999 Forward-Port-Of: odoo/enterprise#108487
This update fixes an issue where bank statement reconciliation in foreign currency journals incorrectly used invoice currency instead of payment currency. When reconciling batch payments, the system now accurately converts amounts to the payment's original currency, ensuring correct bank statement balances. This improves the reliability of financial reporting.
Original PR description
When reconciling a batch payment in a foreign currency journal where payments do not have outstanding accounts, the resulting bank statement lines could use the wrong currency for balance conversion. Steps to reproduce: - Create a journal in a foreign currency (e.g., CHF) - Create two invoices in company currency (e.g., EUR) - Pay both invoices using the foreign journal - Create a batch payment for these payments. - Reconcile a bank statement line against this batch payment. Issue: Reconciliation make use of the payments amount in the wrong currency. Analysis: During the reconciliation of a batch payment, the system creates new amls from the payment values. However, the currency of the computed amount should be the source payment currency, and not the invoice line currency. opw-5887218 Forward-Port-Of: odoo/enterprise#110381 Forward-Port-Of: odoo/enterprise#108745
This update resolves an issue where GS1 barcode filtering would fail due to incorrect date interpretation. The fix prevents errors when a barcode starts with a date identifier, ensuring that products can be correctly filtered by barcode scans. This improves the reliability of internal transfer processes.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal Transfers - Scan the barcode: 15099590225865 to filter transfers by this product barcode Problem: An validation error is raised: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in filter_on_barcode and explicitly reset parsed_results to False, allowing the normal filter on product resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product is correctly filtered opw-5929064 Forward-Port-Of: odoo/enterprise#110679 Forward-Port-Of: odoo/enterprise#110636
This update resolves an issue where users couldn't successfully create events using the Quick Create feature within the Gantt view for Dental Care appointments. The fix ensures that the Quick Create functionality now works as expected, streamlining the process of scheduling appointments. This improves usability for our dental care clients.
Original PR description
Steps to reproduce: - Go to Appointments - Dental Care -> Gantt - Quick Create an event => bug task-6037337
This update fixes a technical issue that previously caused errors during payslip calculations for the Joint Committee 302 (CP302). The fix ensures that the system handles missing data gracefully, preventing tracebacks and ensuring accurate payroll processing, particularly when calculating termination fees.
Original PR description
When computing a monthly payslip for the Joint Commiteee 302, a salary rule was trying to get a rule parameter name generated dynamically from the cp code. The salary rule was expecting the function to not raise in case of error, which was not the case. I made it so that the function could be asked to not raise in case of error to match the expected behavior. The same error appeares when generating termination fees under the CP302 task-6041052
This update adds validation for employee identification IDs within salary configuration settings. Previously, this caused errors when contracts were created, leading to delays. The change ensures data integrity and prevents errors during the contract signing process, streamlining workflow.
Original PR description
Previously, the `identification_id` field could be saved in the salary configuration version model without any validation. However, when the contract is signed by the employer, an employee record is created from this version record. At that moment, a validation error occurs because the `identification_id` field is validated on the employee model in the Belgian localization. To prevent this late validation error, validation for `identification_id` has been added in the salary configuration. I added custom validation`_fieldValidators` but validating fields separately caused duplicate notifications when the field was empty (one from the required field check and another from the localization validator). The validation logic was therefore integrated so both checks work together without producing duplicate errors, while still preserving the required field highlighting. Task Id: 6025668
This update ensures all data files used within Odoo Enterprise are encoded as ‘bytes’ instead of ‘base64’. This resolves potential compatibility issues and improves data handling across various modules, leading to more reliable data processing and reduced errors. It’s a standard best practice for data storage and transmission.
Original PR description
https://github.com/odoo/odoo/pull/254394
This update optimizes the storage of data related to account returns by removing unnecessary default values. Previously, fields were set to 'new' by default, consuming database space without providing actual information. Now, fields will only be populated with a state when a real return is recorded, leading to more efficient data usage.
Original PR description
Before the change the workflow fields have by default 'new' value which is not an actual state, thus it is taking space in the database without providing actual value. Removing the default new value and leaving only the actual states that exist in the workflow is the motivation of this change. After the change: the fields will be non set by default until they get an actual state. task: 5432425
This update fixes an issue where subscription products weren't displaying prices with tax, even when the website setting was enabled. The change ensures that prices accurately reflect tax-inclusive amounts by correctly considering company IDs when calculating taxes. This improves the accuracy of subscription pricing for customers.
Original PR description
subscriptions Despite enabling the website setting to display tax-inclusive prices, subscription products show prices without tax when a recurring pricelist is configured. In `_get_sales_prices`, the product’s company ID is compared to the website’s company, but products visible to all have a false company ID, and products assigned to a parent company retain the parent’s company ID. As a result, when the product’s company ID does not match the website’s company ID, no taxes are applied.Instead, _filter_taxes_by_company should be used to determine whether the company can access the product’s tax_id. opw-5222411 Forward-Port-Of: odoo/enterprise#102102 Forward-Port-Of: odoo/enterprise#100662
This update fixes an error in the calculation of the mobility budget, ensuring accurate yearly cost projections. The previous calculation incorrectly treated a value as a percentage, leading to inaccurate results. This change improves the reliability of the HR contract salary configuration.
Original PR description
Forward-Port-Of: odoo/enterprise#111042 Forward-Port-Of: odoo/enterprise#110827
Features or functions removed from Odoo
This update removes an older VoIP component ('t-esc') that is being phased out in the upcoming Owl 3 release. This change ensures compatibility with newer features and improves the overall stability of the enterprise platform. It’s a routine maintenance update.
Original PR description
`t-esc` is going to be removed in Owl 3
Code cleanup and technical improvements
This update prepares Odoo for the upcoming OWL3 release by adding the '.this' syntax to template variables. This is necessary because OWL3 requires developers to use '.this' to correctly target component variables within templates, ensuring compatibility and functionality after the upgrade.
Original PR description
In preparation for OWL3, where template variables will need to use .this to target component variables, we add .this to template variables that are targetting the component. Script PR: odoo#247965 task: OWL3 prep - add this. to template variables https://github.com/odoo/odoo/pull/253294
26 changes
New functionality added to Odoo
This update introduces a new report for Polish businesses that still need to generate JPK_FA XML reports due to not using the KSeF online invoicing platform. This report ensures compliance with Polish tax regulations by listing invoices and lines not yet validated by KSeF, aligning with JPK-FA(4) standards.
Original PR description
In Poland, if a business chooses to keep B2C invoicing outside of KSeF (online platform), the JPK_FA obligation remains. It is a XML report that lists all the invoices and the invoice lines that have not been validated by KSeF during a desired period of time. The report follows the JPK-FA(4) norms. task-5166047 Forward-Port-Of: odoo/enterprise#103000
Resolved issues and error corrections
This update improves the stability of the HR payroll system by limiting the calculations performed by a key function (`_compute_basic_net`) to only active, open payslips. Previously, this calculation impacted a large number of records, potentially leading to performance issues. This change ensures more efficient payroll processing.
Original PR description
Before this commit, `_compute_basic_net` was not limited to specific payslips, potentially affecting thousands of records and even more of `hr.payslip.line` records. This commit restricts the compute to ongoing payslips. task-6022499
This update fixes a bug where flexible work schedules were incorrectly displaying an inflated number of expected hours (48 instead of 40). The issue stemmed from a misunderstanding of time zone differences when calculating attendance intervals. The fix ensures accurate hour calculations regardless of employee and schedule time zones.
Original PR description
__ ## Short functional explanation of the error When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of…
__ ## Short functional explanation of the error When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of difference with UTC. The schedule is flexible and is set to 40 hours per week. When we open the Attendances app, the expected hours for this employee show 48. ## Reproduction Steps 1. Create an employee. The time zone of the employee should be different from the one on his work schedule. To be sure to replicate the bug, set the time zone of employee's time zone to Pyongyang. 2. Open the work schedule and set it to Flexible. Set the weekly hours to 40, and the full time equivalent to 40. Set the work schedule to Europe/Brussels time. 3. Open Attendances. ### Expected behavior When we hover the name of our employee, we can see in white on green background 0/40h. ### Unexpected behavior Instead, we see 0/48h. ## Origin of the issue This line: https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L419 is used to retrieve the correct date. We assume that `end_datetime` will be set at midnight, so subtracting one second gives us the day before, allowing us to ignore the date of `end_dt`, for which we don't need to compute the intervals. However, this doesn't take into account different time zones. Indeed, we compute `end_datetime_adjusted` from `end_datetime`, which has the user timezone, and not UTC, as defined here: https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L402 As a result, if we set the user timezone to Pyongyang, `end_datetime` will be set at 8am, and `end_datetime_adjusted` will lead to the same date, instead of a day before. Hence, we would compute an additional interval for an additional day, which would in the end give us 48 hours expected instead of the 40 hours indicated in the contract. Therefore, we have to take into account the time zones, hours, minutes and seconds when checking the start and end dates. __ opw-5937298
This update fixes a potential issue where the Gemini AI feature would sometimes return empty responses to users, leading to a blank screen. The fix automatically retries the request with a slightly increased thinking budget and, after three failed attempts, informs the user of the problem. This ensures a smoother and more reliable user experience with the AI.
Original PR description
It often occurs that gemini responses come back empty without anything to show to the users. Specifically, the response object has content but the "parts" are empty - the place were you either get a function call or a message to the user by the LLM. Prior to this commit, when this occured, we didn't perform any explicit handling. We would always just return what the LLM responded with, which when empty would be nothing. UX wise, it would seem like something broke because the user would basically get no reply. In this commit, we add a retry mechanism in `_request_llm_google` of `llm_api_service.py`, where if we get no response, we increase the thinking budget of the next request to 512 and try again. 512 tokens were chosen completely arbitrarily - anecdotally, the model should use around 300 thinking tokens for its tasks so 512 should be enough. After 3 unsuccessful tries, we send a failure response to the user. Task-5959805
This update removes unnecessary default values from company and partner records in the Odoo Enterprise system. By streamlining data storage, this change optimizes database performance, particularly for businesses managing multiple companies with different localization settings. It resolves a previous issue with incorrect date fallbacks, ensuring stability and efficiency.
Original PR description
On multi-company databases, having the defaults value on res.partner fields can unnecessary bloat the database for other companies with different fiscal package (localization). This commit remove the `l10n_ke_branch_code` field default on `res.partner` - the related field on `res.company` has been converted to a stored-compute + inverse so that partner related to a company automatically get the default value `00` whithout needing to touch other partner records. The `l10n_ke_oscu_last_fetch_purchase_date` default on `res.company` has also been removed, cron already fallback to the same default value when none are provided and will update it anyway after it ran. opw-5220129
This update corrects a test failure within the Odoo Enterprise system. The issue occurred when the 'accountant' module was not present, leading to an incorrect expected account value. This fix ensures the test runs successfully, improving the stability of the batch payment functionality.
Original PR description
Currently test_bank_rec_widget_batch_foreign_currency_journal_without_entries fails when `accountant` module is not installed because the expected account differs opw-5887218 Forward-Port-Of: odoo/enterprise#110917
This update fixes an issue where the 'submit' button was hidden when creating a return type in the account reports module. The previous requirement for a 'type_external_id' is no longer needed due to a recent system update. This ensures users can consistently submit return requests.
Original PR description
When a user creates a return_type, the submit button is not visible as there is no type_external_id. Since now, we have the states_workflow this is not useful anymore. This commit is basically a back port of https://github.com/odoo/enterprise/commit/305b0078e584487036d907d6e18b7911bc7ff1de
This update ensures that shift notifications are automatically sent to employees in their preferred language, regardless of the user's language settings. Previously, emails were defaulted to the current user's language, causing confusion. This change improves communication and ensures employees receive important shift information in a clear and accessible way.
Original PR description
Steps to reproduce: ------------------------- 1. Install Planning and Contacts. 2. Install any language other than English (e.g., Arabic). 3. Change an employee's contact language to that language.…
Steps to reproduce: ------------------------- 1. Install Planning and Contacts. 2. Install any language other than English (e.g., Arabic). 3. Change an employee's contact language to that language. 4. Create a shift for that employee and click "Send". 5. Check the message in Settings > Technical > Discuss > Messages. Issue: --------- The email is sent in the language of the current user rather than the language of the employee receiving the shift. Cause: --------- The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language on the planning slot record because it is not directly linked to a `partner_id`. As a result, it falls back to the current user's language. Solution: ------------ Explicitly pass the employee partner's language in the mail context so that the email is sent in the correct language. opw-5928676 Forward-Port-Of: odoo/enterprise#110778 Forward-Port-Of: odoo/enterprise#109619
This update fixes a problem that prevented pay runs from calculating correctly when an employee's contract started mid-period. Specifically, a change was made to handle situations where the contract start date falls after the initial payslip period, preventing an error and ensuring accurate payroll calculations for new hires.
Original PR description
An error is thrown when an employee's contract starts mid-period. ```py Invalid Operation Wrong python code defined for: - Employee: Cesar Osbaldo Cruz Solorzano - Version: False - Payslip: Payslip -…
An error is thrown when an employee's contract starts mid-period.
```py
Invalid Operation
Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Payslip - Cesar Osbaldo Cruz Solorzano - 01/16/2026 - 01/31/2026
- Salary rule: Integrated Daily Wage (Base) (INT_DAY_WAGE_BASE)
- Error: AttributeError("'bool' object has no attribute 'year'") while evaluating
'\nresult = round(payslip.l10n_mx_integration_factor * payslip.l10n_mx_daily_salary, 4)\n
```
Steps to reproduce:
1. Install `l10n_mx_hr_payroll` modules
2. Switch to ESCUELA KEMPER URGATE company
3. Go to Employees and open Cesar Osbaldo Cruz Solorzano
4. Go to Payroll tab, change the start date of contract to 01/10/2026 and save
5. Go to Payroll > Payslips > Payslips and create a new pay run
6. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and Period '01/01/2026 -> 01/31/2026'
7. Click on Continue, select Cesar and click on Select
8. An error is thrown
Problem:
In `_compute_integration_factor` method, `_get_first_contract_date` is called with context `before_date`, it returns `False` as the contract starts after the payslip period. This causes an error when trying to access the `year` field of `start_date`.
Solution:
Add a fallback to call `_get_first_contract_date` without context in case the first call returns `False`.
target: saas-18.4
task-6034836
Forward-Port-Of: odoo/enterprise#110568This update adjusts the demo certificate used in testing to ensure it remains valid for a longer period. The original certificate expired in 2027, but this change extends its lifespan to 2036, resolving a potential issue with test results. This ensures accurate demonstration of the Peru E-Invoicing functionality.
Original PR description
In runbot's faketime tests, the test 1 year in the future goes past the end date of the demo PE certificate which had a lifetime of 2017-02-25 to 2027-02-25. This commit replaces that with one that lasts another ten years (2026-03-13 to 2036-03-13). runbot-241058 Forward-Port-Of: odoo/enterprise#110719
This update resolves a technical issue that was causing test failures related to loading times in the Point of Sale restaurant preparation module. The trigger that was checking for a spinning icon (fa-spin) has been removed, ensuring smoother performance and reliable test results. This change improves the stability of the POS system.
Original PR description
In this commit: = - Removed the trigger that checks for `fa-spin` as it was causing test failures when minor delays occurred between steps. - Checks for `fa-spin(Sync)` is alredy handled by the `isSynced` or `waitRequest`. Runbot-error: [198580](https://runbot.odoo.com/odoo/error/198580), [234025](https://runbot.odoo.com/odoo/error/234025) Forward-Port-Of: odoo/enterprise#87281
This update resolves an issue where 'Other Expenses' account types couldn't be used within the Loan expense tracking system. Now, users can correctly select 'Other Expenses' when recording expenses related to loans, improving the flexibility and accuracy of financial reporting.
Original PR description
Allow accounts with the "Other Expenses" type to be selected in the Expense Account field of Loans. task-5946452 Forward-Port-Of: odoo/enterprise#110085
This update addresses a technical issue where Odoo could experience errors when communicating with Sendcloud for shipping price calculations. Previously, a lack of response from Sendcloud would cause an error, preventing accurate delivery cost display. This fix ensures Odoo gracefully handles situations where Sendcloud doesn't respond, maintaining reliable delivery pricing.
Original PR description
Sendcloud sometimes doesn't respod when asking for `shipping-price`. So when we try to retrieve the first element of the response, we raise an `IndexError`. ----- Ticket: opw-5951749 Forward-Port-Of: odoo/enterprise#109252
This update ensures that files created within the Odoo Enterprise system correctly identify their MIME types, particularly when used with older versions of Chrome. This fix aligns with web standards and improves compatibility across different browsers, preventing potential display issues.
Original PR description
The `type` option passed to the `File` constructor should be a string representing the MIME type of the content that will be put into the file. Chrome 146 actually follows the Fetch Standard and preserve the data URL MIME type parameter. This commit fixes the malformed MIME types passed to the `File` constructor to ensure proper compatibility with pre/post Chrome version 146 (and actually follow the spec). References: - https://chromestatus.com/feature/4874471565557760 - https://developer.mozilla.org/en-US/docs/Web/API/File/File#type runbot-241901 Forward-Port-Of: odoo/enterprise#110812 Forward-Port-Of: odoo/enterprise#110496
This update resolves an issue that occurred when reconciling multiple journal entries within the Accounting module. Specifically, a calculation within the system was incorrectly handling scenarios with multiple reconciled lines, leading to errors. This fix ensures the system functions correctly regardless of how many journal entries are reconciled on a single account.
Original PR description
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with…
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with an amount of 999.99 - Set Account to "Liquidity Transfer" - Create a MISC entry: | Account | Debit | Credit | | -------------------- | ----- | ------ | | Liquidity Transfer | 0.00 | 0.01 | | Cash Difference Gain | 0.01 | 0.00 | - Post the entry - From Journal Items list, group by Account, select the 3 lines on "Liquidity Transfer" account and reconcile them - Go back to the Bank journal and try to edit the previous transaction **Issue:** A traceback is raised. **Cause:** In "_compute_full_amount_switch_html" method, the reconciled lines linked the current line are retrieved. A single line is expected and some operations that are only allowed on a singleton are performed. In our case, the reconciliation has been performed manually and there are several reconciled lines ; which violates the singleton condition. **Solution:** The value computed by "_compute_full_amount_switch_html" has no sense if there's more than one reconciled line. Therefore, the computation can be skipped in such a case. opw-6031879 Forward-Port-Of: odoo/enterprise#110857
This update corrects a problem causing incorrect stock synchronization for Amazon listings, leading to phantom orders. The fix allows users to manually specify the fulfillment channel (FBA or FBM) for listings, resolving a known 'ghost listing' issue. This ensures accurate stock management and order fulfillment.
Original PR description
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and…
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM). However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders. To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa. To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings. To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous. opw-5480254 See also: - https://github.com/odoo/upgrade/pull/9692 Forward-Port-Of: odoo/enterprise#106662
This update corrects a problem where users were receiving duplicate push notifications from Social Marketing. The fix involves changes to how Firebase notifications are handled and ensures the service worker is properly configured for reliable subscription. This improves the user experience and prevents notification overload.
Original PR description
When the user sends a push notification through Social Marketing, the application displays two notification popups because: 1. The Firebase SDK automatically displays a notification popup if the…
When the user sends a push notification through Social Marketing, the application displays two notification popups because: 1. The Firebase SDK automatically displays a notification popup if the request made to Firebase includes a `notification` field. 2. Our service worker displays a notification popup when receiving a background message from Firebase. To prevent duplicate notifications, we will remove the custom event listeners in the service worker and update the request made to Firebase so that the Firebase SDK opens a notification for us. Furthermore, this PR fixes the error `Failed to execute 'subscribe' on 'PushManager': Subscription failed - no active Service Worker` occurring when the user accepts the push notifications. To fix that issue, we will: 1. Ensure that the service worker reaches the `ready` state before communicating with it. 2. Set the service worker's scope to `/` so it controls all pages on the origin, ensuring push subscriptions succeed and the worker can communicate with any page. Finally, we will use the legacy `importScripts` syntax to load Firebase dependencies because the ECMAScript module syntax is not supported for service workers in Firefox. This approach improves push notification compatibility across browsers. Task-5124645 Forward-Port-Of: odoo/enterprise#110823 Forward-Port-Of: odoo/enterprise#96029
Previously, when users uploaded multiple files to a WhatsApp Discuss channel, only the first file was delivered. This update corrects this issue by validating the number of attachments before sending, ensuring all files are transmitted correctly. This improves the reliability of WhatsApp communication within Odoo.
Original PR description
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a…
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a WhatsApp Discuss channel. 2. Send the message. -> Odoo shows all files, but only the first reaches the destination. ### Cause WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest. ### Fix Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss. opw-5889035 Forward-Port-Of: odoo/enterprise#110657 Forward-Port-Of: odoo/enterprise#107424
This update resolves a technical issue that caused a traceback during horizontal autofilling of pivot table row headers. While the core functionality remains unchanged, the fix ensures a more stable and consistent experience for users. The result isn't fully corrected, but aligns with vertical autofilling.
Original PR description
When autofilling a positional pivot row header horizontally, we would get a traceback because we were calling `_autofillPivotColHeader` instead of `_autofillPivotRowHeader`. Note that this fix only fixes the traceback, the result is not correct, but is consistent with autofilling a positional col header vertically. Task: [5909266](https://www.odoo.com/odoo/2328/tasks/5909266) Forward-Port-Of: odoo/enterprise#110521 Forward-Port-Of: odoo/enterprise#109620
This update corrects a technical issue where archived partners were incorrectly identified during bank statement retrieval, leading to inaccurate partner assignments. The change now ensures that partner retrieval only considers active partners, improving data accuracy and reliability for financial reporting.
Original PR description
Description of the issue this commit addresses: Partner auto-detection on statement lines could match archived partners via SQL causing unexpected partner_id assignment. Desired behavior after this commit is merged: Partner retrieval from bank account, partner name, and previous statement lines only considers active partners, preventing archived matches. runbot-238918 Forward-Port-Of: odoo/enterprise#110446
This update resolves an issue where the batch view in the Odoo Enterprise system incorrectly displayed multiple 'Validate' buttons. The fix ensures that only one 'Validate' button is visible, streamlining the quality check process for users. This improves usability and prevents confusion.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/enterprise#109911 Forward-Port-Of: odoo/enterprise#107993
This update resolves an issue where the bulk payments feature would crash if a bank journal wasn't connected. The fix adds a user-friendly warning message to alert users when attempting to check the status of a batch without a linked bank account, preventing errors and improving the user experience.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/c9cc89f58f7d98396afac3bdacfeff9b00a02a21 introduce the initiate bulk payments feature. When selecting a batch you can also check the status of this batch. But for the moment, if you select a batch that is not connected to a bank, the action will traceback with a redirect. This commit will add a user error to warn the user than the journal needs to be connected to a bank. task-6009083 Forward-Port-Of: odoo/enterprise#110474 Forward-Port-Of: odoo/enterprise#109956
This update fixes a previous issue where the tax returns journal wasn't automatically translated into all supported languages. The team has now implemented a standard translation process, ensuring the journal is correctly translated for each user's language setting, improving accuracy and usability.
Original PR description
Currently, the tax returns journal is created in the code and not via the standard `@template` function that makes sure it is always translated in the installed languages. So for now it was only translated in language of the current user. We refactored the code so the journal gets created via the standard `@template` function and thus automatically gets translated into all the installed languages. task-5921458 Forward-Port-Of: odoo/enterprise#111062 Forward-Port-Of: odoo/enterprise#107465
This update corrects a technical issue within the Account Avatax module, ensuring it properly identifies the company it's associated with in system settings. Previously, a key piece of information was missing, which is now included. This ensures accurate tax calculations and reporting.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. Followup of odoo/odoo#254242 task-none Forward-Port-Of: odoo/enterprise#110983
This update resolves a minor issue preventing the correct display of a tour within the industry_fsm_report module. The fix ensures that users can properly access and understand the available features within the FSM reporting functionality. This improves the user experience and guides users through key reporting processes.
Original PR description
task-4489657 Forward-Port-Of: odoo/enterprise#111099 Forward-Port-Of: odoo/enterprise#81823
This update resolves a bug where subscriptions would incorrectly revert to an 'In Progress' state after a credit note payment. The fix prevents the reopening of subscriptions when a credit note payment (specifically refunds) is processed, ensuring subscriptions remain accurately tracked as churned. This improves subscription management and reporting accuracy.
Original PR description
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and…
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and ensure the invoice is in the Paid state. 4. Go back to the subscription and close it with any reason 5. Open the related invoice. * Create and Confirm Credit Note. * Register a payment for the credit note. 6. Go back to subscription Observation: ------------------------------ The subscription is automatically set back to `In Progress` even though it was previously churned. Issue: ------------------------------ The method `_reopen_paid_churned_subscription` reopens churned subscriptions when an invoice is set to `in_payment` or `paid`. There was no check to exclude refund moves (`move_type = 'out_refund'`), causing the subscription to be reopened when a credit note is paid. Solution: ------------------------------ Add a condition to exclude refund invoices from the reopening logic opw-5947999 Forward-Port-Of: odoo/enterprise#108487
1 change
Resolved issues and error corrections
This update fixes a limitation in how service products are linked to projects. Previously, only task-based projects were displayed. Now, both task and employee-based projects are visible, ensuring more accurate project tracking and reporting for sales orders.
Original PR description
**Steps to reproduce (with demo data):**
- Install sale_timesheet.
- Create a product:
- Type: Service
- Create on Order: Task - Project: select (AGR - S00021 - Sales Order)
**Issue:**
Currently, only projects with task_rate pricing type are displayed in the project field.
**Fix:**
In this commit, we updated the domain of the project field to also include employee_rate.so, both task-based and employee-based projects are now visible.
**Technical:**
In the _search_pricing_type() method, we were using the = operator. To keep minimal changes in the stable version, we used the | operator in the field domain instead of modifying the existing logic extensively. like- ('pricing_type', 'in', ('task_rate', 'employee_rate')
task-5118940