Daily updates from Odoo
Thursday, November 28, 2024
25 changes
2 changes
Resolved issues and error corrections
This update refreshes Odoo's spreadsheet component to the latest 17.2 version and fixes an issue where outdated spread cell relationships could remain after calculations changed. Users should see more reliable spreadsheet behavior with fewer incorrect formula or cell reference results.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/fb1cbd8a8 [REL] 17.2.28 Task: 0 https://github.com/odoo/o-spreadsheet/commit/44b8df597 [FIX] Evaluation: Remove old spreaded cells from spread relations Task: 4342240 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fixes an error that prevented customer invoices from being generated for Saudi companies when Arabic was not installed. The invoice report now uses the correct language lookup for this Odoo version, improving reliability for Saudi localization users.
Original PR description
### Steps to reproduce:
- Install 'l10n_sa' and switch to a Saudi company
- Do not have the Arabic language installed
- try to generate a Customer Invoice
- An error pops up
### Cause:
The way the language is retrieved changed in saas-17.2 from `lang='ar_001'` to `lang=o.env['res.lang']._get_code('ar_001')` The forward port of this [commit](https://github.com/odoo/odoo/commit/f1fa69f6a924a68bad4b10e6854f8caae89b43c3) from 16.0 does not adapt to the way the language is retrieved.
### Solution:
Use the new way to retrieve the language.
opw-430336719 changes
Resolved issues and error corrections
This update fixes several user-facing issues, including website scrolling during animations, lost image edits in email campaigns, recruitment activity display, manufacturing work order timing, and CRM contact suggestions. It also improves performance when updating many billable project tasks and adds a job position activities menu, making common workflows more reliable and efficient.
Original PR description
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
Invoices in the Jordanian e-invoicing flow now get marked for sending when they are confirmed from list actions as well as regular posting screens. This prevents missing e-invoicing status values and helps ensure invoices continue through the required reporting process.
Original PR description
This commit makes changing the `l10n_jo_edi_state` to `to_send` take effect inside _post instead of action_post. Repro steps of the problem before this commit: 1. Create an invoice in draft state. 2. Attempt to post the invoice from list view (Actions -> Confirm Entries) 3. This calls the _post method but not the action_post method, leaving the invoice with no value for `l10n_jo_edi_state` task-3895493 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales users with limited permissions can now send invoices for their own sales orders without needing separate accounting access. This prevents an access error in the invoice sending flow and helps sales teams complete customer billing tasks smoothly.
Original PR description
To reproduce: - Create a user with `Sales / User: Own Documents Only` and no `Accounting` rights - Log-in with that user - Create a Sale Order, add some product and confirm it - Create an invoice for that order, post it and then try to send it => An AccessError is raised: `You are not allowed to access 'Account Move Send Wizard' records.` Salesman record rules where adapted in odoo/odoo@9e769e1b11f2 after the introduction of new 'Send & Print' wizard but not the access rights, which this commit does. opw-4351500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The manufacturing work order list now uses compact icons and improved dropdown actions, making key controls easier to scan and keeping columns better aligned. Blocked work orders are also more visibly flagged, helping users spot issues faster.
Original PR description
- changed the "start", "pause" and "done" button text to icons to be able to set the button column size at a fixed value - moved the unblock button in the dropdown - made the previous block button toggle between block and unblock - change the dropdown bullet to red when blocked
Odoo no longer creates automatic stock batches or waves when the Automatic Batches option is turned off, even if grouping preferences are still selected. This prevents unexpected split receipts and keeps warehouse operations aligned with the configured setting.
Original PR description
Issue ===== When one of the operation type settings for auto-batch/auto-wave is enable, the move lines will be batched even if `auto_batch` is disabled. The options for grouping by contact, product or whatever should be used only to define how we want to batch move lines, but at the end, only "Automatic Batches" option should define if we batch or not. How to reproduce ================ - For receipts' operation type, check "Automatic Batches" and "Wavre Grouping" by "Product"; - Once it's done, uncheck "Automatic Batches"; - Create a PO for two different products and confirm it -> You can see two receipts (one for each product) were created. Solution ======== The method `_is_auto_wave_grouped` defines if we need to group by wave or not. To fix the issue, this method also check `auto_batch`, exactly like `_is_auto_batch_grouped` already does. OPW-4349586
This update refreshes the spreadsheet engine and fixes issues affecting formula results, pyramid chart alignment, and conditional formatting data bars. Users should see more accurate spreadsheet behavior and cleaner visual reporting with no expected workflow changes.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6e043e413 [REL] 18.0.6 Task: 0 https://github.com/odoo/o-spreadsheet/commit/35ca29c01 [FIX] Evaluation: Remove old spreaded cells from spread relations Task: 4342240 https://github.com/odoo/o-spreadsheet/commit/fbe6f9630 [FIX] chart: center pyramid charts vertical axis Task: 4334617 https://github.com/odoo/o-spreadsheet/commit/64c919e9d [IMP] conditional_format: improve CF data bar behavior for non-matching range sizes Task: 4280720 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Avatar loading in messaging was simplified to avoid unnecessary permission checks and expensive searches that could slow down large databases. OdooBot avatars remain available, while some broader avatar access behavior was removed to protect performance and scalability.
Original PR description
Easiest possible simplifications with the best possible performance impact. See individual commit messages.
Products that were previously valued by lot are now updated correctly when their inventory tracking is changed to quantity-based tracking. This prevents receipt validation from being blocked by an outdated lot requirement, helping purchase and inventory flows continue smoothly.
Original PR description
Issue: Cannot validate receipts for products whose tracking changed from lot to quantity. Steps to reproduce: - Install both Inventory & Purchase apps - Create a new product - Track the product's inventory by Lot and set it's valuation by Lot - Set the product's tracking in inventory by quantity - Create a Purchase Order for the product - Confirm the PO - Validate the linked Receipt Cause: Lot valuation is not set to False when changing the tracking of a product from lot to quantity. Solution: Add an onchange on the "[tracking](https://github.com/odoo/odoo/blob/78b8a1670b5272c820f64ef904f4bdf00760031e/addons/stock/models/product.py#L694-L700)" field to update "lot_valuated" to False when **lot_valuated is still True** despite **no tracking being specified**. Ticket: [4345571](https://www.odoo.com/odoo/project/49/tasks/4345571) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Imported sales orders now keep pricing consistent when the incoming purchase order uses a different unit of measure, such as dozens instead of units. This prevents incorrect sale order prices caused by recalculating with the product's default unit instead of the unit on the imported line.
Original PR description
Steps: - Install sale. - Import purchase order file with dozen uom which exist in seller database with unit uom. Issue: - Computed price on sale order is not same as purchase order. Cause: - Having product with unit uom and line with dozen uom will re-compute wrong sale price for line as it'll take uom from product instead of line. Fix: - Avoid re-computing price if matching product does not have same uom set on line Alternative: we can pass uom and quantity in context to properly recompute price same as we pass context in view of SOL. 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
Upgrading certain apps from the Apps screen could fail when the module included a file-exclusion setting in its manifest. This fix reuses existing upgrade records instead of creating duplicates, allowing affected modules such as the construction app to upgrade normally.
Original PR description
When trying to upgrade a module having `cloc_exclude` in its manifest, through the main "Upgrade" button from the Apps list, the installation fails. Steps to reproduce: 1. Install the 'construction' industry app 2. Go to Apps and search for 'construction' 3. Click on the main 'Upgrade' purple button 4. Confirm the upgrade popup Reason: The main 'Upgrade' button is internally calling `_import_zipfile`, this function creates new `ir.model.data` records for xml tags in `idref`. However, when upgrading, we're running this code again, and trying to recreate those records, which fails with a unique id constraint error. Solution: Before creating those records, we now check if they exist, and in that case, we just update their values instead of trying to recreate them. opw-4339886
Clicking Powerbox options such as Button or Link no longer disrupts the editor selection. This ensures the related setup popovers open correctly, helping users insert and configure content without interruption.
Original PR description
**Problem**: When the Powerbox menu is open (triggered by `/`), clicking on a command changes the selection inside the editor to the clicked element. For certain commands (e.g., "Button" or "Link"), this behavior disrupts functionality by preventing the popover from being properly linked to the newly added element (e.g., `<a>` tag), leading to misbehavior. **Solution**: Prevent selection changes when clicking on the Powerbox menu items, This fix aligns with the solution implemented in version 17.0: https://github.com/odoo/odoo/blob/cd989d4bf0cc4cedf43ec1d1d5a652beed105e23/addons/web_editor/static/src/js/editor/odoo-editor/src/powerbox/Powerbox.js#L51 **Steps to reproduce**: 1. Open the editor and trigger the Powerbox using `/`. 2. Click on "Button" or "Link". 3. Observe that no popover appears to configure the button/link. opw-4333891 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a regression where server actions with assigned user groups could be blocked by record write access checks even when the user belonged to the allowed group. Server actions can now perform intended updates for authorized group members, while actions without group restrictions still enforce normal record-level access rules.
Original PR description
If the action server has a group and the current user belongs to it, skip the write access check on the records. This allows the action server to explicitly modify records even when the user lacks the necessary access rights. However, if the model has write access but no group, ensure the access rule check is performed on the record. This is a regression introduced in version 18.0 by PR https://github.com/odoo/odoo/pull/179148 (commit: https://github.com/odoo-dev/odoo/commit/298c96045ecaff6cdd89cf192d5ed3a7eb931e98)
Point of Sale self-service invoicing no longer fails when an order is invoiced without selecting a customer first. The receipt QR code or portal link now opens the invoice request flow correctly, avoiding an internal server error for customers and staff.
Original PR description
Steps to reproduce: ===== - Enable Self-Service Invoicing and select any method for print (i.e. QR Code or URL) - Place an order without selecting a customer and invoice. - On the receipt screen, a receipt with a QR or portal URL is visible. - Scan the QR code or open the portal URL, and enter the necessary details from the receipt. - Click on the Request Invoice button. - 500 Internal Server Error! Cause: ===== - In the account module, the `portal_my_details_fields` template will check the length of a `invoice_sending_method` which is not passed in `ticket_validation_screen`. Fix: ===== - `invoice_sending_method` is passed while rendering the `point_of_sale.ticket_validation_screen`. task: 4360753 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures new items or adjustments added to an active Point of Sale order remain attached when the order is pending. It prevents staff from missing changes, such as global discounts, after returning to the floor screen.
Original PR description
Before this commit, when adding a new line to the order, it wasn't added to the pending order. If you clicked back to the floor screen, you might miss the added line. For example, adding a global discount would be missing in that case. opw-4322621 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheets now handle missing or renamed Odoo models and fields more gracefully in pivots, lists, and related data sources. Instead of showing technical errors or crashing, users see clearer error messages in affected cells and panels, helping them understand that the underlying data source needs attention.
Original PR description
Before this commit, if a pivot have an invalid model (renaming, deletion, ...), some tracebacks were raised (opening the side panel, ...) This commit fixes the issue by handling the case where the pivot model is invalid by showing a clear error in the cell (this commit) and displaying an error in the side panel of the pivot (see enterprise PR) Task: 4280402 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
Fixes an issue where retrying Mexican electronic invoice processing after a Print & Send warning could crash when PAC credentials were missing or incorrect. Users can now retry from the warning flow without encountering the error, improving reliability for invoice handling.
Original PR description
This error occurs when attempting to ``Print & Send`` an invoice using incorrect credentials for the ``Authorized Certification Provider (PAC)`` or if no credentials are provided and you choose to ``Retry`` after receiving the warning. Steps to reproduce: --- - Install ``l10n_mx_edi`` module - Change the company to ``ESCUELA KEMPER URGATE`` - Invoicing > Customers > Invoices > Select an Invoice - ``Print&Send`` (you will face a warning) > CFDI(Notebook page) > Retry Traceback: --- ``TypeError: 'int' object is not iterable`` At [1], we are directly passing the ID of self instead of self. [1]- https://github.com/odoo/enterprise/blob/0f7a4eb991fc59240710c0f8ba78f4da5b889fe6/l10n_mx_edi/models/account_move.py#L1726 sentry-6095574663
Salary payment SEPA files now avoid creating duplicate payment reference lines when the Belgian payroll urgency option is used. This prevents banks from rejecting the generated payment file, helping payroll payments process correctly.
Original PR description
When the `l10n_be_hr_payroll_sepa_salary_payment` context option is passed, an extra `<Ustrd>` gets generated with the Urgency SEPA flag. After the refactoring in odoo/enterprise#60393, when there is no recognized reference type in the default `_get_RmtInf()` generation[^1], we end up with 2 Ustrd elements like this: ```xml <RmtInf> <Ustrd>SPLIP/1234</Ustrd> <Ustrd>/A/ SPLIP/1234</Ustrd> </RmtInf> ``` The SEPA file then gets rejected by banks as invalid. Instead we should detect the pre-existing element and update it. [^1]: https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/account_iso20022/models/account_journal.py#L324-L326
Spreadsheet pivots, lists, charts, and related filter panels no longer crash when their underlying Odoo model has been renamed or deleted. Users now see clear error messages instead, helping them understand the issue and continue working without disruptive tracebacks.
Original PR description
Before this commit, if a pivot have an invalid model (renaming, deletion, ...), some tracebacks were raised (opening the side panel, ...) This commit fixes the issue by handling the case where the pivot model is invalid by showing a clear error in the cell (see community PR) and displaying an error in the side panel of the pivot (this commit) Task: 4280402
Frontdesk kiosk users can now select and see the correct language instead of being reset to the first option. This helps visitors use the kiosk in their chosen language without confusion.
Original PR description
**Steps:** - Install the frontdesk module - Open the frontdesk kiosk mode - Change the language from the language selector --- **Description of the issue/feature this PR addresses:** In kiosk mode, changing the language from the selector doesn’t apply the selected language. Instead, the field displays the first language in the list as the default, preventing the correct display of the chosen language. --- **Cause:** The `_get_additional_info` function modifies the language format from `_` to `-`, which results in the incorrect language display. --- **Fix:** This PR resolves the issue by returning the language directly without calling `py_to_js_locale`, ensuring the correct format and accurate display of the selected language. task-4223597
4 changes
Resolved issues and error corrections
This update fixes a bug preventing invoice cancellations in the Mexican tax system (l10n_mx_edi). The system now correctly handles the SAT status update process, allowing for retries until the customer accepts the cancellation, ensuring invoices can be properly processed and preventing delays.
Original PR description
Improved the cancellation process with the following steps: 1. Generate a customer invoice for 30,000 (or any value that makes the invoice `Cancelable con aceptación`). 2. Wait for the required time for the invoice to become `Cancelable con aceptación`, then initiate the cancellation process. 3. Use the option to update the SAT status on the invoice. In step 3, the SAT status remains `Valid` and in `Cancellation process`. The system must allow retrying the SAT status update until the customer accepts the cancellation. Before this fix, when the SAT status was updated after step 3, it was not possible to cancel the invoice. The button to update the SAT status was not visible, and the cancellation option would not proceed because the process was already in progress.
This update corrects an issue where spreadsheet folders were incorrectly linked to multiple companies, leading to data inconsistencies. The fix ensures that each spreadsheet folder is associated with only one company, resolving a potential conflict and improving data integrity. This change enhances the stability and reliability of the documents management feature.
Original PR description
There are several issues with the company of the folders and the field `documents_spreadsheet_folder_id` of a company. To reproduce the issue 01: 1. Create a second company 2. Documents >…
There are several issues with the company of the folders and the field `documents_spreadsheet_folder_id` of a company. To reproduce the issue 01: 1. Create a second company 2. Documents > Configuration > Workspaces, edit "Spreadsheet": - Set a company Step 01, `documents_spreadsheet_folder_id` of the second company is set to "Spreadsheet" folder thanks to a default value on the field. But, looking at the DB after the second step, there is an error: both companies still have the folder "Spreadsheet" defined on `documents_spreadsheet_folder_id`, but this folder is now specific to one company. Step 2 should not be possible, a constraint is missing. To reproduce the issue 02: 1. Repeat above steps 1-2 2. Create a third company Looking at the DB, there is also an error with the third company: the default value has been used for it, even though the folder is now company-specific and can't be used anymore. The default value should be improved to handle this situation. Also, it should not be possible to use such record on the field. Since there is already the attribute `check_company=True` on `documents_spreadsheet_folder_id`, we could therefore add the attribute `_check_company_auto` on the model and take advantage of the ORM: https://github.com/odoo/odoo/blob/f323896028114acb36848b605732797b67fd7da4/odoo/models.py#L614-L618 However, this change would be too invasive on stable, hence the ORM constraint as alternative. OPW-4281530
This update resolves an issue where bank statement imports with missing data would incorrectly populate fields instead of skipping the incomplete lines. The fix ensures accurate processing of CSV files, preventing data misrepresentation in the bank reconciliation view. This improves data integrity and reduces manual correction needs.
Original PR description
### Steps to reproduce: - In Accounting Dashboard, click on "import file" in the Bank kanban box - Select a CSV file with two missing values on a line, for example: ``` Transaction Type,Bank…
### Steps to reproduce: - In Accounting Dashboard, click on "import file" in the Bank kanban box - Select a CSV file with two missing values on a line, for example: ``` Transaction Type,Bank Reference,Narrative,Debit Amount,Credit Amount TRANSFER,bank_ref_1,bank_statement_line_1,,1000 TRANSFER,,bank_statement_line_2,,3500 ``` (missing `bank_ref_2`) - Complete the Odoo fields: Transaction Type, Reference, Label, Debit, Credit - Import - Go in Accounting Dashboard > Bank Reconciliation and select the list view - `bank_statement_line_2` appears in Reference instead of Label ### Cause: In `_parse_import_data` some line values are added and some are expected to be removed. The values expected to be removed are stored by index but they are removed by value. In this case the index supposed to be removed is 3 but its value is empty like index 1. On the line `line.remove(line[index])` the first occurrence is removed, so index 1 is removed instead of 3. ### Solution: Use `del` to remove by index. opw-4319464 Forward-Port-Of: odoo/enterprise#74512
This update optimizes a key query used to find sale order candidates, resulting in significantly faster performance, especially with large datasets. By changing the query structure, the system now processes these candidates more efficiently, improving overall sales processing speed. This change was driven by performance testing and addresses a bottleneck in the system.
Original PR description
The query in `_get_invoice_matching_so_candidates` will frequently plan a Seq Scan because of the low selectivity of the conditions. And when it does not, the number of rows returned by the CTE is…
The query in `_get_invoice_matching_so_candidates` will frequently plan a Seq Scan because of the low selectivity of the conditions. And when it does not, the number of rows returned by the CTE is expected to high. Because of that, filtering the resulting rows by a sequence of `OR` conditions can quickly become slow. In this commit, the `OR` conditions are replaced by `LIKE(ANY(ARRAY[]))` conditions. That way the CTE is only referenced once in the conditions and applying the filter on each row is way faster. We also discarded duplicated `text_tokens` to reduce the size of the `ARRAY`. The reason why using a `LIKE(ANY(ARRAY[]))` is faster is because postgres inlines the CTE in the outer query. This means that it performs a Seq Scan on sale.order and injects the CTE definition of sub.name inside the `WHERE` conditions of the outer query, along with injecting the `WHERE` conditions of the CTE. So, the regex functions are distributed among the `OR` conditions. I.e. every `OR` condition left operand will contain the regex functions. As those have to be executed for every `OR` condition, this quickly becomes slow. We can explicitely materialize the CTE to avoid that. This makes postgres evaluate the regex functions only once. But it will still have lots of `OR` conditions to check along with running pattern matching for each one of them. `LIKE(ANY(ARRAY[]))` avoids this issue. The CTE is still inlined but since we now only have a single condition, the regex functions are only evaluated once and pattern matched once against an array of options. This makes the whole query faster and scale better. #### speedup Customer database with 808341 sale.orders. Query timing when increasing the number of text tokens. | Number of tokens | Before PR | After PR | |:-------------------:|:----------:|:--------:| | 2 | 7s | 1.3s | | 5 | 10s | 1.3s | | 10 | 18s | 1.4s | | 20 | 33s | 1.55s | opw-4329067 opw-4316765