Daily updates from Odoo
Saturday, November 16, 2024
8 changes
7 changes
Resolved issues and error corrections
This update adds coverage for command-line configuration handling and cleans up related test settings. It helps ensure configuration behavior stays reliable during future changes, with no direct impact on day-to-day users.
Merging account records now also updates saved default values used by company-specific settings. This prevents errors when users open product categories after merged accounts have replaced old records in a multi-company setup.
Original PR description
When merging records that are related to company-dependent fields, we update the company_dependent fields referring the merged records but they are `null` if the user has never set them. Therefore, we need to update the `ir_default` table, which stores the default values. Steps: - Install stock_accountant - Install the CoA on both companies - Select both companies in company selector - Go to charts of accounts and merge 'Stock Valuation accounts' - Go to any Product Category for both companies, we get an error whith one of the companies because we're trying to access a record that has been deleted during the merge opw-4245539
Repair orders that create purchase orders now show the related purchase order immediately, even while it is still in draft. This helps users track purchasing for repair work more reliably and avoids missing links in the repair workflow.
Original PR description
Steps to reproduce the issue: 1. Install the Repair and Purchase modules 2. Activate multi-steps routes 3. Unarchive the MTO route 4. Change the trigger action for the associated rule to 5. Create a…
Steps to reproduce the issue: 1. Install the Repair and Purchase modules 2. Activate multi-steps routes 3. Unarchive the MTO route 4. Change the trigger action for the associated rule to 5. Create a product with the MTO route enabled 6. Create a Repair Order with the line type and include the product 7. Confirm the Repair Order Explanation: A Purchase Order will be created to handle the repair; However, the smart button does not appear at the top of the page. This happens because we are using the wrong linkage from repair to purchase. The current linkage is via , and this field is set when the purchase order confirmed. We need the link to be established when the Purchase Order is in draft state. The fix is to use instead. This commit introduces a minor fix in : -> Ensuring the correct rule is used by relying on instead of searching by name. 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
The Barcode app now shows lot and serial number fields only when they are relevant during manufacturing operations. This prevents confusing empty fields when no product is selected and ensures by-product lines created with a manufacturing order can still capture the needed lot information.
Original PR description
This commit fixes two issues with the `lot_id` field in the move line form view in the Barcode app for the manufacturing operations. 1. The `lot_id` field was displayed when no product was selected. 2. The `lot_id` field was not displayed for by-product lines created at the creation of the MO. The first issue was there because the compute fields to determine if we want to hide `lot_id` and/or `lot_name` were false by default. The second issue was there because those fields depend of the line's picking code which depends of the line's picking type which depend of the line's `production_id`. The issue is by-product lines has no `production_id` set.
This fixes an issue in restaurant PoS where an order item intentionally excluded from the preparation display could reappear after adding another product. The display now tracks individual order lines instead of product types, so kitchen staff see only the items that should actually be prepared.
Original PR description
In the PoS restaurant if you marked a line as skipChange not to send it on the preparation display, then add the same product to the order and send it to the preparation display. At this point…
In the PoS restaurant if you marked a line as skipChange not to send it on the preparation display, then add the same product to the order and send it to the preparation display. At this point everything would be correct, only one of the product would be one the pdis. But if you add another different product and send it to the pdis, it would also bring back the one that was marked as skip change. Steps to reproduce: ------------------- * Setup a preparation display for a PoS restaurant * Open PoS and add product A to the order * Double click on the order line to mark it as skip change * Add the same product to the order and click on the order button * At this point the preparation display should only show one product A * Add another different product B to the order * Click on the order button > Observation: The preparation display shows the product B and a second product A Why the fix: ------------ Instead of filtering based on the product we filter directly based on the line UUID that is unique and should avoid any further errors opw-4322597
The Documents app now opens the "Shared With Me" folder much faster by removing a redundant permission check from the search. This reduces waiting time for users accessing shared documents, improving day-to-day productivity.
Original PR description
Bug === The "Shared With Me" folder is really slow on next.odoo.com. We used "user_permission != none" in the domain, but it's already added by the access rules, and so, that part is computed too much time in SQL. The web_search_read query, on my personal account takes (build of 4 November) - 3600ms before the change - 490ms after the change Task-4307300
Document shortcuts now stay aligned with their target document when access or company ownership changes, preventing users from hitting errors when opening folders. This keeps the Documents app more reliable in shared and multi-company setups without adding costly permission checks.
Original PR description
Commit 1: [FIX] documents: avoid crashes on inaccessible targets Reproduce: 1. Create a shortcut for a document you are shared access to. Say it ends up in My Drive 2. Remove your access to the…
Commit 1: [FIX] documents: avoid crashes on inaccessible targets Reproduce: 1. Create a shortcut for a document you are shared access to. Say it ends up in My Drive 2. Remove your access to the shortcut's target 3. Go to the folder/section (My Drive) where you have the shortcut 4. Experience an Access Error Usually, access rights of a document and its shortcuts is synchronized, so a user can see/edit both or none. This is not the case with ownership as a user can create a shortcut to a document they don't own. If they are allowed to view a shortcut they own when they don't have access to the target anymore, the webclient crashes on loading target data (e.g. to show previews). We tested changing the domain of ownership-related access in user_permission, but it is very costly performance-wise, so this is our best approach in stable as it affects writes but not all reads. Commit 2: Reproduce: 1. Enable Company 1 and 2 2. Create a document with Company 1 3. Create a shortcut for the document. 4. Change document's company to Company 2 6. Only enable Company 1 4. Experience an Access Error See previous commit. Syncing company_id with shortcuts allows to avoid this. A test is included. Task-4236268
1 change
Resolved issues and error corrections
This pull request updates the Arabic translations for key Odoo Enterprise modules, specifically l10n_ar_edi and l10n_ar_reports. These updates ensure the software is correctly localized for Arabic-speaking users, improving the user experience and accuracy of financial and reporting functionalities.
Original PR description
Related to https://github.com/odoo/odoo/pull/187430 Forward-Port-Of: odoo/enterprise#73927