Thursday, February 6, 2025
21 changes · 17.0
Resolved issues and error corrections
The inventory count empty-screen message now matches the redesigned Odoo 17 interface. This helps users follow the correct actions and avoids confusion from outdated references to old buttons or menus.
Original PR description
The nocontent message for inventory counts was still referring to old concepts from before the 17.0 Milk redesign (like the "CREATE" button or the Import action in the Favorites menu). This commit updates the message to correctly reference the new design actions, corrects the English and escapes translations inserted into HTML. [task-4550935](https://www.odoo.com/odoo/project.task/4550935)
The mail app restores the previous JPG version of the mail failure icon alongside the newer SVG. This helps avoid display or compatibility issues for users or systems that still rely on the JPG asset.
Original PR description
A recent commit [1] removed the Mail Failure .JPG in favor of an .SVG for transparency. This commit restores the .JPG file alongside the .SVG to prevent potential issues. [1]: odoo/odoo@08f1a78f154d3bf80123b91a1deb0980b95c1ca3 task-4531425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When customers are shown suggested tip amounts after payment, those suggestions are now included on receipts printed early from the Bill screen. This keeps printed receipts consistent with what staff and customers see on screen and avoids confusion at checkout.
Original PR description
Before this commit, when tips were enabled after payment and early receipt printing was enabled, clicking on Bill would show the suggested tips on the Bill screen, but they were not included when printing the receipt. opw-4455884 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes validation for structured payment references so the entire reference must be valid, not just the beginning. It helps prevent SEPA payment files from including references that exceed banking format limits and could be rejected.
Original PR description
In SEPA payment files, when a structured reference is used, it is put in the section `RmtInf/Strd/CdtrRefInf/Ref`. This section has a maximum length of 35 characters. Since we only use structured references that are always less that 35 characters, this should not be a problem. However, the way we validated the structured reference was by performing a `re.match()`, which only matches from the beginning of the string. So if more characters would be after the structured reference, it would still match and it would be possible to go beyond 35 characters. In this commit, we fix this by using a full match instead of a match from the beginning. [opw-4357554](https://www.odoo.com/odoo/project.task/4357554)
Duplicating an all-day calendar event now correctly keeps its start and end dates. This prevents an error that previously interrupted users when copying events, including calendar sync scenarios with Google and Microsoft integrations.
Original PR description
Version: - 17.0 Steps to Reproduce: - Install the Calendar app. - Create an event and enable the "All Day" option. - Duplicate the event. Issue: - When duplicating an All Day event, a traceback error occurs because the start_date and stop_date values are missing. Solution: - The start_date and stop_date are now properly set when duplicating an event resolving the traceback error. task-4353039
The point of sale payment view now excludes cancelled orders whose payments were not actually captured. This prevents misleading payment totals and helps users reconcile finalized sales more accurately.
Original PR description
Before this commit, the payment smart button included payments for cancelled orders, even though those payments were not captured. This caused discrepancies as it inaccurately reflected payments for orders that were not finalized. opw-4487386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Spanish localization now makes the commonly used 21% S tax active again. This prevents users from having to manually reactivate it when configuring or using Spanish tax settings.
Original PR description
21% S taxes were set to active false in https://github.com/odoo/odoo/commit/401a961258e991151370899d4b61809879d5a5a8 . As this tax is commonly used, this commit set it back to active = true.
Website-created helpdesk tickets without attachments now show the expected creation message in the chatter. This improves ticket history accuracy for support teams and ensures consistent tracking regardless of whether files are uploaded.
Original PR description
Steps to Reproduce: - create a helpdesk ticket from the website form without attachments. - creation message in the chatter is missing. Cause: - subtype_id for helpdesk ticket messages was explicitly set in the bridge module's insert_attachment method. When no attachments were present, this prevented the _creation_subtype logic in the helpdesk.ticket model from executing, resulting in the missing creation message. Solution: - Added a condition in the insert_attachment method to skip modifying messages when no attachments are present. It ensures that the default _creation_subtype logic handles subtype assignment, maintaining consistent and accurate creation message logging in the chatter. task-4397661
This fix prevents an error that could occur after an online bank account was disconnected. It makes the synchronization process use a fresh reference instead of one that may no longer exist, improving reliability for accounting users.
Original PR description
This commit avoids calling the toggle cron function with journal_ids recordset after an online account has been unlinked. Previously, this caused an error because the record was already deleted. The journal_ids model is now retrieved from the environment instead of the potentially stale recordset. The bug was introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a
Odoo will no longer automatically recreate standard WhatsApp templates that users have deliberately deleted during module upgrades. This avoids duplicate-template errors and keeps user-managed WhatsApp template choices intact.
Original PR description
There might be little value in re-creating a template that a user has deleted. This can also trigger the model constraint, specially in smaller databases with only one Whatsapp account and one language installed when a standard template is deleted and a new one with the same name is created. To reproduce: - Install `whatsapp_account` - Delete the `Invoice` template - Create a Whatsapp account - Create a new template, call it `Invoice` and link to the account. - Upgrade the module This will trigger the constraint: ``` psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "whatsapp_template_unique_name_account_template" DETAIL: Key (template_name, lang_code, wa_account_id)=(invoice, en, 1) already exists. ```
Clicking a budgetary position now shows only the budget lines linked to that position instead of showing every budget line. This makes budget review faster and reduces the risk of users acting on unrelated financial information.
Original PR description
### Before this commit: Clicking on a budgetary position opened the list view showing all budget lines, regardless of the selected budgetary position. ### After this commit: Now, clicking on a budgetary position will open the list view filtered to show only the budget lines associated with that specific budgetary position. ### Technical: In `doActionButton`, we use the `args` if the action type is object. so, `domain` is irrelevant in this context. **task-4195738**
Imported vendor bills such as Factur-X now keep the tax information provided in the electronic document instead of replacing it with a prediction based on past bills. This helps avoid incorrect taxes on imported invoices and reduces manual correction work.
Original PR description
When we have bills with same Tax in history now we are trying to import EDI document like Factur-X with different Tax the prediction override the Tax that was correctly set inside EDI import methods. This will keep the correct Tax from EDI.
Uruguayan electronic invoices now clear old error messages when users correct and resend them. This prevents outdated warning banners from showing the wrong issue, helping users fix the current problem more confidently.
Original PR description
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the…
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the unit price of the product detailed in the invoice is equal to 0.0), the webservice returns an error that is captured on Odoo and shown as a pop-up and added as a banner on the move header. If the user resets the move to draft, corrects the error and for some reason introduces another one (like leaving the "tax" column empty), then confirm and send the invoice again to DGI, a new pop up is raised showing a new error message accordingly but the banner of the header remains showing the same error as before (saying the product unit price is 0). This leads to confusion about what is the current error to be amended to properly send the invoice to DGI. Steps to reproduce the error: - Create an uruguayan electronic invoice on a testing enviroment. - Select a product and change its unit price to 0. - Try to send & print the invoice, creating the CFE. - An error like this will be shown:  - Go back to the move and check that a banner with the error has been added at the top.  - Reset to draft, add a valid unit price and delete the "Taxes" column value. - Confirm, Send&Print the invoice. - A new pop up like this should raise:  - Go back to the invoice and check that the banner remains as before, showing an outdated error message.
Miscellaneous changes
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
Original PR description
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
**Current behavior:** Changing the `delay` field on a `product.supplierinfo` then looking at the replenishment report will not have updated the qty fields of the orderpoint which were affected by the increase in delay (delivery lead time in the 'Purchase' tab on Product form). **Expected behavior:** The `qty_forecast` and `qty_to_order` fields update to reflect moves which should be captured according to JiT forecasting. **Steps to reproduce:** 1. Create some productA with a vendor
Original PR description
**Current behavior:** Changing the `delay` field on a `product.supplierinfo` then looking at the replenishment report will not have updated the qty fields of the orderpoint which were affected by the…
**Current behavior:** Changing the `delay` field on a `product.supplierinfo` then looking at the replenishment report will not have updated the qty fields of the orderpoint which were affected by the increase in delay (delivery lead time in the 'Purchase' tab on Product form). **Expected behavior:** The `qty_forecast` and `qty_to_order` fields update to reflect moves which should be captured according to JiT forecasting. **Steps to reproduce:** 1. Create some productA with a vendor that has some lead time 2. Create a sale order for that product, edit the sale order `commitment_date` field (Sale Order -> Other Info -> Delivery Date) to some future date such that the delay would not necessitate any replenishment at the current date (i.e., today + delay + 1 day) 3. Create an orderpoint for the productA, see that the `qty_to_order` is 0 -> this makes sense 4. Increase the delay for the vendor on productA enough that a purchase order would be required to fulfill the sale order on time 5. Go back to the replenishment report -> qty to order still 0 **Cause of the issue:** `qty_to_order` is stored and computed, in this sequence none of its dependencies are modified and so it remains 0 after `delay` on the supplier info record is changed. **Fix:** Add `product_id.seller_ids.delay` to the dependency list of `_compute_qty` and `_compute_qty_to_order`. opw-4333016 Forward-Port-Of: odoo/odoo#189427
Steps to reproduce ================== - Install web_studio,mrp - Go to Manufacturing > Operations > Manufacturing Orders - Open studio - Add a related field - Select Product > Image - Change the widget to the ImageField - Exit studio - Open any record - Go to the product - Edit the image - Go back to the list view => The old image is still displayed Cause of the issue ================== We add a unique parameter in the image url with the last record update. In the case of a
Original PR description
Steps to reproduce ================== - Install web_studio,mrp - Go to Manufacturing > Operations > Manufacturing Orders - Open studio - Add a related field - Select Product > Image - Change the widget to the ImageField - Exit studio - Open any record - Go to the product - Edit the image - Go back to the list view => The old image is still displayed Cause of the issue ================== We add a unique parameter in the image url with the last record update. In the case of a related field, the record has not been updated even if the image has changed. Solution ======== We still need to pass a unique value in the URL because browser will not fetch twice the same URL in the same session. In that case, we can simply pass a random value opw-4378605 Forward-Port-Of: odoo/odoo#192036
@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
Original PR description
@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
In the recent fix at 904c7c8a, we forgot the inherited allowed facets and removed too many tags when changing folders. opw-4347910 Original PR: https://github.com/odoo/enterprise/pull/75001 Forward-Port-Of: odoo/enterprise#78616
Original PR description
In the recent fix at 904c7c8a, we forgot the inherited allowed facets and removed too many tags when changing folders. opw-4347910 Original PR: https://github.com/odoo/enterprise/pull/75001 Forward-Port-Of: odoo/enterprise#78616
GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#77423
Original PR description
GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#77423
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root': ``` 2025-02-05 10:29:03,827 4815 ERR
Original PR description
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and…
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box.
However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them
This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root':
```
2025-02-05 10:29:03,827 4815 ERROR ? odoo.addons.hw_drivers.tools.helpers: Failed to delete old IoT handlers
Traceback (most recent call last):
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 435, in delete_iot_handlers
unlink_file(*filenames)
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 534, in unlink_file
path.unlink()
File "/usr/lib/python3.11/pathlib.py", line 1148, in unlink
os.unlink(self)
PermissionError: [Errno 13] Permission denied: '/home/pi/odoo/addons/hw_drivers/iot_handlers/lib/ctep/libeasyctep.so'
```
This PR runs Worldline related script under user "odoo" which fixes the ownership/access issues and allows Odoo service to delete the files.
task-4527243
Forward-Port-Of: odoo/enterprise#78544The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure. This commit aims at fixing this by removing the account code range for the recievable and payable types. From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables and 'C' for receivable. task-4465663 Forward-Port-Of: odoo/enterprise#77103
Original PR description
The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure. This commit aims at fixing this by removing the account code range for the recievable and payable types. From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables and 'C' for receivable. task-4465663 Forward-Port-Of: odoo/enterprise#77103