Saturday, July 27, 2024
11 changes · 17.0
Resolved issues and error corrections
The product configurator now displays long attribute names more clearly when creating sales orders with products that have many variants. This prevents important product option details from being squeezed into a fixed space, making order entry easier and less error-prone.
Original PR description
Steps to reproduce: -Create a product. -Add an attribute with a long name. -Add a significant number of variants (around 15-20). -Create a SO with this product. Issue: The attribute name is not easily readable. Cause: The use of the w-lg-25 class sets a fixed width. Fix: Use col-lg-3 to ensure the width adjusts according to the grid system.
This update corrects how certain partner fields are hidden or shown in the Spanish Facturae administration centers feature. It prevents issues caused by outdated view settings, helping the screen behave correctly in supported Odoo versions.
Original PR description
before this commit, wrong invisible conditions were added using attrs, which is already removed after this commit, valid invisible conditions are added --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the audit trail feature from incorrectly blocking the creation of related outgoing emails when they reuse an existing message record. It allows new information to be added when appropriate while still protecting existing message details from being changed.
Original PR description
Since we are using an existing record as `mail_message_id` in `_notify_thread_by_email`, and we need to allow the creation of new `mail.mail` that will add new values to the `mail.message`, as long as it doesn't modify existing values. We are already writing on `subject` only if it was different than previously, but we are not forbidding to write on it only if there was a previous value set.
This fix stops users from duplicating certain inventory-related list entries that can create incorrect reserved quantities and unreliable forecasts. It helps keep stock availability and valuation information accurate by preventing invalid duplicate records from being created through the interface.
Original PR description
### Steps to reproduce: - Enable Multi-step routes - Create a storable product P - Change the on hand quantity to 10 - Create and confirm a delivery order for 4 units of the product - Go back to the…
### Steps to reproduce: - Enable Multi-step routes - Create a storable product P - Change the on hand quantity to 10 - Create and confirm a delivery order for 4 units of the product - Go back to the product form, click the "On hand" smart button - Select the quant line > Actions > duplicate ### Issues: The reserved quantity was copied but this reserved quantity does not match any move reservation. In addition, since you can not have a quant for a product twice in the same location (unless the product is tracked and the lot_ids are different), the two lines will be merged. However, since you can not modify the reserved quantity directly, you will not be able to update it back and you will not be able to correct the forecast by deleting your duplicated line since it does not exist anymore. #### Note: The stock.quant duplication was introduced in 17.0 because of commit 3192051 which enabled the copy action in the list view. Prior to that it was in my knowledge not possible to copy quants from the UI. ### Fix: We introduce a root attribute `duplicate="0"` on the tree view. We also add the other root attributes `duplicate="0"` added by the commit 9f2949d in saas-17.3 to prior versions where they are also needed. opw-4035690 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an installation crash when a company has removed its Outstanding Receipts default account and later installs the Stock app. It ensures accounting setup handles that missing default account cleanly, allowing installation to complete as expected.
Original PR description
### Steps to reproduce: - Start with an empty DB - Install account_accountant - Open settings - Search "Default Accounts" - Clear Outstanding receipts - Save - Go to Apps: Install stock #### >…
### Steps to reproduce: - Start with an empty DB - Install account_accountant - Open settings - Search "Default Accounts" - Clear Outstanding receipts - Save - Go to Apps: Install stock #### > traceback ### Cause of the issue: The "_setup_utility_bank_accounts" method is called during the installation of the stock module. In this call, data about non-existing fields of the "account.account" model are added to the `account_data` dictionary, namely : `prefix` and `code_digits`: https://github.com/odoo/odoo/blob/e80ff1c285ce633a75ce0de5a7cb8d3dcecd301f/addons/account/models/chart_template.py#L702-L708 Since the "Outstanding receipts" account was removed from the settings of the company, it is not removed from the `account_data` here: https://github.com/odoo/odoo/blob/e80ff1c285ce633a75ce0de5a7cb8d3dcecd301f/addons/account/models/chart_template.py#L749-L751 and the datas of these records will be loaded: https://github.com/odoo/odoo/blob/e80ff1c285ce633a75ce0de5a7cb8d3dcecd301f/addons/account/models/chart_template.py#L756-L761 If the records were to be created, it would not be problematic because these datas are popped and used by the override of the `create` method of the `account.account` model: https://github.com/odoo/odoo/blob/e80ff1c285ce633a75ce0de5a7cb8d3dcecd301f/addons/account/models/account_account.py#L701 However, in our case, the record linked to that xml_id already exists and is added to the list of the records to update. A `write` call will then be launched to update the non-existing `account.account` fields leading to the traceback: https://github.com/odoo/odoo/blob/96d98792bb34772e7acc228dd093c56f2f18b483/odoo/models.py#L5045-L5046 opw-4007561 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in Discuss where the marker for unread messages could disappear when the last seen message was deleted. Users will continue to see the correct place where new messages begin, helping them follow conversations without confusion.
Original PR description
**Current behavior before PR:** Issue detected where the new message separator disappears for Admin after Demo deletes message B which is last seen message. **Desired behavior after PR is merged:** Adjusted logic to correctly position the new message separator between messages A and C after message B is deleted by Demo. Task-3826567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves issues with the document management system when users switch between multiple attached files on accounting records. Previously, attachments would disappear or duplicate documents would be created. The fix ensures that when changing which file is the main attachment, the system properly tracks all versions and maintains correct links between documents and accounting records.
Original PR description
Refs. commits message for steps to reproduce COMMIT 1: ---------------- Issue: ------ One attachment has been removed (not linked anymore to the move). Cause: ------ When switching the main…
Refs. commits message for steps to reproduce COMMIT 1: ---------------- Issue: ------ One attachment has been removed (not linked anymore to the move). Cause: ------ When switching the main attachment, the versioning is triggered; the new main attachment is set on the document and the previous is added to the history for versioning (and therefore also change the res fields to be linked to the document instead of the move). Solution: --------- When updating the attachment of a document that already have an attachment (normal versioning), we should remove the link between the current document attachment (not the new one) and the related model only if the related model has not a `message_main_attachment_id` field or if the current document attachment is different of the main attachment set on the related model. COMMIT 2: ---------------- Issue: ------ A second document is created. Cause: ------ The issue is when switching the second time the invoice main attachment, the current main attachment is in fact in the versioned attachments (`document.preview_attachment_ids`), and since we search only for document that have as attachment (`document.attachment_id`) the current invoice main attachment, we don't find it and create a new document. Solution: --------- Look also in the versioned attachments when searching for the invoice main attachment in case it has been versioned. opw-4028789 Forward-Port-Of: odoo/enterprise#67441 Forward-Port-Of: odoo/enterprise#66501
Fixed a bug in the UK tax reports module where removing authentication credentials for one user would incorrectly remove the current system user's credentials instead. This update ensures that when a manager or administrator removes credentials for a specific user, only that user's credentials are cleared, protecting other users' authentication data.
Original PR description
Step to reproduce: - install `l10n_uk_reports` - create 2 user or more - for each user, fill their hmrc token values - select a user different from the current environment user - remove their credential with the button "Remove Authentication Credentials" Current behavior: - The selected user's credential is not removed, but the environment user one got removed Expected behavior: - the selected user's credential should be the one that is removed, and the environment user should not be removed. Why it happens: - In `_clean_tokens` function, it clears the credential of the environment user by default. Solution: - Add way to clear the selected user's credential instead of the environment user's opw-4041604 todo in master: make the user argument required instead of default Forward-Port-Of: odoo/enterprise#66870
This fix corrects an issue where field service tasks were pulling inventory from the wrong warehouse location. Previously, when validating a field service task after a sales order and transfer, the system would incorrectly pull stock from the parent warehouse location instead of the specific shelf location where inventory was actually stored. This fix ensures inventory is always sourced from the correct location, improving order fulfillment accuracy.
Original PR description
Steps to reproduce: 1. Create a product and add stock in the following location: WH/Stock/Shelf 2 2. Create a field service task and add this product 3. validate the task, the transfer will happen from WH/Stock Bug: If you validate the Sale Order, then the transfer, then the field service task, then transfer will happen from WH/Stock/Shelf 2 (as expected) Fix: apply same logic as for serial tracked products opw-3835698 Forward-Port-Of: odoo/enterprise#65316
This fix corrects how partial payments and credit notes are calculated for Mexican invoices in the CFDI (electronic invoice) system. Previously, credit notes were not being deducted when calculating the remaining balance, causing incorrect residual amounts to appear in generated XML files. Now all partial adjustments, including credit notes, are properly accounted for in the payment chain.
Original PR description
…payments
Steps to reproduce:
- Install l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE)
- Create an invoice:
* Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
* Invoice Date: [yesterday]
* Invoice Lines:
- Product: [any product with UNSPSC Category set]
- Price: [any] - Quantity: 2 - Taxes: [any]
- Confirm the invoice
- Generate CFDI via "Send & Print" button
- Create a partial credit note:
* Reversal date: [yesterday]
* Quantity: 1
- Confirm the credit note
- Register Payment:
* Amount: [the remaining amount]
* Payment Way: Efectivo
* Payment Date: [Today]
- Update Payments
- Go to the payment
- Force CFDI
Issue:
In the generated XML file, "ImpSaldoInsoluto" attribute (corresponding to the residual amount) is not 0.00
Cause:
Credit notes are not taken into account during the computation of the payments values.
opw-3857949This fix resolves an issue where customers' selected rental start and end dates were being cleared whenever they changed a product attribute or filter. The system now properly preserves the rental period dates during attribute selection, providing a better user experience when customizing rental products.
Original PR description
version - 16.0 Steps: -Install rental app. -Activate the date picker from the web-editor. -Add the start date and end date from that. -Select some attribute of the product. Issue: -When any user adds the start date and end date from the date picker and after that, the user adds the other attribute(filter) of the product, that selected rental period gets cleared automatically. Cause: -The selected rental period (start and end dates) is not persisted when the page refreshes or updates due to attribute selection. -The input fields for the rental period are not updated properly, causing the dates to be reset. Fix: Extend the '_onChangeAttribute' method to read the start_date and end_date parameters from the URL. Update the hidden input fields for 'start_date' and 'end_date' with the values before applying the attribute changes. opw-3774060 Forward-Port-Of: odoo/enterprise#64962