Saturday, February 3, 2024
14 changes · 17.0
Enhancements to existing features
The send and print flow now shows clearer warning messages with direct links to fix missing or incorrect invoice data before sending. This helps users resolve Italian e-invoicing issues faster and reduces failed submissions or confusion during invoice processing.
Original PR description
The new ActionableErrors widget new widget is meant to be a warnings header for wizards and forms, where flows like EDI can list a series of errors and actions for the users to fix the roadblocks.…
The new ActionableErrors widget new widget is meant to be a warnings header for wizards and forms, where flows like EDI can list a series of errors and actions for the users to fix the roadblocks.
The HTML result is a `<div>` list with a point for each warning and a link to a given action. Clicking the link will fire the execution of a Python method on the backend, also passing back to it a series of parameters the component has stored on setup time.
During setup, ActionableErrors accepts this structure as incoming data:
```py
{
'error_key' : {
'message': _("Description of the warning"),
'action_text': _("Text of the link"),
'action': {
'type': 'ir.actions.act_window',
'res_model': 'model.to.be.opened',
'views': [(False, 'list'), (False, 'form')],
'target': 'current',
'res_id': res_ids[0],
},
}, ...
}
```
A map is used instead of an array, so that the Owl framework could be more precise in rendering changes in future development, thanks the `t-foreach`'s `t-key` check. (i.e. remove a warning after clicking the action link without re-rendering the whole widget)
In `l10n_it_edi`'s Send&Print flow, we removed the old code from the view, we changed the compute from HTML to Json, and adapted the compute function's output to fit the ActionableErrors widget format.
All the pre-sending checks that were done on the before sending are now split by model, so that there's more separation.
The actions will get created by `base/ir_ui_view.py/Model`.[get_records_action](https://github.com/odoo/odoo/pull/142596/commits/48bb284b33f9939eb68bfb9a8484dc588e2fa0df#diff-dfebe5a93e1b8880e88268b024be4c6f106d144b20298d7bb6c4ae09a18bafd0R2703), which will enable us to **remove a lot of action-building methods** scattered through Odoo.
<details><summary><b>Images preview ←←←←← </b></summary>
<p>
Before:
After:
</p>
</details>When importing invoices in UBL/CII XML format, the system now automatically extracts and populates bank account details (account numbers and BIC codes) from the XML file. This eliminates manual data entry and ensures accurate bank information is captured during the invoice import process.
Original PR description
Problem --------- Currently, when importing a UBL/CII xml, the bank account details remain empty while we usually have the bank account number and the BIC code provided in the XML. Objective…
Problem
---------
Currently, when importing a UBL/CII xml, the bank account details remain empty while we usually have the bank account number and the BIC code provided in the XML.
Objective
---------
Autofill the partner_bank_id field on the invoice using the values provided in the UBL/CII XML.
Solution
---------
Currently, UBL XML are organized as such:
PaymentMeans(0..n)
|-PayeeFinancialAccount
|-ID
|-FinancialInstitutionBranch
|-ID
And CII as such:
SpecifiedTradeSettlementPaymentMeans(0..n)
|-PayeePartyCreditorFinancialAccount
| |-IBANID (for SEPA)
| |-ProprietaryID (for national payment)
|
|-PayeeSpecifiedCreditorFinancialInstitution
|-BICID
We first fetch the account numbers from the XML (several may be present) and store them as a list.
This list is sent to the edi_common which will attempt to find one account that match the given values. If none are found, we create one bank account for each piece of bank data found in the xml.
task-3636150
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#152448
Forward-Port-Of: odoo/odoo#147153Resolved issues and error corrections
This fix resolves a display problem in the grid view where concurrent search operations could cause row and column numbering to become misaligned, resulting in gaps between headers and data. The issue occurred when users initiated a new search before the previous one completed. The fix ensures that row and column IDs are properly managed independently for each search operation, preventing numbering conflicts.
Original PR description
Before this commit, when the load is slow and the user does not wait the load method be executed and launches another search, the section, row and column ids could be altered by the both load are currently executed (the current one and the previous one whom is not yet finished). The problem with that is the section, row and column id is a global variable in the file and so the id is incremented by the both loads once a section, row or column is created and so the user could see a big gap between the grid header and his first result displayed because the row id could be for instance 21 instead of 1. This commit fixes the issue by removing the global variable and define the attributes to increment for section, row and column id into `GridDataPoint` to be sure the id will only be incremented by only one load.
This update fixes two issues with UPS shipping integration: it resolves an error when calculating shipping rates for pallet shipments with heavy items, and corrects phone number formatting in API requests by removing spaces. These fixes ensure customers can successfully get accurate shipping quotes when using UPS freight services.
Original PR description
**Steps to reproduce the bug:**
- Configure the ups connector:
- UPS Package Type: UPS Pallet
- UPS Service Type: UPS Worldwide Express Freight
- Package Weight Unit: Kilograms
- Package Size Unit: Centimeters
- Create a French contact
- Create a storable product “P1”:
- Weight: 500 kg
- Create a SO
- Add the product P1
- Add shipping:
- Select UPS
- Get Rate
**Problem:**
A user Error is triggered: “Missing or Invalid Total Number of Pieces in all Pallets in a Shipment."
Phone numbers in the API can't contain space characters: e.g: “+32 465 65 65 65”
opw-3680420
opw-3681186
Forward-Port-Of: odoo/enterprise#55241
Forward-Port-Of: odoo/enterprise#55121This update fixes an issue in the Luxembourg payroll salary rule configuration. The correction ensures that salary calculations for Luxembourg employees are accurate and comply with local payroll requirements. This fix prevents potential payroll processing errors that could affect employee compensation.
This update fixes an issue where certain text content in the bank reconciliation form was not being translated into different languages. The fix reorganizes how the content is structured so that translation tools can properly capture and translate all user-facing text. This ensures users in different countries see the interface in their own language.
Original PR description
Like props, slot params are not translated. This commit moves the content to be translated to a text node, allowing it to be translated. opw-3702748 part of task-3718993
Fixed an issue where repair orders with unpicked parts were not being properly cancelled when the repair was completed. Previously, only automatically picked parts were handled correctly, but parts that remained unpicked would leave orphaned moves in the system. This fix ensures all unpicked parts are now properly cancelled when a repair order is finalized.
Original PR description
Confirming a repair order with parts assign moves quantities. Ending it without any of the picked flags automatically pick them. But ending it with some non-picked parts does not cancel the moves. Now they are. task: 3679247 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users encountered an error when trying to unpack packages in the inventory system. This fix resolves the issue by adjusting how the system handles package unpacking, allowing users to complete this operation without restrictions. This improves the workflow for warehouse and inventory staff managing packaged products.
Original PR description
**Steps to reproduce the bug:** 1. Create a storable product "P1." 2. Create a quant for P1 with a package and apply. 3. Navigate to the package. 4. Attempt to unpack. **Problem:** A user error is triggered: "Quant's editing is restricted; you can't perform this operation." This occurs because when accessing the package from the quant, we are in inventory mode. And as the "package_id" field is on the forbidden list, the error is raised. **Solution:** During the unpacking process, ensure that we are not in inventory mode. opw-3687164 Forward-Port-Of: odoo/odoo#151567 Forward-Port-Of: odoo/odoo#151508
This fix corrects the tax regime classification (clave regimen 02) in the Spanish EDI TBAI module to properly handle exports of goods. The change ensures that export transactions are correctly categorized according to Spanish tax authority requirements, improving compliance with local tax regulations.
Original PR description
…ts of goods 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 update corrects how discounts are calculated in sales analysis reports. Previously, the system was incorrectly summing discount percentages together, which doesn't produce meaningful results. The fix changes the calculation method to use averages instead, which provides more accurate discount information when analyzing sales data, especially when grouping by product.
Original PR description
Summing discount percentages doesn't mean anything. This commit makes sure the operator used to compute discount on group of records is 'average'. It won't always be meaningful, but in some cases, e.g. when the solines only hold one product, and the lines are grouped by product. opw-3649377 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152386 Forward-Port-Of: odoo/odoo#152265
This update fixes a bug in the mail module where removing a record from an assignment would not properly update related records. The fix ensures that when records are added or removed from assignments, all connected records are correctly synchronized. This improves data consistency and prevents users from seeing outdated information.
Original PR description
The opportunity is taken to fix an issue where removing a record from assign would not update the inverse.
Fixed an issue where users clicking the unsubscribe link in marketing emails would see the unsubscribe page in English regardless of their website's language setting. Now the page correctly displays in the website's configured language, providing a better user experience for international customers.
Original PR description
Before: When a user receive a mass_mailing and click on the unsubscribe button, he arrives on the unsubscribe webpage where the first sentence stay in english whatever the website language Step to reproduce: - Create a db with the email marketing and web module - Create a mailing list with at least one recipient - Send the mailing (catch the email with an email catcher, ex: mailhog) - Click on the unsubscribe button Now: The first sentence is in the website (or portal) language opw-3538873 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#142714
Fixed an issue where automation rules that trigger on field changes weren't working until users manually refreshed their browser. The system now properly clears its cache when these rules are created, so the new automation takes effect right away without requiring a page reload.
Original PR description
Create an automation rule for a field for which there's no onchange yet. The rule type is "on_change" (on UI change). This type of automation rule adds an onchange method on the selected fields, which thus involve the onchange mecanism: the "on_change" attribute will be set on that field nodes in views, s.t. when the user changes it, onchange rpcs are done. However, views are cached, and creating such a rule didn't clear the cache. So if the view was already in cache, the rule seemed not to work, because the client still received the old version of the view, without the "on_change" attribute. This commit clears the cache when such a rule is created, s.t. after a client reload, the feature gets enabled as expected. opw 3701125 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 resolves an issue where product ribbon colors could not be properly edited on shop pages. The problem was that default ribbons were using Bootstrap styling classes that prevented custom color changes from being applied. The fix updates the ribbon system to use dedicated color fields instead, allowing users to successfully modify ribbon background and text colors when editing shop pages.
Original PR description
To reproduce ============= - Go to shop page - Edit the page - select a product - add a ribbon - modify the ribbon (background or text color) the ribbon is not updated Problem ======= the default ribbon are using the bootstrap class "text-bg-*" to set the background color and the text color. But the editor expects the ribbon to have a class "bg-*" and color css style. That's why when editing, the class "text-bg-*" is never removed so each time it's taken instead of the added style. Solution ======== remove the class "text-bg-*" from default ribbons and use the fields "bg_color" and "text_color" to set the background and text color opw-3674520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150185