Thursday, December 12, 2024
22 changes · 17.0
New functionality added to Odoo
This pull request adds translations for the Dutch payroll modules, specifically for accounting accounts. This update ensures the system correctly supports Dutch accounting regulations and reporting requirements, improving accuracy and compliance for businesses operating in the Netherlands.
Enhancements to existing features
This update simplifies the accounting report button bar by ensuring the XLSX export button is consistently displayed. This change reduces complexity and improves the user experience by making the key export functionality readily available on all accounting reports.
Original PR description
Refactors the button bar component and makes the xlsx button always show on accounting reports. task-4402561
Resolved issues and error corrections
The activity view now follows the same creation restrictions as list and kanban views. When creating new records is disabled for an action, users will no longer see or use the New button there, preventing inconsistent behavior.
Original PR description
When we pass create = false in the action context, a new record cannot be created in the kanban and list views. However, a new record could still be created in the activity view. In this commit, we have prevented that. task-3887972
Miscellaneous changes
* STEP TO REPRODUCE: try to _message_log on a channel contain record link (an a tag with data-oe-model and data-oe-link) then click on it -> nothing happen * REASON: when _message_log in mail.channel, it will consider that message as a NotificationMessage and we do not have store.handleClickOnLink for it unlike Message * SOLUTION: add handleClickOnLink for MessageNotification Forward-Port-Of: odoo/odoo#188380
Original PR description
* STEP TO REPRODUCE: try to _message_log on a channel contain record link (an a tag with data-oe-model and data-oe-link) then click on it -> nothing happen * REASON: when _message_log in mail.channel, it will consider that message as a NotificationMessage and we do not have store.handleClickOnLink for it unlike Message * SOLUTION: add handleClickOnLink for MessageNotification Forward-Port-Of: odoo/odoo#188380
This fix ensures the Indian withholding tax wizard first checks whether any records were selected. If none are selected, users now receive a clear error message instead of running into an unexpected failure.
Original PR description
We need to first check if active_ids exist and get usererror if there are no active_ids present. [Link to Runbot Error builds](https://runbot.odoo.com/web#id=74407&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that email addresses added through the link widget are saved as email links instead of regular web links. It prevents recipients from being sent to an invalid web address when clicking an email link in a mailing.
Original PR description
**Steps to reproduce:** - Create a new mailing - Add a link with "Link" widget - Enter an email - Insert the link **Issue:** `http://` is prepended to the email instead of `mailto:`. **Cause:** Introduced by this commit: https://github.com/odoo/odoo/commit/31dff0ed609b0e95c6097afc8d3a5daf194737f5 As `this.state.url = url;` is executed each time the domain is not stripped, it is undoing the code adding "mailto:" to an email address. opw-4357095 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website editors can no longer add helpdesk team pages directly to the website menu, because those links may not appear publicly after publishing. Helpdesk team menu entries must now be managed through the helpdesk team settings, reducing confusion and preventing broken or hidden navigation items.
Original PR description
To reproduce: ============= - after enabling **website forum** feature in settings of helpdesk team - go to website editor -> Menu items -> add new item with url `/helpdesk/<team-slug>` - save and publish the changes -> the menu item is not visible in the website menu publicly Fix: ======== -User should not be able to add helpdesk team to website menu from editor, it must be done from the helpdesk team settings. - A validation is added to check if the menu item is for helpdesk team and if so, it will be rejected. - The suggested urls are filtered to avoid suggesting helpdesk team urls. opw-3931376
This update corrects a technical issue in the Romanian localization reports module that prevented the correct handling of date formats. The change ensures that date information is consistently formatted as strings, resolving potential reporting errors and improving data accuracy. This update focuses on internal reporting processes.
Original PR description
Options dict is not supposed to contain date objects.
This update restores the Sales Order (SO) and Service Order (SOL) buttons within the project updates view for field service projects. Previously, these buttons were accidentally removed, preventing users from easily accessing related sales information. This change ensures users can seamlessly link project updates to their corresponding sales orders.
Original PR description
Versions: ---------- - 17.0 Steps to Reproduce ------------ - Create a product and add the template of the field service project. - Create a sale order. - Open the project updates. - We do not see the SO and SOL buttons. Issue ------------ - SO and SOL smart button was removed on project updates in this commit https://github.com/odoo/enterprise/commit/7a82c52fb007ad0f827dd5d124f80d6195bff919 Fix ---------- - We are adding the SO and SOL buttons back. - So the user can at least see the linked data. task-3887972
This update fixes a potential upgrade issue caused by incorrectly mapping window actions to experimental grid views. Removing grid views previously led to problems during updates, particularly when uninstalling related modules. This change ensures that grid views are properly handled, preventing future upgrade complications.
Original PR description
When a grid view is removed we should cascade the removal to the window actions mapping. Grid views are considered experimental. They do not have a `_get_default_grid_view` method, and crafting an acceptable general one is close to impossible due to grid views' requirements in terms of the model fields. Allowing the grid mapping for window actions have been proven to cause issues during upgrades if clients uninstall one of the few modules providing grid views (like analytic_enterprise). Forward-Port-Of: odoo/enterprise#74912
This update prevents the creation of templates when uploading PDF documents for signature processing via the 'Upload a pdf & sign' button. Previously, users could inadvertently save template information. This change ensures a cleaner workflow and avoids unnecessary data storage.
Original PR description
When uploading a pdf through "Upload a pdf & sign" button, no template should be saved. Hence the "Template Properties" button shouldn't show up. This commit aims to hide the button for this type of files. Task: 4317966 Forward-Port-Of: odoo/enterprise#73912
A bug was causing two 'Sign Now' buttons to appear in the signature request dialog. This has been corrected by adjusting the button visibility condition to ensure it disappears when either condition is met. This improves the user experience and prevents confusion.
Original PR description
Version: - 17.0 Step to reproduce: - upload sign template - click on sign now button on template Issue: - two sign now buttons are visible to user Cause: - there is an issue in condition to make button invisible as it require both the condition to be true to make button invisible Solution: - change condition which will make button invisible when any one condition true. task-4234996
This update fixes an issue where clicking between buttons in the softphone interface would unexpectedly generate an input field. The fix ensures that input is only created when a user actively clicks on a button, improving the user experience and preventing unwanted data entry.
Original PR description
Issue: Clicking the space between buttons but no click on any buttons, a input of "123456789*0#" will be generated. Fix: Do nothing when click in this situation, only generate input when clicking on buttons.
This update resolves an issue where incoming call ringtones were playing across all open tabs in Odoo. Now, ringtones will only play on the main 'master' tab, creating a cleaner and less disruptive user experience. This improves usability and reduces potential confusion for users.
Original PR description
Currently when receiving incoming calls, it's possible that all opened tabs will play the ringtone. To reduce the chaos, we now only play the incoming ringtone on the master tab. Task-4402909
Steps to reproduce the issue: - go to currencies; - search for a rate with something else than a date; - it crashes. This happens because the currency rate model is searched with two fields, a date field (`name`) and a float field (`rate`). This crashes when converting the value to match against, because the value cannot be serialized in SQL both as a date and a float. What we do in such a case is to explicitly convert the value to the field's type. If the conversion fails, we simply
Original PR description
Steps to reproduce the issue: - go to currencies; - search for a rate with something else than a date; - it crashes. This happens because the currency rate model is searched with two fields, a date field (`name`) and a float field (`rate`). This crashes when converting the value to match against, because the value cannot be serialized in SQL both as a date and a float. What we do in such a case is to explicitly convert the value to the field's type. If the conversion fails, we simply ignore that part of the domain. opw-4278234 Forward-Port-Of: odoo/odoo#187838
**Current behavior:** When computing the total cost for a kit product in a POS order, extra stock moves are included if another POS order line has a product that shares the same components. This results in an incorrect total cost displayed on the POS order, which does not match the computed price from the BOM shown on the product page. **Expected behavior:** The total cost for the POS order should match the computed BOM price shown on the product page. **Steps to reproduce:** 1. Creat
Original PR description
**Current behavior:** When computing the total cost for a kit product in a POS order, extra stock moves are included if another POS order line has a product that shares the same components. This…
**Current behavior:** When computing the total cost for a kit product in a POS order, extra stock moves are included if another POS order line has a product that shares the same components. This results in an incorrect total cost displayed on the POS order, which does not match the computed price from the BOM shown on the product page. **Expected behavior:** The total cost for the POS order should match the computed BOM price shown on the product page. **Steps to reproduce:** 1. Create two products: Product 1 and Product 2. 2. Set both products to be tracked by "quantity" or make them "storable" and assign them to a product category with "average cost" as the costing method (instead of "standard price"). 3. Create a Bill of Materials for each product, ensuring they share at least one component. Make sure BoM Type is 'kit' - Tip: For better visibility of the error, assign a quantity of 10 or more to the shared component in Product 2's BOM, and set the shared component’s `standard_price` (cost) to 5 or higher. This will make the discrepancy in the total cost more apparent. 4. Create the shared component as a new product and assign it a price. 5. Open a new POS order, add Product 1 and Product 2, and close the order. 6. Locate the order and observe that the "total cost" is incorrect. **Cause of the issue:** The stock move filter does not consider that stock moves for BOM lines need to belong to the current product. As a result, if two kit products share components, the stock moves for one product are mistakenly included in the calculation for the other, leading to an incorrect total cost. **Fix:** When filtering out the stock moves, ensure they are correctly associated with the current product by verifying that each stock move’s BOM line belongs specifically to the current product and does not include nested BOMs. opw-4274532 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187130
Before this commit: In case an E-waybill is already generated we post a help message as log note on the invoice with URL that user can check that on the government portal, But whenever user links on the URL it give a error code of 404 In this commit we post the correct URL, and the user is re-directed on the correct page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190308
Original PR description
Before this commit: In case an E-waybill is already generated we post a help message as log note on the invoice with URL that user can check that on the government portal, But whenever user links on the URL it give a error code of 404 In this commit we post the correct URL, and the user is re-directed on the correct page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190308
Consider this situation: - Customer invoice. - All invoice lines use a tax type with l10n_es_type=no_sujeto_loc. - The sum of the invoice is 0€. - Sent to SII. Before this patch, the process would raise a wrong `UserError`. If the process was being executed by the cron, **no invoice would be sent**, even if there was only one failing. After this patch, the invoice will be notified nevertheless. If there's any kind of real validation problem, the SII servers will return an error that wi
Original PR description
Consider this situation: - Customer invoice. - All invoice lines use a tax type with l10n_es_type=no_sujeto_loc. - The sum of the invoice is 0€. - Sent to SII. Before this patch, the process would raise a wrong `UserError`. If the process was being executed by the cron, **no invoice would be sent**, even if there was only one failing. After this patch, the invoice will be notified nevertheless. If there's any kind of real validation problem, the SII servers will return an error that will get logged in the invoice. No exceptions raised in Odoo. The process can continue. Faulty invoices are marked; others work. Apart from that, there's also the fix to support the specific case outlined above. @moduon MT-7949 OPW-4344661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189529
body_content is a better representation of what the email will actually look like when sent. task-4333657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188803
Original PR description
body_content is a better representation of what the email will actually look like when sent. task-4333657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188803
In d636c1f49ce1e680565663c272cd50e09b8662c6 we replace body with the body content. However the original field should not be removed entirely as it could break any override of the view. task-4333657 Forward-Port-Of: odoo/odoo#190471
Original PR description
In d636c1f49ce1e680565663c272cd50e09b8662c6 we replace body with the body content. However the original field should not be removed entirely as it could break any override of the view. task-4333657 Forward-Port-Of: odoo/odoo#190471
When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input using 'email_split(_and_format)', which finds emails but do not format them. This leads to incoherent behavior as most emails are normalized as we generally always use partners, but not all. In this commit we now split, normalize and format email_to and email_cc in outgoing emails. This fixes a fi
Original PR description
When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input…
When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input using 'email_split(_and_format)', which finds emails but do not format them. This leads to incoherent behavior as most emails are normalized as we generally always use partners, but not all. In this commit we now split, normalize and format email_to and email_cc in outgoing emails. This fixes a first issue where name are lost if a formatted email was entered in email_cc field. Only address was kept, now the name is correctly found and put back. This also fixes an issue for validated email detection, in order to compare normalized emails. This was introduced at odoo/odoo#185793 and may skip valid emails entered in email_to or email_cc. This commit backports a tool introduced at odoo/odoo@dd4709e579841672b0c2a57d5f2941f3ce770801 which aims at allowing a quick convert from a string holding emails to a list of nicely formatted emails, using normalize version of email addresses. This is the standard we use in most flows. Task-4376876 Followup of task-3704658 Forward-Port-Of: odoo/odoo#189409
Incorporate Eduardo Martinez (emtz10) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190149
Original PR description
Incorporate Eduardo Martinez (emtz10) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190149