Daily updates from Odoo
Tuesday, November 25, 2025
267 changes
21 changes
Resolved issues and error corrections
This update fixes an issue where users couldn't find UNSPSC codes by typing partial numbers. The system now allows for partial matching, making it easier to locate and select the correct UNSPSC code when managing products. This enhancement improves the user experience and data accuracy.
Original PR description
**Steps to reproduce:** * Install the **Accounting** and **l10n_mx** modules. * Open any product form view. * Navigate to the **Accounting** tab. * In the *UNSPSC Category* field, start typing a numerical code such as **'10101500'**. **Observed behavior:** * No results are returned, even though the corresponding UNSPSC code exists in the database. **Cause:** * The `_search_display_name` method used an exact match (`=`) on the `code` field, preventing any partial or prefix-based lookup during user input. **Fix:** * Replace the exact-match domain on `code` with a partial match using `ilike`, allowing users to find UNSPSC codes by typing any part of the numerical sequence. opw-5244705 Forward-Port-Of: odoo/enterprise#99651
A recent update caused a bug where changing a journal's currency would erase outstanding account information from payment method lines. This change ensures that account details remain accurate after currency adjustments, particularly when using bank synchronization. This fix prevents financial discrepancies and maintains proper record-keeping.
Original PR description
Changing the currency on a journal triggers the compute of inbound/outbound method lines, which clears the method lines before reasign the default method lines. This leads to the loss of any outstanding account set on the method lines. Steps: - Have a bank journal with outstanding accounts set on the payment method lines - Change the currency (in our case, this is the bank sync that changed the currency of the journal) -> Outstanding accounts are missing on the payment method lines, even if the accounts currency is the same as the journals or no currency is set on the accounts. opw-5175794 Forward-Port-Of: odoo/odoo#234008
This update resolves an error that occurred when automatically cleaning up withhold data. The issue stemmed from a technical limitation in how the system handles temporary 'Withhold' records linked to related data. The fix ensures a smoother cleanup process without disrupting normal operations.
Original PR description
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** *…
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** * Install `l10n_ec_edi` and change company to `EC company` * Create invoice with customer `EC Company` > Set Payment Method (SRI) > Confirm * Add Withhold > Document number: `001-001-123456789` > Add lines > Create & Post * Set system time to future date > Run `Base: Auto-vacuum internal data`. Refer video [1] for replication steps. **Error:** `psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line' ` **Root cause:** * The error happens because Withhold Wizard [2] is a transient model that gets cleaned up by function [3] after reaching its max hours. * However, since [2] is linked to Withhold Wizard Lines [4], the cleanup fails, causing the error. **Solution:** * Unlink the lines first and then unlink the wizard. [1]: https://drive.google.com/file/d/1HethT8tpa3Ez0uwueUuKzW4F7KxEKOv_/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/2275fe560d5db0b5a21ffbc4d4c66264e4e12601/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L20 [3]: https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7465-L7497 [4]: https://github.com/odoo/enterprise/blob/7ca0635d4c479a956bfae8fb60da8b50362fd99b/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L423-L427 sentry-6253783256 Forward-Port-Of: odoo/enterprise#99653
This update resolved a bug where the 'whiteboard pen' product wasn't appearing on the product screen or in tour tests. By assigning the same product category as the main POS configuration, the product now correctly loads and displays, ensuring a smooth user experience.
Original PR description
Before this commit: ======================= The `whiteboard_pen` product had no assigned category, while the main POS configuration was limited to specific categories. As a result, `whiteboard_pen` was not displayed on the product screen. When no products were loaded, special products like gift cards and e-wallets also not shown,showing the `Load Sample` button instead of products. This caused tour tests expecting gift cards on the screen to fail. After this commit: ====================== Assigned the same product category to whiteboard_pen as used in the POS configuration. This ensures that the product appears on the product screen and special products like gift cards also load properly, preventing the tour test from failing. Runbot Error: 233434, 233435 Forward-Port-Of: odoo/odoo#233563
This update prevents a bug where the 'Unfollow' button appeared when a portal user opened a shared project with a new, unsaved task. The fix ensures the button is hidden until the task is saved, improving the user experience and preventing errors.
Original PR description
Currently, an error occurs when a portal user opens a shared project and clicks the `Unfollow` button in the chatter of a `new(unsaved)` task. **Steps to produce:** - Install the `project` module. -…
Currently, an error occurs when a portal user opens a shared project and clicks the `Unfollow` button in the chatter of a `new(unsaved)` task. **Steps to produce:** - Install the `project` module. - Open the project app and create a new project with at least one task. - From the project’s `dropdown menu(⋮)`, select `Share Project`. - Add a `collaborator: Joel Willis`, with `Edit access mode`, copy the `public link`, and click `Share Project`. - Open the shared link in an incognito window and sign in as a `portal user`. - Open the project folder > open any task > click `New` > click `Unfollow` button. **Error**: `ValueError: Expected singleton: project.task()` **Root cause:** The Unfollow button at [1], is displayed even when the task record is not yet saved (`props.threadId` is `undefined`). At [2], the method is called on an empty recordset, causing an `error`. **Fix:** This commit prevents the error by ensuring the `Unfollow` button is hidden when the record is `unsaved`. [1]: https://github.com/odoo/odoo/blob/be138ef2ff1b3a83f77fe300f789d754ed3383fd/addons/project/static/src/project_sharing/chatter/portal_chatter_patch.xml#L7-L14 [2]: https://github.com/odoo/odoo/blob/be138ef2ff1b3a83f77fe300f789d754ed3383fd/addons/project/models/project_task.py#L2022 No task ID Forward-Port-Of: odoo/odoo#236633
This update addresses an issue where pressing Backspace within an empty blockquote would unexpectedly remove the entire Table of Contents. The change ensures that an empty blockquote is now converted into a standard container when Backspace is pressed, maintaining the integrity of the document structure. This improves the user experience and prevents data loss.
Original PR description
### Steps to reproduce: - Create a new Project task. - Insert a Table of Contents (e.g., /tableofcontent). - Insert a quote below it (e.g., /blockquote). - Place the cursor at the start of the empty quote and press Backspace. - The Table of Contents is removed. ### Desired behavior after PR is merged: - Empty blockquote is converted into a base container when backspace is pressed. task-5246130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235087
This update resolves a memory issue that occurred when processing invoices for the Serbian EDI system (l10n_rs_edi). By proactively retrieving country codes, the system now avoids running out of memory, ensuring smoother and faster invoice processing. This improves the overall efficiency of the system when handling RS-specific transactions.
Original PR description
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in…
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in memory records ``` sagu_3267671=> select count(id) from account_move; count --------- 1034179 (1 row) ``` ``` File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine return needle(*args) File "/home/odoo/src/odoo/17.0/addons/l10n_rs_edi/models/account_move.py", line 85, in _compute_l10n_rs_edi_is_eligible move.l10n_rs_edi_is_eligible = move.country_code == 'RS' and move.is_sale_document() and move.l10n_rs_edi_state in (False, 'sending_failed') File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__ self.compute_value(recs) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value records._compute_field_value(self) File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine return needle(records, *args) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp> values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__ return self._fields[key].__get__(self, self.env.registry[self._name]) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__ return super().__get__(records, owner) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__ recs._fetch_field(self) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field self.fetch(fnames) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch fetched = self._fetch_query(query, fields_to_fetch) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query self.env.cache.insert_missing(fetched, field, values) File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing field_cache.setdefault(id_, val) MemoryError ``` upg-3267671 opw-5246681 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235919
This update fixes an issue where the HTML editor would create unnecessary empty elements after processing FEFF characters. This change ensures the editor's stability and prevents potential performance problems by cleaning up the underlying HTML structure. The fix improves the overall user experience by removing these lingering elements.
Original PR description
Steps to Reproduce: - Create a link in the editor (e.g., "abc"). - Select all and change the font size from 14 to 80. - Two empty tags are created before and after the formatted <span><a></a></span> with only FEFF Characters. - Change the font size again (e.g., back to 14). - Multiple empty tags remain in the DOM. Description of the issue this PR addresses: - In the removeFeffs method, FEFF characters are replaced with empty text nodes, which can lead to unwanted empty elements and empty text nodes being left in the DOM. Desired behavior after PR is merged: - Empty text nodes resulting from FEFF replacement are now properly removed, preventing leftover empty elements in the DOM. task-5097770 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233909
In the Peru UBL, adding a reference to a partner would cause an error from the OSE (code 3090). This was because the call to super in _get_partner_party_identification_vals_list would add the partner.ref as an ID, which is incorrect in the Peruvian context. Removed the call to super which did not bring any other information. ticket-5193233 Forward-Port-Of: odoo/enterprise#100043
Original PR description
In the Peru UBL, adding a reference to a partner would cause an error from the OSE (code 3090). This was because the call to super in _get_partner_party_identification_vals_list would add the partner.ref as an ID, which is incorrect in the Peruvian context. Removed the call to super which did not bring any other information. ticket-5193233 Forward-Port-Of: odoo/enterprise#100043
## Issue 1: In this issue, active/inactive filter is not working correctly. #### To reproduce: 1- Install `Sale` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a loyalty program 4- Create a `Loyalty Card` for the program 5- Archive the card 6- In search, click on `inactive` filter As you see, you can't find the archived card. ### Cause: This is caused due to setting the filter on `program_id.active` rather than `loyalty_card.active`. ## Issue 2:
Original PR description
## Issue 1: In this issue, active/inactive filter is not working correctly. #### To reproduce: 1- Install `Sale` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a…
## Issue 1: In this issue, active/inactive filter is not working correctly. #### To reproduce: 1- Install `Sale` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a loyalty program 4- Create a `Loyalty Card` for the program 5- Archive the card 6- In search, click on `inactive` filter As you see, you can't find the archived card. ### Cause: This is caused due to setting the filter on `program_id.active` rather than `loyalty_card.active`. ## Issue 2: In this bug, earned points on archived loyalty can be used to claim rewards. #### To reproduce: 1- Install `Sale` and `Ecommerce` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a loyalty program 4- Add a rule to grant 10 points per order 5- Apply a reward in exchange of 10 points 6- Create a `Loyalty Card` for the admin with 0 points. 7- In Ecommerce, add a product to your cart 8- Remove the product from the cart 9- Archive the loyalty card created for the admin 10- In Ecommerce, add another product to cart 11- As you see, you still can use the loyalty card ### Cause: When a product is first added to the cart, a `sale.order.coupon.points` record is created to grant points. Even if the cart is later emptied, the created `coupon_point_id` still exists. After the loyalty card is archived, points are still granted to this existing `coupon_point_id`, allowing it to be used to claim rewards. To prevent this, we can unlink points from draft sale order when the card is archived. opw-5166696 Forward-Port-Of: odoo/odoo#233645
Bug: In Belgium, after 30 calendar days of sick leave, all public holidays during the sick leaves are no longer paid. But here they were still being paid. Cause: The method that was checking what to do about public holidays was never seeing public holidays since they were already changed to their corresponding work entries at the work entry generation. Fix: Add the public holidays in the context and change the condition for checking if the current leave is actually from a public holiday
Original PR description
Bug: In Belgium, after 30 calendar days of sick leave, all public holidays during the sick leaves are no longer paid. But here they were still being paid. Cause: The method that was checking what to do about public holidays was never seeing public holidays since they were already changed to their corresponding work entries at the work entry generation. Fix: Add the public holidays in the context and change the condition for checking if the current leave is actually from a public holiday or not. Task: 3864585 Forward-Port-Of: odoo/enterprise#98496 Forward-Port-Of: odoo/enterprise#95178
Before this PR: - Sending invoice/vendor bill to eTIMS would send null item codes if products weren't registered. - `View Product(s)` button in validation messages opened standard product variant view with generic product fields instead of eTIMS-specific fields. - When sending multiple invoices via batch processing, product registration used incorrect company context (in `self.env.company`) instead of the specific invoice's company, causing products to be registered to the wrong c
Original PR description
Before this PR: - Sending invoice/vendor bill to eTIMS would send null item codes if products weren't registered. - `View Product(s)` button in validation messages opened standard product variant view with generic product fields instead of eTIMS-specific fields. - When sending multiple invoices via batch processing, product registration used incorrect company context (in `self.env.company`) instead of the specific invoice's company, causing products to be registered to the wrong company's eTIMS system. After this PR: - Products are automatically registered with eTIMS before sending invoices/vendor bills. - `View Product(s)` button now opens custom `l10n_ke_kra_product_tree` view with eTIMS-specific fields. - Product registration now properly uses the invoice's company context (`move.company_id`) ensuring products are registered to the correct company's eTIMS system in multi-company scenarios. Task-5039671 Forward-Port-Of: odoo/enterprise#93375
This update resolves an issue where the 'Export ZIP' option on customer invoices was unavailable and resulted in a blank page when the invoice hadn't been sent. The fix ensures that this functionality is only displayed for invoices that have been successfully processed and sent, improving usability.
Original PR description
**Steps to reproduce:** * Install the *Accounting* module. * Create a customer invoice. * Post the invoice. * Click the *gear* icon → **Print** → **Export ZIP**. * Observe that the invoice opens a blank page. **Issue:** * Clicking **Export ZIP** on an unsent invoice opens a blank page. **Cause:** * The `account.move.send` model returns an empty dataset when the invoice is not sent, leading to an empty export result. **Fix:** * Add a condition to display **Export ZIP** only when the invoice has been sent. --- opw-5245483 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the price displayed in Point of Sale (PoS) was incorrect when using non-groupable units of measure. The fix ensures that the correct price unit is applied during order settlement, leading to accurate pricing calculations for products with these UoMs. This improves the reliability of PoS transactions.
Original PR description
Steps to reproduce ------------------ 1. Create a product with a UoM that is non groupable in PoS 2. Make a sale order with that product having a UoM that is based on the UoM of the first steps. If…
Steps to reproduce ------------------ 1. Create a product with a UoM that is non groupable in PoS 2. Make a sale order with that product having a UoM that is based on the UoM of the first steps. If the UoM in the first step was Kg for intsance, use Gram (g) here. 3. Confirm the order, and settle it in PoS. Notice that the price of that order in PoS is not correct. Why it's happening ------------------ When settling the PoS order, we first convert the sale_order's line UoM (g) to the original product UoM (kg), and we update the quantity accordingly (in this example by dividing by 1000). https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L94-L96 So this step updates both the qty and the unit_price. https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L160-L161 However, when the UoM is not groupable, we split the lines by taking into consideration the updated qty, but we still use the old price_unit, which creates an inconsitency and wrong calculations. The fix ------- When splitting the lines, we're just supposed to change the qty per line to max 1, but we're not supposed to change the price per unit for this qty. We now use the updated `price_unit` to have a correct math. opw-5232571 Forward-Port-Of: odoo/odoo#237172 Forward-Port-Of: odoo/odoo#236008
This update fixes an issue where tax return amounts were incorrectly calculated for section reports, specifically in the LU tax return. The change ensures the correct return periodicity is used by retrieving the return type from the section source, resolving a discrepancy between the main report and the section report.
Original PR description
We have some reports with sections, like l10n_lu generic tax return.
Since account.return are born, when submitting the lu tax return, the periodicity is wrongly
computed, because of the self in `_init_options_return_periodicity` is the section report, not the main,
but the account.return.type is set with report_id = main report
Step to reproduce:
With a LU company:
1. Create a journal entry for a previous period
2. Submit the tax return for the same period
3. The amount shown is the amount of the current month
Solution: use options['sections_source_id'] to fetch the return_type instead of self.return_type_ids
opw-5163352
Forward-Port-Of: odoo/enterprise#100063This update corrects a technical problem where unregistering a Nemhandel user caused it to be lost within the system's user database. Previously, attempting to manually unregister a user resulted in an error. This fix ensures that Nemhandel users are correctly managed and tracked, preventing data loss and operational issues.
Original PR description
If you unregister a Nemhandel user, it won't ever be picked up by the user db. And trying to unregister by hand will give a traceback. This is due to mismatch between Exception types. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236670
This update fixes an issue where the SAFT report incorrectly assigned the supplier's receivable account to customers. The fix ensures customers are correctly identified with their receivable account, resolving a reporting discrepancy. This improves the accuracy of SAFT reports.
Original PR description
### Issue: In the SAFT report both the Customer and the Supplier have the same account. ### Cause: In the XML there was probably a typo and both have `property_account_payable_id` as account. ### Solution: For the `Customers` node, use `property_account_receivable_id`. opw-5144009 Forward-Port-Of: odoo/enterprise#99196
This update fixes an issue where a product valued by lot would incorrectly use the average value instead of 0 when a lot was specified with a value of 0. This ensures accurate stock valuation calculations, particularly when starting with a lot that has no initial standard price. The change improves the reliability of inventory tracking.
Original PR description
**Problem:** when selling a product valued by lot and chosing a lot with a value of 0 the average value of the product is used instead of 0. **Steps to reproduce:** - make sure your warehouse is in…
**Problem:**
when selling a product valued by lot
and chosing a lot with a value of 0
the average value of the product
is used instead of 0.
**Steps to reproduce:**
- make sure your warehouse is in single step receipt and delivery
- create a product tracked by lot and valued by lot
- set the category as avco
- create a PO for a quantity of 10 and a unit price of 10
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot A" in the lot column and save
- validate
- create a PO for a quantity of 10 and a unit price of 0
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot B" in the lot column and save
- validate
- create a quotation for 1 quantity of your product
- confirm
- open the delivery
- open the stock move widget on the stock move
- in the 'pick from' column enter lot B and save
- validate
- open the valuation smart button
**Current behavior:**
the value of the stock valuation layer is -5
**Expected behavior:**
it should be 0
**Cause of the issue:**
Inside _prepare_out_svl_vals
lot.standard_price is 0 so the if condition
is false and we don't use the price of the lot
https://github.com/odoo/odoo/blob/cd2a241182cf56fc36d03df9f0afdcea30f682d2/addons/stock_account/models/product.py#L277
**fix:**
deleting the lot.standard_price condition
is not possible because when the lot is created
at delivery it has no standard_price and in this
case we want to use the standard_price of the
product.
(see test https://github.com/odoo/odoo/blob/d3835668349d466ed4ba27c9eacdbd3339f2ac37/addons/stock_account/tests/test_lot_valuation.py#L58)
opw-5077671
Forward-Port-Of: odoo/odoo#234764This update resolves an issue where stopping ringtone playback triggered unwanted HTTP requests to '/null'. The fix resets the element's source using removeAttribute, streamlining the process and improving performance. This ensures a smoother user experience for ringtone functionality.
Original PR description
Setting the src of an element to null triggers a GET HTTP request to /null. This is not the intended behavior; we want to reset the source so that it is not linked to any file, but the browser interprets it as an attempt to load a file called "null". This commit fixes the problem by resetting the source using removeAttribute instead. [Task-5349985](https://www.odoo.com/odoo/project/5778/tasks/5349985) Forward-Port-Of: odoo/enterprise#100146
This update fixes a bug where composite reports weren't consistently applying filters. Now, enabling a filter on a composite report will automatically enable it on its individual sections, ensuring accurate and complete report results. This aligns with standard Odoo reporting practices and improves user experience.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237003 Forward-Port-Of: odoo/odoo#236893
This update ensures that filters applied to composite reports consistently work across all sections within those reports. Previously, some filters weren't displayed correctly, leading to inconsistent reporting. This change aligns with standard Odoo reporting practices for filter behavior.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. Forward-Port-Of: odoo/enterprise#100240 Forward-Port-Of: odoo/enterprise#100148
17 changes
Resolved issues and error corrections
A recent update caused outstanding account information to disappear from payment method lines when a journal's currency was changed. This was due to how the system recomputes method lines after currency adjustments. This fix ensures that account details remain accurate, preventing financial discrepancies.
Original PR description
Changing the currency on a journal triggers the compute of inbound/outbound method lines, which clears the method lines before reasign the default method lines. This leads to the loss of any outstanding account set on the method lines. Steps: - Have a bank journal with outstanding accounts set on the payment method lines - Change the currency (in our case, this is the bank sync that changed the currency of the journal) -> Outstanding accounts are missing on the payment method lines, even if the accounts currency is the same as the journals or no currency is set on the accounts. opw-5175794 Forward-Port-Of: odoo/odoo#234008
This update resolves an issue where closing Studio resulted in a technical error. The fix ensures that POS-specific views are correctly loaded, allowing users to enable and disable the Kanban view within Studio without encountering the 'pos_kanban' key error. This improves Studio's stability and usability.
Original PR description
**Steps to reproduce:** * Install the *pos_appointment* and *web_studio* modules. * Open **Appointments → Schedule → Resource Booking**. * Activate Studio. * In Studio, open the **Views** panel and enable the **Kanban** view. * Attempt to close Studio; a traceback occurs. **Observed behavior:** * Closing Studio triggers a traceback: *'Cannot find key 'pos_kanban' in the 'views' registry'.* **Cause:** * POS-specific views are not loaded in the **web.assets_backend** bundle, so the backend environment cannot register the required `pos_kanban` view when Studio activates it. **Fix:** * Load the necessary POS assets in the backend bundle to ensure POS views are registered and available when Studio try to load them. --- opw-5186459
This update resolves an error that occurred when the system automatically cleaned up data related to withhold taxes. The issue stemmed from a technical limitation with how the system linked the Withhold Wizard to its associated lines, causing a database error. The fix ensures a smoother and more reliable cleanup process.
Original PR description
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** *…
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** * Install `l10n_ec_edi` and change company to `EC company` * Create invoice with customer `EC Company` > Set Payment Method (SRI) > Confirm * Add Withhold > Document number: `001-001-123456789` > Add lines > Create & Post * Set system time to future date > Run `Base: Auto-vacuum internal data`. Refer video [1] for replication steps. **Error:** `psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line' ` **Root cause:** * The error happens because Withhold Wizard [2] is a transient model that gets cleaned up by function [3] after reaching its max hours. * However, since [2] is linked to Withhold Wizard Lines [4], the cleanup fails, causing the error. **Solution:** * Unlink the lines first and then unlink the wizard. [1]: https://drive.google.com/file/d/1HethT8tpa3Ez0uwueUuKzW4F7KxEKOv_/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/2275fe560d5db0b5a21ffbc4d4c66264e4e12601/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L20 [3]: https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7465-L7497 [4]: https://github.com/odoo/enterprise/blob/7ca0635d4c479a956bfae8fb60da8b50362fd99b/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L423-L427 sentry-6253783256 Forward-Port-Of: odoo/enterprise#99653
This update prevents a bug where the 'Unfollow' button appeared when a portal user opened a shared project with a new, unsaved task. The fix ensures the button is hidden until the task is properly saved, improving the user experience and preventing errors.
Original PR description
Currently, an error occurs when a portal user opens a shared project and clicks the `Unfollow` button in the chatter of a `new(unsaved)` task. **Steps to produce:** - Install the `project` module. -…
Currently, an error occurs when a portal user opens a shared project and clicks the `Unfollow` button in the chatter of a `new(unsaved)` task. **Steps to produce:** - Install the `project` module. - Open the project app and create a new project with at least one task. - From the project’s `dropdown menu(⋮)`, select `Share Project`. - Add a `collaborator: Joel Willis`, with `Edit access mode`, copy the `public link`, and click `Share Project`. - Open the shared link in an incognito window and sign in as a `portal user`. - Open the project folder > open any task > click `New` > click `Unfollow` button. **Error**: `ValueError: Expected singleton: project.task()` **Root cause:** The Unfollow button at [1], is displayed even when the task record is not yet saved (`props.threadId` is `undefined`). At [2], the method is called on an empty recordset, causing an `error`. **Fix:** This commit prevents the error by ensuring the `Unfollow` button is hidden when the record is `unsaved`. [1]: https://github.com/odoo/odoo/blob/be138ef2ff1b3a83f77fe300f789d754ed3383fd/addons/project/static/src/project_sharing/chatter/portal_chatter_patch.xml#L7-L14 [2]: https://github.com/odoo/odoo/blob/be138ef2ff1b3a83f77fe300f789d754ed3383fd/addons/project/models/project_task.py#L2022 No task ID Forward-Port-Of: odoo/odoo#236633
This update addresses an issue where pressing Backspace within a blank blockquote would unexpectedly delete the entire Table of Contents. The change now converts an empty blockquote into a standard container when Backspace is pressed, ensuring the Table of Contents remains intact and the editor functions as expected. This improves the user experience and prevents data loss.
Original PR description
### Steps to reproduce: - Create a new Project task. - Insert a Table of Contents (e.g., /tableofcontent). - Insert a quote below it (e.g., /blockquote). - Place the cursor at the start of the empty quote and press Backspace. - The Table of Contents is removed. ### Desired behavior after PR is merged: - Empty blockquote is converted into a base container when backspace is pressed. task-5246130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235087
This update resolves a memory issue that occurred when processing sales documents in the RS (Romania) region. The fix pre-fetches key data, preventing the system from running out of memory and improving processing speed for these documents. This ensures smoother and more reliable EDI processing for our customers in Romania.
Original PR description
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in…
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in memory records ``` sagu_3267671=> select count(id) from account_move; count --------- 1034179 (1 row) ``` ``` File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine return needle(*args) File "/home/odoo/src/odoo/17.0/addons/l10n_rs_edi/models/account_move.py", line 85, in _compute_l10n_rs_edi_is_eligible move.l10n_rs_edi_is_eligible = move.country_code == 'RS' and move.is_sale_document() and move.l10n_rs_edi_state in (False, 'sending_failed') File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__ self.compute_value(recs) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value records._compute_field_value(self) File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine return needle(records, *args) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp> values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__ return self._fields[key].__get__(self, self.env.registry[self._name]) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__ return super().__get__(records, owner) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__ recs._fetch_field(self) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field self.fetch(fnames) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch fetched = self._fetch_query(query, fields_to_fetch) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query self.env.cache.insert_missing(fetched, field, values) File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing field_cache.setdefault(id_, val) MemoryError ``` upg-3267671 opw-5246681 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235919
#### Issue: The Swissdec test suite was failing during setup with the following error: ``` ValueError: External ID not found: product.group_product_manager KeyError: False ``` #### Root cause: The Swissdec test setup tried to access a standard `product` group, but the `product` module wasn’t installed in the test DB (because no dependencies were declared that would install it). This left the test environment incomplete and caused the XML ID lookup to fail. #### Fix: Add `accou
Original PR description
#### Issue:
The Swissdec test suite was failing during setup with the following error:
```
ValueError: External ID not found: product.group_product_manager
KeyError: False
```
#### Root cause:
The Swissdec test setup tried to access a standard `product` group, but the `product` module wasn’t installed in the test DB (because no dependencies were declared that would install it). This left the test environment incomplete and caused the XML ID lookup to fail.
#### Fix:
Add `account` to the dependencies so that `product` is installed automatically and the required XML ID is available during test setup.
[RB-234176](https://runbot.odoo.com/odoo/error/234176/runbot.build.error/234176)Steps to reproduce ------------------ 1. Create a product with a UoM that is non groupable in PoS 2. Make a sale order with that product having a UoM that is based on the UoM of the first steps. If the UoM in the first step was Kg for intsance, use Gram (g) here. 3. Confirm the order, and settle it in PoS. Notice that the price of that order in PoS is not correct. Why it's happening ------------------ When settling the PoS order, we first convert the sale_order's line UoM (g
Original PR description
Steps to reproduce ------------------ 1. Create a product with a UoM that is non groupable in PoS 2. Make a sale order with that product having a UoM that is based on the UoM of the first steps. If…
Steps to reproduce ------------------ 1. Create a product with a UoM that is non groupable in PoS 2. Make a sale order with that product having a UoM that is based on the UoM of the first steps. If the UoM in the first step was Kg for intsance, use Gram (g) here. 3. Confirm the order, and settle it in PoS. Notice that the price of that order in PoS is not correct. Why it's happening ------------------ When settling the PoS order, we first convert the sale_order's line UoM (g) to the original product UoM (kg), and we update the quantity accordingly (in this example by dividing by 1000). https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L94-L96 So this step updates both the qty and the unit_price. https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L160-L161 However, when the UoM is not groupable, we split the lines by taking into consideration the updated qty, but we still use the old price_unit, which creates an inconsitency and wrong calculations. The fix ------- When splitting the lines, we're just supposed to change the qty per line to max 1, but we're not supposed to change the price per unit for this qty. We now use the updated `price_unit` to have a correct math. opw-5232571 Forward-Port-Of: odoo/odoo#237172 Forward-Port-Of: odoo/odoo#236008
## Issue 1: In this issue, active/inactive filter is not working correctly. #### To reproduce: 1- Install `Sale` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a loyalty program 4- Create a `Loyalty Card` for the program 5- Archive the card 6- In search, click on `inactive` filter As you see, you can't find the archived card. ### Cause: This is caused due to setting the filter on `program_id.active` rather than `loyalty_card.active`. ## Issue 2:
Original PR description
## Issue 1: In this issue, active/inactive filter is not working correctly. #### To reproduce: 1- Install `Sale` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a…
## Issue 1: In this issue, active/inactive filter is not working correctly. #### To reproduce: 1- Install `Sale` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a loyalty program 4- Create a `Loyalty Card` for the program 5- Archive the card 6- In search, click on `inactive` filter As you see, you can't find the archived card. ### Cause: This is caused due to setting the filter on `program_id.active` rather than `loyalty_card.active`. ## Issue 2: In this bug, earned points on archived loyalty can be used to claim rewards. #### To reproduce: 1- Install `Sale` and `Ecommerce` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a loyalty program 4- Add a rule to grant 10 points per order 5- Apply a reward in exchange of 10 points 6- Create a `Loyalty Card` for the admin with 0 points. 7- In Ecommerce, add a product to your cart 8- Remove the product from the cart 9- Archive the loyalty card created for the admin 10- In Ecommerce, add another product to cart 11- As you see, you still can use the loyalty card ### Cause: When a product is first added to the cart, a `sale.order.coupon.points` record is created to grant points. Even if the cart is later emptied, the created `coupon_point_id` still exists. After the loyalty card is archived, points are still granted to this existing `coupon_point_id`, allowing it to be used to claim rewards. To prevent this, we can unlink points from draft sale order when the card is archived. opw-5166696 Forward-Port-Of: odoo/odoo#233645
This update automatically registers products with eTIMS before invoices are sent, ensuring accurate data transmission. It also fixes the display of product information, now using the correct eTIMS-specific fields and ensuring proper registration across multiple companies. This improves compliance and data accuracy for Kenyan e-invoicing.
Original PR description
Before this PR: - Sending invoice/vendor bill to eTIMS would send null item codes if products weren't registered. - `View Product(s)` button in validation messages opened standard product variant view with generic product fields instead of eTIMS-specific fields. - When sending multiple invoices via batch processing, product registration used incorrect company context (in `self.env.company`) instead of the specific invoice's company, causing products to be registered to the wrong company's eTIMS system. After this PR: - Products are automatically registered with eTIMS before sending invoices/vendor bills. - `View Product(s)` button now opens custom `l10n_ke_kra_product_tree` view with eTIMS-specific fields. - Product registration now properly uses the invoice's company context (`move.company_id`) ensuring products are registered to the correct company's eTIMS system in multi-company scenarios. Task-5039671 Forward-Port-Of: odoo/enterprise#93375
This update resolves an issue in the Odoo Enterprise Peru UBL export that was causing errors due to an incorrect partner reference. The fix removes a problematic code addition, ensuring the UBL XML conforms to Peruvian regulations and avoids export failures. This improves the reliability of our Peru-specific accounting reports.
Original PR description
In the Peru UBL, adding a reference to a partner would cause an error from the OSE (code 3090). This was because the call to super in _get_partner_party_identification_vals_list would add the partner.ref as an ID, which is incorrect in the Peruvian context. Removed the call to super which did not bring any other information. ticket-5193233 Forward-Port-Of: odoo/enterprise#100043
This update resolves an issue where CFE PDFs weren't being generated correctly after invoice creation and CFE generation in Uruguay. The fix ensures that the PDF from Uruway is consistently linked to the invoice, addressing a gap in the automated CFE process. This improves the accuracy and completeness of invoice documentation.
Original PR description
### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the…
### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the Settings change 'UCFE Web Services' to 'Testing' and input credentials - Create a new invoice, confirm and send, click 'Generate CFE' - The CFE status is accepted but the PDF from Uruware is not on the record ### Cause: This [commit](https://github.com/odoo/enterprise/commit/726ebfe7c6266b7e54d8b2716983e62eb3142a81) changed how `l10n_latam_document_number` is computed: it's no longer related to `move_id.l10n_latam_document_number` but computed when `move_id` is set. In our case `move_id.l10n_latam_document_number` is [set in `_l10n_uy_edi_send()`](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/account_move.py#L837-L839) but as `move_id` is not changed, the compute is not triggered and the field of the document is not the same. Later in `_get_pdf()` we use `self.l10n_latam_document_number` to retrieve the PDF from Uruware ([see](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/l10n_uy_edi_document.py#L240)). ### Solution: We need to keep the fields coherent with either `move_id` or `picking_id`. To do this we add the fields of the linked redord in `depends`. opw-5272776 Forward-Port-Of: odoo/enterprise#100128
This update corrects a technical issue where unregistering a Nemhandel user caused it to be lost from the system's user database. Previously, attempting to manually unregister a user would result in an error. This fix ensures that users are properly tracked, preventing data inconsistencies and improving system stability.
Original PR description
If you unregister a Nemhandel user, it won't ever be picked up by the user db. And trying to unregister by hand will give a traceback. This is due to mismatch between Exception types. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236670
This update fixes an issue where the SAFT report incorrectly assigned the supplier's receivable account to customers. The fix changes the XML data to use the correct customer receivable account, ensuring accurate reporting for Romanian VAT returns. This resolves a discrepancy identified in the SAFT report output.
Original PR description
### Issue: In the SAFT report both the Customer and the Supplier have the same account. ### Cause: In the XML there was probably a typo and both have `property_account_payable_id` as account. ### Solution: For the `Customers` node, use `property_account_receivable_id`. opw-5144009 Forward-Port-Of: odoo/enterprise#99196
This update fixes an issue where a product valued by lot would incorrectly use the average value instead of 0 when a lot was assigned with a value of 0. The change ensures that stock valuation layers are accurately set to 0 when a lot with a zero standard price is used, preventing incorrect valuation calculations. This improves the accuracy of inventory accounting.
Original PR description
**Problem:** when selling a product valued by lot and chosing a lot with a value of 0 the average value of the product is used instead of 0. **Steps to reproduce:** - make sure your warehouse is in…
**Problem:**
when selling a product valued by lot
and chosing a lot with a value of 0
the average value of the product
is used instead of 0.
**Steps to reproduce:**
- make sure your warehouse is in single step receipt and delivery
- create a product tracked by lot and valued by lot
- set the category as avco
- create a PO for a quantity of 10 and a unit price of 10
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot A" in the lot column and save
- validate
- create a PO for a quantity of 10 and a unit price of 0
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot B" in the lot column and save
- validate
- create a quotation for 1 quantity of your product
- confirm
- open the delivery
- open the stock move widget on the stock move
- in the 'pick from' column enter lot B and save
- validate
- open the valuation smart button
**Current behavior:**
the value of the stock valuation layer is -5
**Expected behavior:**
it should be 0
**Cause of the issue:**
Inside _prepare_out_svl_vals
lot.standard_price is 0 so the if condition
is false and we don't use the price of the lot
https://github.com/odoo/odoo/blob/cd2a241182cf56fc36d03df9f0afdcea30f682d2/addons/stock_account/models/product.py#L277
**fix:**
deleting the lot.standard_price condition
is not possible because when the lot is created
at delivery it has no standard_price and in this
case we want to use the standard_price of the
product.
(see test https://github.com/odoo/odoo/blob/d3835668349d466ed4ba27c9eacdbd3339f2ac37/addons/stock_account/tests/test_lot_valuation.py#L58)
opw-5077671
Forward-Port-Of: odoo/odoo#234764This update fixes an issue where users were incorrectly changing product details on combo item lines. To address abuse of this functionality, a temporary workaround has been implemented requiring users to hide product columns before editing the description. This ensures data integrity within the sale module.
Original PR description
This was initially allowed so that the user could edit the description on combo item lines (since both the product and description fields are displayed in a single column). However, users seem to abuse this (see https://github.com/odoo/odoo/pull/234090). For information, the description can still be edited, but to do so, the user must first hide the `Product` and `Product variant` columns (which can be shown again after making the necessary changes). Forward-Port-Of: odoo/odoo#236964 Forward-Port-Of: odoo/odoo#235547
This update adds a notification to alert users when they are utilizing the Chorus Pro module without the necessary module installed. This ensures they have access to all required checks and functionality, preventing potential issues and maintaining system integrity. It's a proactive measure to support a smooth user experience.
Original PR description
This commit will add an alert when the customer use Chorus pro but don't have the module installed, and so don't have all the additional checks <img width="982" height="242" alt="image" src="https://github.com/user-attachments/assets/fc35d4ee-9a8b-41b8-8ee3-cbc32b266379" /> task-5223874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236856
8 changes
Resolved issues and error corrections
This update resolves an error that occurred when the system automatically cleaned up data related to withhold payments. The fix ensures that linked data is properly disconnected before cleanup, preventing database errors. This improves the stability of the EC company accounting processes.
Original PR description
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** *…
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** * Install `l10n_ec_edi` and change company to `EC company` * Create invoice with customer `EC Company` > Set Payment Method (SRI) > Confirm * Add Withhold > Document number: `001-001-123456789` > Add lines > Create & Post * Set system time to future date > Run `Base: Auto-vacuum internal data`. Refer video [1] for replication steps. **Error:** `psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line' ` **Root cause:** * The error happens because Withhold Wizard [2] is a transient model that gets cleaned up by function [3] after reaching its max hours. * However, since [2] is linked to Withhold Wizard Lines [4], the cleanup fails, causing the error. **Solution:** * Unlink the lines first and then unlink the wizard. [1]: https://drive.google.com/file/d/1HethT8tpa3Ez0uwueUuKzW4F7KxEKOv_/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/2275fe560d5db0b5a21ffbc4d4c66264e4e12601/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L20 [3]: https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7465-L7497 [4]: https://github.com/odoo/enterprise/blob/7ca0635d4c479a956bfae8fb60da8b50362fd99b/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L423-L427 sentry-6253783256 Forward-Port-Of: odoo/enterprise#99653
Step to reproduce: - for Spain localization, in developer mode: - Go to Balance sheet - Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES) - Click on the parameters button - Click on the "Accounts Coverage Report" Observation: - we receive a traceback ``` psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d" LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance... ``` Caus
Original PR description
Step to reproduce: - for Spain localization, in developer mode: - Go to Balance sheet - Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES) - Click on the parameters button…
Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"
Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```
Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback
https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680
Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.
opw-5224114
Forward-Port-Of: odoo/enterprise#98745A bug was causing image resizing within Odoo Studio reports to fail, resulting in PDFs displaying images at their original size. This fix disables the percentage-based resizing option, preventing incorrect rendering in PDFs due to limitations of the underlying PDF generation tool. This ensures consistent image display in generated reports.
Original PR description
Problem: When resizing an image in Studio within any report, the change is not reflected in the generated PDF. This happens because `wkhtmltopdf` does not support percentage-based `width` / `height` values, which are used by the resize tool (e.g., `width: 25%`). Solution: Disable the image resize option in Studio when editing reports, since the resulting `%` sizing cannot be rendered correctly in PDFs. Steps to reproduce: 1. Open Studio → Reports → open any report. 2. Add an image. 3. Resize it to 25%. 4. Save and print the PDF. 5. The image appears at its original size in the PDF. opw-5233052 Forward-Port-Of: odoo/enterprise#100301
This update automatically registers products with eTIMS before invoice submission, ensuring accurate data transmission. It also fixes the display of product information, now showing eTIMS-specific fields. Crucially, it corrects a multi-company issue where product registration was using the wrong company's eTIMS system.
Original PR description
Before this PR: - Sending invoice/vendor bill to eTIMS would send null item codes if products weren't registered. - `View Product(s)` button in validation messages opened standard product variant view with generic product fields instead of eTIMS-specific fields. - When sending multiple invoices via batch processing, product registration used incorrect company context (in `self.env.company`) instead of the specific invoice's company, causing products to be registered to the wrong company's eTIMS system. After this PR: - Products are automatically registered with eTIMS before sending invoices/vendor bills. - `View Product(s)` button now opens custom `l10n_ke_kra_product_tree` view with eTIMS-specific fields. - Product registration now properly uses the invoice's company context (`move.company_id`) ensuring products are registered to the correct company's eTIMS system in multi-company scenarios. Task-5039671 Forward-Port-Of: odoo/enterprise#93375
This update corrects a technical issue in the Odoo Enterprise software related to the generation of Peru UBL XML invoices. Specifically, an error was preventing the correct formatting of the XML, now resolved by removing a problematic code addition. This ensures accurate invoice generation for Peruvian clients.
Original PR description
In the Peru UBL, adding a reference to a partner would cause an error from the OSE (code 3090). This was because the call to super in _get_partner_party_identification_vals_list would add the partner.ref as an ID, which is incorrect in the Peruvian context. Removed the call to super which did not bring any other information. ticket-5193233 Forward-Port-Of: odoo/enterprise#100043
This update resolves an issue where CFE PDFs weren't being generated correctly for Uruguayan invoices. The fix ensures that the PDF from Uruway is properly linked to the invoice data, allowing users to access and download the required documents. This improves the accuracy of invoice processing for our Uruguayan clients.
Original PR description
### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the…
### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the Settings change 'UCFE Web Services' to 'Testing' and input credentials - Create a new invoice, confirm and send, click 'Generate CFE' - The CFE status is accepted but the PDF from Uruware is not on the record ### Cause: This [commit](https://github.com/odoo/enterprise/commit/726ebfe7c6266b7e54d8b2716983e62eb3142a81) changed how `l10n_latam_document_number` is computed: it's no longer related to `move_id.l10n_latam_document_number` but computed when `move_id` is set. In our case `move_id.l10n_latam_document_number` is [set in `_l10n_uy_edi_send()`](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/account_move.py#L837-L839) but as `move_id` is not changed, the compute is not triggered and the field of the document is not the same. Later in `_get_pdf()` we use `self.l10n_latam_document_number` to retrieve the PDF from Uruware ([see](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/l10n_uy_edi_document.py#L240)). ### Solution: We need to keep the fields coherent with either `move_id` or `picking_id`. To do this we add the fields of the linked redord in `depends`. opw-5272776 Forward-Port-Of: odoo/enterprise#100128
This update fixes a potential issue where rental orders could incorrectly record more returned products than were initially picked up. The change ensures that returned quantities never exceed the quantity originally picked, improving order accuracy and preventing discrepancies in rental accounting. This resolves a previous bug reported by our team.
Original PR description
## Versions 17.0+ ## Issue It is possible to return more products than what has been picked in Rental. ## Steps to reproduce - Create a service product available for rent; - Create a rental SO for any partner: - Add 5 units of the created service; - Confirm the SO; - Pickup 5; - Return 4; - Return 4; - Check the SOL containing 5 delivered products and 8 returned products. opw-5259727 Forward-Port-Of: odoo/enterprise#100015
This update fixes an issue where the SAFT report incorrectly assigned the supplier's receivable account to customers. The fix changes the XML data to use the correct customer receivable account, ensuring accurate reporting for Romanian VAT returns. This resolves a discrepancy identified in previous reports.
Original PR description
### Issue: In the SAFT report both the Customer and the Supplier have the same account. ### Cause: In the XML there was probably a typo and both have `property_account_payable_id` as account. ### Solution: For the `Customers` node, use `property_account_receivable_id`. opw-5144009 Forward-Port-Of: odoo/enterprise#99196
14 changes
Resolved issues and error corrections
This update resolves an error that occurred when the system automatically cleaned up data related to withhold taxes. The fix ensures that linked data is properly disconnected before cleanup, preventing database errors. This improves the stability of the EC company accounting processes.
Original PR description
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** *…
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** * Install `l10n_ec_edi` and change company to `EC company` * Create invoice with customer `EC Company` > Set Payment Method (SRI) > Confirm * Add Withhold > Document number: `001-001-123456789` > Add lines > Create & Post * Set system time to future date > Run `Base: Auto-vacuum internal data`. Refer video [1] for replication steps. **Error:** `psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line' ` **Root cause:** * The error happens because Withhold Wizard [2] is a transient model that gets cleaned up by function [3] after reaching its max hours. * However, since [2] is linked to Withhold Wizard Lines [4], the cleanup fails, causing the error. **Solution:** * Unlink the lines first and then unlink the wizard. [1]: https://drive.google.com/file/d/1HethT8tpa3Ez0uwueUuKzW4F7KxEKOv_/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/2275fe560d5db0b5a21ffbc4d4c66264e4e12601/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L20 [3]: https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7465-L7497 [4]: https://github.com/odoo/enterprise/blob/7ca0635d4c479a956bfae8fb60da8b50362fd99b/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L423-L427 sentry-6253783256 Forward-Port-Of: odoo/enterprise#99653
This update automatically registers products with eTIMS before invoices are sent, resolving issues with incorrect product registration and view displays. It now uses the correct company context for accurate eTIMS registration, particularly important when handling multiple invoices across different companies. This ensures proper compliance with Kenyan e-invoicing regulations.
Original PR description
Before this PR: - Sending invoice/vendor bill to eTIMS would send null item codes if products weren't registered. - `View Product(s)` button in validation messages opened standard product variant view with generic product fields instead of eTIMS-specific fields. - When sending multiple invoices via batch processing, product registration used incorrect company context (in `self.env.company`) instead of the specific invoice's company, causing products to be registered to the wrong company's eTIMS system. After this PR: - Products are automatically registered with eTIMS before sending invoices/vendor bills. - `View Product(s)` button now opens custom `l10n_ke_kra_product_tree` view with eTIMS-specific fields. - Product registration now properly uses the invoice's company context (`move.company_id`) ensuring products are registered to the correct company's eTIMS system in multi-company scenarios. Task-5039671 Forward-Port-Of: odoo/enterprise#93375
This update enhances account reporting by ensuring that when a company views a report with multi-ledger access, it only displays journals from the company with access, improving data accuracy and usability. It resolves an issue where reports were unintentionally showing data from other companies' ledgers. This change primarily impacts multi-company accounting workflows.
Original PR description
When multi-company, if multi-ledger is visible to one company, exclude journals of other companies when opening the report. task-5180393 Forward-Port-Of: odoo/enterprise#98546
This update fixes an issue where the SAFT report incorrectly assigned the same account to both customers and suppliers. The change ensures customers are assigned the correct receivable account, resolving a discrepancy in the report's financial data. This improves the accuracy of the SAFT report for Romanian businesses.
Original PR description
### Issue: In the SAFT report both the Customer and the Supplier have the same account. ### Cause: In the XML there was probably a typo and both have `property_account_payable_id` as account. ### Solution: For the `Customers` node, use `property_account_receivable_id`. opw-5144009 Forward-Port-Of: odoo/enterprise#99196
This update optimizes the way account reports are generated by removing unnecessary data transmission. Specifically, the 'column_group_key' is no longer sent in report configurations, leading to faster report loading times and improved system performance. This change enhances the overall user experience for financial reporting.
Original PR description
task-5164369
This update fixes a bug where drag-and-drop functionality in Gantt views could inadvertently modify readonly fields, particularly within MRP planning. The change ensures that Gantt views respect the 'readonly' status of fields, preventing accidental data updates and maintaining data integrity. This impacts users working with MRP planning and related workflows.
Original PR description
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping…
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO. Steps to reproduce ----- - Have 2 products - Create a MO for product 1 with a WO at work center 1, plan it - Create a MO for product 2 with a WO at work center 2, plan it - Got to Manufacturing, Planning, Planning by Work Center - Add a custom group (by product) - Drag the WO of WC2 and drop it on top of the other WO > Both the WC and the product of the second WO change Cause ----- The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored. https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34 While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored. More broadly, gantt views should not ignore the `readonly` attribute of fields. Solution ----- Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly. When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop. ----- Ticket: opw-4875366 Forward-Port-Of: odoo/enterprise#100209 Forward-Port-Of: odoo/enterprise#94166
When grouping by the ``Status (audit_status)`` field in the Chart of Accounts view, A traceback will appear. Steps to reproduce the error: - Install ``Accounting`` module - Go to Accounting > Configuration > Chart of Accounts - Group By: ``Status (audit_status)`` field Traceback: ```py SyntaxError: non-integer constant in ORDER BY LINE 1: ..."res_company_id" IN (1)) GROUP BY 'todo' ORDER BY 'todo' ASC... ``` https://github.com/odoo/enterprise/blob/289e837ff80e2697cf337fe453aab09
Original PR description
When grouping by the ``Status (audit_status)`` field in the Chart of Accounts view,
A traceback will appear.
Steps to reproduce the error:
- Install ``Accounting`` module
- Go to Accounting > Configuration > Chart of Accounts
- Group By: ``Status (audit_status)`` field
Traceback:
```py
SyntaxError: non-integer constant in ORDER BY
LINE 1: ..."res_company_id" IN (1)) GROUP BY 'todo' ORDER BY 'todo' ASC...
```
https://github.com/odoo/enterprise/blob/289e837ff80e2697cf337fe453aab09e4c569fe6/account_reports/models/account.py#L184-L189
In the main view of ``acount.account``, ``working_file_id`` is not available
in the context,
So, ``working_file`` becomes ``False`` and ``status_query`` will be empty,
and it returns ``SQL('%s', 'todo')``.
So, ordering by a string literal ``todo`` leads to the above traceback.
sentry-6944233306
Forward-Port-Of: odoo/enterprise#97490This update corrects a technical issue where stopping ringtone playback caused unnecessary HTTP requests. The fix resets the element's source instead of setting it to null, preventing the browser from attempting to load a non-existent file and improving performance. This ensures ringtones play correctly.
Original PR description
Setting the src of an element to null triggers a GET HTTP request to /null. This is not the intended behavior; we want to reset the source so that it is not linked to any file, but the browser interprets it as an attempt to load a file called "null". This commit fixes the problem by resetting the source using removeAttribute instead. [Task-5349985](https://www.odoo.com/odoo/project/5778/tasks/5349985) Forward-Port-Of: odoo/enterprise#100146
This update ensures the commercial state field is only visible when processing transactions related to Colombian companies. Previously, it incorrectly appeared on moves for companies outside of Colombia, leading to potential confusion. This change improves data accuracy and simplifies the accounting process for users.
Original PR description
The commercial state field should only be visible on moves part of Colombian companies. Steps to reproduce: load the `l10n_co_dian` module and switch a non-Colombian company, then create a move -> the commercial event is visible. task: 5232473 Forward-Port-Of: odoo/enterprise#98750
This update resolves a recent problem where variant availability wasn't correctly reflected in reports. The fix ensures that reports accurately display variant availability based on defined conditions, improving data accuracy for financial reporting. Comprehensive tests have been added to prevent this issue from recurring.
Original PR description
…n tests previous commit: https://github.com/odoo/enterprise/commit/a01cac65346eee4ff78925e53036c01b83feaa8b The previous commit added urgently a fix to restore variants availability when their conditions are met. This test suite ensure the issue no longer occurs in the future. task-5262958 Forward-Port-Of: odoo/enterprise#99876
This update ensures that filters applied to composite reports in the Odoo Enterprise accounting module work correctly across all sections of the report. Previously, filters weren't consistently applied, leading to inaccurate reporting results. This change aligns with standard Odoo reporting practices for filter behavior.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. Forward-Port-Of: odoo/enterprise#100240 Forward-Port-Of: odoo/enterprise#100148
This update resolves an issue where creating a new invoice on a subscription order would fail if the original invoiced line was deleted. The fix ensures that the system correctly handles deleted lines during invoice creation, preventing errors related to unit of measure mismatches. This improves the reliability of subscription invoicing processes.
Original PR description
**Issue** When a subscription order line is deleted after being invoiced, attempting to create a new invoice for the subscription raises a UserError about UoM category mismatch. Video:…
**Issue** When a subscription order line is deleted after being invoiced, attempting to create a new invoice for the subscription raises a UserError about UoM category mismatch. Video: https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view **Steps to Reproduce** 1. Create and confirm a subscription with a recurring product (e.g., Car Leasing) 2. Generate and post the invoice for the subscription 3. Add a new product line to the subscription (e.g., Office Cleaning Service) 4. Delete the original invoiced line (Car Leasing) 5. Attempt to create an invoice for the new product line → Error: "The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product, they should belong to the same category." (https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view) **Root Cause** Commit https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 introduced quantity tracking per period in _get_max_invoiced_date() to fix partial credit note handling. The implementation accesses `sale_line_ids.product_uom` assuming sale_line_ids is always populated. However, when a sale order line is deleted, the related account.move.line remains in the system with empty sale_line_ids. Accessing `sale_line_ids.product_uom` on an empty recordset returns False, causing the UoM validation to fail during invoice creation. **Fix** Add a fallback to use the invoice line's own product_uom_id when sale_line_ids is empty. This preserves the partial credit note fix from https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 while handling the edge case of deleted subscription lines. If no valid UoM is found, the line is skipped in the calculation. Forward-Port-Of: odoo/enterprise#99598 Forward-Port-Of: odoo/enterprise#99231
This update fixes an issue where users couldn't find UNSPSC codes by typing partial numbers. The system now uses a flexible search method, allowing users to enter any part of the code and receive relevant results. This improves the accuracy and usability of product categorization.
Original PR description
**Steps to reproduce:** * Install the **Accounting** and **l10n_mx** modules. * Open any product form view. * Navigate to the **Accounting** tab. * In the *UNSPSC Category* field, start typing a numerical code such as **'10101500'**. **Observed behavior:** * No results are returned, even though the corresponding UNSPSC code exists in the database. **Cause:** * The `_search_display_name` method used an exact match (`=`) on the `code` field, preventing any partial or prefix-based lookup during user input. **Fix:** * Replace the exact-match domain on `code` with a partial match using `ilike`, allowing users to find UNSPSC codes by typing any part of the numerical sequence. opw-5244705 Forward-Port-Of: odoo/enterprise#100367 Forward-Port-Of: odoo/enterprise#99651
This update fixes an issue where the client nihil option for Belgian VAT returns was accidentally removed. The system now accurately determines if a client is eligible for nihilization based on invoiced amounts, ensuring correct VAT reporting. The temporary module is being integrated into the main l10n_be_reports module.
Original PR description
Since the new return system, the client nihil option that was inside the vat export xml was removed. We used a too simple mechanism which only checks if the tax report was empty or not. This was completely wrong, now we added the checkbox back for finer tuning and we precomputed it. The precompute is checking if any partner is exceeding 250€ invoiced for the current year. This commit adds a new module l10n_be_report_client_nihil which will be removed in master. It will be integrated with l10n_be_reports directly. task-5217079 Forward-Port-Of: odoo/enterprise#99496
31 changes
Resolved issues and error corrections
This update resolves a problem in the avatar card test that was caused by pre-existing activities set up when the demo data was installed. By removing these activities during the test setup, the test now runs reliably and accurately, ensuring the multi-company activities function correctly.
Original PR description
Before this commit, the admin user had some pre-defined activites when installed with demo data, this was interfering with the test since it is using the count of activities to ensure the correct functioning of the multi-company activities. Now, we simply unlink all activities in the setup of the test to ensure its stability. fixes-runbot-234343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where reordering lists with multiple pages would cause elements to temporarily disappear. The fix prevents incorrect page loading when deleting the last item on a page, ensuring lists refresh correctly and data is consistently displayed. This improves the user experience for all users managing sortable lists.
Original PR description
****Behavior:**** **Current:** When adding an element to any reorderable empty list, then deleting it, then adding two new ones, and lastly trying to reorder them. They will disappear until you…
****Behavior:**** **Current:** When adding an element to any reorderable empty list, then deleting it, then adding two new ones, and lastly trying to reorder them. They will disappear until you reload the list. This is occurring since list can be presented in multiple pages, the length of which is defined by the variable limit and the current page is represented by offset (multiple of limit) and when the last element of a page is deleted, we load the previous page (deduce limit from offset), the issue is that there isnt any checks that we are not currently on the first page of the list, and thus we change offset to a negative number (0-limit) which results in an empty list when trying to load the ids of the records (which happens when we reorder the list, and not when adding new elements which explains why they only disappear at that moment) **Steps to reproduce:** (example with sale orders but works with any manually sortable list) - Create a Sale Order - Add any product - Delete it - Add any two combination of product or sections - Swap the order of both - You'll see the elements disappear, when reloading the page they should come back. opw-5191103
This update resolves a test failure related to leave requests, specifically during weekends. The fix ensures the test accurately reflects the system's behavior by using a consistent, non-weekend date for leave calculations. This improves the reliability of our leave management process.
Original PR description
In this commit, we fixed the failed runbot test test_reset_leave_work_entries. The test is failing during weekends since we are requesting and approving leaves using datetime.now(). As a fix, we choose a specific date for the leave (non weekend date). task-5353513. Related to 247070 (runbot errorr) 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 fixes an issue where code blocks within the HTML editor's syntax highlighting weren't properly aligned with their surrounding code blocks. By applying the same styling to the textarea as the pre element, the alignment is now consistently maintained, improving the user experience for writing and viewing code.
Original PR description
When writing in a code block, we need to ensure its textarea's contents are aligned with its pre's. This could get broken when the textarea's contents would wrap and the pre's wouldn't. To fix this, we set the css property `white-space` of the textarea to 'pre' (as is done for the pre element), so that both elements behave the same way. task-5354848 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue with how images were loaded and resized within the HTML editor. The change ensures that image listeners are properly cleaned up, preventing performance problems and ensuring the editor functions smoothly. It replaces a custom listener with Odoo's built-in `t-on-load` for improved stability.
Original PR description
In `AutoResizeImage`, a listener for the load of an image was made with a `useEffect`, but it was not correctly cleaning. It should return a function that remove the listener not directly call `removeListener`, and it should remove the same listener that was added. This commit uses the `t-on-load` in the template instead. task-5190618 Forward-Port-Of: odoo/odoo#232987
This update resolves a technical issue that could have caused the Point of Sale system to become unresponsive (freeze) when certain settings were empty. The fix prevents an infinite loop triggered by a specific condition, ensuring smoother operation and preventing potential disruptions to sales transactions. This improves system stability and reliability.
Original PR description
The condition `config.default_preset_id.id not in config.available_preset_ids.ids` is equivalent to True when both default_preset_id and available_preset_ids are empty. This triggers an infinite loop as assigning with `|=` triggers a nested write. 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#231649 Forward-Port-Of: odoo/odoo#231378
This update significantly speeds up the process of finding deliveries associated with stock lots. By optimizing a key database query, the system now responds much faster, particularly when dealing with a large number of lots. This improves overall system responsiveness and efficiency.
Original PR description
### Description: This refactoring replaces the recursive calculation in `_find_delivery_ids_by_lot` with an iterative process. This change significantly reduces the amount of database queries by prefetching and batching all required lines in a single pass, and it also eliminates the overhead caused by repeated recursive function calls. ### Benchmark: | Total Lots | Before | After | |------------|--------|--------| | 69 | 1 sec | 106 ms | | 1152 | 1 min | 5 sec | ### Reference: opw-5096599 Forward-Port-Of: odoo/odoo#236773 Forward-Port-Of: odoo/odoo#233478
This update resolves an issue where changing a journal's currency caused outstanding account information to disappear from payment method lines. This change ensures that account details remain accurate after currency adjustments, preventing data loss and maintaining financial reporting integrity. The fix was triggered by a bank sync updating currency.
Original PR description
Changing the currency on a journal triggers the compute of inbound/outbound method lines, which clears the method lines before reasign the default method lines. This leads to the loss of any outstanding account set on the method lines. Steps: - Have a bank journal with outstanding accounts set on the payment method lines - Change the currency (in our case, this is the bank sync that changed the currency of the journal) -> Outstanding accounts are missing on the payment method lines, even if the accounts currency is the same as the journals or no currency is set on the accounts. opw-5175794 Forward-Port-Of: odoo/odoo#234008
This update resolves an error that prevented users from sending messages in Chatter when using the Arabic localization (ar_001). The issue stemmed from a mismatch in date formatting expectations, specifically requiring Latin numerals. This change ensures proper message sending functionality for all supported languages.
Original PR description
Currently, an error occurs when a user tries to send log notes or messages in a localization that uses a non-Latin numbering system. **Steps to produce:** * Install `accountant` with demo data and…
Currently, an error occurs when a user tries to send log notes or messages in a localization that uses a non-Latin numbering system. **Steps to produce:** * Install `accountant` with demo data and language `ar_001` * Open `General Ledger` report in accounting * Click the chat bubble on any item to open Chatter and type a message. **Error:** `ValueError: time data '٢٠٢٥-١٢-٣١' does not match format '%Y-%m-%d'` **Root cause:** * This error happens because field [1] is a date field and expects a format using Latin numerals (as seen in [2]). Using Arabic numerals makes the text display right-to-left, causing an error when stripping the string at [3]. **Solution:** * Change the datetime object to use Latin numbers, as the system expects. [1]: https://github.com/odoo/enterprise/blob/5a7cf0f8c3817b5b0fafb798e55f290a53478dfb/account_reports/wizard/mail_compose_message.py#L11 [2]: https://github.com/odoo/odoo/blob/47e561bd1f6bc14724d60ebf09a66e458dfd4799/odoo/tools/misc.py#L536 [3]: https://github.com/odoo/odoo/blob/47e561bd1f6bc14724d60ebf09a66e458dfd4799/odoo/orm/fields_temporal.py#L158 sentry-7015787743
This update resolved a bug where the 'whiteboard pen' product and gift cards were not appearing correctly on the POS screen. By assigning a standard product category, the system now correctly displays these items, preventing tour tests from failing and ensuring a smooth user experience.
Original PR description
Before this commit: ======================= The `whiteboard_pen` product had no assigned category, while the main POS configuration was limited to specific categories. As a result, `whiteboard_pen` was not displayed on the product screen. When no products were loaded, special products like gift cards and e-wallets also not shown,showing the `Load Sample` button instead of products. This caused tour tests expecting gift cards on the screen to fail. After this commit: ====================== Assigned the same product category to whiteboard_pen as used in the POS configuration. This ensures that the product appears on the product screen and special products like gift cards also load properly, preventing the tour test from failing. Runbot Error: 233434, 233435 Forward-Port-Of: odoo/odoo#233563
This update prevents a display error in the project portal when users try to unfollow a task that hasn't been saved. The fix ensures the 'Unfollow' button is hidden for new, unsaved tasks, improving the user experience and preventing a technical error.
Original PR description
Currently, an error occurs when a portal user opens a shared project and clicks the `Unfollow` button in the chatter of a `new(unsaved)` task. **Steps to produce:** - Install the `project` module. -…
Currently, an error occurs when a portal user opens a shared project and clicks the `Unfollow` button in the chatter of a `new(unsaved)` task. **Steps to produce:** - Install the `project` module. - Open the project app and create a new project with at least one task. - From the project’s `dropdown menu(⋮)`, select `Share Project`. - Add a `collaborator: Joel Willis`, with `Edit access mode`, copy the `public link`, and click `Share Project`. - Open the shared link in an incognito window and sign in as a `portal user`. - Open the project folder > open any task > click `New` > click `Unfollow` button. **Error**: `ValueError: Expected singleton: project.task()` **Root cause:** The Unfollow button at [1], is displayed even when the task record is not yet saved (`props.threadId` is `undefined`). At [2], the method is called on an empty recordset, causing an `error`. **Fix:** This commit prevents the error by ensuring the `Unfollow` button is hidden when the record is `unsaved`. [1]: https://github.com/odoo/odoo/blob/be138ef2ff1b3a83f77fe300f789d754ed3383fd/addons/project/static/src/project_sharing/chatter/portal_chatter_patch.xml#L7-L14 [2]: https://github.com/odoo/odoo/blob/be138ef2ff1b3a83f77fe300f789d754ed3383fd/addons/project/models/project_task.py#L2022 No task ID Forward-Port-Of: odoo/odoo#236633
This update prevents a bug where optional products in quotes could have negative quantities when rapidly reducing their amounts. The fix ensures that optional product quantities always remain at zero, improving data accuracy and preventing potential issues in sales processing. This resolves a minor user experience problem.
Original PR description
**Steps to reproduce:** * Install the **Sale Management** module with demo data. * Create a Quotation and set the *Quotation Template* to **Office Furniture**. * Open the **Preview** mode of the…
**Steps to reproduce:** * Install the **Sale Management** module with demo data. * Create a Quotation and set the *Quotation Template* to **Office Furniture**. * Open the **Preview** mode of the quotation. * Scroll to the bottom where **Optional Products** are listed. * Increase the quantity of an optional product from the initial value of zero. * Rapidly click the **minus (-)** button multiple times. **Observed behavior:** * The quantity of an optional product goes below zero when the **minus button** is clicked rapidly. **Cause:** https://github.com/odoo/odoo/blob/5ab45d45073463495e517aca9fd061415a73e893/addons/sale_management/views/sale_portal_templates.xml#L9-L16 * The decrease button is bound using classes that is not updated in the DOM after quantity changes rapidly. As a result, rapid clicks continue triggering the handler on the outdated element, causing multiple unexpected decrease events and allowing the quantity to become negative. **Fix:** * Add a guard to prevent the quantity from dropping below zero, ensuring the minimum quantity always remains zero. --- opw-5250851 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an error that occurred when the system automatically cleaned up data related to withhold payments. The fix ensures that linked data is properly disconnected before cleanup, preventing database errors. This improves the stability of the EC company accounting processes.
Original PR description
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** *…
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** * Install `l10n_ec_edi` and change company to `EC company` * Create invoice with customer `EC Company` > Set Payment Method (SRI) > Confirm * Add Withhold > Document number: `001-001-123456789` > Add lines > Create & Post * Set system time to future date > Run `Base: Auto-vacuum internal data`. Refer video [1] for replication steps. **Error:** `psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line' ` **Root cause:** * The error happens because Withhold Wizard [2] is a transient model that gets cleaned up by function [3] after reaching its max hours. * However, since [2] is linked to Withhold Wizard Lines [4], the cleanup fails, causing the error. **Solution:** * Unlink the lines first and then unlink the wizard. [1]: https://drive.google.com/file/d/1HethT8tpa3Ez0uwueUuKzW4F7KxEKOv_/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/2275fe560d5db0b5a21ffbc4d4c66264e4e12601/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L20 [3]: https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7465-L7497 [4]: https://github.com/odoo/enterprise/blob/7ca0635d4c479a956bfae8fb60da8b50362fd99b/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L423-L427 sentry-6253783256 Forward-Port-Of: odoo/enterprise#99653
This update resolves a memory issue that occurred when processing sales documents in the RS (Romania) region. The fix pre-fetches key data, preventing the system from running out of memory and improving processing speed. This ensures accurate and efficient handling of RS EDI transactions.
Original PR description
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in…
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in memory records ``` sagu_3267671=> select count(id) from account_move; count --------- 1034179 (1 row) ``` ``` File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine return needle(*args) File "/home/odoo/src/odoo/17.0/addons/l10n_rs_edi/models/account_move.py", line 85, in _compute_l10n_rs_edi_is_eligible move.l10n_rs_edi_is_eligible = move.country_code == 'RS' and move.is_sale_document() and move.l10n_rs_edi_state in (False, 'sending_failed') File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__ self.compute_value(recs) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value records._compute_field_value(self) File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine return needle(records, *args) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp> values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__ return self._fields[key].__get__(self, self.env.registry[self._name]) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__ return super().__get__(records, owner) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__ recs._fetch_field(self) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field self.fetch(fnames) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch fetched = self._fetch_query(query, fields_to_fetch) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query self.env.cache.insert_missing(fetched, field, values) File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing field_cache.setdefault(id_, val) MemoryError ``` upg-3267671 opw-5246681 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235919
This update fixes an issue where users couldn't find UNSPSC codes by typing partial numbers. The system now uses a flexible search method, allowing users to enter any part of the code and receive relevant product results. This enhances the accuracy and usability of product categorization.
Original PR description
**Steps to reproduce:** * Install the **Accounting** and **l10n_mx** modules. * Open any product form view. * Navigate to the **Accounting** tab. * In the *UNSPSC Category* field, start typing a numerical code such as **'10101500'**. **Observed behavior:** * No results are returned, even though the corresponding UNSPSC code exists in the database. **Cause:** * The `_search_display_name` method used an exact match (`=`) on the `code` field, preventing any partial or prefix-based lookup during user input. **Fix:** * Replace the exact-match domain on `code` with a partial match using `ilike`, allowing users to find UNSPSC codes by typing any part of the numerical sequence. opw-5244705 Forward-Port-Of: odoo/enterprise#99651
Before this commit, quickly triggering the opening of the file viewer multiple times (e.g. double-click on an attachment) caused a crash. This happens because the `createFileViewer` hook generates a `fileViewerId` on initialization. When `open()` is called, it registers the component using this specific ID. If `open()` is triggered a second time while the component is still registered (or being registered), the registry throws an error because duplicate keys are not allowed. This commit fi
Original PR description
Before this commit, quickly triggering the opening of the file viewer multiple times (e.g. double-click on an attachment) caused a crash. This happens because the `createFileViewer` hook generates a `fileViewerId` on initialization. When `open()` is called, it registers the component using this specific ID. If `open()` is triggered a second time while the component is still registered (or being registered), the registry throws an error because duplicate keys are not allowed. This commit fixes the issue by calling `close()` at the beginning of the `open()` function. This ensures that any existing `FileViewer` instance associated with this hook is removed from the registry before a new one is added. task-5262556
**Problem:** when selling a product valued by lot and chosing a lot with a value of 0 the average value of the product is used instead of 0. **Steps to reproduce:** - make sure your warehouse is in single step receipt and delivery - create a product tracked by lot and valued by lot - set the category as avco - create a PO for a quantity of 10 and a unit price of 10 - confirm and open the receipt - open the stock move widget on the stock move - write "lot A" in the lot column and sa
Original PR description
**Problem:** when selling a product valued by lot and chosing a lot with a value of 0 the average value of the product is used instead of 0. **Steps to reproduce:** - make sure your warehouse is in…
**Problem:**
when selling a product valued by lot
and chosing a lot with a value of 0
the average value of the product
is used instead of 0.
**Steps to reproduce:**
- make sure your warehouse is in single step receipt and delivery
- create a product tracked by lot and valued by lot
- set the category as avco
- create a PO for a quantity of 10 and a unit price of 10
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot A" in the lot column and save
- validate
- create a PO for a quantity of 10 and a unit price of 0
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot B" in the lot column and save
- validate
- create a quotation for 1 quantity of your product
- confirm
- open the delivery
- open the stock move widget on the stock move
- in the 'pick from' column enter lot B and save
- validate
- open the valuation smart button
**Current behavior:**
the value of the stock valuation layer is -5
**Expected behavior:**
it should be 0
**Cause of the issue:**
Inside _prepare_out_svl_vals
lot.standard_price is 0 so the if condition
is false and we don't use the price of the lot
https://github.com/odoo/odoo/blob/cd2a241182cf56fc36d03df9f0afdcea30f682d2/addons/stock_account/models/product.py#L277
**fix:**
deleting the lot.standard_price condition
is not possible because when the lot is created
at delivery it has no standard_price and in this
case we want to use the standard_price of the
product.
(see test https://github.com/odoo/odoo/blob/d3835668349d466ed4ba27c9eacdbd3339f2ac37/addons/stock_account/tests/test_lot_valuation.py#L58)
opw-5077671
Forward-Port-Of: odoo/odoo#234764This update resolves an issue where preparation printing failed when no order was selected in the POS service. The fix prevents a traceback during preparation, ensuring UrbanPiper orders are correctly sent for printing. This improves the reliability of the restaurant's preparation workflow.
Original PR description
Steps to reproduce: - Set up UrbanPiper and a preparation printer in the restaurant. - Open the Ticket Screen from the Floor Screen. - Accept an UrbanPiper order. Issue: - Traceback occurs when sending the order for preparation if no order is currently selected in the POS service. Fix: - Prevent error during preparation printing when no order is selected. ---- Remove redundant `modeUpdate` logic from `categoryCount` computation Task-5241128
Steps to Reproduce: - Create a link in the editor (e.g., "abc"). - Select all and change the font size from 14 to 80. - Two empty tags are created before and after the formatted <span><a></a></span> with only FEFF Characters. - Change the font size again (e.g., back to 14). - Multiple empty tags remain in the DOM. Description of the issue this PR addresses: - In the removeFeffs method, FEFF characters are replaced with empty text nodes, which can lead to unwanted empty elements and
Original PR description
Steps to Reproduce: - Create a link in the editor (e.g., "abc"). - Select all and change the font size from 14 to 80. - Two empty tags are created before and after the formatted <span><a></a></span> with only FEFF Characters. - Change the font size again (e.g., back to 14). - Multiple empty tags remain in the DOM. Description of the issue this PR addresses: - In the removeFeffs method, FEFF characters are replaced with empty text nodes, which can lead to unwanted empty elements and empty text nodes being left in the DOM. Desired behavior after PR is merged: - Empty text nodes resulting from FEFF replacement are now properly removed, preventing leftover empty elements in the DOM. task-5097770 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233909
Before this PR: - Sending invoice/vendor bill to eTIMS would send null item codes if products weren't registered. - `View Product(s)` button in validation messages opened standard product variant view with generic product fields instead of eTIMS-specific fields. - When sending multiple invoices via batch processing, product registration used incorrect company context (in `self.env.company`) instead of the specific invoice's company, causing products to be registered to the wrong c
Original PR description
Before this PR: - Sending invoice/vendor bill to eTIMS would send null item codes if products weren't registered. - `View Product(s)` button in validation messages opened standard product variant view with generic product fields instead of eTIMS-specific fields. - When sending multiple invoices via batch processing, product registration used incorrect company context (in `self.env.company`) instead of the specific invoice's company, causing products to be registered to the wrong company's eTIMS system. After this PR: - Products are automatically registered with eTIMS before sending invoices/vendor bills. - `View Product(s)` button now opens custom `l10n_ke_kra_product_tree` view with eTIMS-specific fields. - Product registration now properly uses the invoice's company context (`move.company_id`) ensuring products are registered to the correct company's eTIMS system in multi-company scenarios. Task-5039671 Forward-Port-Of: odoo/enterprise#93375
When the user tries to perform create or copy operations on the ``hr.recruitment.stage.report`` model, a traceback appears. Steps to reproduce the error: - Install ``hr_recruitment_reports`` module with demo data - Go to Recruitment > Reporting > Hiring Velocity > switch to cohort view > click on any record > select any record > duplicate Traceback: ```py ObjectNotInPrerequisiteState cannot insert into view 'hr_recruitment_stage_report' ``` ``hr.recruitment.stage.report`` mode
Original PR description
When the user tries to perform create or copy operations on the ``hr.recruitment.stage.report`` model, a traceback appears. Steps to reproduce the error: - Install ``hr_recruitment_reports`` module with demo data - Go to Recruitment > Reporting > Hiring Velocity > switch to cohort view > click on any record > select any record > duplicate Traceback: ```py ObjectNotInPrerequisiteState cannot insert into view 'hr_recruitment_stage_report' ``` ``hr.recruitment.stage.report`` model is ``_auto=False``, meaning that no database table is created for this model. When the user attempts to create or duplicate a record of that model, It will lead to the above traceback. sentry-7024266324
This update fixes an issue where MTO backorders incorrectly displayed the delivered quantity instead of the original order total. The fix ensures that the 'Ordered' quantity accurately reflects the remaining demand for MTO products, resolving a discrepancy in reporting. This improves the accuracy of inventory tracking for MTO orders.
Original PR description
Steps To Reproduce ------------------ 1- Create an MTO product. 2- Create an SO for 10 units and confirm. 3- Deliver 5 on the first picking, validate, and create the backorder. 4- Print the delivery…
Steps To Reproduce ------------------ 1- Create an MTO product. 2- Create an SO for 10 units and confirm. 3- Deliver 5 on the first picking, validate, and create the backorder. 4- Print the delivery slip of the first (done) picking. Issue ----- 1- MTO: Ordered = 5, Delivered = 5, Remaining = 5. 2- Normal product: Ordered = 10, Delivered = 5, Remaining = 5. The ordered quantity for MTO products is wrong, it shows the delivered amount instead of the original order total. Cause ----- The delivery report calculates the "Ordered" quantity by adding what we just delivered to what is left in the backorders. I found that the code was looking for move lines in the backorders to count what is left. When I checked a backorder that is waiting for stock (like MTO), there is no reserved stock yet, so no move lines exist. Because of this, the report thought the backorder was empty and ignored the remaining quantity. Fix --- I changed the code to look at the `move_ids` instead of the `move_line_ids`. While debugging I found out that the `move_ids` record always holds the correct demand regardless of the product. opw-5112467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where users without administrative access would encounter an error when creating projects based on templates with Field Service. The fix involves ensuring proper access controls are enforced during schedule retrieval, preventing access errors for non-administrator users. This ensures consistent project creation functionality.
Original PR description
--- ## Short functional explanation of the error Let's say we create a project template with field service. This will enable the start and end date of the project template and its tasks. If we assign…
---
## Short functional explanation of the error
Let's say we create a project template with field service. This will enable the start and end date of the project template and its tasks. If we assign an employee, their schedule will be retrieved to see if it matches the start and end date of the project.
If we try to create a project based on this template as an employee who's not an admin (only has rights for the project and services apps, for example), this will result in the error
This operation is allowed for the following groups:
- Employees/Administrator
- Employees/Officer: Manage all employees
Contact your administrator to request access if necessary.
Explanation: as we try to retrieve the employee schedule with an employee who doesn't have access rights to the Employee infos, it raises an access error.
## Reproduction Steps
1. As an admin, go to Projects and create a new project with a new stage and a new task. Assign an employee to this task.
2. Enable debug mode and go to the settings of the project. Under field service, check Field Service, then save.
3. Click on the small cog next to the project name and click Convert to Template.
4. Set a planned start and end date for the project and for its task. Assign a customer on the task.
5. Go to Users and select a different user than the one you assigned to the task.
6. Set this user administrator for Project and Field Service.
7. Make sure that this user also has an employee profile. Log in with this user and create a project based on this
### Expected behavior
The project is created without the entries the employee doesn't have access to
### Unexpected behavior
An access error is raised
## Origin of the issue
A sudo() was missing in the code.
__
opw-5263024This update ensures that employee contract details, specifically the work address and location, are consistently saved when a new contract version is created through the configurator. Previously, this information was sometimes lost, leading to potential data discrepancies. This change improves data accuracy for employee records.
Original PR description
When a new version is created by the configurator, we need to keep the work address and location.
This update fixes an issue where the SAFT report incorrectly assigned the supplier's receivable account to customers. The fix changes the XML data to use the customer's receivable account, ensuring accurate reporting for the SAFT document. This ensures compliance and proper financial reporting.
Original PR description
### Issue: In the SAFT report both the Customer and the Supplier have the same account. ### Cause: In the XML there was probably a typo and both have `property_account_payable_id` as account. ### Solution: For the `Customers` node, use `property_account_receivable_id`. opw-5144009 Forward-Port-Of: odoo/enterprise#99196
This update refines how website builder tests use snippets, ensuring they accurately reflect the real snippets used in the application. By avoiding matching snippets within other snippets and applying necessary processing, the tests now provide more reliable results and prevent discrepancies between the test environment and the live website.
Original PR description
Forward-Port-Of: odoo/odoo#234902
This update resolves an issue where unregistering a Nemhandel user caused the user database to no longer recognize them. The fix corrects a mismatch in exception types, ensuring that the user database is properly updated when a user is unregistered, preventing errors and maintaining accurate user tracking.
Original PR description
If you unregister a Nemhandel user, it won't ever be picked up by the user db. And trying to unregister by hand will give a traceback. This is due to mismatch between Exception types. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236670
This update ensures that filters applied to composite reports consistently work across all sections within those reports. Previously, filters weren't always correctly applied, leading to inconsistent report results. This change aligns with standard Odoo reporting practices, guaranteeing accurate and reliable reporting.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. Forward-Port-Of: odoo/enterprise#100240 Forward-Port-Of: odoo/enterprise#100148
This update corrects a technical glitch where stopping ringtone playback caused unnecessary HTTP requests. The fix resets the element's source, preventing the browser from incorrectly attempting to load a 'null' file. This ensures ringtone functionality operates smoothly and efficiently.
Original PR description
Setting the src of an element to null triggers a GET HTTP request to /null. This is not the intended behavior; we want to reset the source so that it is not linked to any file, but the browser interprets it as an attempt to load a file called "null". This commit fixes the problem by resetting the source using removeAttribute instead. [Task-5349985](https://www.odoo.com/odoo/project/5778/tasks/5349985) Forward-Port-Of: odoo/enterprise#100146
This update fixes an issue where composite reports weren't consistently applying filters to their individual sections. Now, enabling a filter on a composite report will automatically enable it on all of its components, ensuring accurate reporting results. This aligns with standard Odoo reporting practices.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237003 Forward-Port-Of: odoo/odoo#236893
This update addresses an issue where pressing Backspace within a blank blockquote would unexpectedly delete the entire Table of Contents. The change ensures that an empty blockquote is now converted into a standard container when Backspace is pressed, preserving the intended content and functionality. This improves the user experience and prevents data loss.
Original PR description
### Steps to reproduce: - Create a new Project task. - Insert a Table of Contents (e.g., /tableofcontent). - Insert a quote below it (e.g., /blockquote). - Place the cursor at the start of the empty quote and press Backspace. - The Table of Contents is removed. ### Desired behavior after PR is merged: - Empty blockquote is converted into a base container when backspace is pressed. task-5246130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235087
7 changes
Resolved issues and error corrections
This update resolves a memory issue that occurred when processing sales documents for the Romanian EDI (RS) system. By proactively retrieving country codes, the system now avoids running out of memory, leading to smoother and faster processing of these documents. This improves the overall efficiency of the RS EDI functionality.
Original PR description
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in…
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in memory records ``` sagu_3267671=> select count(id) from account_move; count --------- 1034179 (1 row) ``` ``` File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine return needle(*args) File "/home/odoo/src/odoo/17.0/addons/l10n_rs_edi/models/account_move.py", line 85, in _compute_l10n_rs_edi_is_eligible move.l10n_rs_edi_is_eligible = move.country_code == 'RS' and move.is_sale_document() and move.l10n_rs_edi_state in (False, 'sending_failed') File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__ self.compute_value(recs) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value records._compute_field_value(self) File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine return needle(records, *args) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp> values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__ return self._fields[key].__get__(self, self.env.registry[self._name]) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__ return super().__get__(records, owner) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__ recs._fetch_field(self) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field self.fetch(fnames) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch fetched = self._fetch_query(query, fields_to_fetch) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query self.env.cache.insert_missing(fetched, field, values) File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing field_cache.setdefault(id_, val) MemoryError ``` upg-3267671 opw-5246681 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235919
This update resolves an error that prevented the Accounts Coverage Report in the Spanish localization (l10n_es_reports) from generating correctly. The issue stemmed from incorrect data formatting within the report's database queries. By correcting the data file and adjusting its loading order, the report now functions as intended, ensuring accurate account coverage reporting for Spanish businesses.
Original PR description
Step to reproduce: - for Spain localization, in developer mode: - Go to Balance sheet - Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES) - Click on the parameters button…
Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"
Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```
Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback
https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680
Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.
opw-5224114
Forward-Port-Of: odoo/enterprise#98745This update fixes an issue where the SAFT report incorrectly assigned the supplier's receivable account to customers. The fix corrects a typo in the XML data, ensuring customers now use the correct receivable account for reporting purposes. This ensures accurate SAFT report generation and compliance.
Original PR description
### Issue: In the SAFT report both the Customer and the Supplier have the same account. ### Cause: In the XML there was probably a typo and both have `property_account_payable_id` as account. ### Solution: For the `Customers` node, use `property_account_receivable_id`. opw-5144009 Forward-Port-Of: odoo/enterprise#99196
This update automatically flags stock moves resulting from returns as 'refunds,' streamlining the accounting process. Previously, only returns initiated through the return wizard were correctly marked for refund. This change ensures accurate tracking and reconciliation of returned goods, simplifying inventory management and financial reporting.
Original PR description
This commit makes the `to_refund` field `True` by default for stock move in case of return. The value is True for product coming from the return wizard but not for extra product added later in the picking. In `stock_barcode` there is even not return wizard. Task: 4680813 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 a technical issue where stopping ringtone playback caused unintended HTTP requests to '/null'. The fix resets the element's source, eliminating this problematic behavior and improving performance. This ensures the application functions smoothly without unnecessary network activity.
Original PR description
Setting the src of an element to null triggers a GET HTTP request to /null. This is not the intended behavior; we want to reset the source so that it is not linked to any file, but the browser interprets it as an attempt to load a file called "null". This commit fixes the problem by resetting the source using removeAttribute instead. [Task-5349985](https://www.odoo.com/odoo/project/5778/tasks/5349985) Forward-Port-Of: odoo/enterprise#100146
This update corrects an issue where credit notes' XML files weren't properly validated by the FACe system, a Spanish tax authority. The fix ensures compliance by standardizing the 'ReasonDescription' field, aligning with Spanish requirements. Additionally, the reversal wizard has been streamlined for clarity.
Original PR description
In cases of credit notes, the xml would not be validated by the FACe. This was caused by the field 'ReasonDescription', which can only be one of the proposed field. We used to provide it in English when the available reasons are only in Spanish. Also fixed CorrectionMethodDescription. See https://www.facturae.gob.es/formato/Paginas/version-3-2.aspx for more documentation. ticket-5184181 Took the opportunity to improve the reversal wizard : In the reversal wizard, two fields 'Reason' would be displayed. Only kept the mandatory one and used it in place of the non-mandatory one. Forward-Port-Of: odoo/odoo#236684
This update optimizes how sales orders are accessed, specifically when filtering by sales team. By adding an index to the `sale.order.team_id` field, the system now searches more efficiently, reducing delays and improving the speed of reports and data views related to sales teams. This enhances the overall performance of our sales tracking processes.
Original PR description
`team_id` might be used in filters to conditionally see related `sale.order` for a specific (or set of) sales teams. If the field isn't indexed, it's a Sequential Scan on `sale_order`, which can be a large table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237116
2 changes
Resolved issues and error corrections
This update resolves an issue where users were unable to set invalid default values for fields in Odoo. Specifically, attempting to set an integer as a default for a date field resulted in an error. The fix ensures that users cannot input incorrect data types as defaults, improving data integrity.
Original PR description
Steps:
- Create a user defined defaults value
- Model: res.partner
- Field: date
- Value: 1
- Create a new contact
Actual result:
- invalid field type
- 'int' object is not subscriptable (depends of field type)
Expected result:
- No error
- User is not able to put an invalid value as a default
task-3729963This update ensures the Sign app meets legal requirements for U.S. companies. It now alerts users when a sender is based in the U.S., offering the option to request a paper copy of signed documents – a key step in complying with the ESIGN Act.
Original PR description
Previously, the Sign app did not comply with the ESIGN Act. It now notifies users when the sender company is U.S.-based that they can request a paper copy of a signed document, ensuring ESIGN Act compliance. task-5166918