Daily updates from Odoo
Friday, January 26, 2024
45 changes · 17.0
New functionality added to Odoo
A new reporting module has been added for Philippine businesses to generate and export Summary List of Sales and Summary List of Purchases reports. These reports follow the official format required by the Bureau of Internal Revenue (BIR), enabling companies to easily comply with Philippine tax reporting requirements.
Original PR description
Add a l10n_ph_reports module, adding a new composite report comprised of two sub-reports: Summary List of Sales and Summary List of Purchases. Also add an export for these reports following the format set by the BIR. Task id #3211351
This update allows businesses in Argentina's Free Trade Zones (Zona Franca) with special tax status to successfully generate export invoices through AFIP's system. Previously, these invoices would fail validation in production. The fix uses the correct AFIP export concept code to bypass unnecessary registry checks, enabling smooth invoice processing for this specific business scenario.
Original PR description
LATAM 1143 / ADHOC 36000 --- We want to invoice a "Zona Franca" partner (It has AFIP Responsibility IVA Liberado): in this case AFIP forces us to use an Exportation Invoice (Invoice E) on Exportation…
LATAM 1143 / ADHOC 36000 --- We want to invoice a "Zona Franca" partner (It has AFIP Responsibility IVA Liberado): in this case AFIP forces us to use an Exportation Invoice (Invoice E) on Exportation Webservice (WSFEX).  ### Before this change We are not able to generate the invoice. When we try to generate an expo invoice we get the next error from WS  In English, it means that the Issuer should be registered on Exportation Partners (a register of AFIP to identify the companies that made exportations to other countries). In this case, it is not needed to be registered because we are not making a real exportation outside the country. #### NOTE: This error only shows in a production environment, we do not receive errors when validating in the testing environment because there is not checking the Exportation Registry This is the info related to the error in the Webserive [specification](https://www.afip.gob.ar/fe/documentos/WSFEX-Manual-para-el-desarrollador.pdf)  ### After this change We can validate the invoice without error since we are informing Tipo_expo=4 option as mentioned in the WS specification that avoids AFIP checking if the issuer is or is not part of the Exportation Registry.   --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147643
This update adds comprehensive tax reporting capabilities for Philippine businesses, including new tax grids, tax categories, and support for generating official tax reports and SLS/P compliance documents. This enables Philippine users to properly calculate, track, and report their tax obligations within Odoo.
Original PR description
Adds the tax report, associated tax grids along with new taxes, required in order to generate a tax report as well as a SLS/P report Task id # 3211351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update improves how payment tokens are created for subscription renewals by including Monthly Recurring Revenue (MRR) information. This allows the system to automatically set appropriate spending limits on payment tokens based on each subscription's actual monthly value, reducing payment processing issues and improving security.
Original PR description
This commit add MRR in `_get_mandate_values` return dict to use it in at time of token creation to set max amount according to MRR of subscription. See also: - https://github.com/odoo/odoo/pull/150410
This update removes two outdated account codes (999001 and 999002) from the Bulgarian financial reports that were previously used to categorize extraordinary income and expenses. This ensures the profit and loss reports now accurately reflect the current chart of accounts structure used in Bulgaria.
Original PR description
999001 and 999002 are no longer used for extraordinary income/expenses. This commit removes them from the domains of the corresponding report. Task ID: 3672294 Forward-Port-Of: odoo/enterprise#55022 Forward-Port-Of: odoo/enterprise#54491
The payroll dashboard now loads warning messages faster by retrieving them in the background instead of making users wait. This improvement reduces load times and makes the payroll application more responsive for HR teams managing employee payments.
Original PR description
In this PR we improve the usability of a production payroll app where dashboard warnings might take a long time to load by loading them asynchronously using rpc calls. task-3597092
This fix eliminates redundant data evaluations when spreadsheets load multiple data sources simultaneously, dramatically improving performance. In real-world scenarios with many data sources, spreadsheet loading time is reduced from 33 seconds to 7 seconds. The trade-off is that cells will show "Loading..." until all data sources are ready, rather than updating incrementally.
Original PR description
In a spreadsheet with multiple data sources (2 pivots), each data source initially loads and triggers a new evaluation upon loading. This results in two evaluations, even if both data sources resolve…
In a spreadsheet with multiple data sources (2 pivots), each data source initially loads and triggers a new evaluation upon loading. This results in two evaluations, even if both data sources resolve in less than 10ms apart. In such cases, the first re-evaluation becomes redundant, as a new one is immediately triggered. The issue is worse when more than 6 RPCs are required, as most browsers limit network calls to 6 in parallel. Consequently, the 7th RPC will unnecessarily wait after the evaluation triggered by the first RPC to resolve. For spreadsheets with many many data sources, the accumulation of these pointless evaluations significantly impacts performance. In a real-life scenario with 18 data sources from our production database, the spreadsheet took approximately ~33s to fully load and become reactive. With this commit, the loading time is reduced to ~7s (only one evaluation instead of 18). Note that this testing was conducted locally, with minimal latency, and with a limited amount of data. One consequence of this commit is that cells won't load incrementally as each data source loads. Instead, all cells will display "Loading..." until all data sources are loaded. Given the substantial speed improvement, we consider this trade-off worthwhile. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149767
This improvement adds a validation check to determine if a point of sale order can be paid before actually processing the payment. This allows businesses to control when the Pay button is available (for example, disabling it on the Product Screen) without needing to execute the full payment function, providing better control over the checkout experience.
Original PR description
With this change, we can set other conditions easily. Also, it allows us to check if it can be payed without actually executing the pay function, because sometimes we don't want to change the screen but we want to check if the order can be processed for payment. For example, we could disable the Pay Button from the Product Screen --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update applies miscellaneous improvements to Bulgaria's localization module, including adjustments to the Chart of Accounts, tax configurations, and fiscal position settings. These changes ensure the accounting system accurately reflects current Bulgarian regulatory requirements and improves the overall accuracy of financial reporting for Bulgarian businesses.
Original PR description
This commit adds misc changes to CoA, Taxes and Fiscal Positions. Task ID: 3672294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150850 Forward-Port-Of: odoo/odoo#149696
This update significantly improves the speed of select menus when working with forms containing many options. Previously, the system was unnecessarily re-sorting menu options every time the page loaded, causing delays and potential browser crashes. Now sorting only happens when the menu opens, making selections and deletions up to 20 times faster in real-world scenarios.
Original PR description
## Description Having several select menu containing a lot of options on a page may lead to significant wait times and browser crashes when selecting or deleting a value. ## Analysis Sorting of the…
## Description Having several select menu containing a lot of options on a page may lead to significant wait times and browser crashes when selecting or deleting a value. ## Analysis Sorting of the options is being computed on each mounted select menu during the useEffect() hook since this commit: https://github.com/odoo/odoo/commit/8a4485748f49c5b8fdb780b0bcd2435eeadd63b. ### Before this commit All of the select menu are sorted when the user select a value in one of them. This is not necessary as the sorting is already handled in beforeOpen. ### After this commit Selecting or deleting a value from a select menu is significantly faster as the sorting is not being unnecessarily computed in useEffect() anymore. ## Benchmarks When importing an Excel file containing 70 columns as an invoice with subfields search enabled, selecting/deleting an option from a select menu: | | Before | After | |-------------|---------|--------| | Selecting | 31.2 s | 1.5 s | | Deleting | 35.9 s | 1.6 s | ## References opw-3616438 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146324
Resolved issues and error corrections
Fixed a bug in Kenya's payroll system where NHIF and NSSF reports would crash when accessed in January due to an invalid month value. The system now correctly defaults to December instead of causing an error, ensuring payroll reports work reliably throughout the year.
Original PR description
steps to reproduce: 1. Go to Payroll with Kenya localization 2. Click on Reports > NHIF Report or NSSF Report -> Odoo error because 0 is not a valid month Expected behavior: The wizards should not crash and the default month should be december fix: set the default month to december in january Behavior after fix: The wizards do not crash and the default month is december in january task-3668618
This fix resolves an issue where recurring subscription payments were incorrectly marked as failed even though the payment was successfully processed through Razorpay. The problem occurred due to database conflicts when multiple processes tried to update subscription records simultaneously. The fix improves how subscription status is updated during payment processing to prevent these conflicts and ensure accurate payment status reporting.
Original PR description
Steps: - Install subscription app and razorpay provider. - Configure and publish razorpay provider. - Create a subscription and pay via razorpay. - Now change system date to next recurring date.…
Steps: - Install subscription app and razorpay provider. - Configure and publish razorpay provider. - Create a subscription and pay via razorpay. - Now change system date to next recurring date. Issue: - Subscription is in `Payment Failure` state even though payment is successfully captured. Cause: - Because of concurrent update in database while creating transaction from token for recurring charges - When razorpay make tokenize request via `_send_payment_request` method then transaction process data via `_handle_notification_data` and from web-hook so it tries to write on transaction with same data multiple times and at same time subscription also tries to write so because of concurrent update it skips to write on subscription and subscription stays in `Payment Failure` state. Fix: - Handle writing on subscription in there state changing method instead of trying to write in between when transaction processing so it does not skip writing on subscription and properly set/remove subscription state. task-3652228
This fix resolves an issue where IoT Box settings would become inaccessible after reinstalling the Point of Sale Enterprise module. By adjusting the priority of the settings view, the IoT Box configuration details now remain visible and accessible even after module reinstallation, ensuring users can always manage their connected devices.
Original PR description
Setting higher priority on pos_enterprise setting view to ensure that reinstalling pos_enterprise won't make IoT Box Settings unaccessible. [Reproduce] - run odoo 16 - install pos_enterprise - Go to Settings/Point_of_Sale/Connected_Devices: - check "IoT Box" - No Bug: iot box details are visible - uninstall and install again pos_enterprise - Go to Settings/Point_of_Sale/Connected_Devices: - check "IoT Box" - Bug: iot box details are not visible opw-3606033 Forward-Port-Of: odoo/enterprise#54304
This update removes unnecessary validation checks in timesheet grid views and planning slot calculations that were causing performance issues. The changes streamline how the system retrieves timesheet data and computes planning information, reducing unnecessary processing and preventing access errors when certain records are unavailable.
Original PR description
# [FIX] timesheet_grid: avoid extra condition for group expand in grid view Before this commit, when the group expand is triggered in the grid view of timesheets to get the empty lines according to…
# [FIX] timesheet_grid: avoid extra condition for group expand in grid view
Before this commit, when the group expand is triggered in the grid view of timesheets to get the empty lines according to the timesheets recorded in the previous period, the domain to gather the additional lines will make sure the projects still have the timesheets feature enabled and the tasks are always actives.
This commit removes those extra conditions because we could assume in one week the project in which we previously record a timesheet, still has the timesheets feature enabled. Same idea for the tasks, we could also assume the tasks are still actives. For the reason about removing those extra conditions is because `('task_id.active', '=', True)` leaf will also trigger the `ir.rule` to make sure the user can read the fields in the task, idem for project with `('project_id.allow_timesheets', '=', True)` leaf.
# [FIX] palnning,project_forecast: only compute template_id when it is needed
Before this commit, when the `allocated_hours` is altered in a `planning.slot`,
it will trigger the compute of `template_id` in `planning_slot` to finally do
nothing since the `allocated_hours` is not used inside that compute.
The problem by letting that field in the dependencies is the `compute_role_id`
will be triggered because the template_id potentially changed thanks to its
compute method and so the compute method of `slot_properties` will be triggered
and could raise an access error in the case the `planning.slot` cannot be read.
This commit removes `allocated_hours` field in the dependencies of
`compute_template_id` since it does not seem to have any reason to trigger
that compute when the allocated_hours is changed on a `planning.slot`.This fix resolves an issue where forwarding messages through WhatsApp would fail with an error and prevent the message from being sent. The problem occurred because the system was incorrectly processing multiple messages at once instead of handling them individually. Users can now successfully forward messages through WhatsApp without encountering errors.
Original PR description
When the user sends forwarded message to the WhatsApp business account a log error occurs and the forwarded message will not be sent to WhatsApp business account Error:- ``` ValueError: Expected…
When the user sends forwarded message to the WhatsApp business account a log error occurs and the forwarded message will not be sent to WhatsApp business account
Error:-
```
ValueError: Expected singleton: mail.message(195, 193, 192)
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "home/odoo/src/enterprise/17.0/whatsapp/controller/main.py", line 42, in webhookpost
wa_account_id._process_messages(value)
File "home/odoo/src/enterprise/17.0/whatsapp/models/whatsapp_account.py", line 190, in _process_messages
channel = self.env['discuss.channel'].sudo().search([('message_ids', 'in', parent_id.id)], limit=1)
File "odoo/fields.py", line 5118, in __get__
raise ValueError("Expected singleton: %s" % record)
```
This is because at line [1], we receive multiple parent ids in WhatsApp messages because the value of `context.get()` is none, so at line [1] searches for the message whose msg_uid is not set (messages either in queue or failed).
This commit fixes the above issue by adding the condition that checks the ID is present in the context of the message.
https://github.com/odoo/enterprise/blob/272856993b21d9e7edfb573e33a368f80ba0c9c8/whatsapp/models/whatsapp_account.py#L185
sentry-4745952077
Forward-Port-Of: odoo/enterprise#53500Credit notes in the AvaTax integration were incorrectly calculating negative total amounts, which prevented them from being posted. This fix corrects how AvaTax return values are processed so credit notes now calculate with the proper positive amounts. This ensures credit notes can be successfully recorded in the system.
Original PR description
Before this commit, credit notes would be calculated to have a negative total amount which is incorrect and prevents posting. New in Odoo 17 is that account_external_tax sets line.price_subtotal on invoices. This was necessary to correctly support price-included taxes for Brazil. A side-effect is that it uncovers an inconsistency in the US integration [1]. Avatax returns negative amounts (both lineAmount and tax) when the record is a ReturnInvoice. In Odoo we don't invert the price_* fields on account.move.line for credit notes so this commit inverts the sign coming from Avatax in these cases. [1] PS. in https://github.com/odoo/enterprise/pull/45095#issuecomment-1696102292 opw-3699206
This fix prevents the system from making unnecessary requests to external tax services when vendor bills are reset or unlinked. Previously, these operations would trigger external tax calculations even though they shouldn't apply to vendor bills, which could cause delays and unnecessary service calls. This change improves system performance and reduces external service usage.
Original PR description
Before this, resetting or unlinking a vendor bill would try to launch requests to external tax services. opw-3702163
This fix resolves a problem where website visitors (public users) couldn't add products to their cart when the system was configured to automatically detect their location and apply taxes using AvaTax. The issue occurred because the system tried to validate the visitor's address before they had entered one. The fix skips this validation for public users, allowing them to proceed with adding items to their cart normally.
Original PR description
Currently, a public user can't add any product to the cart when using GeoIP and Avatax. ### Steps to reproduce * setup GeoIP[^1] * setup Avatax credentials * enable "Detect Automatically" on the…
Currently, a public user can't add any product to the cart when using GeoIP and Avatax.
### Steps to reproduce
* setup GeoIP[^1]
* setup Avatax credentials
* enable "Detect Automatically" on the "Automatic Tax Mapping (AvaTax)" fiscal position
* access to the website as a public user with an IP address from the US[^1]
* try adding a product to the cart.
You should be met with a validation pop.
[^1]:
This is quite annoying to reproduce on a local database. In cases like these, I find it much easier to directly modify the code in order to emulate the behavior we want. Here, you can simply replace the entire content of `odoo/addons/http_routing/geoipresolver.py` with the following:
```py
class GeoIPResolver(object):
@classmethod
def open(cls, fname):
return GeoIPResolver()
def resolve(self, ip):
return {
'city': 'New York',
'country_code': 'US',
'country_name': 'United States',
'latitude': 40.7263,
'longitude': -73.9818,
'region': 'NY',
'time_zone': 'America/New_York'
}
```
### Cause
For the Avatax fiscal position to work, we need the partner's country, state and zip code. Usually, this isn't a problem because the fiscal position is set after the Public User enters their address. But, when using GeoIp, the fiscal position is set right when the user lands on the page, based on their location data. This triggers a check for the address, but the Public User hasn't entered one yet, which causes a validation error.
opw-3625410
Forward-Port-Of: odoo/enterprise#53547This fix resolves an issue in the bank reconciliation feature where analytic distribution settings were incorrectly persisting when switching between different transaction lines. The component now properly refreshes when users switch between regular and exchange difference lines, ensuring accurate financial tracking and reporting.
Original PR description
When setting an analytic distribution on an aml line in bank reco widget and switching to exchange diff line (and vice versa), the component is not rerendered, therefore analytic distribution is also set on analytic distribution component. opw-3686867 Forward-Port-Of: odoo/enterprise#55140
Fixed an issue where timesheet entries were being rounded up instead of preserving the exact duration values entered by users. When stopping a timer and manually adjusting the duration in Field Service tasks, the system now saves the precise value you enter rather than automatically rounding it up. This ensures accurate time tracking and billing.
Original PR description
**Steps:** - Open Field Service > Tasks - Select any task and start timer - Now stop the timer and change the duration from the wizard - On saving, observe the value of timesheet entered in the Timesheet tab **Issue:** - the timesheet entry shows the round up value instead of edited value. **Cause:** - Due to the round up function used, the time duration entered will always be rounded up **Fix:** - Discarding the use of the function in order to get the edited unit amount. **Task**-3631383 Forward-Port-Of: odoo/enterprise#54948 Forward-Port-Of: odoo/enterprise#52755
This update fixes a bug in the subscription order note search feature. The system was incorrectly processing search results that returned both ID and display name information, when only the ID was needed. This fix ensures the search function works correctly when looking up order notes.
The "Add Document" button in the document upload dialog has been renamed to "Add URL" to better clarify its purpose. This change reduces confusion for users who see both an "Upload Document" button and the URL button side-by-side, making it immediately clear that the button is for adding documents via URL rather than uploading files.
Original PR description
Before this commit the button to add documents from an URL is labeled "Add Document" which is confusing given it is displayed besides an "Upload Document" button. This commit renames the "Add Document" button into "Add URL" to make its purpose more obvious. task-3493618 Forward-Port-Of: odoo/odoo#149120 Forward-Port-Of: odoo/odoo#136512
This fix resolves an access rights error that occurred when standard users (like the demo user) tried to use the "Update Only" filter in the audit trail report. The filter is now hidden for users who don't have the necessary permissions, preventing the error and improving the user experience.
Original PR description
To reproduce: - Go in admin user - activate Audit Trail in the settings - Log out - Connect as demo - Go to the audit trail report - Activate the filter Update Only => Access right error The demo user doesn't have the right access for the domain of the filter. We should hide this filter for these users (Causes an issue in the click_all test) 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
This fix removes the confusing arrow indicator that was appearing in date range fields when they were both empty and set to read-only mode. Users couldn't interact with these fields anyway, so showing the arrow was misleading. The change improves the user experience by only displaying the arrow when users can actually edit the field.
Original PR description
Recently, a new option 'always_range' has been added to the datetime field (task 3628069, commit bc98aad). This option forces the display of the arrow between the two dates from the start. Before that, you would add a first date, click a button to add a second date and then only would the arrow appear. The oversight here is when the field is empty AND readonly. In that case, you have an visible arrow next to the label but you can't do anything with the field anyway. So better not to show it. This commit makes sure to not display the arrow in this case. task 3690523
This fix resolves an issue where Razorpay subscription payments between 100,000 and 500,000 were incorrectly being rejected with a limit exceeded error. The system now properly calculates the maximum allowed payment amount for tokenized transactions, allowing subscriptions in this range to process successfully without errors.
Original PR description
Steps: - Install subscription and razorpay app. - Configure razorpay provider with tokenizable razorpay account. - Enable allow tokenize field. - create subscription with more then 100k and less then 500k amount. - Try to pay that subscription with razorpay. Issue: - Throwing limit exceed warning even though amount is less then 500k which can create token and paid normally. Cause: - We forgot to check minimum of method max amount and amount * 5 to send proper mandate max amount while creating token and because of that paying more then 100k via subscription raise error even to it should processed normally. Fix: - Check minimum of `method max amount` and `amount * 5` to send proper mandate max amount so it'll not raise error while paying amount in between 100k to 500k. See also: - https://github.com/odoo/enterprise/pull/55009
This update fixes a bug where the same task ID could appear multiple times in search results for time-off tasks, and improves the performance of timesheet grid display. The changes reduce unnecessary database calls and speed up the monthly timesheet view from 9 seconds to approximately 4.5 seconds.
Original PR description
Before this commit, the `_search_is_timeoff_task` search method for the `is_timeoff_task` field could return the same task id many times in the right part of the leaf inside the domain returned by the method. This commit makes sure the list of ids in the right part of the leaf in the domain returned by the search method will be each time different task ids.
This update fixes a bug where email addresses were appearing twice in the project sharing interface when inviting people on mobile devices. The issue was caused by an unnecessary email display setting in the system configuration. Removing this setting resolves the duplicate display and improves the user experience when sharing projects on mobile.
Original PR description
Steps: - In mobile open project - Project.project form view - Share project - Invite people, the 'email' is displayed twice in the kanban view Issue: - In mobile when project share invite people, the 'email' is displayed twice in the kanban view Cause: - This will be coming because of the context for show_email Fix: - By removing of context show_email it will be working fine. task-3550702 Forward-Port-Of: odoo/odoo#140920
Fixed a bug in the Point of Sale payment screen where deleting a tip by pressing backspace multiple times would cause the system to crash. The issue occurred because the system was receiving a null value instead of an empty string when no tip was present. This fix ensures the system properly handles empty tip values, preventing the crash and improving the user experience during payment processing.
Original PR description
**Before this commit:** When a user adds a tip and removes it by hitting multiple backspaces, a traceback occurs. The value passed as the tip was supposed to be an empty string if no tip is applied, but it received a null value, causing a traceback. **After this commit:** The tip value is checked to be a truthy value. If it is not a truthy value, then an empty string is passed, resolving the traceback. task-3692849
This update fixes three bugs in the product configurator that were causing errors when saving and reopening sales orders with customizable products. The fixes allow empty custom values to be handled properly, ensure attribute values are correctly set for no-variant attributes, and enable archived product combinations to be displayed when needed. These changes improve the reliability of the product configuration process for users creating and editing orders with custom products.
Original PR description
**[FIX] sale_product_configurator: allow type False for customValue** Steps to reproduce(locally): 1) Create SO with the product that has a custom value attribute 2) Leave the custom field empty 3)…
**[FIX] sale_product_configurator: allow type False for customValue** Steps to reproduce(locally): 1) Create SO with the product that has a custom value attribute 2) Leave the custom field empty 3) Save SO and open product configurator again 4) Observe TypeError traceback Reason: customValue is supposed to be string but if value is not set, it remains False which cause a type error. After this commit: allow customValue be false **[FIX] sale_product_configurator: set value for no_variant attribute** Steps to reproduce: 1) Create product with an attribute that has several values and with an attribute with 'create_mode = 'no_variant' and one value. 2) Create SO with this product, save 3) Open product configurator again and see the traceback Reason: selected_attribute_value_id is not set. After this commit: the attribure value is defined in get_values of product configurator. opw-3513685 **[FIX] sale_product_configurator,product: show archived combination** Steps to reproduce: 1) Create SO with customizable product (example “Customizable Desk”) 2) Let default values in product configurator 3) Save SO 4) Go to product template, and in the Attribute remove all value options, only leaving the custom value 5) Try to open the product in configurator in the saved SO Reason: archived combination is not loaded After this commit: When requested combination is archived, load it opw-3513685 Forward-Port-Of: odoo/odoo#146454
This fix enables the accounting system to properly recognize and import matching numbers from CSV files during data imports. Previously, matching numbers were manually imported in specific import scenarios but were missing from the generic import process, causing the system to fail to understand imported matching numbers. This update ensures consistent handling of matching numbers across all import methods.
Original PR description
The import feature of matching numbers was done manually in all imports, but the generic import was missing. For instance, with this file: ```csv name,line_ids/account_id,line_ids/debit,line_ids/credit,line_ids/matching_number test 2,400000,,121,1 ,500000,121 test 1,400000,121,,1 ,451000,,21 ,700000,,100 ``` The system wouldn't understand that this is an imported number.
This fix corrects a display issue in the Bill of Materials (BOM) overview where components with zero quantity were incorrectly showing the default BOM quantity instead. Now when a subproduct quantity is explicitly set to zero, it will correctly display as zero in the overview report.
Original PR description
Steps to reproduce: - open bom - open product `Table` - set the quantity of all subproduct to `0` - Open overview Issue: the table top has 1 in qty Cause: For a bom subproduct, if there is no qty set (0/False), we automatically set the qty defined on the bom opw-3677052 Forward-Port-Of: odoo/odoo#149392
This fix resolves a crash that occurred when creating invoices from sales orders in Italian companies after installing the stock delivery tracking module. The issue happened because the system tried to process an empty delivery number field as if it contained text, causing the invoice confirmation to fail. The fix ensures the system properly handles cases where the delivery number field is empty.
Original PR description
Steps to reproduce: - Install Accounting, Inventory, Sales and l10n_it_edi - Switch to an Italian company (e.g. IT company) - Create a storable product (e.g. Product X) - Update its available quantity to more than 0 - Create a SO with Product X and confirm it - Deliver the products - Install l10n_it_stock_ddt - From SO, create an invoice and confirm it Issue: When confirming the invoice, a traceback is raised: "TypeError: 'bool' object is not subscriptable" Cause: When installing "l10n_it_stock_ddt", a new char field "l10n_it_ddt_number" is added to "stock.picking" model, but its value is False for existing pickings. When generating the electronic invoice, "format_alphanumeric" is performed on the field, assuming it has a string value. opw-3661824 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151166 Forward-Port-Of: odoo/odoo#149803
This fix resolves an error that occurred when closing a production order that uses expired product lots. The issue was that a required technical field was missing from the action definition, preventing the wizard dialog from displaying properly. The fix adds this field so users can successfully complete the production close process.
Original PR description
Steps to reproduce: - Create a product and set it tracked by lot and expirable - Create a lot for this product that is already expired - Create a MO using this product as component and confirm it - Go the Shop floor and force the use of the expired lot for this component - Click on 'Close Production', a traceback will appear Issue: Since the action is defined directly in the python code, we don't have some extra fields that are usually computed on a `ir.actions.act_window` record, such as the `views` field. Yet, on the js side, the action service requires that field to properly work [1], so we add it in the action definition. [1] https://github.com/odoo/odoo/blob/294a37b0a31ec88165da596c3f3e2dd6f6cb735d/addons/web/static/src/webclient/actions/action_service.js#L261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that data modules (like industry packages) properly track their dependencies, so that when a required module is uninstalled, the dependent data module is also uninstalled automatically. Previously, data modules were not handling dependencies correctly, which could leave orphaned modules in the system.
Original PR description
Dependencies and other manifest attributes are not set for data modules. Note: it's easier to reproduce issue in 17 since we have data module available on runbot. **steps to reproduce (in 17.0):** - install an industry (ex: bar_and_lounge) - uninstall a dependency of that module (ex: mrp) **before this commit:** - bar_and_lounge is not uninstalled if you uninstall mrp **after this commit:** - data model dependencies are handled the same way as 'regular' modules opw-3660052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150926 Forward-Port-Of: odoo/odoo#149574
This update corrects the names of VAT accounts in the Slovak localization package. Previously, the system used identical names for both sales and purchase VAT accounts, which could cause confusion and errors in financial reporting. The fix ensures each account type has a distinct, appropriate name for proper accounting practices.
Original PR description
This fixes names of VAT accounts in Slovak localization package as it uses the same names for sale and purchase accounts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151107
This fix prevents the web interface from crashing when a popover (a small popup window) references an element that has been removed from an embedded webpage (iframe). The issue occurred because the system couldn't properly access the document properties after the element was deleted. This improves the stability and reliability of the user interface.
Original PR description
This commit solves a crash which can happen when a popover points to an element inside an iframe that has been removed from the DOM. In those cases, the element's ownerDocument does not have a defaultView. Forward-Port-Of: odoo/odoo#151134 Forward-Port-Of: odoo/odoo#149174
This fix resolves an issue where repair orders for serial-tracked products stored in packages would incorrectly fail validation with an "insufficient quantity" error. The system now properly recognizes packaged inventory when validating repairs, allowing users to successfully confirm repair orders for these products without encountering false inventory warnings.
Original PR description
Steps to reproduce the bug:
- Create a product “P1” tracked by SN
- Update the quantity with “SN1” and a package “Pack 1”
- Create a repair order to repair the product P1:
- Select the “SN1”
- Try to confirm the repair
Problem:
A wizard with the following message is triggered:
Insufficient Quantity to repair “The product is not available in sufficient quantity in WH/Stock
Because when the function “action_validate” is called, we check if there is quant with the same SN but with strict=True so, the package should be false to find the quant:
https://github.com/odoo/odoo/blob/61c9921596662a2cbc15a154a91dd2f52c9854fd/addons/mrp_repair/models/mrp_repair.py#L210-L211
https://github.com/odoo/odoo/blob/b3180c841101510081ee8ef9c52d205497efdd4f/addons/stock/models/stock_quant.py#L102
Opw-3648874
Forward-Port-Of: odoo/odoo#150719
Forward-Port-Of: odoo/odoo#149740This fix resolves an issue where vendor pricelist prices were not being applied correctly when only a product variant was specified without a parent product. The system now ensures that product variant and template information stay consistent, allowing vendor pricelists to work properly in purchase orders.
Original PR description
Versions -------- 15.0+ Steps ----- 1. Go to Purchase; 2. create a Vendor Pricelist; 3. select a Product, a Product Variant & a Unit Price; 4. empty the Product field & save; 5. create a RFQ; 6. add…
Versions -------- 15.0+ Steps ----- 1. Go to Purchase; 2. create a Vendor Pricelist; 3. select a Product, a Product Variant & a Unit Price; 4. empty the Product field & save; 5. create a RFQ; 6. add the Product Variant from the Vendor Pricelist. Issue ----- The product's price remains 0. Cause ----- The `seller_ids` field in `product.template` creates one-to-many relation with `product.supplierinfo`'s `product_tmpl_id` field. While it is possible to select a specific product variant and have the product field empty, this renders the Vendor Pricelist unavailable for Purchase Orders. Solution -------- Add a `_sanitize_vals` method to `product.supplierinfo` to be used on create/write, which ensures that if there's a `product_id`, the record's `product_tmpl_id` is consistent with it. This allows for record imports to be usable & consistent when only a variant is specified. Also backport a modified `onchange` method added in 5537090f1c688f0e1f9de366f83387277d60612a. Originally it only reset `product_id` if `product_tmpl_id` was changed to a different non-falsy value. Modified, it also resets `product_id` if `product_tmpl_id` is changed to a falsy value, as it would otherwise just re-add the removed value on create/write after this commit. opw-3664524 Forward-Port-Of: odoo/odoo#151045 Forward-Port-Of: odoo/odoo#149618
This fix prevents incorrect partner selection when importing invoices from XML files that contain incomplete VAT numbers. Previously, incomplete VAT codes like "BE" (without numbers) would cause the system to randomly select any partner from that country. Now the system requires VAT numbers to be at least 6 characters long before using them to match partners, ensuring accurate invoice routing.
Original PR description
When importing an xml, impose a minimum length on the VAT to consider the value. Some xml contains VAT = "BE" (without numbers...). In this case, we search on the partners with matching VAT, and end up selecting a random belgium partner. Now, we only search the VAT if len(VAT) > 5. In addition, in a UBL xml where multiple tags can contain a VAT (PartyTaxScheme/CompanyID and PartyLegalEntity/CompanyID), we retain the first value which have the minimum length. opw-3675350 Forward-Port-Of: odoo/odoo#150959 Forward-Port-Of: odoo/odoo#150695
This fix corrects an issue where product prices displayed on eShop listing pages for branch websites were not including taxes from parent companies. Products now correctly show tax-inclusive prices on eShop pages, matching the prices shown on individual product detail pages. This ensures consistent and accurate pricing information for customers shopping on branch websites.
Original PR description
Steps to reproduce: - Create a branch for a company (e.g. Branch X) - Go to "Website / Configuration / Websites" - Create or configure a website on Branch X (e.g. Website X) - Go to "Website / Configuration / Settings" - Select Website X - Set "Display Product Prices" to "Tax Included" - Create a product for a price of $100 and a tax from parent company (e.g. 15%) - Go to eShop page of Website X Issue: On the eShop products list page, the price of the product should be "Tax Included" ($115), but it is not. The displayed price is $100. When accessing the product page, the price is correctly displayed with the tax ($115). Cause: When computing the prices, taxes from parent companies are not taken into account. opw-3660156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151223
This fix corrects how discounts are displayed on the shopping cart page. Previously, a performance optimization removed certain calculations, which caused discounts to be calculated differently than intended. The fix ensures that discounts are now properly calculated and displayed consistently, showing the correct crossed-out original price on the cart.
Original PR description
Since 17.0 , calls to _get_combination_info on the /shop/cart page were removed to avoid recomputing values already stored on the cart, speeding up the page loading. See 824fc94bbcc6ea63b5416a2be59b860ef65714eb Nevertheless, this highlighted the difference in pricelist discount computation between sale and website_sale. In sale, the discount is computed while considering the base price of the pricelist, whereas for `website_sale`, the base price was always the sales price. To make sure the crossed price displayed is the sales price as before on /shop/cart, we override the default sale behavior to force the sales price to be considered as price before the pricelist discount. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where custom models created in Odoo Studio that combine manually-created fields with inherited base fields could not be deleted. Previously, the system would raise an error when attempting to delete such models even when they contained no data. Now, these models can be successfully deleted after removing all associated views and objects.
Original PR description
Create an ir.model custom (state = "manual" -- for example via studio) that has a mix of manual fields (named x_...) and of base fields (originating from some mixin). Unlink all linked views or object, and try to unlink that model eventually. Before this commit, an error was raised because base fields couldn't be deleted, even though the table was empty. After this commit, the deletion works. Note that this commit is a fix of https://github.com/odoo/odoo/pull/130420/ , which added partial support for this and a backport of 7550bcd61e52bc9c3de007d06cf95c91eaec893a which fixed the former PR in 17.0 opw-3558590 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#151238 Forward-Port-Of: odoo/odoo#151020
This update fixes two issues with the SelectMenu component: it now properly displays selected values when they are empty strings or null (previously the selection would appear empty), and it improves the visual styling to match Odoo's current design standards. These fixes ensure the dropdown menu looks correct and functions as expected when users select options with empty values.
Original PR description
The first commit fixes the behavior of the SelectMenu component when an option
is being used with an empty string or a null value.
Let's suppose we have the following choices:
{ label: 'Empty', value: '' },
{ label: 'Full', value: 'full' }
Before this fix, when selecting 'Empty', the value would be selected in the
menu, but the toggler would still be empty, as if no value was selected.
Now, any value corresponding to a choice value can be selected.
A test has been added for each value supported (null and empty strings).
The second commit fixes the style of the SelectMenu since the Milk redesign
Forward-Port-Of: odoo/odoo#151219
Forward-Port-Of: odoo/odoo#150627This fix resolves an issue where bulk-scheduling multiple work orders would fail to appear in the Planning calendar. The problem occurred when setting start dates for multiple work orders simultaneously because the system was checking for both start and finish dates before the finish date was calculated. The fix now properly validates only the start date when it's first set, ensuring work orders are correctly scheduled and visible in the Planning by Workcenter view.
Original PR description
[FIX] mrp: Fail to set workorder on calendar 'Planning by Workcenter' **Steps to reproduce:** 1- Install Manufacturing module 2- Create 2 or more new WOs and make sure that their corresponding MOs is…
[FIX] mrp: Fail to set workorder on calendar 'Planning by Workcenter' **Steps to reproduce:** 1- Install Manufacturing module 2- Create 2 or more new WOs and make sure that their corresponding MOs is not planned 3- Go to Operations > Work orders 4- Mark all of those WOs and write a start date to apply on all of them 5- Check Planning > Planning by Workcenter 'you will not find the scheduled WOs' **Current behavior before PR:** When you try to mark more than one record in Work orders and set start date for all of them at the same time it will not be set therefore it will not be visible in Planning calendar. This is happening because if you are setting the start date for the first time it will call the function that sets the start date first before calculating the finish date so it will not pass the condition where it checks if both dates have values. **Desired behavior after PR is merged:** Now we are checking just the start date if it has value or not and to raise the same user error if the customer tries to delete the finish date we are checking this on change of the finish date from a value to null. opw-3596100 Forward-Port-Of: odoo/odoo#151154 Forward-Port-Of: odoo/odoo#147861
This update fixes an issue where the transaction code field was required but customers couldn't set it during registration, causing problems with automatic invoicing systems. The system now automatically assigns a default transaction code (01) when customers don't provide one, ensuring invoices can be generated smoothly without manual intervention.
Original PR description
Kode transaksi is a required field on account moves. This field is either set on the move itself, or is taken from the partner. It NEEDS to be set when invoicing, but customers cannot provide this values by themselves when registering for example. This would cause issues with automatic subscriptions amongst other systems. In order to fix this issue, we will define the code 01 as default value. Note: there is no task linked to this small change --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151078