Daily updates from Odoo
Wednesday, April 16, 2025
28 changes · 18.0
Security fixes and vulnerability patches
The Attendance Gantt view now hides employee names from users who are not authorized to manage or view them. This prevents misleading displays and reduces the risk of exposing restricted employee information, while HR officers and administrators retain full visibility.
Original PR description
### Issue: - In the Attendance Gantt view, users can see all employees in the company, including those they are not allowed to manage or view. - While access rules prevent users from seeing…
### Issue: - In the Attendance Gantt view, users can see all employees in the company, including those they are not allowed to manage or view. - While access rules prevent users from seeing attendance records for these employees, the employees' names still appear in the Gantt view as group headers. - This creates a misleading user experience and potentially exposes restricted information (employee names). ### Steps To Reproduce: 1. Log in as Marc Demo. 2. Open the attendance App. 3. Observe that all employees are shown as group headers. ### Solution: - Since Odoo 18.0, the `employee_id` field in `hr.attendance` was given a `group_expand='_read_group_employee_id'`. this method returns all employees in the allowed companies, without checking if the user actually manages them. - We updated the `group_expand` method `_read_group_employee_id` to restrict the list of employees shown in the Gantt view. Now, users will only see employees for whom they are set as the `attendance_manager_id`, unless they belong to the HR Officer group or are superusers, in which case they continue to see all employees. - This ensures that group headers in the Gantt view match the user's actual access rights. opw-4570867 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
The website editor's video-focused editing experience now includes fields for a video title and description. This helps teams provide clearer context for embedded videos and improve the quality of published website content.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request adds and updates themes in the staging environment so they can be tested and reviewed before production use. It also includes setup for the apps bar add-on and deployment workflow changes, helping validate visual and configuration compatibility early.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a typo in the Jordan electronic invoicing module. It is a small quality improvement that helps keep labels or messages clear and professional without changing business workflows.
Original PR description
No task ID.
Resolved issues and error corrections
Point of Sale now calculates customer change correctly when prices include tax and cash rounding is set to round up. This prevents cashiers from giving the wrong change in affected payment scenarios.
Original PR description
…unding method **Problem:** The bug is in pos, when the products are tax included and the rounding method is UP. When, the client is paying more cash than the amount, the change is not rounded as it…
…unding method **Problem:** The bug is in pos, when the products are tax included and the rounding method is UP. When, the client is paying more cash than the amount, the change is not rounded as it should be. **Steps to reproduce:** - Open point Of Sale/Configuration/Taxes - Create a new tax, with an amount of 7% - In the Advanced option tab set "Included In Price" to "Tax Included" - Create a product A with a Sales Price of 95$ and select the tax you created as the "Sales tax" - Create a product B with a Sales Price of 42$ and select the tax you created as the "Sales tax" - Open Accounting/Configuration/Management/Cash Roundings and create a new rounding - As Rounding Precision select 1.00 (the bug can happen also with other values here) - Set Rounding Strategy as "Add a rounding line" - Set Rounding Method to "Up" - Open the point of Sale app and open a store - Select one product A and two product B in the order - Click on payment and Cash - Enter a cash value of 200$ **Current behavior:** The Change has a value of 20 **Expected behavior:** The change should have a value of 21 **Cause of the issue:** In account_tax.js tax_totals_summary.base_amount_currency takes the values of values.total_excluded_currency https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L871 values.total_excluded_currency is computed as the sum of two floats With the values of our steps it creates a floating-point rounding error (the value is 88.79+78.50=167.29000000000002 and the rounding error is 0.00000000000002) https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L1166 tax_totals_summary.base_amount_currency is then used in another float addition to compute total_amount_currency.Because it's the second float addition the rounding error increases. (the value calculated is 167.29000000000002+11.71=179.00000000000003 and now the rounding error is 0.00000000000003) https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L1011 total_amount_currency is then used in pos_order.js to compute the remaining https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L157 https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L161 The remaining is used inside of the get_change method https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L887 this 0.00000000000003 rounding error has propagated to there and the value is 20.99999999999997 instead of 21 Because the rounding error comes from two consecutive float addition it's too big to be compensated by epsilon (here epsilon has a value of 1.8651746813702624e-14 which brings the value to 20.99999999999999) https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/web/static/src/core/utils/numbers.js#L71 Consequently when it's rounded down (the inversion from up to down is because the change value is negative) it's rounded to 20 instead of 21 **Fix:** Because this rounding mistake only appears with the value of "remaining" I added a rounding inside getRoundedRemaining before applying any customized rounding method. opw-4615638 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
Users can now duplicate several payment terms at once from the Invoicing list view without triggering an error. This keeps bulk setup and maintenance of payment terms working smoothly.
Original PR description
Currently, an error occurs when a user tries to duplicate more than one payment term at once from the list view. **Steps to produce:** - Install the `account` module. - Navigate to `Invoicing > Payment Terms` (list view). - Select at least two records and duplicate them. - Observe the error. `ValueError - Expected singleton: account.payment.term(3, 4, 5, 6, 7, 8, 9, 10)` An error occurs because the **copy** method accesses `self.name`, assuming a single record, when multiple records are duplicated, causing the `ValueError`. [1] - https://github.com/odoo/odoo/blob/6b970a0bfbcdac92d05389aac994c0db36730a34/addons/account/models/account_payment_term.py#L270 This commit ensures that each duplicated payment term has its name individually updated after being copied. Sentry - 6531350963
The payment provider test setup was adjusted so Worldline and AsiaPay no longer depend on accounting-only test data. This prevents failures when testing community-only installations where the accounting app is not installed.
Original PR description
It doesn't seem to be of any use, and neither module depends on account. It happens to pass if enterprise is available because avatax is `auto_install=['payment']` and has a dependency on `account`, so you install a payment module which installs `payment` which auto_installs avatax which installs `account` and you have account's groups available for `account`'s test utilities to resolve. If you only have community tho, it blows up in your face. Which I guess is what happens in the single app tests. https://runbot.odoo.com/odoo/error/163117
Unarchiving a company now correctly refreshes the related company access information for users. This prevents errors when users try to open accounting records, such as charts of accounts, after a company has been restored.
Original PR description
Issue: When a company is unarchived, the cache for some fields are not updated. Steps to reproduce: - create company b - archive company b - access CoA - unarchive company b - try to access specific chart of account, error will be raised Purpose of this PR: when we unarchive a company we call the `_get_company_ids` method on the user to update the cache. opw-4427576
This fix adjusts payment-related tests so they only run checks when the optional supporting apps they rely on are installed. It helps avoid false test failures and keeps development and release validation smoother without changing customer-facing payment behavior.
Original PR description
`payment` does not depend on `account`, it thus can't unconditionally use `account` groups. Skip tests if `account` is not installed (matches `account_custom` behaviour). `account_custom` does not depend on `product`, so can't use `product.product` unconditionally. `setUpClass` doesn't seem useful so just remove it entirely.
Peppol demo mode has been adjusted to behave more like the production service. This helps teams test electronic invoicing scenarios with more realistic results before using Peppol in live operations.
Original PR description
… behavior Fix the demo mode of Peppol to be closer to the behavior in production. task-no (review with TSB/PMAX 31/03/25)
This fixes an error that blocked users from creating a debit note from an existing credit note in Latin American invoicing flows. Businesses can now correct an incorrect credit note directly, reducing manual work and avoiding interruptions in localized accounting processes.
Original PR description
### Description of the issue/feature this PR addresses: In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo…
### Description of the issue/feature this PR addresses: In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice. ### Steps to reproduce the error. 1. Install the Argentine localization 2. Create an invoice and post it 3. From the invoice using the wizard create a credit note and post it. 4. From the credit note open the wizard to create a debit note. 5. On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value. ### Current behavior before PR: When creating a debit note from a credit note get an error. ### Desired behavior after PR is merged: We can create a debit memo from a credit note. Adhoc tiket 69428 - 69854 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale now keeps unavailable pricelists, categories, and products hidden when paid orders are loaded. This prevents staff from seeing or selecting items that should be restricted, keeping the register interface aligned with configured limits.
Original PR description
Before this commit, when limited categories were enabled and a limited pricelist was selected, loading the paid orders caused unavailable categories, pricelists, and products to appear in the PoS interface. This commit filters out these non-available items even if they are loaded, ensuring that only valid data is shown. opw-4629843 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users now get a clearer warning when they try to create a bank account that already exists but was archived. This avoids a confusing uniqueness error and updates activity history wording from deleted to archived, matching what actually happens.
Original PR description
Commit ebb09234e6444576e7e934f53de1d23a0d9760d2 made it so that bank account are archived instead of deleted meaning that they are never deleted in the DB. If a user tries to create a new bank account for the same partner with the same account number, the following validation error is raised: "The operation cannot be completed: The combination Account Number/Partner must be unique." This commit introduces a new UserError when a user attempts to create an account that was previously archived. It also updates the message in the chatter from "deleted" to "archived." opw-4669340 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Clearing the description from a section line on an invoice no longer causes an error. This prevents interruptions while editing invoices and keeps the invoicing workflow stable.
Original PR description
This error occurs when a user `adds a section` in an `invoice line`, enters a description, and then remove the description. Step to reproduce : - Install module `Invoicing`. - Create a `new Invoice`. - In the Invoice Line, `add a section`. - Enter a description and save. - Remove the description and click anywhere on the screen. KeyError: `name` This error occurs when the system tries to update an invoice line section but the `name` field is missing from the update values, causing a KeyError. This commit fixes the issue by using optional chaining and nullish coalescing to ensure productName returns an empty string instead of undefined. Sentry - 6327760196 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes test setup problems in the Sales Manufacturing area by avoiding attempts to fill fields that are hidden in certain scenarios. It helps keep automated checks reliable as test coverage expands across all modules, reducing noise from false failures.
Original PR description
Revealed by the changes to single app tests (which now test every module). While at it, remove a few unnecessary setting of product-id on non-variant scenarios, they don't blow up but they look a lot like odoo/odoo#206050 and why bother? https://runbot.odoo.com/odoo/error/163244
This update fixes two issues: customer details from UrbanPiper orders now refresh correctly when the same phone number is reused, and Mexican EDI documents can correctly read fiscal folio data from longer uploaded XML files. This helps keep customer records accurate and prevents missing fiscal identifiers on payment documents.
Fixes an issue where uploading longer Mexican Payment 2.0 XML files could leave the Fiscal Folio blank. The system now reads the full XML content instead of a file-size placeholder, ensuring the document identifier is extracted correctly.
Original PR description
**Steps to reproduce:** With mexican localisation installed: - Open form view for the model 'l10n_mx_edi.document' - Prepare a payment document in the Payment-20 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos20.xsd) - Remove existing attachment - Change attachment on the document to the relatively long XML file **Issue:** After saving the change, the attachment_uuid (Fiscal Folio) is left blank. **Cause:** Normally, the uuid should be extracted from the uploaded attachment, but the computation of the 'raw' field on the attachment returns the value "b'56.00 bytes'", leaving the attachment_uuid field empty because the XML is assumed to be in the wrong format. The issue doesn't exist for shorter XML files in the Payment-10 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos10.xsd) **Solution:** Before computing the attachment_uuid from the attachment, we set the bin_size to False in the context. opw-4641487
Orders coming from the same phone number now refresh the customer's name and address when those details change. This helps restaurants and delivery operations keep customer records accurate and avoid sending orders to outdated addresses.
Original PR description
Before this commit: ======================== - The customer name was not updated when an order was received from the same phone number but with a different name. - If the ZIP code remained the same, changes in the address were not reflected in Odoo. After this commit: ======================== - The customer name is now updated if it differs, even when the phone number is the same. - Address updates are now applied in Odoo, even if the ZIP code has not changed. --- task - 4714559
This fixes an error that could appear when exporting the XML file for the Italian tax return. The export now uses the correct process depending on whether it is run from the tax report or from the closing entry, helping users complete the required filing without interruption.
Original PR description
Since https://github.com/odoo/enterprise/commit/7323435468c8db15cd5643f7d6ecf5928ab2f3dc , a traceback shows up when exporting the xml of the italian tax return. It was fixing a traceback on the closing entry export which was not usable in the report itself an created another issue there. This fix makes the method chosen depend on wether we are in the report or the closing entry. no-task
Miscellaneous changes
Steps to reproduce: - Drag and drop image gallery snippet. - Delete the snippet. - Click on Undo. - The snippet appears but images will not be there. The issue comes from the fact that when the snippet is deleted, a relayout of the snippet is triggered for each image present in it. This is necessary when an image is deleted, but not when the snippet itself is deleted. task-4690318 Forward-Port-Of: odoo/odoo#206019
Original PR description
Steps to reproduce: - Drag and drop image gallery snippet. - Delete the snippet. - Click on Undo. - The snippet appears but images will not be there. The issue comes from the fact that when the snippet is deleted, a relayout of the snippet is triggered for each image present in it. This is necessary when an image is deleted, but not when the snippet itself is deleted. task-4690318 Forward-Port-Of: odoo/odoo#206019
Purpose of this commit: This commit aims to restrict the log notes to not be squashed when posted on a record from a chat window. task-4718225 Forward-Port-Of: odoo/odoo#205998
Original PR description
Purpose of this commit: This commit aims to restrict the log notes to not be squashed when posted on a record from a chat window. task-4718225 Forward-Port-Of: odoo/odoo#205998
Before this commit, if the language name couldn't be detected by babel, attempting to translate the message resulted in a crash with `UnknownLocaleError`. Steps to reproduce: - make a livechat with visitor with `crh-Latn` locale - as livechat operator, attempt to translate the message This happens because babel is unable to parse `crh-Latn`, which stands for Crimean Tatar based on Latin script. This locale has been officially approved by the National Commission on the Crimean Tatar Langu
Original PR description
Before this commit, if the language name couldn't be detected by babel, attempting to translate the message resulted in a crash with `UnknownLocaleError`. Steps to reproduce: - make a livechat with…
Before this commit, if the language name couldn't be detected by babel, attempting to translate the message resulted in a crash with `UnknownLocaleError`. Steps to reproduce: - make a livechat with visitor with `crh-Latn` locale - as livechat operator, attempt to translate the message This happens because babel is unable to parse `crh-Latn`, which stands for Crimean Tatar based on Latin script. This locale has been officially approved by the National Commission on the Crimean Tatar Language on April 4th [1], very recently from the date of this commit. Because of the recency of the new locale, babel lack its parsing. Failure lead to error `UnknownLocaleError`, which is a problem because data of translated message also passes the Language name, which requires the good parsing of the locale by babel. This commit fixes the issue by displaying the language name as the locale code in case babel was unable to parse it. In practice this happens rarely, and there's incentive to update babel as quickly as possible, but that's not a reason to display the translated message even if it cannot deduce the lang name. [1]: https://babel.ua/en/news/116901-ukraine-approves-new-crimean-tatar-orthography-based-on-latin-script Forward-Port-Of: odoo/odoo#205943
…simplfied When the partner has no VAT and it is within Europe and it is below the simplified invoice limit, we could indicate the invoice as simplified by default. If it is wrong, the user can still change it. opw-4633564 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#204630
Original PR description
…simplfied When the partner has no VAT and it is within Europe and it is below the simplified invoice limit, we could indicate the invoice as simplified by default. If it is wrong, the user can still change it. opw-4633564 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#204630
Problem: When calling `modify_image` for an attachment linked to a record that hasn't been created yet (`res_id` is `None`), a traceback occurs. This is because `fields` lacks the `res_id` key when we call: request.env[fields['res_model']] .browse(fields['res_id']) .check_access_rights('write') Solution: Use `0` as default `res_id`. This is consistent with what `get_existing_attachment` already does: fields['res_id'] = fields.get('res_id') or 0 Steps to re
Original PR description
Problem:
When calling `modify_image` for an attachment linked to a record that hasn't been created yet (`res_id` is `None`), a traceback occurs. This is because `fields` lacks the `res_id` key when we call:
request.env[fields['res_model']]
.browse(fields['res_id'])
.check_access_rights('write')
Solution:
Use `0` as default `res_id`. This is consistent with what `get_existing_attachment` already does:
fields['res_id'] = fields.get('res_id') or 0
Steps to reproduce:
1. Go to "Email Marketing" > "New".
2. Fill in the "Subject" and choose a mailing list.
3. In the mail body, insert a template containing an image.
4. Click on the image and replace it.
5. Save (only at this step). → Traceback occurs since `modify_image` is called with a `None` res_id.
opw-4715999
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#205838STEPS ------------ 0. You'll require IAP credit for PDF extraction 1. Create 1 POs (we'll call it PO-1) and set the vendor as the current company 2. Duplicate PO-1 (we'll call the duplicate PO-2) and change the amount value of one product 3. Create an invoice with the extact same values as PO-2 and set the customer reference (in the 'Other Info' tab) to "PO-2"; we'll call it INV-1 4. Create a bill and use the Auto-Complete field to manually select PO-1 5. Drag and drop INV-1 in the chatte
Original PR description
STEPS ------------ 0. You'll require IAP credit for PDF extraction 1. Create 1 POs (we'll call it PO-1) and set the vendor as the current company 2. Duplicate PO-1 (we'll call the duplicate PO-2) and change the amount value of one product 3. Create an invoice with the extact same values as PO-2 and set the customer reference (in the 'Other Info' tab) to "PO-2"; we'll call it INV-1 4. Create a bill and use the Auto-Complete field to manually select PO-1 5. Drag and drop INV-1 in the chatter -> IAP should trigger -> The chatter says ''' The invoice already contains lines, it was not updated from the attachment. ''' but yet, it updated the purchase reference to PO-2 and updated the lines OBJECTIVE ------------ If a bill has lines, it should not be updated with the content of the PO. task-4633298 Forward-Port-Of: odoo/enterprise#83336 Forward-Port-Of: odoo/enterprise#83246
https://runbot.odoo.com/odoo/error/163099 This issue became visible as part of the change to test ACLs (removal of demo data, possibly change to groups too) as well as running the "single app tests" on *every module*, not just the apps. The issue is that `self.Requests.user` and `self.employee_user` are unrelated (the amazingly named `self.employee_user` doesn't even have a user). On leave creation, this triggers the rule `hr_leave_rule_employee_update` which checks if: - The current us
Original PR description
https://runbot.odoo.com/odoo/error/163099 This issue became visible as part of the change to test ACLs (removal of demo data, possibly change to groups too) as well as running the "single app tests"…
https://runbot.odoo.com/odoo/error/163099 This issue became visible as part of the change to test ACLs (removal of demo data, possibly change to groups too) as well as running the "single app tests" on *every module*, not just the apps. The issue is that `self.Requests.user` and `self.employee_user` are unrelated (the amazingly named `self.employee_user` doesn't even have a user). On leave creation, this triggers the rule `hr_leave_rule_employee_update` which checks if: - The current user is the employee's, which is not the case because the employee doesn't have a user. - Or the current user is the employee's leave manager, which is also not the case because the employee does not have a leaves manager. As a result the creation of the leaves fails immediately. Fix in 17.4 as the test was introduced in #53940 which was merged in (what would become) 17.3, even though the test setup means it might not be possible to trigger there because of all the demo messing with groups. Forward-Port-Of: odoo/enterprise#83427
**Steps to reproduce:** - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Go to "Settings / Technical / Database Structure / Decimal Accuracy" - Set 4 digits for "Product Price" - Create a product with a lower price than 0.01 (e.g. 0.0045) - Create an invoice: * Customer: [a Peruvian customer] (e.g. Comercial Constructora los Patitos S.A.) * Product: [the created product] * Quantity: 100 - Confirm the invoice - Process the invoice by the E-i
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Go to "Settings / Technical / Database Structure / Decimal Accuracy" - Set 4 digits for…
**Steps to reproduce:** - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Go to "Settings / Technical / Database Structure / Decimal Accuracy" - Set 4 digits for "Product Price" - Create a product with a lower price than 0.01 (e.g. 0.0045) - Create an invoice: * Customer: [a Peruvian customer] (e.g. Comercial Constructora los Patitos S.A.) * Product: [the created product] * Quantity: 100 - Confirm the invoice - Process the invoice by the E-invoicing service **Issue:** An error is triggered because "PriceTypeCode" is set to "02", which is the code used to declare that it is free. But in this case, it is not free. **Cause:** "PriceTypeCode" is computed by using "is_zero" method of the currency on the unit price. As the decimal accuracy of the currency is set to 2 and the unit price is 0.0045, "is_zero" is returning True. **Solution:** Compute "PriceTypeCode" from the line subtotal instead of the unit price. This is not perfect as it can also be lower than 0.01, but it's less probable. opw-4608671 Forward-Port-Of: odoo/enterprise#83401 Forward-Port-Of: odoo/enterprise#82019
The miscellaneous were displayed in the VIES summary report (even if it was rare as it needs to have the field l10n_cz_transaction_code set). A common case would be to create deferred entries with this transaction field set. opw-4688616 Forward-Port-Of: odoo/enterprise#83112
Original PR description
The miscellaneous were displayed in the VIES summary report (even if it was rare as it needs to have the field l10n_cz_transaction_code set). A common case would be to create deferred entries with this transaction field set. opw-4688616 Forward-Port-Of: odoo/enterprise#83112