Daily updates from Odoo
Sunday, January 25, 2026
45 changes · master
New functionality added to Odoo
This update introduces a new module for Odoo Enterprise to help Finnish businesses comply with Intrastat reporting requirements. It generates CSV reports of import and export data, allowing for easy submission to Finnish Customs, and includes a wizard for simplified report downloads and submissions.
Original PR description
Added a new module to support Finnish Intrastat compliance by generating CSV declarations compatible with the Finnish Customs service. This Includes: - Export arrivals and dispatches reports in CSV format (bundled in ZIP). - Configure agent VAT for arrivals when filed via an agent. - Wizard to download and submit periodic Intrastat reports. task-5049047 Forward-Port-Of: odoo/enterprise#95457
This update enhances Odoo's translation system by introducing a caching mechanism. Previously, the system re-translated records unnecessarily. Now, Odoo can efficiently track and reuse previously translated data, leading to faster performance and reduced resource usage. This change prepares Odoo for more flexible translation options.
Original PR description
Add new class StoredTranslations for cache value, which allows ORM to
know if it has already cached all translations for a record.
task-5499441
prepare to support `record.tranlated_field = {'en_US': 'en', 'fr_FR': 'fr'}`
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update introduces the Caribbean Guilder (XCG) as a new currency option within Odoo. It's specifically designated as the default currency for Curaçao and Sint Maarten, expanding Odoo's currency support to include these regions. This change allows users to accurately track financial transactions in these local currencies.
Original PR description
Introduce the Caribbean Guilder (XCG) as an available currency and set it as the default currency for Curaçao and Sint Maarten. Related PR-https://github.com/odoo/enterprise/pull/104404 taskID-5490423 Forward-Port-Of: odoo/odoo#243955
This update introduces support for the Caribbean Guilder (XCG) as a new currency option within Odoo Enterprise. It's now the default currency for Curaçao and Sint Maarten, aligning our financial data with local requirements. This change improves reporting accuracy for businesses operating in these regions.
Original PR description
Align enterprise currency data with the community with addition of new currency XCG. Related PR-https://github.com/odoo/odoo/pull/243955 taskID-5490423 Forward-Port-Of: odoo/enterprise#104404
Enhancements to existing features
This update reorganizes the UBL test files within the Odoo system, moving them to a more structured folder. This change prepares the system for future support of different invoice formats and enhances the ability to validate schema compliance. It’s a technical update to improve testing capabilities.
Original PR description
This commit rearranges the UBL test files' subfolder to be one level higher, from `export/bis3/be` to `export/bis3/invoice/be`, in preparation for supporting different move formats and for better ignore schema support. task-4891206 Forward-Port-Of: odoo/odoo#244886 Forward-Port-Of: odoo/odoo#244665
Resolved issues and error corrections
This update ensures that optional product images are only shown when the system is configured to display them. Previously, images were always shown, even when disabled, leading to a less polished user experience. Now, a placeholder is used when no image is available, aligning with the system's settings and improving visual consistency.
Original PR description
Before this commit: =================== - When the `Show product images` setting was disabled, the optional products UI still displayed product images. - If an optional product did not have an image, the UI displayed the image's alt text - Also when the product don't have image, the combo popup and product card just display the product name. After this commit: ================== - Optional product images are displayed only when the `Show product images` configuration is enabled. - If the optional product doesn't have an image, we will display an image placeholder instead of alt text. - If there is no product image, the combo popup and product card will display the image placeholder. Task: 5480181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244809 Forward-Port-Of: odoo/odoo#243222
This update resolves a hidden bug that occurred when using multiple databases within PostgreSQL. The change ensures queries accurately reflect the current database schema, preventing incorrect data retrieval and improving overall system performance. This enhances data reliability and efficiency.
Original PR description
It prevents hidden bugs when multiple schemas are used in PostgreSQL This was mentioned in: - PR odoo/odoo#243967 Forward-Port-Of: odoo/enterprise#104936
This update fixes a potential issue where custom buttons on the website could display incorrectly due to text wrapping within a paragraph tag. The change adds a test to ensure buttons are rendered correctly, preventing a confusing user experience. This improves the overall stability and appearance of the website.
Original PR description
Add a hoot test covering the case where the custom button snippet gets incorrectly wrapped inside a `<p>` tag. Original changes introduced in commit 3a8f2cc418510c3b91f8b9086bb4a89a1745e40d. Forward-Port-Of: odoo/odoo#244208 Forward-Port-Of: odoo/odoo#224476
This update resolves an issue where GS1 barcodes were causing errors during scanning, preventing users from correctly identifying products. The fix prevents the system from attempting to interpret GS1 barcodes as dates, allowing the barcode scanner to function properly and accurately detect products.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: 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 main_menu and explicitly reset parsed_results to False, allowing the normal main menu resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product, picking, or location detection still works as expected. opw-5357611 Forward-Port-Of: odoo/enterprise#104832 Forward-Port-Of: odoo/enterprise#104641
This update fixes a problem where the status banner for digitized vendor bills disappeared when auto-posting was enabled. When auto-posting is used, the bill's status jumps directly to 'to_validate', and sometimes 'done', causing the banner to not update correctly. This ensures the status banner accurately reflects the bill's processing stage.
Original PR description
The status banner widget expected the state to be equal to `waiting_validation` once the document was successfully digitized. But when auto-post is used on vendor bills, the state will skip directly to `to_validate` as the bill is posted right after the digitization. It can even be moved to `done` if the validation cron has time to run before the update of the banner. task-[5480954](https://www.odoo.com/odoo/49/tasks/5480954) Forward-Port-Of: odoo/enterprise#104793
This update corrects a problem where Saudi partner addresses were being unintentionally cleared when related contacts were created or updated. The fix prevents address data from being reset, ensuring accurate address information for all Saudi partners. This improves data consistency and reliability.
Original PR description
All Saudi partners use the saudi_o_address_format. As a result, contacts created from a company partner also inherit this address format, which includes fields such as street, city, zip, and state. These fields are set as read-only by the address format. When child_ids are written on the parent partner, those read-only fields are written with False values. Due to the address field synchronization between parent and related contacts, these False values are then propagated back to the parent partner, causing its address data to be cleared. This fix prevents address fields from being unintentionally reset when related contacts are created or updated. task-5349050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241862
This update strengthens the reliability of our IoT translation tests by ensuring they work with standard string values instead of internal implementation details. By 'allowing' translations within the tests, we've addressed a potential instability issue and improved the overall robustness of the system.
Original PR description
Before this commit, a test in iot was looking at the 'values' key of a LazyTranslatedString to make an assertion. This is not robust, as this is an implementation detail internal to the translation system. To fix this, the translations have been "allowed" (i.e. loaded) in the test, ensuring that the returned value is a string and not a lazy-translated string. Community: https://github.com/odoo/odoo/pull/244588 Forward-Port-Of: odoo/enterprise#104939
This update resolves an issue that occurred when users clicked the 'Code History' button within Server Actions. The error stemmed from a missing timezone setting, which caused a technical problem. This fix ensures the button functions correctly regardless of the user's timezone configuration.
Original PR description
This error occurs when clicking the `Code History` button in Server Action. Steps to reproduce: - Search `Server Actions` > Open any server action - Change `Code` and Save > Click `Code History` button Traceback: `AttributeError: 'bool' object has no attribute 'upper'` This error occurs when the `Code History` button is clicked and, at that point, the user’s timezone is `False` because it is not set in the user’s calendar. [1]- https://github.com/odoo/odoo/blob/54681272e9f00a171fe49f690979e2a8353ff5fb/odoo/addons/base/models/ir_actions.py#L515 sentry-7167683304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245093 Forward-Port-Of: odoo/odoo#242276
A recent test was failing intermittently due to an issue with redirect URLs being incorrectly formatted. This update corrects the test to handle these URLs properly, ensuring consistent test results. This resolves a technical problem that could have impacted the stability of the system.
Original PR description
Bug === On some runs, the redirect URL is absolute and not relative, (eg: `http://127.0.0.1:8069/web/signup?db=...`) and so the test needs to be adapted. Task-5857520 Forward-Port-Of: odoo/enterprise#105027
This update resolves an issue preventing correct Spanish translations in reports. The previous method of triggering translations was failing due to a lack of necessary data within the translation process. By changing the computation method, the system now correctly retrieves the language information, ensuring accurate Spanish translations.
Original PR description
Problem --------- Currently, the lazy translation is executed inside the Markup frame. This has the consequence of having the frame pretty much empty (no context, no user, no cr) when looking for the language. Thus, the lazy translate cannot retreive any language. Solution --------- Use `str` in the compute method so that the frame used to compute the translation is actually the compute method (which has data needed to retreive the language) and not the markup. Before: -> compute ..|-> Markup (the frame used) ....|-> _lt => fail After: -> compute (the frame used) ..|-> _lt ....|-> Markup error-237535 error-237536 Forward-Port-Of: odoo/enterprise#104834 Forward-Port-Of: odoo/enterprise#104776
This update fixes a technical error that occurred when generating invoices for the Colombian DIAN tax system. Previously, an empty invoice document caused a system crash. Now, the system gracefully handles empty documents, preventing the error and ensuring accurate invoice generation.
Original PR description
Since this fix: ba24b48 , a default empty document contains `<Note>No xml</Note>` was created when posting bills. However, the `l10n_co_dian.report_invoice_document` template attempts to parse this document for DIAN values. Because these values are missing from the empty document, a traceback occurs. In this commit, we fallback to standard template when the empty document exists. opw-5246912 Forward-Port-Of: odoo/enterprise#100040
This update optimizes the way live chat expertise data is handled, preventing unnecessary data retrieval and potential performance issues. Previously, data was fetched regardless of whether it was needed, now it's only loaded when a live chat conversation is opened, resulting in a smoother user experience.
Original PR description
Before this commit, the user's live chat expertise were always returned as part of `_init_store_data`. However, this led to a warning in portal tours because the expertises are inserted into the store while the live chat models are not loaded (they are not needed). We shouldn't return useless data. This commit fixes this issue by fetching the data when they will be needed (i.e. when the discuss app is opened with a live chat user). runbot-234137 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245062 Forward-Port-Of: odoo/odoo#244463
A technical issue causing a traceback when creating maintenance requests from work orders in the Shop Floor module has been fixed. This was due to a mismatch in XML IDs after a recent code refactoring. The fix ensures that maintenance requests can now be created without errors, maintaining the existing functionality.
Original PR description
Issue before this commit: ========================= When creating a maintenance request from a work order in the Shop Floor module, a traceback was raised. Steps to Reproduce:…
Issue before this commit: ========================= When creating a maintenance request from a work order in the Shop Floor module, a traceback was raised. Steps to Reproduce: ========================= - Install the mrp_maintenance module. - Create a Manufacturing Order with at least one operation. - Open the Shop Floor module. - From a work order, click on the three-dot (extra) menu. - Click on Request Maintenance. - A traceback occurs: ValueError: External ID not found in the system: mrp_maintenance.maintenance_request_view_form_inherit_mrp_workorder Cause of the issue: ========================= The above XML ID was previously used to add a custom JS widget that displays a notification when creating a maintenance request from the Shop Floor. During a recent refactoring in this [PR](https://github.com/odoo/enterprise/pull/100326), this XML record was removed (while the notification functionality remained intact). However, the Python code was still referencing this XML ID, which has now been reintroduced in this [PR](https://github.com/odoo/enterprise/pull/100348), and this mismatch resulted in the traceback. With This Commit: ========================= Ensure that creating a maintenance request from the Shop Floor no longer raises a missing external ID error, while keeping the expected behaviour unchanged. Forward-Port-Of: odoo/enterprise#105030
This update fixes an issue where the floating order name displayed during direct sales in the restaurant POS was incorrectly showing the POS reference instead of the tracking number. This change ensures customers receive the accurate order information, improving the overall sales process and customer experience. The fix was part of a larger effort to improve data accuracy within the Odoo system.
Original PR description
Before this commit, when making a direct sale, the floating order name was the pos reference instead of the tracking number. This is now fixed. task-id: 5470874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242359
This update enhances the reliability of connections to our IoT boxes. Previously, relying on domain names could cause issues due to DNS problems. Now, the system automatically retrieves the IP address of the IoT box when LNA is enabled, ensuring a more stable connection.
Original PR description
In order to avoid DNS resolution issues, we now parse the domain to get the IP of the IoT Box if LNA is enabled. Forward-Port-Of: odoo/enterprise#105138
This update fixes a potential performance issue in the IoT drivers by preventing unnecessary ID additions when actions take longer than 6 seconds to complete. Previously, the system would add IDs repeatedly, which has now been corrected to only add IDs when actions successfully finish, improving overall system responsiveness. This change ensures more efficient data transmission and reduces potential delays.
Original PR description
If an action takes a long time to execute (>6s), then we don't add the unique id during this time as the action didn't finish. As it exceeds 6 seconds, we also send one through websocket, that isn't filtered as duplicate as the action id isn't set yet in the `_recent_action_ids` cache. To avoid this, we add the action id to the cache, then execute the action and remove the id from the cache if there is an exception. Forward-Port-Of: odoo/odoo#245049 Forward-Port-Of: odoo/odoo#244953
This update fixes an issue where role mentions disappeared when users edited messages in Odoo. The change ensures that role mentions are correctly preserved during the editing process, improving communication and collaboration within the system. This resolves a previous bug that prevented users from accurately referencing team members in their messages.
Original PR description
**Current behavior before PR:** Editing a message with a role mention would cause the mention to be lost. **Desired behavior after PR is merged:** Role mentions are now preserved when editing a message. task-4702960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245080 Forward-Port-Of: odoo/odoo#218992
This update corrects a problem where the avatar card didn't correctly display the partner's local time when viewing from different time zones. The fix ensures that the avatar card accurately reflects the user's timezone, improving the user experience and data consistency. This resolves a test failure related to timezone handling.
Original PR description
The `Avatar card shows local timezone` ensure partner local time is shown in the avatar card when the user that consults it has a different tz. This test also ensures that nothing is shown when timezone are the same. However, the assertion expects to find the node containing the text in the DOM while it's not rendered when both tz are the same. This commit fixes the issue. runbot-238383 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245219
This update fixes an issue where a single error during invoice import would halt the entire process, leading to duplicate invoices being created. The change ensures that the import process continues smoothly even if an invoice encounters an unexpected error, improving data accuracy and reducing manual intervention. This resolves a previous bug impacting invoice import reliability.
Original PR description
When you import a batch of invoice and one of them gets an unexpected Exception, the others are created but we stop the method. It's a problem with crons that don't expect to be interrupted in the middle. It creates duplicates as we fail on the same invoice each time. Of course, we should avoid all Exceptions when we can, but we should not loop on the same error. opw-5503069 part of task-5499871 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245040 Forward-Port-Of: odoo/odoo#244543
This update resolves an issue where the system was unintentionally preventing the setting of 'Anglo Saxon Accounting' for company records. A recent fix to optimize template data loading inadvertently triggered an older fix that removed this setting. This change ensures 'Anglo Saxon Accounting' is correctly applied as needed.
Original PR description
In 19.1 a fix was developed to avoid bridge modules for template data [1]. A couple of `ChartTemplate._pre_load_data` calls without template data were added to discard non-existent fields in the database. It inadvertently triggers an older fix [2] that was meant to unset `anglo_saxon_accounting` for existing companies if not explicitly set in the template, which meant that in practice `anglo_saxon_accounting` wasn't being set anymore. [1] https://github.com/odoo/odoo/pull/238115 [2] https://github.com/odoo/odoo/pull/178113 task-5785189 Forward-Port-Of: odoo/odoo#245152
This update fixes an issue where test bank statement imports in Odoo created actual records in the database, even when the test failed. The change ensures that test imports don't trigger reconciliation processes, preventing unintended data creation. This improves the reliability of test data and reduces potential data inconsistencies.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to Accounting dashboard 1) - On "Bank" journal card, select "Import File" option in dropdown menu - Upload a file containing a lot of statements…
**Steps to reproduce:**
- Install Accounting
- Go to Accounting dashboard
1) - On "Bank" journal card, select "Import File" option in dropdown menu
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
2) - Open "Bank" journal
- Select "Import records" in the cog menu
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
3) - Open "Bank" journal
- Click on "Upload" button
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
**Issue:**
The issue happens when the test import fails.
Even if it was a test, all the records are created in the database.
**Cause:**
During a test import the records should not be reconciled after creation.
However, by default, "auto_statement_processing" property is True and trigger the reconciliation.
When an error is raised during the test import, a rollback is made on a previous savepoint.
But a commit can be done in "_cron_try_auto_reconcile_statement_lines" method, which results in the records being created for real.
**Solution:**
Set "auto_statement_processing" property to False for Test import.
For use case 1) and 2), we make sure that we follow the same flow than use case 3).
opw-5436937
Forward-Port-Of: odoo/enterprise#104954This update fixes a test that was intermittently failing due to how Odoo marked inbox messages as read. The change ensures the test waits for the initial message fetch, preventing a common failure scenario. This improves the stability and reliability of the inbox read functionality.
Original PR description
The `Opening thread with needaction messages should mark all messages of thread as read` text composer test ensures that opening a channel marks the related inbox messages as read. However, this test can fail in a non-deterministic fashion. There are two flows that can mark inbox messages as read: fetching the messages or a manual request after opening the channel. The test expects the rpc to be issued, but if the messages are fetched before, it won't happen thus making the test fail. This commit awaits the initial fetch to prevent this issue. As a bonus, the second flow is also tested. runbot-238360 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245067 Forward-Port-Of: odoo/odoo#244950
This update ensures that links within the HTML editor now correctly inherit font sizes from the surrounding text, regardless of previous settings. This change simplifies styling and aligns with best practices, removing a previously used customization option that is no longer needed.
Original PR description
Ensure that a simple link can inherit from an ancestor `font-size` defined using the Editor toolbar, overriding the `mass_mailing` Design Tab `--link-font-size` special variable. That variable will be removed in the future, because it is more natural that a link font-size is aligned with its container. task-5868086 Forward-Port-Of: odoo/odoo#245225
This update ensures that admin users retain their intended default options when reviewing courses, regardless of edits or deletions made by other users. This prevents unintended changes to course ratings and improves the stability of the review process. The change was made to consolidate fixes and avoid duplicated efforts.
Original PR description
*: website_slides The default values for the admin user should not be changed by editing or deleting others' messages in courses. task-5326273 Forward-Port-Of: odoo/odoo#245127 Forward-Port-Of: odoo/odoo#236475
This update fixes an issue where employee appraisals weren't automatically selecting the correct company template when the employee lacked a department. The change ensures that appraisals use the employee's company template, regardless of department assignment, improving appraisal accuracy and consistency. This resolves a previous bug impacting appraisal setup.
Original PR description
### Issue: When having a template with a company but no department, it's not selected by new appraisal. ### Steps to reproduce: - Have an employee whose appraisal date is today. - Have only one…
### Issue: When having a template with a company but no department, it's not selected by new appraisal. ### Steps to reproduce: - Have an employee whose appraisal date is today. - Have only one template, with the company of the employee but no department - Run the cron "Appraisal: Run employee appraisal" - Open the Appraisals app - Click on the newly created appraisal - It doesn't have the template ### Cause: - In `_compute_appraisal_template()`, only the department of the appraisal is used to compute the template. But `_create_new_appraisal()` doesn't include the department in `appraisal_values` to create the appraisal. So `appraisal.department_id` is `False` and the template from the department is ignored. - Another issue is if the employee has no department, then the appraisal also has no department. Then no template is selected by the search domain. ### Solution: - Include `department_id` in `appraisal_values` - Modify the search domain to include the case where the appraisal has no department opw-5477450 Forward-Port-Of: odoo/enterprise#104470
This update fixes a display issue in the appointment calendar for Ukrainian and Polish users. Previously, month names were shown in the genitive case, which was incorrect. The fix ensures month names are displayed in the nominative case, aligning with standard calendar conventions and improving user experience.
Original PR description
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word…
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word used depends on grammatical situation. Steps to reproduce: - activate Ukrainian (or Polish) language - Preview (i.e. the website view) of any appointment - Change the preview into Ukrainian (or Polish) Expected result: Calendar month at top of calendar is shown in the nominative case: e.g. January 2026 = січень 2026 (in Ukrainian) Actual result: Calendar month is shown in the genitive case (e.g. "of January", as in "the 12th of January): e.g. January 2026 = січня 2026 (in Ukrainian) Fix is to switch from the "MMMM Y" format (i.e. month based on grammar context) to "LLLL Y" (i.e. stand alone month) which will use the correct month case. Ref: https://www.unicode.org/reports/tr35/tr35-dates.html#dfst-month Note that for most languages this won't make a difference since there is usually only 1 way of writing a month. opw-5474705 picture diff (for January 2026): before fix: <img width="1168" height="468" alt="image" src="https://github.com/user-attachments/assets/36754439-e664-40f3-9c5b-7c9c76cd7cca" /> after fix: <img width="1215" height="492" alt="image" src="https://github.com/user-attachments/assets/82f0665e-fe70-4b9f-b1d4-f420b52db38f" /> Forward-Port-Of: odoo/enterprise#104942
This update fixes an issue where refund and bill payments to the same bank account and partner weren't always combined into a single payment. Previously, separate payments were created for inbound and outbound transactions. Now, the system correctly merges these payments, simplifying reconciliation and reducing potential errors.
Original PR description
When we register payments for a list of journal entries, the `account.payment.register` wizard computes batches and sometimes merge them together. For instance, this allows to create a single payment if there is an outbound (a bill to pay) and an inbound (a refund to receive) payment to the same bank for the same partner. Instead of creating two payments of -1000 and +500, we only create one of -500. Currently, this mechanism does not always work. That's because the `batch_key` used to decide whether to merge or not refers to a value that is not updated in the loop. Related ticket: opw-5401372 Forward-Port-Of: odoo/odoo#242863
This update optimizes the Odoo database by removing unnecessary default settings in the Spanish localization module (l10n_es_edi_facturae). This reduces database size and improves performance, particularly for businesses operating across multiple companies with different tax requirements. The change ensures correct handling of user-defined values, maintaining data integrity.
Original PR description
On multi-company databases, having the defaults value on `account.move` selection fields unnecessary bloat the database for other companies with different fiscal package (localization). Moreover those two selection fields (`l10n_es_payment_means` and `l10n_es_edi_facturae_reason_code`) are not required, meaning the user can still set the value to `False` and we must be sure to handle that case anyway. opw-4397651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242539
This update resolves a technical issue that could cause Odoo upgrades to fail when setting up manual one-to-many fields. The fix ensures that Odoo properly checks if the related inverse field is set up before attempting to use it, preventing a 'KeyError' and ensuring smoother upgrades.
Original PR description
When ``setup`` a manual one2many field, if its ``inverse_name`` field hasn't been ``setup`` and is also a manual field which might be ``pop`` when ``setup``, the one2many field can be ``setup`` successfully. But when computing ``setup_inverses`` when ``init_models``, the ``inverse_name`` will cause a ``KeyError``. ``invf = registry[self.comodel_name]._fields[self.inverse_name]`` Reproduce: see https://github.com/odoo/odoo/pull/240085 This commit simply checks the ``setup`` for the inverse field of the one2many field. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245240
This update corrects a display issue where deleted floors would reappear in the floor selector after a refund was processed. The fix filters out inactive floors, ensuring the selector only shows active floor options. This improves the user experience by preventing confusion and outdated information.
Original PR description
Task: [#5421683](https://www.odoo.com/odoo/project/1737/tasks/5421683) --- **Steps to reproduce:** * Create a new floor with one table * Create and pay an order on that table * Delete the floor * Refund one line of the order ==> The deleted floor is shown again in the floor selector, without its table. This happens because the deleted floor is loaded when fetching the table of the order in the Ticket Screen. If an order is linked to a table that belonged to a deleted floor, that floor is loaded again and displayed in the floor selector. **Fix:** Filter out inactive floors from the floor selector. Forward-Port-Of: odoo/odoo#244344 Forward-Port-Of: odoo/odoo#240276
This update corrects an issue where the invitation link in shared documents was incorrectly formatted, leading to a broken link. The change ensures that the correct, functional link is consistently generated when sharing documents, improving the user experience. This resolves a previous bug related to how links were constructed in the system.
Original PR description
Bug === Since 22446368503fadc0e0bf459dd3c8ab8b8f6624b0 , we use a mail template to share access, but in e3e8d6a6b9423feae4dd88978065bd8799031b2b , we added the link in the standard notification process (because it was done in 18.0). Task-5242208 Forward-Port-Of: odoo/enterprise#105081 Forward-Port-Of: odoo/enterprise#104573
This update corrects a technical error where a function was being called in the wrong module, causing a potential issue with payroll document generation. The fix involves creating a new function in the correct module to properly execute the necessary process, ensuring accurate payroll document creation.
Original PR description
Issue: `_check_create_documents` is called in 'hr_payroll' but only defined in 'documents_hr_payroll' Solution: Create a new method that will be redefined in 'documents_hr_payroll' to call `_check_create_documents` opw-5213979 Forward-Port-Of: odoo/enterprise#105099 Forward-Port-Of: odoo/enterprise#104282
This update resolves an error that occurred when viewing work orders, specifically related to how employee assignments were processed. The fix corrects a technical issue where the system incorrectly identified duplicate keys, preventing work orders from opening properly. This ensures work orders can be accessed and managed without interruption.
Original PR description
The previous loop used `employee.id` as the key, which is undefined in this context because values come from resIds and represent record IDs directly. Steps to reproduce: - Enable work orders - Create a BOM with a work order - Configure 2 Assigned employees - Open the work order in Shop Floor An error is raised because, since `employee` is an integer (the ID), `employee.id` is undefined so odoo founds duplicate keys (all undefined). opw-5417887 Forward-Port-Of: odoo/enterprise#102510
This update corrects a minor issue where the Requests library was causing import errors. The team installed a specific version of Requests and added a necessary import statement, resolving a conflict that arose from a recent update to the Requests package itself. This ensures the Odoo system continues to function correctly.
Original PR description
Installing `requests==2.25.1` and using the following line of code:
from requests.exceptions import JSONDecodeError
It raises the following error:
ImportError: cannot import name 'JSONDecodeError' from 'requests.exceptions' (python3.10/site-packages/requests/exceptions.py)
It was removed from the following commit in the `requests` package:
https://github.com/psf/requests/commit/db575eeedcfdb03bf31285afd3033e301df8b685
This change fixes this error importing the original exception from `json` package
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245075This update aligns the network icon used in Odoo with established design guidelines. The change ensures a more consistent and professional look and feel for the enterprise version of Odoo. It's a minor update focused on visual branding.
Original PR description
This `network_light.svg` wasn't quite aligned with Milky picto's design guidelines. In this PR the pictogram has been tweaked in order for it to follow the guidelines. task-5126719 Forward-Port-Of: odoo/enterprise#104356 Forward-Port-Of: odoo/enterprise#95895
This update resolves an issue where internal users without sales permissions encountered errors when accessing their sales orders through the /my page. The change mirrors a previous fix and ensures a smoother experience for all users within Odoo. This prevents disruptions and maintains consistent functionality.
Original PR description
Avoid error when internal user (no sale permissions) see Orders at /my Similar to https://github.com/odoo/odoo/commit/5ebab949a06ec338cc28e912317a74bbfb3fe6ac @Tecnativa TT60025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245039
This update resolves a visual issue in the invoicing dashboard caused by enlarging icons in the bills list view. The fix uses a temporary setting to display larger icons only when needed, restoring the dashboard's original layout and ensuring a consistent user experience. This change was part of a broader effort to improve the bills list view.
Original PR description
As a part of task-5258726 the icons of no-content help in bills list view were enlarged. The icons used there were also used in the module dashboard, so enlarging them messed the dashboard styling. This commit fixes this issue by using a prop `largeIcons` on the `BillGuide` componenet to make it with large icons when needed only (in the bills list view no content help). task-5801970 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245209
This update fixes an issue where the website's cookie consent settings weren't being saved correctly after changing the 'I agree' button style to 'Default'. The change ensures that when the user saves the updated style, their cookie consent is properly recorded, preventing the cookie bar from reappearing. This maintains a consistent user experience and accurate tracking of consent.
Original PR description
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape…
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape to "Default" (this applies the `.btn-primary` class). & Save 4. Accept the cookies & refresh -> The cookie bar appears again because the consent was not saved. Cause: ====== The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup. By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written. Solution: ========= Override the event to avoid side effects on hide. opw-5484578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244875 Forward-Port-Of: odoo/odoo#243562
This update resolves an error that prevented users from selecting the Auto-Complete field when a vendor wasn't initially chosen. The fix hides this field until a vendor is selected, ensuring a smoother user experience. This prevents a technical error that was blocking functionality.
Original PR description
Currently, an exception is generated when the user tries to select `Auto-Complete` without selecting `Vendor`. Steps to produce an error - Go to Invoicing > Vendors > Bills > Click New - Try…
Currently, an exception is generated when the user tries to select `Auto-Complete` without selecting `Vendor`. Steps to produce an error - Go to Invoicing > Vendors > Bills > Click New - Try selecting `Auto-Complete` >>> Error occurs Error `AssertionError: Invalid falsy real id` This error occurs because, after the recent refactoring in commit [1], falsy ids are no longer allowed in domains. In the `Account Entry` view `[partner_id]` (see [2]) is passed as part of the domain. When the user has not selected a vendor (partner_id) it evaluates to False, which results in [False] being passed and triggers the error introduced by commit [1]. This commit will fix the above issue by hiding the `Auto-Complete` field when `Vendor` is not selected. [1]: https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f [2]: https://github.com/odoo/odoo/blob/7b288aa436f669d8c8e2ddac5277bb98321a390e/addons/account/views/account_move_views.xml#L1067 Sentry-7201563878 Forward-Port-Of: odoo/odoo#244729
This update corrects a potential issue where tax calculations in point-of-sale reports were slightly inaccurate due to rounding. The change ensures that the total tax base amounts displayed in reports precisely match the sum of individual line items, providing more reliable financial reporting. This fix addresses a minor discrepancy and enhances the overall accuracy of sales data.
Original PR description
Before this commit, the total base amounts of taxes might be different from summing the base amounts of each line, due to rounding issues. opw-5408201 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244280