Monday, May 27, 2024
21 changes · 17.0
Enhancements to existing features
Italian electronic document processing now validates files based on their actual XML structure rather than filename, making the system more reliable and consistent with other EDI methods. This change also improves handling of digitally signed files (.xml.p7m) by automatically removing signatures before processing.
Original PR description
Italian EDI used to look at the filename to determine whether the uploaded attachment is related to it or not. With this change we look at the structure of the XML file, making it more standard - it's what all other EDIs do. CADES signed files (.xml.p7m) have their signature removed and then they are treated like normal XML files. In order to be able to do this, we have to move the code that specially handles the account_predictive_bills for Italy to the `account` level. Related PR: odoo/odoo#163849 Related issue: #150382
Italian EDI document processing has been improved to validate the actual XML structure of uploaded files rather than relying on filename patterns. This makes the system more robust and consistent with how other EDI formats work. The change also properly handles digitally signed files (.xml.p7m) by removing the signature before processing.
Original PR description
Italian EDI used to look at the filename to determine whether the uploaded attachment is related to it or not. With this change we look at the structure of the XML file, making it more standard - it's what all other EDIs do. CADES signed files (.xml.p7m) have their signature removed and then they are treated like normal XML files. In order to be able to do this, we have to move the code that specially handles the account_predictive_bills for Italy to the `account` level. Old PR for master: odoo/odoo#165673 Related PR: odoo/odoo#163849 Related issue: #150382
Resolved issues and error corrections
The Austrian financial reports module had an unbalanced Balance Sheet that has now been corrected. The fix adds missing account classifications, separates current year profits from carried-forward profits in both the Balance Sheet and Profit & Loss statements, and aligns the reports with official Austrian accounting standards. This ensures accurate financial reporting for Austrian companies.
Original PR description
According to the Balance Sheet diagnostic test in #47602, the Balance Sheet was unbalanced. To fix this, - missing account tags have now been added (cf community PR); - the Balance Sheet Profit (loss) line has been split into the current year's profit/loss and the profit/loss carried forward. - the Profit and Loss carried forward from previous years has been created as a new line in the P&L. This is all done in accordance with the official Balance Sheet and Profit & Loss found at https://www.jusline.at/gesetz/ugb/paragraf/224 https://www.jusline.at/gesetz/ugb/paragraf/231 Community PR: https://github.com/odoo/odoo/pull/158542 Taskid: 3060790
This update fixes how payment tax documents (CFDIs) are dated in Mexico. Previously, payments created in Odoo before being sent to the government would use an incorrect date. Now the system uses the actual submission date, which complies with Mexican law allowing payments to be submitted up to 10 days into the following month. This ensures your tax filings are legally accurate.
Original PR description
[REF] l10n_mx_edi: change fecha date to sent date Issue: Sometimes payments are created in Odoo prior to sending the CFDI, by law payments don't have to be necessarily sent to the government on the same month and can sometimes be sent up to the first 10 days of the next month. Solution: fill the 'fecha' field with the current datetime for the cfdi of the payments, Then send it. Task-3885769
This fix resolves a crash that occurred when users tried to retry sending comment notifications in the Knowledge module. When a user tags another user in a Knowledge comment, the system attempts to send a notification email. If an error happens and the user retries, the system was crashing due to a missing data field. The fix ensures the system gracefully handles this situation so users can successfully retry sending notifications.
Original PR description
This commit fixes an issue with comments notifications in Knowledge. When a user tags another user in a Knowledge comment, a mail should be sent. When an error occurs the user have the possibility to retry to send the notification. Retrying this action triggers an error with threads because the msg_vals key doesn't exist when trying to access it inside `_notify_thread_by_email`. The fix is to use the get function of Python dict so that if the msg_vals aren't set, no error is triggered. task-3933062
This fix resolves an issue where shipping addresses with longer city and state names would cause Bpost delivery validation to fail. The system now properly limits the address field length to prevent errors when customers have addresses that exceed the character limit, such as "Marche-lez-Ecaussinnes, Brabant Wallon (BE)".
Original PR description
Steps to reproduce: - Create a contact who has the "City" and "State" populated, that would exceed 40 characters in the following format: "[City], [State] ([Country Code])" eg: "Marche-lez-Ecaussinnes, Brabant Wallon (BE)" - Enable Bpost and enter test credentials. - Create a Sales Order and add Bpost shipping. - Try to validate the transfer - Error about the "LocalityCode" being too long. Fix: same as for other fields impose max length limit opw-3895123 Forward-Port-Of: odoo/enterprise#62710
This fix corrects how asset depreciation amounts are calculated when an asset's lifetime is extended through revaluation. Previously, when extending an asset's depreciation period (for example, adding 12 months), the depreciation entries would end too early. Now the system properly calculates depreciation amounts based on the original asset value, ensuring consistent monthly depreciation across the entire extended lifetime.
Original PR description
Create an asset for 2400$, acquisition date on 1/1/2023. Reevaluate it on 31/12/2023, 36 montths (+12) and add 1200$ to the amount. => The entries on the parent asset finish way too early. You don't get 36 months of lifetime. We would expect the amount of each new depreciation to be 50, so the amount of the parent + the child equals 100 each month for 36 months The reason why it happened is that we tried to compute the expected amount after each depreciation. This took into account changes of amount, but not changes of length. We don't have a good way to incorporate changes of length in the old computation. To fix this, for linear, we consider the original amount from the beginning/the reevaluation to compute the amount for each period. It does not hold for degressive_then_linear, so we separate the logic. opw-3811165 Forward-Port-Of: odoo/enterprise#62377
This fix resolves an issue where Knowledge articles couldn't embed certain views (like Cohort and Gantt views) if their optional modules were manually uninstalled. The system now intelligently detects which modules are loaded and only applies the necessary patches when available, preventing errors and ensuring a smooth user experience.
Original PR description
Cohort views were patched to allow inserting them as an embed in a Knowledge article, but `web_cohort` was not a dependency of `knowledge`. It was an issue if the `web_cohort` (which is auto_install: True) module was manually uninstalled. Using an odoo runtime import, we can evaluate if the module was loaded and apply the patch at that point. If the module was not loaded, the patch is not applied. task-3918938 Forward-Port-Of: odoo/enterprise#63100 Forward-Port-Of: odoo/enterprise#62181
Fixed an issue in the document signing process where users were unable to close the confirmation dialog box after signing documents. Previously, users had to close the entire browser window to dismiss the dialog. Now a close button has been added, allowing users to easily dismiss the dialog and continue with their work.
Original PR description
Steps to reproduce: - Install sign - Add two document to sign for the Marc Demo - Sign in as Marc Demo - Go to the sign app and sign both documents Issues: There's no button to close the dialog box, you are forced to close the window. opw-3847269 Forward-Port-Of: odoo/enterprise#61380
When revaluing an asset with an increase from a previous month, the system was incorrectly recording today's date on the value increase transaction instead of the actual revaluation date. This fix ensures the transaction is dated to match the asset's acquisition date, providing accurate financial records and proper period tracking.
Original PR description
To reproduce: Create an asset. Reevaluate, with an increase, last month. => the move of Value Increase has today's date. We decided to instead put the acquisition date of the child asset. (so it won't be the same in 16.0) opw-3922067 Forward-Port-Of: odoo/enterprise#63115 Forward-Port-Of: odoo/enterprise#63097
This fix prevents dashboards from disappearing when users accidentally remove all group assignments. By making the group field required, dashboards must always be assigned to at least one group, ensuring they remain accessible and cannot be lost.
Original PR description
Purpose ------- If you remove all groups of dashboard and save, the dashboard disappears and there's no way to find it back. Specification ------------- make the field required. Task: 3770194 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where users without write permissions could not properly drag and drop items in kanban views. Previously, items would not reset to their original position when users lacked reordering rights. Now the drag-and-drop functionality works correctly for all users, with items properly returning to their original position when the action is not permitted.
Original PR description
Before this commit, drag-and-drop functionality for groups/records in the kanban view did not work properly if the user lacked write access. Steps to Reproduce: - Log in to Odoo as Marc Demo. - Open the Project module. - Attempt to drag and drop any group/record in the kanban view. Observed Behavior: The group in the kanban view does not reset to its original position if the user lacks the right to reorder the groups/records, rendering the group/record immovable. Expected Behavior: The group in the kanban view should reset to its original position if the user lacks the right to reorder the groups/records. After this commit, drag-and-drop functionality for groups/records in the kanban view now works properly, even if the user does not have write access. Task ID: 3865617 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error that occurred when searching for vehicles by driver in the Fleet app when installed without the HR module. The fix ensures the vehicle search functionality works correctly regardless of which modules are installed alongside Fleet.
Original PR description
Problem: * If the fleet app is installed **by itself** (i.e. without hr) searching a vehicle by driver will throw an error. Notes about fix: * The error is caused by a hr_fleet child field being accessed in the base Vehicle model. opw-3858626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed a bug in the Accounting app where PDF attachments uploaded to bills would not display a preview. The issue occurred because the system tried to show the PDF before it was fully saved. This update ensures the file is completely uploaded before attempting to display it.
Original PR description
Caused a bug in accounting app. ### Steps to reproduce: - Go to Accounting > Vendors > Bills - Create a new bill - Upload a pdf using the link button in the chatter - The pdf viewer displays but without preview ### Cause: The call to display the attachment occurs before the attachment record is created. This is due to the onUploaded function of mail not being async, so the program does not wait for it to end. ### Solution: Make the function async and waiting for the file to be uploaded. opw-3927764 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where test emails sent through the mass mailing feature contained broken placeholder links that would result in 404 errors when clicked. The fix ensures that placeholder links are properly replaced with actual working links when test emails are sent, while preventing unsubscribe links from being modified to protect users from accidentally unsubscribing themselves.
Original PR description
This commit fixes an issue with the mailing_mailing_test wizard in mass_mailing. When sending a test email the snippet `s_mail_block_header_view` contains a placeholder link that is replaced by the…
This commit fixes an issue with the mailing_mailing_test wizard in mass_mailing. When sending a test email the snippet `s_mail_block_header_view` contains a placeholder link that is replaced by the actual link when rendered. When the user sends a test mailing, the mail sent will still contain the placeholder link without being replaced. This means that when clicking on it the user is redirected to a 404 error as this is a mere placeholder. This link isn't replaced because the mail created inside testing wizard did not give a res_id, linked to a `mailing.contact`, to the `mail.mail` created. This led the function `_prepare_outgoing_list` to be exited prematurely without replacing any placeholder. This commit fixes the issue by adding a res_id linked to the current user to the mail.mail created in order for the method to finish its execution. But we don't want the unsubscribe links to be replaced, as the user could blacklist himself. Thus we added a context key `send_as_test` which blocks the replacement of the unsubscribe link. task-3869575 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where repair orders were not receiving auto-generated sequence numbers after a system upgrade. The problem was caused by an incorrect comparison logic that was checking for a translated value when the field doesn't support translation. By correcting this comparison, repair orders now properly generate their sequence numbers automatically instead of remaining with the default 'New' label.
Original PR description
Issue: In the upgraded version, we have implemented the condition vals['name'] == _('New'). However, the data type of the 'name' field is character and translate = False. Additionally, the default…
Issue: In the upgraded version, we have implemented the condition vals['name'] == _('New').
However, the data type of the 'name' field is character and translate = False.
Additionally, the default value for the 'name' field is set to 'New', causing
this condition to evaluate to false and consequently terminating the execution
of the if block.
Solution: To address this, we propose changing the condition to vals['name'] == 'New'
to ensure correct comparison. This modification is warranted due to the
[configuration](https://github.com/odoo/odoo/blob/89fbb75659ba71b8c76dddd62ba331966161f59b/addons/repair/models/repair.py#L31)
of the field:
The field is not translatable.
The field is required and set to readonly true, preventing customers from inputting values.
The default value for the field is set to 'New'.
Before:
Unable to obtain the auto-generated sequence (receiving default value 'New').
After:
The sequence is generated automatically.
OPW-3887638
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#165771This update fixes an issue where portal access couldn't be granted to multiple customers with the same email address when they're linked to different websites. The system now correctly handles scenarios where customers create separate accounts per website, allowing each to receive portal access independently while preventing conflicts when appropriate.
Original PR description
[FIX] portal, website: allow to grant portal access for certain users Context: - Have a db with two websites (website1 and website2) with two different domains. - For those two websites, make sure…
[FIX] portal, website: allow to grant portal access for certain users Context: - Have a db with two websites (website1 and website2) with two different domains. - For those two websites, make sure that the "Shared Customer Accounts" setting is disabled. The user is so forced to create an account per website. - As a visitor, create an account in each website using the same email address. -> No issue; it is possible to create two accounts with the same email address. Steps to reproduce the issue: - Create two contacts (e.g. partner or customer) with the same email address. One is linked to website1, the other is linked to website2. - Select them, click on "Action" and then on "Grant portal access". - Click on "Grant Access" for the first contact; it works as expected. -> It is not possible to grant access for the second contact. The goal of this commit is to ensure that the two described behaviors lead to the same results. More specifically, it should be possible to grant portal access for two partners that have: - The same email address but are linked to different websites that have the "Shared Customer Accounts" setting disabled. - The same email address. One user is linked to a website that has the "Shared Customer Accounts" setting disabled and the other is not linked to a website. It should however not be possible to grant portal access for two partners that have: - The same email address and are linked to the same website that has the "Shared Customer Accounts" setting disabled. - The same email address and are not linked to a website. It should also not be possible to grant portal access for a partner that is not linked to a website if it exists a user with the same email address that is linked to the current website. Indeed, in this situation, the partner is redirected to the current website at the creation of its account and an "Access Denied" message would then be displayed. To solve the problem, the method `_get_similar_user_domain()` has been implemented in the "website" module. Its goal is to build the domain needed to find the users that have the same email than partners depending on their linked website characteristics. The `_is_portal_similar_than_user()` method has also been introduced. Its goal is to check if the credentials of a portal user and a user are the same. If it is the case, `email_state` field of the portal user is set to `exist`. task-3640503 Forward-Port-Of: odoo/odoo#166349 Forward-Port-Of: odoo/odoo#148482
This update corrects faulty translations in the Swedish language pack for sales templates that were causing system errors when messages were sent in Swedish. The fix ensures that Swedish-speaking users can properly send sales communications without encountering translation-related failures.
Original PR description
Correcting faulty translation of templates that will break the system when messages are sent in Swedish. Reported as support tickit #3900977.
This pull request contains multiple fixes and improvements across various Odoo modules including web editor link handling, accounting journal synchronization, delivery weight calculations, manufacturing operations, and inventory management. The changes address specific bugs that impact user workflows and system performance, such as incorrect picking weights, missing operation durations, and unnecessary recalculations in inventory systems.
Original PR description
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 corrects errors in the Swedish language translation of sales email templates that were causing emails to fail when sent. The translation contained mistranslated code and unclosed XML tags that prevented proper email generation. This resolves support ticket #3900977.
Original PR description
Current Swedish templates are done wrong and will give error when e-mail is sent out, because code has been translated and XML tags are not closed. There are also multiple lines copied multiple times. This is the fix for support ticket #3900977.
This fix resolves an issue in the website editor where drop zones (areas to place new content) would disappear when hiding a column in a snippet. The problem occurred because a visibility attribute was incorrectly propagating to parent elements. The fix adjusts how the system determines where to place drop zones, ensuring they remain available even when columns are hidden.
Original PR description
Steps to reproduce the bug: - In Website edit mode. - Drop 2 "Columns" snippets. - Hide one of the columns in the first snippet by clicking on the "Hide on desktop" button of the "Column" options in…
Steps to reproduce the bug: - In Website edit mode. - Drop 2 "Columns" snippets. - Hide one of the columns in the first snippet by clicking on the "Hide on desktop" button of the "Column" options in the side panel. - Start to drag another snippet. - Bug: There is no dropzone between the 2 "Column" snippets. The issue happens because when the column becomes invisible, after clicking the button, the attribute `data-invisible="1"` is added to the column in the DOM thanks the 'snippet_option_visibility_update' event. However, this event then propagates to the column's parent elements (`<section>` and `<main>`). So, the attribute `data-invisible="1"` is also added to the `<section>`, causing the dropzone not to be inserted as expected. We should investigate this further later because it doesn't seem consistent. For now, we prefer not to make changes at this level to avoid introducing other bugs. In this commit, we change the selector that determines where not to insert dropzones so that it no longer considers `data-invisible="1"`. This was added by this commit [1], but it seems unnecessary, and ':not(:visible)' in the selector is sufficient to avoid placing dropzones between two non-visible elements. [1]: https://github.com/odoo/odoo/commit/f9bd3033b21dbd1e4487d6d6cd1d8d8fdfbfb2ac Forward-Port-Of: odoo/odoo#165797