Saturday, March 30, 2024
7 changes · 17.0
Resolved issues and error corrections
This fix resolves an access error that prevented non-admin users from using the UPS shipping method when creating sales orders. The issue occurred when the system needed to request a new access token to communicate with UPS, which previously required administrator privileges. Now, non-admin users like sales representatives can successfully add UPS delivery options to orders.
Original PR description
follow up to https://github.com/odoo/enterprise/pull/58895 Steps to reproduce: - Install ups_rest - Configure the new ups shipping method as admin - Create an SO and try to add ups delivery as demo - Access error Bug: if a new acces token is requested we need sudo accesn to update the carrier access token opw-3771840 Forward-Port-Of: odoo/enterprise#59811
This fix resolves a system crash that occurred in the Journal Report when processing taxes with distribution lines set to zero percent. The system was attempting a division by zero calculation, which has now been corrected by ignoring zero percent distribution lines. This ensures the accounting reports generate successfully without errors.
Original PR description
The issue: Go to Accounting > Reporting > Journal Report, if you have a tax with a distribution invoice/refund line that has a zero percent line, this will cause a Division By Zero traceback The fix: Ignore the lines with the zero percent opw-3785700 Forward-Port-Of: odoo/enterprise#58444
This fix corrects an issue where non-subscription items added to subscription orders were incorrectly displaying duration information on invoices, making them appear as if they were temporary items to be returned. The fix ensures that duration labels only appear for actual subscription-based items, improving invoice clarity and accuracy.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Create a subscription SO; 2. confirm, invoice, and upsell; 3. on upsell, add a non-subscription item; 4. create invoice. Issue ----- On the invoice, the non-subscription item gets labeled with a duration, as if it's supposed to be returned afterwards. Cause ----- When preparing invoice lines, the conditional checks whether the line has a subscription item, or the order is an upsell. The latter part was added in c8b79afe1bf2971a7ac7709e7165b863969d6a3d to store subscription id, start_date and end_date on upsell invoice lines. Solution -------- Add an additional conditional to format the description, only displaying duration for items that are subscription-based. opw-3687626 Forward-Port-Of: odoo/enterprise#59684 Forward-Port-Of: odoo/enterprise#58303
Fixed a display issue where the operator licence field was not visible in the customer form. The field was positioned incorrectly within a tax information section, making it hidden from users. The field has been repositioned to be properly visible and accessible.
Original PR description
Open customer form view Issue : Name for the field 'l10n_mx_edi_operator_licence' is not visible This occurs because the xpath position the field after the vat which is inside a div made to show the Tax information opw-3819273
This fix restores the intended behavior where only account tags are updated when loading an existing Chart of Accounts, preventing unnecessary updates to other fields like account codes. A recent change had broken this logic, causing the system to attempt updating account codes during upgrades, which led to excessive processing and memory errors. This fix ensures smooth Chart of Accounts updates without performance degradation.
Original PR description
The intended behavior to only update tags and no other fields on existing accounts during CoA loading was originally introduced in https://github.com/odoo/odoo/pull/125320 and has recently been…
The intended behavior to only update tags and no other fields on existing accounts during CoA loading was originally introduced in https://github.com/odoo/odoo/pull/125320 and has recently been broken by commit f2861b9d8d50 (https://github.com/odoo/odoo/pull/155256). This has been recognized because of failing requests in the upgrade platform when it tried to update the `code` field, which lead to excessive recomputations and in turn to MemoryErrors.
The problem is that the tests, if the current `xmlid` constitutes a record update or a new record[^1], need to be correct, no matter if the code above[^2] managed to update the `xmlid` pointer or not. Thus, restore the previous logic regarding that by only assigning the alternative record to the `account` var if it is not None.
[^1]: https://github.com/odoo/odoo/blob/35bb495d5e5a8dac563ba4dee1702d77e4b71461/addons/account/models/chart_template.py#L312
and
https://github.com/odoo/odoo/blob/35bb495d5e5a8dac563ba4dee1702d77e4b71461/addons/account/models/chart_template.py#L314
[^2]: https://github.com/odoo/odoo/blob/35bb495d5e5a8dac563ba4dee1702d77e4b71461/addons/account/models/chart_template.py#L303
Forward-Port-Of: odoo/odoo#159866This update allows users to download electronic invoices (UBL format) even when Peppol configuration details are not set up. Previously, users were blocked from downloading these files if their company or customer was missing Peppol identifiers. Now the system will show a warning banner instead, making the invoicing process more flexible while still alerting users to complete their Peppol setup when needed.
Original PR description
This reverts commit ed651c93ca23c25f7cc3431b62be8f131b3ac9b6. With that commit, the users will have to empty eas/endpoint fields in order to see the checkbox and then they'll see a usererror when trying to download the ubl file. We will fix it differently, showing the checkbox at all times (if edi format is set) and allowing to download the UBL file regardless of the eas/endpoint fields. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159553
A recent fix for XML file creation was causing accounting users (non-administrators) to encounter access errors when registering payments. This update removes unnecessary administrative privileges from an unused attachment, allowing accounting users to complete payment registration without errors.
Original PR description
The issue: A new fix has been introduced to solve the mimtype issue with creating an XML file: https://github.com/odoo/odoo/pull/124507 since the attachment create_uid now is the SUPERUSER_ID, when a user with the accounting role (not admin) tried to register a payment on any account.move type (invoice, credit note...) an access error is thrown The fix: remove the unused attachment as sudo opw-3787008 Forward-Port-Of: odoo/odoo#158881