Wednesday, March 26, 2025
17 changes · 17.0
Enhancements to existing features
### Before Codabox used to require a fiduciary VAT and the VAT of a company (managed by the fiduciary) in order to connect to their services. - Access to Codabox was limited to companies with an accounting firm with a VAT number assigned ### Now Codabox gives the opportunity for companies to directly connect (without being a fiduciary/ being managed by one). This is through the same port as before, just receiving two identical VAT numbers. - Module summary, descriptions and ot
Original PR description
### Before Codabox used to require a fiduciary VAT and the VAT of a company (managed by the fiduciary) in order to connect to their services. - Access to Codabox was limited to companies with an accounting firm with a VAT number assigned ### Now Codabox gives the opportunity for companies to directly connect (without being a fiduciary/ being managed by one). This is through the same port as before, just receiving two identical VAT numbers. - Module summary, descriptions and other texts are updated to generalize - Companies without an accounting firm can access the Codabox configuration settings odoo/enterprise/pull/81655 odoo/documentation/pull/12540 task - 4460499
Resolved issues and error corrections
Indian localization now recalculates the fiscal position when GST treatment changes. This helps ensure invoices use the correct tax setup and reduces the risk of incorrect fiscal position selection.
Original PR description
**Before this commit:** The fiscal position computation method did not depend on `gst_treatment`, causing issues where changes to `gst_treatment` were not detected. As a result, the computation did not trigger as expected, leading to incorrect fiscal position determination. **After this commit:** The computation method now depends on `gst_treatment`, ensuring that any changes to it trigger a recalculation. This guarantees accurate fiscal position computation as required. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
- Ensured that when a group of taxes is selected, the designated label is displayed on the invoice instead of the tax names. Task-4637341 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#201308
Original PR description
- Ensured that when a group of taxes is selected, the designated label is displayed on the invoice instead of the tax names. Task-4637341 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#201308
Creating resource time off records now works even if the default Sick Time Off type has been deleted. This prevents an error that could block HR administrators from saving resource time off entries in certain configurations.
Original PR description
Currently, An error occurs when creating a resource time off. Step to produce: - Install the `hr_holidays` module. - Enable debug mode. - Go to Time Off / Configuration / Time Off Types, And delete…
Currently, An error occurs when creating a resource time off. Step to produce: - Install the `hr_holidays` module. - Enable debug mode. - Go to Time Off / Configuration / Time Off Types, And delete `Sick Time Off`. - Go to Settings / Technical / Resource / Resource Time Off, and create a new record. - Add a Time Off Request with the following conditions: The start date is before today's date, end date is after today's date, And state is set to Draft. - Try to save a Resource Time Off record. `ValueError: External ID not found in the system: hr_holidays.holiday_status_sl` An error occurs when the system tries to retrieve an external ID of the 'Sick Time Off' at [1], but it is not available. Link [1]: https://github.com/odoo/odoo/blob/1303193386665d120ccb5d0045ee984337af0826/addons/hr_holidays/models/resource.py#L67 To handle this issue, add 'raise_if_not_found=False' in ref() argument if the external ID of the 'Sick Time Off' is not available. Sentry-6320807644 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers who reach checkout with a promotion that expires during payment now receive clearer guidance. The message explains that refreshing the page can resolve the issue, reducing confusion and support needs.
Original PR description
Commit 2afc30a introduced reward validation before payment, due to this if promotion expired during payment step during checkout, error informing that promotion was expired was thrown, but user was not able to do anything about. Info about refreshing page has been added. opw-4573640 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
The wishlist page now uses a shorter Add to Cart button so it does not get cut off on small screens, especially in translated stores or with wider currency symbols. This improves the mobile shopping experience for customers using languages like French and currencies such as CHF.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Open website in French; 2. select a pricelist using CHF as currency; 3. add a product to the wishlist; 4. open wishlist in mobile view. Issue ----- With the increased amount of space the currency symbol needs, along with the translation of "Add", the view gets truncated. Cause ----- View was probably designed with only English & USD in mind. Solution -------- Same approach as commit ba2a0d7e33e8 took for the product configurator: - In full view, display `<fa-shopping-cart> Add` - On mobile, display `<fa-shopping-cart>` opw-4624112
The accounting dashboard now calculates amounts to check using the same currency logic as other payment totals. This prevents misleading company-currency values from appearing when a journal uses a different currency, improving accuracy for finance teams.
Original PR description
Steps to reproduce: ------------------ - Create a new journal - Change the currency for another one than the company one - To check amount is in the company currency Issue: ----- The calculation of the amount to check differed from the logic of the other amounts. The to check amount was calculated based on the amount_total_signed which is by default in the company currency. Fix: --- Created a new dict that follows the logic of the right calculated amount (to pay, late, ...). Now the to_check_vals is a dict of the same kind as others. This allows to use the function _count_results_and_sum_amounts. Since there are no to_check_vals for each journal, used a get with a False default return. opw-4349684 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Peppol participant status update now only checks Peppol registrations, avoiding accidental use of other EDI connections. This prevents scheduled updates from failing when both Peppol and Italian EDI are configured.
Original PR description
Ensures only Peppol-type proxies are retrieved for updating participant status. Steps to reproduce: - Install Peppol and IT EDI - Register Peppol and IT EDI users - Go to Scheduled Actions and run “PEPPOL: update participant status” - Error: “Error while updating Peppol participant status: The URL requested returned an error. The URL it tried to contact was False/api/peppol/1/participant_status” opw-4624633
A manufacturing test was updated so it can access product attribute information that is normally hidden on product forms. This prevents an automated test failure and helps keep manufacturing-related product workflows stable.
Original PR description
Test introduced in 6a4c02e6 fails because the `attribute_line_ids` field is not visible by default in product forms. Fixes [runbot error 161456](https://runbot.odoo.com/odoo/runbot.build.error/161456)
Unnamed delivery or invoice addresses now use the partner’s preferred language when their displayed name is created. This keeps address names correctly localized for non-English partners while preserving the ability to sort partner lists by name.
Original PR description
There are two competing issues and their solutions when using the list view for `res.partner`. ### Issue - If a Delivery/Invoice Address partner is created, but isn't named, we instead concatenate…
There are two competing issues and their solutions when using the list view for `res.partner`. ### Issue - If a Delivery/Invoice Address partner is created, but isn't named, we instead concatenate the parent's name with the `type_description` title. However, this value is stored in `complete_name` in English and isn't translated. To remedy this, `display_name` was used to translate on the fly depending on the user's language, showing the proper translation when viewing the `display_name`. Previous Fix: #147650 - `display_name` is computed and not stored, which prevents us from alphabetically sorting the list by the name column. While the records are ordered by `complete_name ASC`, this still prevents DESC ordering when using the view. To rememdy this, `display_name` was replaced by `complete_name` in the list view. Previous Fix: #186031 Unfortunately, this leaves us back where we started, where these types of partners always have their names in English. We can either sort or show the translation, but not both. ### Solution The issue is really only noticeable when 1) the Delivery/Invoice/etc partners aren't given a name and 2) the user is using a non-English language. Instead of translating the `type_description` every time, we can use the partner's `lang` to compute the `complete_name` from the start. This will always display the `Delivery Address` portion in that language, no matter what language the user has set. opw-4595049
This fix prevents errors when a business connects an existing WhatsApp account before installing a related WhatsApp bridge module. Odoo now avoids reusing a default template name if that name already exists, making setup smoother and reducing installation failures.
Original PR description
It is possible for a user to sync an existing whatsapp account and only after install some whatsapp bridge module. In that case the user will get an error as the template is created on the existing account with an existing name. We now prevent using the default value if a template with the same name already exists on it. task-4369979
This fix prevents the bank reconciliation widget from showing an error when imported bank transaction details contain hidden control characters such as line breaks or tabs. It helps users continue reconciling existing bank statement data without manual cleanup.
Original PR description
In the bank reconciliation widget, when the transaction_details of bank statement lines get formatted by calling json.loads(), an error will show if some strings contain control characters (`\n`, `\t`, `\r`, `\0`). Adding the parameter `strict=False` to the call to json.loads would allow such characters to be kept by the formatting. In the view, they will not be used (any of those 4 chars will simply be considered a whitespace). One could add `style="white-space: pre-line"` as an attribute to the span tag of those element, but this is not necessary. This PR simply aims to patch the already existing data in databases. opw-4480250
The online bank synchronization process now turns off its background fetching job when no accounts are actively fetching transactions. It will turn back on automatically when a customer manually starts a fetch, reducing unnecessary background activity without changing the user workflow.
Original PR description
Following this commit[[1]], we're still improving the activate / deactivate flow for the asynchronous fetch cron. Now, the (by default) twice a day cron which fetches transactions automatically will deactivate the asynchronous cron if no account online account is in the fetching process. This cron is directly re-activate by the existing behavior when a customer does a manual fetch on the dashboard. no task id [1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a
Description of the issue/feature this PR addresses: A bug occurred when the system attempted to automatically add a rounding line to an invoice in a multi-company environment. The company-dependent field was being updated without properly considering the invoice’s company context. Current behavior before PR: An error was raised when trying to create the rounding line because the system looked up the accounts for Company 1 instead of the invoice’s assigned company. Desired behavior after
Original PR description
Description of the issue/feature this PR addresses: A bug occurred when the system attempted to automatically add a rounding line to an invoice in a multi-company environment. The company-dependent field was being updated without properly considering the invoice’s company context. Current behavior before PR: An error was raised when trying to create the rounding line because the system looked up the accounts for Company 1 instead of the invoice’s assigned company. Desired behavior after PR is merged: No error was raised --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196479
For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the `export_data` public method on the models. However: - The domain is only available in the controller. `export_data` does not receive the domain in its params. Putting the logger in `export_data` would therefore lead to the inability to log the domain. Or we would need to do one logger in the con
Original PR description
For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the…
For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the `export_data` public method on the models. However: - The domain is only available in the controller. `export_data` does not receive the domain in its params. Putting the logger in `export_data` would therefore lead to the inability to log the domain. Or we would need to do one logger in the controller just for the domain, and a second logger in `export_data`. - During an export using a group by (and without import compatibility) `export_data` is called recursively, in `insert_leaf`. Hence, if the logger would be put in `export_data`, there would be one log per group, therefore bloating the logs. Hence, for stable versions, the decision taken is to put the log in the controller rather than in a lower level method. It's better than nothing. A rework of the API of `export_data` is planned in master to solve the above concerns. Forward-Port-Of: odoo/odoo#202568
Certain reports were incorrectly referring to DIAN, even though the Industry and Commerce Tax (ICA) is administered at the district level. According to Colombian regulations (e.g., Decree 807 of 1993, Agreement 65 of 2002 for Bogotá), the collection and administration of ICA falls under the local Secretariat of Finance, not DIAN. This commit adds logic so that if the report is for ICA, it shows the correct reference to the Secretariat of Finance; otherwise, it preserves the reference to DIAN.
Original PR description
Certain reports were incorrectly referring to DIAN, even though the Industry and Commerce Tax (ICA) is administered at the district level. According to Colombian regulations (e.g., Decree 807 of 1993, Agreement 65 of 2002 for Bogotá), the collection and administration of ICA falls under the local Secretariat of Finance, not DIAN. This commit adds logic so that if the report is for ICA, it shows the correct reference to the Secretariat of Finance; otherwise, it preserves the reference to DIAN. Forward-Port-Of: odoo/enterprise#79630
[This commit] updated the XBRL version of the Dutch tax reports from the 2024 version (NT18) to the 2025 version (NT19). However, users still need to be able to submit reports for 2024 using the previous scheme. In order to allow this, we keep both the 2024 and 2025 version of the XBRL template and choose the right one depending on the year of the report. In subsequent years, we can then remove the oldest version and add the newest version. The report IDs are suffixes with the year. [op
Original PR description
[This commit] updated the XBRL version of the Dutch tax reports from the 2024 version (NT18) to the 2025 version (NT19). However, users still need to be able to submit reports for 2024 using the previous scheme. In order to allow this, we keep both the 2024 and 2025 version of the XBRL template and choose the right one depending on the year of the report. In subsequent years, we can then remove the oldest version and add the newest version. The report IDs are suffixes with the year. [opw-4600111](https://www.odoo.com/odoo/project.task/4600111) [opw-4664515](https://www.odoo.com/odoo/project.task/4664515) [This commit]: https://github.com/odoo/enterprise/commit/f1710461f37f3560486a1410f9b9ff420b052b7b Forward-Port-Of: odoo/enterprise#82026