Wednesday, March 26, 2025
11 changes · 17.0
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
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