Daily updates from Odoo
Saturday, August 2, 2025
12 changes
7 changes
Resolved issues and error corrections
Invoice base rounding differences are now spread across invoice lines instead of being placed on a single line. This helps generated UBL/PEPPOL electronic invoices stay within validation limits and reduces the risk of rejected invoices.
Original PR description
Before this commit, the behaviour of `_round_base_lines_tax_details` was to assign all the base line delta to the largest base line. However, when generating the UBL, the delta would then get included in the LineExtensionAmount, but BIS3 rule PEPPOL-EN16931-R120 enforces that the LineExtensionAmount must be at most 2 cents away from `(quantity * net price) + sum(charges) - sum(allowances)`. Effectively this means that we can put at most 2 cents base delta on each invoice line. After this commit, `_round_base_lines_tax_details` redistributes the base delta evenly over all the base lines. task-none Forward-Port-Of: odoo/odoo#221569 Forward-Port-Of: odoo/odoo#219244
Users limited to a company branch can now open the Accounting Chart of Accounts without hitting an access error. This removes a blocker for branch accounting teams while keeping company access rules intact.
Original PR description
#### Steps to reproduce
- Create a branch in a company that has a CoA installed.
- Create a user that only has access to the branch
- Login as the user
- Try to open Accounting > Configuration > Chart of Accounts
- You get an AccessError in your face.
#### Analysis
- When calling `web_search_read` on `account.account`, the `company_ids` field is loaded into cache by `search_fetch`.
- Since the user does not have access to the parent company, the parent company will not be in the account's `company_ids` in cache.
- When calling `_check_access` in `fetch`, the `filtered_domain` (even though it is called behind `sudo`) will use the `company_ids` in cache to determine whether the accounts can be accessed, triggering the `AccessError`.
#### Solution
- Set `depends_context=('uid',)` on the `company_ids` field to keep separate sudo / non-sudo caches for the field.
opw-4730107
Forward-Port-Of: odoo/odoo#220294
Forward-Port-Of: odoo/odoo#217752This fixes tax calculations for invoices, sales, purchases, and point of sale when down payments or global discounts are used across multiple currencies. Businesses should see more reliable totals and tax amounts, especially when manual tax adjustments or foreign currencies are involved.
Original PR description
…anual_tax_amounts When using 'manual_tax_amounts', both 'raw_tax_amount' & 'tax_amount' get the forced tax amount. However, by doing that, we lost accuracy in the raw amount. With this commit, the manual_tax_amounts become a way to ensure some results in '_round_base_lines_tax_details'. So after this commit, the manual_tax_amounts won't be manage in '_get_tax_details' anymore. That way, we could also use the manual_tax_amounts for amounts in company's currency. For down payment/global discount, let's handle both currencies instead of only the foreign one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219930
This fix adjusts the demo data setup so restaurant point-of-sale sample data loads in the right order. It prevents failures when demo restaurant data is loaded through a custom point-of-sale flow, improving setup reliability without changing day-to-day user features.
Original PR description
Finetuning of ffb976c3ed5fbcff2e5d06a3183bab2fbe0307ff to ensure that the product attributes demo data are loaded before loading the pos restaurant demo data --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an error that could block users from registering vendor payments in the Vietnam localization when bank account details were configured for sending money. The validation order was corrected so payments can proceed normally instead of showing an unexpected failure.
Original PR description
### Issue: When creating a vendor with a bank account and certain fields configured, trying to register a payment could raise a KeyError: 'none'. This was due to the incorrect order of validations in…
### Issue: When creating a vendor with a bank account and certain fields configured, trying to register a payment could raise a KeyError: 'none'. This was due to the incorrect order of validations in _check_for_qr_code_errors, introduced in PR #219566. This commit reorders the checks to ensure proxy_type is validated before being used. ### Affected Versions: 17.0 and later ### To reproduce: 1. Install account_accountant, l10n_vn 2. Select VN Company 3. Go to Accounting > Vendors > Vendors 4. Create a partner with country set to Vietnam 5. In Accounting tab, add a bank account with: - Account Name - Bank - Currency - "Send money" set to True 6. Go to Accounting > Vendors > Payments 7. Try to create a payment for that partner ##### Expected: Payment is created successfully ##### Current: KeyError: 'none' is raised OPW-4976541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221522
This fixes a display issue in Mail where an email recipient prompt could cover an alert when sending to a contact without an email address. Users will now see important warning messages clearly, reducing confusion during the send process.
Original PR description
## Before this commit When the user clicks the Send button and the partner does not have an email address, an alert message is raised. However, the recipient popover `(email input prompt)` appears above the alert, visually blocking it and breaking the expected `modal` behavior. <img width="1844" height="873" alt="image" src="https://github.com/user-attachments/assets/31585785-27d6-48d4-b64c-c88b5f9426d6" /> ## After this commit The recipient popover's `z-index` is adjusted so that it no longer overlaps alert messages. This ensures that alerts remain visible and unobstructed, preserving clarity in the UI and respecting the intended visual hierarchy. <img width="1736" height="764" alt="image" src="https://github.com/user-attachments/assets/9ff258b4-2072-4100-bcc4-b8420d5d1aa2" /> Forward-Port-Of: odoo/odoo#221313
This fixes UrbanPiper POS behavior so draft cart items are no longer lost when the page is refreshed. It also ensures product variants inherit the correct meal type during menu synchronization, helping restaurants publish accurate vegetarian or non-vegetarian information.
Original PR description
Steps to reproduce: - Installed urbanpiper - Open POS and add product to cart - Refresh the page . Issue: - Product in the cart automatically removes. Cause: - Order lines were filtered out when urban piper is enabled. Fix: - Filter out the order lines which are not associated with online order. Issue 2: - While menu sync to Urban piper, 'product variant' food_type is sent as NA although main product food_type is set as Vegetarian or Non-Vegetarian. Fix: - Set variant food_type as main product food_type. task- 4971503 Forward-Port-Of: odoo/enterprise#91098
2 changes
Resolved issues and error corrections
Vendor payments in the Vietnam localization could fail when certain bank account details were configured. The validation order was corrected so payments can be created normally instead of showing an unexpected error.
Original PR description
### Issue: When creating a vendor with a bank account and certain fields configured, trying to register a payment could raise a KeyError: 'none'. This was due to the incorrect order of validations in…
### Issue: When creating a vendor with a bank account and certain fields configured, trying to register a payment could raise a KeyError: 'none'. This was due to the incorrect order of validations in _check_for_qr_code_errors, introduced in PR #219566. This commit reorders the checks to ensure proxy_type is validated before being used. ### Affected Versions: 17.0 and later ### To reproduce: 1. Install account_accountant, l10n_vn 2. Select VN Company 3. Go to Accounting > Vendors > Vendors 4. Create a partner with country set to Vietnam 5. In Accounting tab, add a bank account with: - Account Name - Bank - Currency - "Send money" set to True 6. Go to Accounting > Vendors > Payments 7. Try to create a payment for that partner ##### Expected: Payment is created successfully ##### Current: KeyError: 'none' is raised OPW-4976541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221522
This fix prevents in-progress POS orders from losing their cart items after a page refresh when UrbanPiper is enabled. It also ensures product variants sent to UrbanPiper keep the same vegetarian or non-vegetarian label as their main product, improving menu accuracy for online customers.
Original PR description
Steps to reproduce: - Installed urbanpiper - Open POS and add product to cart - Refresh the page . Issue: - Product in the cart automatically removes. Cause: - Order lines were filtered out when urban piper is enabled. Fix: - Filter out the order lines which are not associated with online order. Issue 2: - While menu sync to Urban piper, 'product variant' food_type is sent as NA although main product food_type is set as Vegetarian or Non-Vegetarian. Fix: - Set variant food_type as main product food_type. task- 4971503 Forward-Port-Of: odoo/enterprise#91098
2 changes
Resolved issues and error corrections
Users with limited timesheet access can now start and stop timers on tasks they are allowed to access, even when the parent project is private. This prevents unnecessary access errors and lets field service work be recorded correctly.
Original PR description
Before this commit, when the project is private and the user can only access to some tasks inside that project, he can create timesheets but cannot stop timer in one of those tasks when…
Before this commit, when the project is private and the user can only access to some tasks inside that project, he can create timesheets but cannot stop timer in one of those tasks when `industry_fsm` module is installed. This commit makes sure the user can start/stop a timer on task for which he has access to even if the project is private and he does not have access to it. Steps to reproduce the issue: ---------------------------- 0. install industry_fsm module 1. Create a project A with "followers" as privacy visibility 2. Create a task A and assign it to a project user with lowest timesheet access right. 3. log in as that user 4. Start a timer on Task A 5. Stop the timer and confirm the wizard Expected Behavior: ----------------- The timesheet should be created without any issue Current Behavior: ---------------- An Access error is raised because the user has no access to the project. task-4680412 Forward-Port-Of: odoo/enterprise#91370 Forward-Port-Of: odoo/enterprise#84807
This fix keeps draft POS cart items from disappearing after a page refresh when UrbanPiper is enabled. It also sends the correct meal type for product variants during UrbanPiper menu sync, improving accuracy for online ordering menus.
Original PR description
Steps to reproduce: - Installed urbanpiper - Open POS and add product to cart - Refresh the page . Issue: - Product in the cart automatically removes. Cause: - Order lines were filtered out when urban piper is enabled. Fix: - Filter out the order lines which are not associated with online order. Issue 2: - While menu sync to Urban piper, 'product variant' food_type is sent as NA although main product food_type is set as Vegetarian or Non-Vegetarian. Fix: - Set variant food_type as main product food_type. task- 4971503 Forward-Port-Of: odoo/enterprise#91578 Forward-Port-Of: odoo/enterprise#91098
1 change
Resolved issues and error corrections
This fix prevents an error when registering payments for Vietnamese vendors with specific bank account settings. Users can now create those vendor payments normally, improving reliability for Vietnam accounting workflows.
Original PR description
### Issue: When creating a vendor with a bank account and certain fields configured, trying to register a payment could raise a KeyError: 'none'. This was due to the incorrect order of validations in…
### Issue: When creating a vendor with a bank account and certain fields configured, trying to register a payment could raise a KeyError: 'none'. This was due to the incorrect order of validations in _check_for_qr_code_errors, introduced in PR #219566. This commit reorders the checks to ensure proxy_type is validated before being used. ### Affected Versions: 17.0 and later ### To reproduce: 1. Install account_accountant, l10n_vn 2. Select VN Company 3. Go to Accounting > Vendors > Vendors 4. Create a partner with country set to Vietnam 5. In Accounting tab, add a bank account with: - Account Name - Bank - Currency - "Send money" set to True 6. Go to Accounting > Vendors > Payments 7. Try to create a payment for that partner ##### Expected: Payment is created successfully ##### Current: KeyError: 'none' is raised OPW-4976541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221522