Daily updates from Odoo
Monday, March 2, 2026
47 changes · saas-19.1
Enhancements to existing features
This update enhances how Odoo identifies partners in Saudi Arabia. Previously, partner identification relied solely on VAT. Now, it also considers the Identification Scheme and Identification Number, leading to more accurate distinctions between companies and individuals, especially when VAT information is unavailable.
Original PR description
Before this commit: - Partner identification relied only on the VAT field. After this commit: - Partner identification in Saudi Arabia also considers Identification Scheme and Identification Number. - This improves detection of companies vs individuals when VAT is missing. task-5866942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update integrates an AI agent ('Odoo agent') to automatically create partner records during account creation. To ensure data accuracy, a new feature will be added to exclude specific partners from this automated retrieval process. This enhancement improves the efficiency of partner onboarding within the accounting system.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/84d84687ac09abad698b1b00a445f69a0d896e5f introduce a new ai agent called "Odoo agent" and in the create method a partner is created from it. We will add a new function to blacklist some partner from the retrieve partner functionality task-5973417 Forward-Port-Of: odoo/enterprise#108871
Resolved issues and error corrections
This update ensures that check printing in the Philippines accurately reflects the net payment amount after withholding taxes. Previously, the check amount didn't correctly account for these deductions. A new test case has been added to verify this fix.
Original PR description
In Philippines' check localization module, the amount on check should be based on the net amount after deducing withholding amount for payments if the payment is with taxes that are set as withholding on payment. This commit fixes the check print's values to reflect the net amount. Minimal test case is also added to safeguard the new behavior. [Task-5928813](https://www.odoo.com/odoo/all-tasks/5928813) Forward-Port-Of: odoo/enterprise#108859 Forward-Port-Of: odoo/enterprise#108611
This update resolves an error that occurred when users attempted to initiate the Colombian Electronic Invoicing certification process without a pre-existing certificate. The fix prevents a traceback by ensuring the system handles the case where no certificate is found, improving the user experience and preventing process interruptions.
Original PR description
When no certificate is found in the company, clicking on ``Begin Certification Process`` raises a traceback. Steps to reproduce the error: - Install ``l10n_co_dian`` module with demo data - Switch to the CO Company - Go to Invoicing > Configuration > Settings > Colombian Electronic Invoicing - Set the Testing ID for Operation mode - In Certificates, delete the existing certificate - Click on Activate the certification process > Begin Certification Process > Ok Traceback: ```py UnboundLocalError cannot access local variable 'cert_sudo' where it is not associated with a value ``` https://github.com/odoo/enterprise/blob/6294be57cf1aa577ec546a958514bc8ec6705935/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1459 The variable ``cert_sudo`` is used outside of the for loop. If no certificate is found, ``cert_sudo`` will be undefined, leading to the UnboundLocalError. sentry-7256943298 Forward-Port-Of: odoo/enterprise#107094
This update corrects a previous issue where archived accounts could be incorrectly assigned as default journal accounts. Previously, the system allowed inactive accounts to be used, leading to potential inconsistencies. This change ensures that only active accounts are considered for journal defaults, maintaining data accuracy and stability.
Original PR description
### Steps to Reproduce: 1. Go to Accounting > Create a journal. 2. Archive the company’s default income/expense or cash diff. accounts. 3. Change the journal type. 3. Observe that an archived account…
### Steps to Reproduce: 1. Go to Accounting > Create a journal. 2. Archive the company’s default income/expense or cash diff. accounts. 3. Change the journal type. 3. Observe that an archived account is assigned by the onchange method. ### Issue: - Prior to saas-18.3, no onchange logic existed for assigning default accounts. With the introduction of the [onchange] (https://github.com/odoo/odoo/commit/334a8161cd2feb092cafedc35d94645900b40518) , archived income/expense or default cash diff. accounts can be assigned to journals. - This creates an inconsistency, as the domain [defined] (https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L70-#L82) for `default_account_id` only returns active accounts. ### Solution: - Since the domain for `default_account_id` returns only active accounts, this commit aims to update the onchange [logic](https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L540-#L551) in order to follow the same restriction, ensuring that only active accounts are assigned thereby preventing inconsistent behavior. OPW-5501539 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#246725
This update fixes an issue where the 'Missing Required Details' widget incorrectly appeared on the self-order system, especially on smaller screens. The change ensures the widget only shows when a required field is hidden and hasn't been selected, providing a smoother user experience.
Original PR description
The "Missing Required Details" widget appeared when there was required attributes to choose in combo item or on the product page AND when the height of the screen was smaller than the content size. So sometimes, it was showing when it was not required and when we clicking on it, nothing was done because we saw everything on the screen. So, what I did, is basically change the condition for displaying the widget. Now it will appear only when a title of a required attributes is hidden by the header and this required attribute is not selected. part ot task: 5493798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244667
This update resolves a bug that caused inventory valuation reports to fail when stock moves associated with subcontracting had multiple destination receipts. The fix limits the record considered during valuation to the last 'done' receipt, ensuring accurate inventory reporting. This improves the reliability of inventory valuation processes.
Original PR description
With older subcontracting MOs, a singleton error will be thrown when the MO has more than one `move_dest_ids` and we try to do an inventory valuation Steps to reproduce: 1. A product with…
With older subcontracting MOs, a singleton error will be thrown when the MO has more than one `move_dest_ids` and we try to do an inventory valuation
Steps to reproduce:
1. A product with `qty_available`, that is not `lot_valuated`
2. The product has a stock move with a `production_id` where `is_in` is true
3. The stock move has more than 1 `move_dest_ids` where `done` and `is_subcontract` is true
4. Open an inventory valuation report from any date in the past. One can access inventory valuation reports from Accounting app > Review menu
> Inventory > Inventory Valuation. You will get a singleton error
Issue:
Followup to previous fix: dae71a2ba5a51ad5a07c4294ecdd6192d8752b07
Because older subcontracting MOs may have multiple destination receipts, a singleton error will occur if there are more than one of these `last_subcontract_done_receipt` records. This is due to the recordset calling `_get_value_from_account_move` on itself, which expects only 1 record and results in a singleton access error when it reaches: https://github.com/odoo/odoo/blob/e7ebe07e1d60659f3d468255808a305e7423741b/addons/purchase_stock/models/stock_move.py#L184
Solution:
Limit `last_subcontract_done_receipt` to 1 record. Because we have no way of knowing which receipt move is the absolute last done receipt, we assume it is the last one created that is also 'done'.
This solution was taken from @kihy-odoo on the PR https://github.com/odoo/odoo/pull/245662
opw-5489433
opw-5416006
Forward-Port-Of: odoo/odoo#250920This update fixes an issue where accounting users without HR permissions would encounter an error when trying to edit a contact's bank account. The fix hides the bank account field for users lacking the necessary HR rights, ensuring data integrity and preventing unexpected access errors.
Original PR description
**Steps to reproduce** - have `hr` and `account` installed - add a bank account to a contact - switch to a user with accounting rights but no HR rights - on the contact form, click on the tag of the bank account in the "Bank accounts" field - Access Error due to missing rights related to employee model **Cause** The `_compute_employee_id` method requires read access on the `hr.employee` model. **Solution** Hide the field for non-HR users. opw-5217072 Forward-Port-Of: odoo/odoo#247792
This update resolves an issue where overtime calculations failed when an employee had multiple versions with differing rulesets. The fix ensures that only the correct ruleset is used during overtime generation, preventing errors and guaranteeing accurate compensation. This improves the reliability of our attendance tracking system.
Original PR description
_ ## Short functional explanation of the error When we generate overtime for an employee who has 2 different versions. If each version has a different overtime ruleset and an attendance exists during…
_ ## Short functional explanation of the error When we generate overtime for an employee who has 2 different versions. If each version has a different overtime ruleset and an attendance exists during the time frame of each version. When trying to generate overtime for the ruleset of the first version, a traceback occurs. ## Reproduction Steps 1. Create an employee. Create 2 different versions for this employee. On each version, set a different overtime ruleset. 2. Create 2 attendances: one during the time frame on which the first version applies, and one during the time frame on which the second version applies. 3. Go to overtime rulesets. Click on the ruleset you applied on the first version and click Reenerate Overtimes. ### Expected behavior The overtimes are regenerated correctly. ### Unexpected behavior A traceback occurs: `ValueError: Expected singleton: hr.attendance.overtime.ruleset(7, 6) ` ## Origin of the issue In the code, we retrieve the version applying to the attendance for which we want to compute overtimes, to get the ruleset with which we will compute the compensation for overtimes: https://github.com/odoo/odoo/blob/347c46f8ecff7ae97c2a686bf5750374b6c3e2d3/addons/hr_attendance/models/hr_attendance.py#L303-L306 However, `version = inter._items[0][2]` returns both versions, thus obtaining both rulesets and creating the error when trying to accss the field `self.ruleset_id.rate_combination_mode` later, as self.ruleset_id will contain both rulesets. __ opw-5443700 Forward-Port-Of: odoo/odoo#249736
This update corrects an issue where the IoT module couldn't properly access a key token. By directly accessing the token from the pos_self_order service, the system now reliably retrieves and utilizes this data, ensuring smoother operation of IoT-connected point-of-sale systems. This improves data accuracy and functionality.
Original PR description
Access token is not accessible from pos_config, it should be accessed from pos_self_order service directly. Forward-Port-Of: odoo/enterprise#109158
This update fixes an error in the Spanish Profit & Loss reports where accounts 7950 and 7957 were incorrectly placed in section 10. The change aligns with official Spanish tax documentation, ensuring accurate reporting for non-SME fiscal localization packages. This ensures compliance with Spanish tax regulations.
Original PR description
In the Profit & Loss reports, accounts 7950 and 7957 were incorrectly shown in section 10 instead of section 6 These accounts appear only for non-SME fiscal localization packages According to the official Spanish tax documentation, these accounts should belong to section 6 and not section 10: https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884 opw-5363664 Forward-Port-Of: odoo/enterprise#108820 Forward-Port-Of: odoo/enterprise#107949
This update fixes a bug in the pipeline dashboard that prevented accurate matching of leads within the first list. The change ensures that the dashboard displays correct data, improving the visibility and accuracy of sales pipeline information. This resolves a previously reported issue impacting sales performance.
Original PR description
…oard Field matching was missing for the list #1 in the pipeline dashboard. Task: 5092979 Forward-Port-Of: odoo/enterprise#107516
This update resolves issues with the Belgian XBRL report, specifically correcting inaccurate translations and removing irrelevant company types. The changes enhance the report's data quality and reliability for financial reporting compliance.
Original PR description
This commit fixes several issues in the Belgian XBRL report. - Values in report like "false" were being wrongly translated. - Not all company types are valid/relevant. Removed invalid company types. task-5907118 Forward-Port-Of: odoo/enterprise#108556
This update adjusts the Italian tax system integration to comply with a new law. Starting January 1, 2025, forfettari (RF19) can now utilize simplified invoices regardless of the total amount. This simplifies invoice processing for this specific business segment.
Original PR description
Since 01/01/2025, Italian law allows forfettari (RF19) to use simplified invoices even if the total amount exceeds 400€. References: - https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:legge:2014-12-23;190;1;59#:~:text=L'emissione%20della%20fattura%2C%20ove%20prevista%2C%20può%20avvenire%20in%20modalità%20semplificata%20ai%20sensi%20dell'articolo%2021%2Dbis%20del%20decreto%20del%20Presidente%20della%20Repubblica%2026%20ottobre%201972%2C%20n.%20633%2C%20anche%20se%20di%20ammontare%20complessivo%20superiore%20al%20limite%20indicato%20nel%20comma%201%20del%20medesimo%20articolo%2021%2Dbis. - https://www.dkpost.it/fattura-semplificata-senza-limiti-per-i-forfettari/ - https://www.gazzettaufficiale.it/eli/id/2024/11/30/24G00196/sg Forward-Port-Of: odoo/odoo#250743 Forward-Port-Of: odoo/odoo#247264
This update resolves an issue where adding a column within a list item caused a system error. The fix separates column insertion within lists, preventing errors related to restoring selections on removed elements. This ensures stable column insertion functionality within list items.
Original PR description
Problem: When trying to add a column under a list item, a traceback occurs. Cause: The list item is removed during the operation, but the selection that is restored still references the removed list item. As a result, the selection is restored on a disconnected element, causing a traceback. Solution: Handle column insertion inside lists separately. In this case, according to the specifications, we split the list and insert the columns between the resulting lists (or after the list if the cursor is in the last list item). This avoids restoring the selection on a removed node. Steps to reproduce: - Add any list. - Run `/column` while the cursor is inside a list item. - Observe the traceback. task-5916246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250847 Forward-Port-Of: odoo/odoo#248206
This update resolves an issue where event email templates incorrectly used the sender's company instead of the event's company, causing incorrect styling and potential access errors in multi-company environments. The fix ensures event templates now correctly reference the event's company, guaranteeing accurate styling and proper access rights.
Original PR description
Steps to reproduce: 1. Create a multi-company environment with at least two companies. 2. Create a new user with Company 1 as default and access to Company 2. (+ Admin rights for events.) 3. Connect…
Steps to reproduce: 1. Create a multi-company environment with at least two companies. 2. Create a new user with Company 1 as default and access to Company 2. (+ Admin rights for events.) 3. Connect to the user and switch to Company 2. 4. Go to Events > Any event on this company with at least 1 attendee. 5. Go to the attendee form and in the chatte go to send message and expand. 6. Finally, try to select an email template from the 3 dots. This issue was introduced by commit aff20f8, which added logic to style email buttons using company-specific colors. The bug occurs because the template incorrectly retrieves the company of the current user sending the email instead of the company linked to the event registration (object.company_id). This leads to two problems in a multi-company environment: 1. The button colors will always be based on the user's default company, leading to incorrect styling. 2. It can provoke an access rights error when trying to read the email colors of a company that is not the one we've currently selected. To fix this, we should ensure that the email templates for events use the company associated with the event registration (object.company_id) when styling the email buttons. This way, the correct company context is used, ensuring proper access rights and more accurate button styling. opw-5256010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236764
This update corrects a bug where custom analytic distribution settings on sales order lines were being overwritten when using product-partner combinations with Analytic Distribution Models. Now, user-defined distributions are preserved, ensuring accurate tracking of costs associated with project sales. This improves financial reporting and compliance.
Original PR description
*: project_purchase, sale_project --- Decription of the issue this commit addresses: When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned,…
*: project_purchase, sale_project --- Decription of the issue this commit addresses: When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned, any custom analytic distribution done on the line of the product will be lost, resetting the analytic distribution to the default value set on the Analytic Distribution Model. --- Steps to reproduce: 1. Install sale_project,project_purchase. 2. Activate "Analytic Accounting" in the settings. 3. Create a new Product "test"; Type: Service, Create on Order: Project. 4. Create a new Analytic Distribution Models; Partner: Acme, Product: test, Analytic Distribution: anything but blank. 5. Create a new Quotation in the Sales apps; Partner: Acme. 6. Assign the Product test to the first order line. This will automatically set the analytic distrib of the Analytic Distribution Model. 7. In the Analytic Distribution cell, add a line with any non null distribution. 8. Confirm the Quotation. 9. The analytic distribution that was anually added has been removed. Only the default analytic distribution of the model remains. --- Desired behavior after this commit is merged: Any custom analytic distribution done on a line is never lost. The Analytic Distribution Model's distribution serves as a template but never overrides the values set by the user. --- opw-4934291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250707 Forward-Port-Of: odoo/odoo#249747
This update fixes an issue where SII invoices weren't correctly formatted, preventing successful submission. The change updates XML tags related to withholding taxes to align with SII's specifications, ensuring invoices are accepted by the SII system. This ensures compliance with Chilean tax regulations.
Original PR description
Link to SII API Documentation: https://www.sii.cl/factura_electronica/formato_dte.pdf Problem: The DTE template was using incorrect XML elements for withholdings when confirming an invoice with SII. This fix replaces: ImptRetOtrMnda -> ImpRetOtrMnda ValorImpOtrMnda -> VlrImpOtrMnda so the generated DTE matches SII specifications. OPW-5437484 Forward-Port-Of: odoo/enterprise#105152
This update resolves an error that occurred when generating the Reception Report through Odoo's Web Studio. The issue stemmed from an incorrect data type being passed to a database query, preventing the report from loading. The fix removes problematic data types to ensure proper report generation.
Original PR description
Currently an error occurs when user tries to open reception report through web studio. Steps to replicate: - Install stock, web_studio with demo. - Open receipts and turn on studio mode. - Go to…
Currently an error occurs when user tries to open reception report through web studio. Steps to replicate: - Install stock, web_studio with demo. - Open receipts and turn on studio mode. - Go to reports and try to open `Reception Report`. Error: ``` psycopg2.ProgrammingError: can't adapt type 'NewId' ``` Cause: - Error occurs after this [PR] that prevents passing of falsy ids to orm. - As a result the [line] passes `api.NewId()` that is received as `docids` in the function `_get_docs()` performs search using the `NewId` [here] which causes this error to occur. - In the previous version the id passed was passed a static list `[0]` and then changed to `api.NewId()` which works perfectly fine with `browse()` but with any other operation that fires direct queries like `search()` or `_read_group()` it will cause this error to occur. Solution: - Removed NewIds from docids before the search. [PR]: https://github.com/odoo/enterprise/pull/95117/changes#diff-cf8f46a54f86279b4d773f0d39b23d22f046eb6d33a39c851f2a86dcd2b5b202R645 [line]: https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/web_studio/controllers/report.py#L649 [here]: https://github.com/odoo/odoo/blob/3263a7f54948d57f13176cf0416b1419150e9d87/addons/stock/report/report_stock_reception.py#L190 sentry-7236339558 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request updates the core spreadsheet component to the latest version (19.1.8). It includes several performance improvements and bug fixes related to spreadsheet calculations and rendering, ensuring a smoother user experience when working with spreadsheets in Odoo.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/308237a70c [REL] 19.1.8 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/308237a70c [REL] 19.1.8 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5f09698747 [REV] borders: revert infinite borders [Task: 5932734](https://www.odoo.com/odoo/2328/tasks/5932734) https://github.com/odoo/o-spreadsheet/commit/4d6dd66e7f [FIX] dynamic_tables: trim overlap on the correct side [Task: 5905900](https://www.odoo.com/odoo/2328/tasks/5905900) https://github.com/odoo/o-spreadsheet/commit/e0169c6507 [FIX] side_panel: restore scroll position on pivot tab change [Task: 5900595](https://www.odoo.com/odoo/2328/tasks/5900595) https://github.com/odoo/o-spreadsheet/commit/8ffb04ba31 [FIX] side_panel: restore vertical scrolling for chart side panel tabs [Task: 5900595](https://www.odoo.com/odoo/2328/tasks/5900595) https://github.com/odoo/o-spreadsheet/commit/31c21dd164 [PERF] formulas: Force the use of the cache for linear search functions [Task: 5956354](https://www.odoo.com/odoo/2328/tasks/5956354) https://github.com/odoo/o-spreadsheet/commit/8bc66cca9b [PERF] recompute_zone: binary search with bit shift [Task: 5955352](https://www.odoo.com/odoo/2328/tasks/5955352) https://github.com/odoo/o-spreadsheet/commit/943331f6d9 [FIX] Evaluation: Provide cell position for isolated formula evaluation [Task: 5798610](https://www.odoo.com/odoo/2328/tasks/5798610) https://github.com/odoo/o-spreadsheet/commit/ca96bd9a84 [FIX] package: saas-19.1 is no longer the latest version [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update reverses a recent change to the spreadsheet edition's styling, specifically related to borders. The change was reverted to restore the previous visual appearance. This ensures consistent and expected formatting within the spreadsheet functionality.
This update fixes a bug where restarting the chat bot after a page reload caused duplicate actions. Previously, reloading the support page and restarting the bot would result in multiple questions being presented simultaneously. The fix removes a redundant call to start the bot during the restart process, ensuring a smoother user experience.
Original PR description
Since [1], restarting the chat bot after reload could lead to multiple steps being executed at the same time. Steps to reproduce: - Go to the `/im_livechat/support/2` page. - Chat with the support bot until the end of the conversation. - Reload the page. - Click on the restart button. - Two question selections are displayed at the same time. This occurs because the bot starts from the `_toggleChatbot` field's `onUpdate` method. The `restart` method also calls `start` on the chat bot. To fix this issue, the call to `start` is removed from the `restart` method. [1]: https://github.com/odoo/odoo/pull/194399 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#250782 Forward-Port-Of: odoo/odoo#250623
This update fixes an issue where newly hired employees were incorrectly receiving their private email address as their work email. The change ensures that the employee's work email field is properly cleared during the contract signing process, preventing this duplication. This improves data accuracy for employee records.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797 Forward-Port-Of: odoo/enterprise#108933 Forward-Port-Of: odoo/enterprise#106974
This update resolves an issue where users weren't receiving clear guidance when a previous payslip was missing for after departure payments. Now, a helpful error message is displayed, guiding users to add a required reference payslip. This ensures accurate payment processing and avoids technical errors.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607 Forward-Port-Of: odoo/enterprise#108980 Forward-Port-Of: odoo/enterprise#107386
This update fixes an issue where the shipping weight for deliveries wasn't accurately calculated when products were placed into packages. The fix ensures that the total weight of items in a package is correctly reflected in the delivery's shipping weight, improving order accuracy and fulfillment.
Original PR description
Steps to reproduce: - Enable “Packaging” in Inventory settings. - Create a storable product “P1” with: - weight: 10 kg - Create a delivery picking: - Add one unit of P1 - Mark as “To Do” - Set…
Steps to reproduce:
- Enable “Packaging” in Inventory settings.
- Create a storable product “P1” with:
- weight: 10 kg
- Create a delivery picking:
- Add one unit of P1
- Mark as “To Do”
- Set quantity to 1 → the move becomes assigned and the picking weight is correctly computed to 10
- Click “Put in Pack” → a package is created with `shipping_weight = 0`, and the picking weight incorrectly computed to 0
Problem:
- `picking.shipping_weight` is computed as: `weight_bulk` + sum(`pack.shipping_weight or pack.weight`) https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L72-L79
- Once the product is placed in a package:
- `weight_bulk` becomes 0 (because Total weight of products which are not in a package). https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L96
- `pack.shipping_weight` is 0 on creation.
- The fallback `pack.weight` is 0 because its compute depends on the `picking_id` in context. Without this context, the compute uses only quants https://github.com/odoo/odoo/blob/f7c033eff7b7bc83d6d18fc5e4df320f43ae5021/addons/delivery/models/stock_quant_package.py#L11-L13
opw-5357843
Forward-Port-Of: odoo/odoo#249029
Forward-Port-Of: odoo/odoo#238917This update fixes an issue where the 'Reply' function in the HTML composer wouldn't reliably focus the editor, particularly in Firefox. The fix involves adding invisible characters around mentions to ensure the cursor can move correctly, resolving a known compatibility problem.
Original PR description
In chatter, using "Reply" in HTML composer could focus the composer without giving a usable caret. The inserted partner mention is a non-editable link (`contenteditable="false"`), and selection could end up inside that node, so typing would not insert text. This also fix the related firefox issue: mentions are rendered as `a[contenteditable=false]`. Firefox is stricter than Chrome for carret positions around non-editable inline nodes, so clicking before a mention or moving left from its right edge could make stuck. so we register mention selectors as FEFF providers in the mention plugin. (a feature of html_editor FEFF plugin to add invisible boundary characters around mentions, which gives firefox what it need to move carret around. some tests had to be adapted to take the insertion of FEFFs in the composer text into account task-5262368 Forward-Port-Of: odoo/odoo#250296
This update resolves an issue where non-administrator users were receiving access errors when viewing the accounting dashboard with the l10n_tr_nilvera module. The fix ensures that non-admin users can access the necessary features within the dashboard, improving usability and workflow for all users.
Original PR description
…nting dashboard # How to reproduce - Add the l10n_tr_nilvera module - Have at least one journal - Connect with a non-admin user - Go to the accounting dashboard # The problem An access right error message is displayed # Why When going to the accounting dashboard, both "_compute_show_fetch_in_einvoices_button" and "_compute_show_refresh_out_einvoices_status_button" are triggered. They both try to access the nilvera api key field of account.journal but only administrator users have access to that field. opw-5928715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249425
This update resolves a bug where hiding the price on an invoice section caused that section to disappear from the preview and PDF. The fix also addresses a related issue where removing tax on a product duplicated the subsection. This ensures invoices render correctly regardless of price hiding.
Original PR description
**STEP TO REPRODUCE** 1. Create an invoice, with: - Section A - Subsection 1 - product a, with tax Click on hide price on section A, and preview the invoice. Notice the Section A is missing from the preview/pdf. If you remove the tax on product a, there will also be a bug where Subsection 1 is duplicated, with one copy with no children lines below it. opw-5927563 Forward-Port-Of: odoo/odoo#249808
This update introduces a new ‘Net Cost’ salary rule to accurately track employer costs related to employee payroll. Previously, a specific rule sign caused incorrect deductions, impacting both employee and employer contributions. This change ensures that employer costs are calculated correctly, improving payroll accuracy.
Original PR description
## Before: - Setting appears_on_employee_cost_dashboard to True on a salary rule uses the rule’s sign to compute employee cost. - For rules like Social Insurance Employee Contribution and DEWS Employee Contribution, the sign must be negative to deduct the amount from the employee, which incorrectly reduces the employer cost as well. ## After: - Introduced a new salary rule “Net Cost” to correctly reflect employer cost. - This allows employee contribution rules to keep a negative sign for deductions while still increasing the employer contribution amount. Task-5912761 Forward-Port-Of: odoo/enterprise#107090
This update corrects a bug where the '#top' and '#bottom' menu links were incorrectly prefixed with the current page's URL, preventing users from easily scrolling to the top of the website. The fix ensures these standard 'scroll to top' links function correctly, improving website navigation and user experience. A new test confirms this resolution.
Original PR description
__Before commit:__ Menu items with anchor URLs (e.g., `#my-anchor`) are prefixed with the current page's path. This is correct for page-specific anchors but breaks generic ones like `#top` and…
__Before commit:__ Menu items with anchor URLs (e.g., `#my-anchor`) are prefixed with the current page's path. This is correct for page-specific anchors but breaks generic ones like `#top` and `#bottom`. A menu with the URL `#top` becomes `/current-page#top`, preventing it from functioning as a universal "scroll to top" link. __Cause:__ The server-side logic for processing menu URLs does not differentiate between page-specific anchors and generic anchors like `#top` or `#bottom`, treating all anchor links as belonging to the current page. __Fix:__ In the `save` method, exclude `#top` and `#bottom` from the logic that prefixes anchors with the current page's URL. This ensures these special anchors, typically set on the header and footer, work consistently across the entire website. A new unit test verifies that `#top` and `#bottom` menu URLs are saved correctly without being prefixed. task-5941115 Forward-Port-Of: odoo/odoo#251154 Forward-Port-Of: odoo/odoo#250136
This update fixes an issue where the 'hours_per_day' and 'hours_per_week' fields weren't correctly recalculated when a Working Schedule was set to 'Define Amount of Hours per day'. The change ensures these values update dynamically when the schedule duration is modified, providing accurate time management.
Original PR description
### Issue: When creating a Working Schedule, and choosing the option "Define Amount of Hours per day" then the fields `hours_per_day` and `hours_per_week` are not recomputed correctly. ### Steps to…
### Issue: When creating a Working Schedule, and choosing the option "Define Amount of Hours per day" then the fields `hours_per_day` and `hours_per_week` are not recomputed correctly. ### Steps to reproduce: - Create a new Working Schedule - Tick the option "Define Amount of Hours per day" - Change the duration on a line - Hours per day and hours per week are not updated ### Cause: This [commit](https://github.com/odoo/odoo/commit/77f860f5d3757e5a56861ac1de95b9ad29ea0dff) introduced the possibility of defining `resource.calendar.attendance` with `duration_hours` instead of `hour_from`/`hour_to`. The fields `hours_per_week`/`hours_per_day` are recomputed when changing `hour_from`, `hour_to` or `duration_hours`. This recompute is done because an onchange is triggered and will recompute all compute fields displayed in the form view. As the fields `hour_from`/`hour_to` are not computed, they are not changed when changing `duration_hours` on the form view but they are when saving because of `_inverse_duration_hours()`. The compute method of `hours_per_week` only takes into account `hour_from`/`hour_to`. So if `duration_based` is False, then changing `hour_from` will recompute `hours_per_week` but changing `duration_hours` will not as `hour_from`/`hour_to` still have the previous values. ### Solution: We need the recomputation to be made on `duration_hours` when `duration_based` is True. As `duration_hours` is recomputed via `_compute_duration_hours()` when `hour_from`/`hour_to` change, we only use `duration_hours`. opw-5942240 Forward-Port-Of: odoo/odoo#249446
This update fixes a technical issue preventing the search bar's placeholder text on the website from being translated. The change replaces a complex code method with a standard translation-friendly element, ensuring all website content, including search prompts, can be localized for different languages. This improves the user experience for international customers.
Original PR description
The placeholder of the search bar for attributes in eCommerce was not translatable, because it was using a Python expression to set its value. This commit replaces the Python expression with a t-attf-placeholder, which allows the placeholder to be translated. opw-5978276 Forward-Port-Of: odoo/odoo#251145
This update fixes inaccurate calculations of worked days and work entries for new employees, particularly those with contracts starting in the current month. The change ensures that attendance and work entry data aligns with the employee's contract start date, resolving issues with incorrect day counts and preventing unnecessary work entry generation when no contract exists.
Original PR description
Problems: ------- 1. For a new employee, with a contract starting in the current month but before today: in the payslip for the current month number of days of attendance and days of out of contract…
Problems: ------- 1. For a new employee, with a contract starting in the current month but before today: in the payslip for the current month number of days of attendance and days of out of contract are not correct Same for an employee, with a contract ending in the current month (before today) 2. In both cases above worked entries are not generated correctly (from today to the end of month) 3. Additional bug: If we create an employee with no contract and create a payslip draft for him for the current month, work entries with type "Attendance" will be created Objective: --------- Problems 1 and 2 : date_version was equal to today (date of the employee's creation), so number of attendance days was calculated as ( end_of_payslip_month - today ) or ( today - start_of_payslip_month ) Problem 3 : Work entries are generated even when there is no active contract Solution: --------- Problems 1 and 2: This commit adds an additional part (already exists in v19) in the method write() of hr.version which sets date_version = contract_date_start Problem 3: by generating work entries check if contract_date_start is filled Tests ware added in odoo/hr: test_hr_version.py and in enterprise/hr_payroll: test_new_employee_worked_days, test_payslip_empty_contract.py task-5430759 Forward-Port-Of: odoo/odoo#250722 Forward-Port-Of: odoo/odoo#241978
This update fixes an error in how Odoo calculates worked days for employees without contracts or when contracts don't fully align with pay periods. The change ensures accurate attendance and out-of-contract day reporting, particularly for new hires and those with contracts starting or ending during a pay period.
Original PR description
Problem: ------- In several scenarios, Worked Days are incorrectly computed when the employee has no contract or when the contract does not fully overlap with the payslip period. Case 1: - Create an…
Problem: ------- In several scenarios, Worked Days are incorrectly computed when the employee has no contract or when the contract does not fully overlap with the payslip period. Case 1: - Create an employee without a contract - Create a payslip for this employee for the current month: You'll see X days of attendance (= today until the end of the payslip period) and Y days of out of contract (= number of days from the start of the payslip period until today) - Create a payslip for this employee for the previous month: you'll see ( Z_prev + Y ) days out of contract ( Z_prev = number of working days in the previous month) - Create a payslip for this employee for the next month: you'll see Z_next days of attendance (Z_next = number of working days in the next month) Case 2: - Create a new employee with a contract starting during the current month - Create a payslip for this employee for the previous month - Out-of-Contract days are incorrectly computed as: contract_start_date - previous_month_start. Case 3: - Create an employee with a contract ending during this month - Create a payslip for this employee for the next month - Out-of-Contract days are incorrectly computed as: next_month_end - contract_end_date. Solution: -------- When generating work days lines: - Explicitly handle employees without a contract. - Use adjusted date bounds when the contract does not overlap the payslip period. Several tests were added to cover these scenarios, as well as the tests the corresponding commit in odoo/odoo (PR odoo: 241978) task-5430759 Forward-Port-Of: odoo/enterprise#108783 Forward-Port-Of: odoo/enterprise#103207
This update adjusts the size of custom snippet titles within the Mass Mailing builder to ensure they are clearly visible. A recent update to the preview snippet selector improved readability, but the default font size for custom snippet titles was previously set too large. This change halves the title size to maintain a consistent and readable appearance.
Original PR description
In Mass Mailing, users can save modified snippets as Custom Snippets, allowing for their later reuse. These snippets can be found in the Custom category. However, their title was too large. This is due to d2b56435736e8d507434c1378cb68fae23e8511f rescaling the preview snippet selector, allowing for better readability of each snippet's text from the selector. As the default builder font size for custom snippet titles was set for the previous scale (50px at 0.3 scale), it has to be halved to restore its previous appearance at the new scale (25px at 0.6 scale). task-5959033
This update fixes an issue where new tables were assigned numbers based on the highest floor number across the entire restaurant, regardless of the current floor. Now, new tables are assigned numbers based on the highest table number *on the current floor*, ensuring a more logical and user-friendly table numbering system, especially in multi-story restaurants.
Original PR description
Before this commit: =================== When multiple floors exist, creating a new table assigns the next table number based on the maximum table number across all floors. After this commit: ================== When multiple floors exist, creating a new table assigns the next table number based on the maximum table number of the current floor. Task: 5888449 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a rounding error in early payment discounts when cash discount tax reduction is enabled. Previously, discounts were calculated line-by-line, leading to discrepancies. This change ensures discounts are rounded globally for accurate calculations, improving financial reporting.
Original PR description
**PROBLEM** There is a rounding issue with early payment discount when cash discount tax reduction is set to always (upon invoice). The move.line created for the discount is computed by applying the discount to each line, rounding each line individually. But the early payment discount is computed by rounding globally. **STEP TO REPRODUCE** 1. Create a payment term, with early discount of 1%, and cash discount tax reduction set to 'Always (upon invoice)'. 2. Create an invoice with 4 identical lines, unit price 4.76€ and tax 15%. 3. set the payment term on the invoice and save. 4. Go to journal item, early payment discount is 0.20€. 5. toggle discount_amount column on the the journal item tab. 6. notice on the last line, that balance - discount_amount = 0.19€ instead of 0.20€ opw-5865308 Forward-Port-Of: odoo/odoo#250638 Forward-Port-Of: odoo/odoo#247996
This update resolves a client-side error that occurred when users closed the certificate signing wizard without saving. The fix ensures the system correctly handles wizard dismissals, preventing a JavaScript crash and improving stability. This ensures a smoother user experience for signing certificates.
Original PR description
**Issue:**
Closing the signing certificate wizard without saving triggers a client-side traceback (`UncaughtPromiseError: Invalid ids list: [object Object]`).
**Cause:**
When the wizard dialog is discarded, Odoo's dialog manager passes a dismissal object (`{dismiss: true}`) to the `onClose` callback. The existing code only checked if the payload was truthy (`if (cert_id)`), causing it to attempt to update the `signing_certificate_id` Many2one field with the event object. The framework's validation (`validatePrimitiveList`) expects an integer or array of integers, resulting in a crash when it tries to parse the object.
**Fix:**
Updated the `onClose` callback to strictly verify the type of the payload (`typeof cert_id === 'number'`). The record is now only updated when the wizard successfully returns a valid primitive integer ID.
task: 5975643This update resolves a significant performance issue that caused slow loading times (80+ seconds) and memory errors when accessing key reports like 'Invoices to be Issued' and 'Invoiced Not Delivered'. The fix optimizes the data retrieval process, dramatically reducing load times to just 8.5 seconds and eliminating memory errors on large databases.
Original PR description
### Problem Opening the "Invoices to be Issued" and "Invoiced Not Delivered" menus caused MemoryErrors and 80+ second load times on large databases. ### Root Cause `_read_group_for_accrual` loops…
### Problem
Opening the "Invoices to be Issued" and "Invoiced Not Delivered" menus
caused MemoryErrors and 80+ second load times on large databases.
### Root Cause
`_read_group_for_accrual` loops over each group result to manually sum
non-stored computed fields. On each iteration it called `search()` with
a domain containing `('invoice_to_be_issued', '=', True)`, triggering
`_get_accrual_line_ids` once per group instead of once per request.
### Fix
Move the `search()` call outside the loop so matching records are fetched
once per request. The per-group partition is then resolved using
`search_fetch` + `grouped`, which handles the field prefetching and
grouping into recordsets in one call.
### Before / After
| Metric | Before | After |
|-------------------------------|---------|--------|
| Total request time | 82s | 8.5s |
| `_get_accrual_line_ids` calls | 82 | 3 |
| MemoryError on large DBs | ✓ | ✗ |
opw-5392606
Forward-Port-Of: odoo/enterprise#108102This update resolves an issue where salary inputs weren't correctly duplicated when creating a new salary input. Previously, this prevented certain payslips from displaying accurate information. The change ensures that all necessary selections are copied, improving payroll accuracy and reporting.
Original PR description
When having a salary input avaiblable for employee and payslip, and using it in an employee made it unavailable in payslips. This is unwanted behaviour and is due to the domain restricting existing_ids in employees. This was extracted from the action and is set in each separate model according to the needs. task-5909636
This update corrects a minor issue in the Odoo Point of Sale Self-Order module. A necessary field, 'other_devices', was missing from the configuration settings, preventing it from appearing in the user interface. This fix ensures all configuration options are fully visible and accessible to users.
Original PR description
Missing `other_devices` in `pos.config` model in whitelist load data, which causes the field to be missing in the form view of pos config. Forward-Port-Of: odoo/odoo#251373
This update fixes an issue where the system incorrectly predicted taxes on imported invoices. Previously, it relied on customer history, even if the XML invoice contained only one tax rate. Now, the system accurately uses the tax information directly from the imported XML file, ensuring correct tax calculations.
Original PR description
Context: When importing an XML invoice or vendor bill, the tax prediction was based on the customer’s invoice history. Example: if the imported invoice contains an item found in the history with two taxes (6% and 21%), the prediction would return both taxes (6% and 21%), even though only one tax is present in the XML file. The actual tax data present in the imported XML was not taken into account. After this commit, the prediction is more rigorous and correctly relies on the tax information provided in the XML (restricted search domain) task-5503126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249930 Forward-Port-Of: odoo/odoo#246308
This update ensures the cash drawer opens automatically when the cash details popup is accessed in the Italian Point of Sale (POS) system. Previously, the drawer only opened when the POS session was closed. This fix resolves a discrepancy in functionality for Italian fiscal printers.
Original PR description
When opening the cash details popup the cash drawer should be opened. It was not the case for the Italian fiscal printer. Steps to reproduce: ------------------- * Setup a Italian fiscal printer with cash drawer support * Open PoS * Open the cash details popup > Observation: The cash drawer does not open * Try to close the PoS session * Open the cash details popup > Observation: The cash drawer opens Why the fix: ------------ The cash drawer opening function was simply not called opw-5391094 Forward-Port-Of: odoo/enterprise#109057 Forward-Port-Of: odoo/enterprise#107987
This update prevents unexpected session rotations when using specific websocket routes (/websocket/peek_notifications and /websocket/update_bus_presence). Previously, these calls caused session expiry errors due to unchanged client-side cookies. This fix ensures smoother websocket functionality and prevents user disruption.
Original PR description
Before this commit, calling `/websocket/peek_notifications` or `/websocket/update_bus_presence` could rotate the session. Since those routes are not called by the client, the cookie is unchanged on the client side, leading to expire sessions error later on. This commit ensure we won't rotate the sessions for those routes. opw-5445323 Forward-Port-Of: odoo/odoo#250826
This update fixes an issue where dropshipped components to subcontractors were incorrectly categorized as expenses. Now, these components are properly valued within the stock valuation account, aligning with how ordered quantities are handled. This ensures accurate inventory tracking and reporting for subcontracting operations.
Original PR description
A component bought from a vendor and dropshipped to a subcontractor should the valued into the stock valuation account and not the expense one. In case this component have its "Invoice Policy" set to…
A component bought from a vendor and dropshipped to a subcontractor should the valued into the stock valuation account and not the expense one. In case this component have its "Invoice Policy" set to "ordered quantity", the `_eligible_for_stock_account` method will test if the related stock move are dropshipped https://github.com/odoo/odoo/blob/7436e0cfaf8d4b0c0e0390e8d6a3df404ba240f6/addons/stock_account/models/account_move_line.py#L31-L35 The value `is_dropship` is only set at the validation of the stock move. Due to the invoice policy, the receipt is not validated yet. close #243015 This commit will rather use the helper `_is_dropshipped()` that only rely on the location and not on the state. This commit also clean and reenable the related tests. 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#245930
This update fixes a bug where employees with scheduled future attendances couldn't check out. The fix ensures that only past attendances are considered when determining the employee's status, preventing the checkout error. This improves the usability of the kiosk mode and attendance tracking.
Original PR description
### Issue: When having an attendance in the future, the employee cannot checkout anymore. ### Steps to reproduce: - In Attendances, create an attendance in the future for an employee - Go in the kiosk mode - Manually select the employee to check in - Do the same to check out - An error pops up ### Cause: The field `last_attendance_id` of the employee contains his future attendance. The field `attendance_state` use `last_attendance_id` in its computation, so it's always "checked_out", even if an attendance is curently open for the employee. So when trying to check out an exception is raised in [`_check_validity()`](https://github.com/odoo/odoo/blob/fee6b32a8a57577bd8229c80dff6f93964f9f556/addons/hr_attendance/models/hr_attendance.py#L224-L234). ### Solution: Add a condition in the domain of `_compute_last_attendance_id()` to only consider the last **past** attendance. opw-5491867 Forward-Port-Of: odoo/odoo#248875
This update corrects a technical issue within the Odoo Enterprise payroll module that could cause discrepancies in the calculation of payslips. The fix ensures that changes to payslip line data are consistently reflected, improving the accuracy of payroll processing. This prevents potential errors and ensures employees are paid correctly.
Original PR description
Forward-Port-Of: odoo/enterprise#109112 Forward-Port-Of: odoo/enterprise#108729