Daily updates from Odoo
Friday, January 23, 2026
351 changes
19 changes
New functionality added to Odoo
This update adds support for the Caribbean Guilder (XCG) as a new currency option within Odoo. It's specifically configured as the default currency for Curaçao and Sint Maarten, expanding Odoo's currency coverage to include these regions. This change allows users to accurately record financial transactions in XCG.
Original PR description
Introduce the Caribbean Guilder (XCG) as an available currency and set it as the default currency for Curaçao and Sint Maarten. Related PR-https://github.com/odoo/enterprise/pull/104404 taskID-5490423 Forward-Port-Of: odoo/odoo#243955
This update introduces support for the Caribbean Guilder (XCG) currency in Odoo Enterprise. It’s now the default currency for Curaçao and Sint Maarten, aligning our financial data with the latest community standards. This change ensures accurate reporting and transactions for businesses operating in these regions.
Original PR description
Align enterprise currency data with the community with addition of new currency XCG. Related PR-https://github.com/odoo/odoo/pull/243955 taskID-5490423 Forward-Port-Of: odoo/enterprise#104404
Enhancements to existing features
This update enhances the user experience in the Discuss meeting view by increasing the size of key buttons and refining the overall design. It also includes smaller avatar images and a more modern card name appearance. These changes improve usability and visual appeal within the discuss calls feature.
Original PR description
- bottom buttons in meeting view are bigger - layout buttons in meeting view are moved with side meeting actions - side meeting actions uses non-bg visual - meeting bottom buttons now have hover effect Also makes these other UI changes to discuss calls: - card name has text-shadow instead of dark bg color - avatar img size has been reduced (100px to 80px, was too big) Task-5462123 Before / After <img width="959" height="644" alt="Screenshot 2026-01-02 at 18 16 50" src="https://github.com/user-attachments/assets/b2bd4128-c298-4bfe-9843-4ff9aa2a7595" /> <img width="954" height="639" alt="Screenshot 2026-01-02 at 18 01 24" src="https://github.com/user-attachments/assets/5b954d86-e65e-4c97-8485-9c62200f60b0" />
Resolved issues and error corrections
This update resolves an issue preventing proper employee filtering within the l10n_ch_hr_payroll module. By using 'sudo' for filtering, the system now reliably processes payroll data regardless of the user's specific role (Payroll or Assistant). This ensures consistent and accurate payroll processing.
Original PR description
We perform the filtering with sudo so that it can be done even in cases where the user is not a Payroll/Assistant. This is primarily to fix the following runbot error, but in general to avoid blocking errors where they shouldn't happen. Runbot Error: 237851
This update restricts who can validate payslips within the Odoo Enterprise system. Previously, users with the Payroll Assistant role could validate payslips, which has now been limited to Officers and Managers only. This change enhances security and ensures appropriate access controls for payroll processes.
Original PR description
Cause: Currently a user with payroll Assistant role can validate payslips After the fix: Only officers and managers should have the ability to validate payslips Task-5376223
This update fixes a bug that prevented users from successfully uploading attachments to expense records. The issue stemmed from a restriction in how Odoo handles attachment records, specifically when an attachment wasn't linked to an expense. The fix ensures attachments are correctly associated with expenses, improving the user experience.
Original PR description
Currently, an exception occurs when a user tries to open expenses or upload an attachment on expenses after following the steps described below. - Create an attachment with an `image/PDF` file and set the resource model as `hr.expense` - Go to expense > Create a new expense and upload the same `image/PDF` file This issue occurs because when a user creates an attachment without specifying a `res_id`, it defaults to `0`. In the previous version, `0` was allowed in the record set. However, after the changes introduced in [1], `falsy` values like `0` are strictly disallowed in the record set. This commit fixes the issue by reading only the `read_group` attachments that have a valid `res_id`, effectively ignoring attachments without a `res_id`. [1]: https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f sentry-7201563878
This update resolves an issue where incorrect data IDs within Odoo could trigger errors. The fix adds a filter to ensure all IDs used for browsing `ir.model.data` are valid, preventing potential disruptions to the system. This improves stability and reliability.
Original PR description
Since https://github.com/odoo/odoo/pull/227477, using falsy ids ids illegal This commit adds an additional filter to the domain used to browse `ir.model.data` to compute the following fields:…
Since https://github.com/odoo/odoo/pull/227477, using falsy ids ids illegal
This commit adds an additional filter to the domain used to browse `ir.model.data` to compute the following fields: `(menus|views|reports)_by_module` in order to avoid selecting any that would contain a falsy `res_id` and thus cause the above-mentioned assertion to fail.
One way to reproduce this in a new trial:
- Create a new trial with several modules: `account`, `crm`, `project`, `sales`
- Install `web_studio`
- Uninstall `base_automation`
- Traceback
```
File “/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py”, line 5200, in browse
assert all(ids) or all(isinstance(x, NewId) or x for x in ids), “Invalid falsy real id”
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```
This is due to an `ir.model.data` containing a falsy res_id in the internal code of `saas_trial` (`installed-17`)
This fix will avoid any additional traceback like this one.
opw-5865316This update resolves an issue where chat windows were overlapping the website editor panel, causing a disrupted user experience. The fix adjusts the chat window's starting position dynamically within the website editor context, ensuring a cleaner and more functional design.
Original PR description
Before this commit, chat windows were overlapping website editor panel. This happens because chat windows had a hard-code starting position of 15px starting from the right of the screen, which is applied in all contexts. This commit turns `BUBBLE_START` into computed field, so that this is patched when in website editor to offset it next to website editor panel, as to not overlap it. Before / After <img width="1918" height="604" alt="Screenshot 2026-01-16 at 18 11 50" src="https://github.com/user-attachments/assets/25051548-0c6e-4aea-97a1-459558601636" /> <img width="1920" height="605" alt="Screenshot 2026-01-16 at 18 21 53" src="https://github.com/user-attachments/assets/191c1323-380d-4328-b9c5-cf76deeb1d6a" />
This update resolves a minor UI issue related to the ActivityWatch timesheet download screen within the Enterprise version of Odoo. The fix ensures a smoother and more reliable user experience when downloading timesheet data. This improves the usability of a key reporting feature.
Original PR description
This PR fixes some minor stuff that didn't make it into the previous PR.
A technical error preventing mail template creation was fixed. The issue stemmed from a validation process unaware of rental order functionality, causing a template creation failure. The fix involved moving a necessary method to the `sale_renting` module to ensure compatibility.
Original PR description
The mail template `mail_template_sale_cart_recovery` creation fails in some cases if there is a rental order in the database. Indeed, during a template creation, the first record of the corresponding model is used to validate the template validity. In this case, the template is only meant for e-commerce orders and there won't be any e-commerce rental order without `website_sale_renting` but the validation is not aware of functional specificities, leading to a traceback because the method `_get_rental_pricing_description` doesn't exist when only `sale_renting` and `website_sale` are installed. To avoid this error, we move the method to `sale_renting`, even though there is no real life flows where this was breaking (except templates validation ofc). Was fixed first with c3f5dafa23a8b1fd36eaedd83a575b717e5e9377 but moved back into `website_sale_renting` by mistake with fd1d7f91e7e60a20a5401201ff89a7e875faad82
This update fixes a warning message appearing in Point of Sale when expiration dates are disabled. The issue stemmed from a missing field in the product data, preventing accurate lot number retrieval. The fix ensures the system correctly handles this scenario, improving the user experience.
Original PR description
Steps to reproduce: = - Install only `point_of_sale` with demo data. - Ensure `Settings->Inventory->Traceability->Expiration Dates` is unchecked. - Open POS. - Click a product that uses lots. Issue: = - PoS always shows the warning “The existing serial/lot numbers could not be retrieved. Continue without checking the validity of serial/lot numbers?” even though lots are available. - Terminal error:`AttributeError: 'stock.lot' object has no attribute 'expiration_date'` Reason: = - When *Expiration Dates* is unchecked and the `product_expiry` module is not installed, the `expiration_date` field is not available (it is defined in `product_expiry` module by inheriting `stock.quant` model). Fix: = - Check field existence using the model’s _fields registry before accessing `expiration_date`, to prevent traceback. runbot-234958, 234959, 234960, 234961, 234964
This update resolves issues related to access rights for employee data when using Stripe expense cards. It allows expense card managers to access necessary employee information required by Stripe, while also correcting issues with card limit calculations and time interval restrictions to ensure accurate expense tracking.
Original PR description
[FIX] hr_expense_stripe: Fix access rights Fix access rights to some employee fields in the cardholder creation. Allowing the expense card manager to read some employee private fields as stripe requires some identity checks Improve activate card access rights checks when activating a card [FIX] hr_expense_stripe: Fix card limits Fix the limits computation for the cards, only looking at expenses paid with said card without unintended granularity. Also fixing the short time intervals that were considered as an all time limit Forward-Port-Of: odoo/enterprise#105149
This update resolves an issue where enlarging icons in the bills list view also disrupted the layout of the invoicing dashboard. The fix utilizes a new setting to display larger icons only when needed, ensuring a consistent and professional appearance for users.
Original PR description
As a part of task-5258726 the icons of no-content help in bills list view were enlarged. The icons used there were also used in the module dashboard, so enlarging them messed the dashboard styling. This commit fixes this issue by using a prop `largeIcons` on the `BillGuide` componenet to make it with large icons when needed only (in the bills list view no content help). task-5801970 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245209
This update resolves an issue where the website's cookie consent settings weren't being saved correctly after changing the 'I agree' button style to 'Default'. The fix ensures that the user's consent is properly recorded when this style change is applied, maintaining consistent cookie consent management.
Original PR description
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape…
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape to "Default" (this applies the `.btn-primary` class). & Save 4. Accept the cookies & refresh -> The cookie bar appears again because the consent was not saved. Cause: ====== The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup. By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written. Solution: ========= Override the event to avoid side effects on hide. opw-5484578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244875 Forward-Port-Of: odoo/odoo#243562
This update fixes a potential discrepancy in tax reporting within the Point of Sale module. Previously, the total tax base amounts in reports could slightly differ from the sum of individual line items due to rounding. This change ensures more accurate tax calculations and reporting, improving the reliability of financial data.
Original PR description
Before this commit, the total base amounts of taxes might be different from summing the base amounts of each line, due to rounding issues. opw-5408201 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244280
This update fixes a potential issue in the Point of Sale reporting where rounding errors could incorrectly identify small cash differences as non-zero. Previously, the system didn't account for currency rounding, leading to inaccurate cash difference calculations and unintended removal of transactions. This ensures more precise reporting of cash flow.
Original PR description
Before this commit, when calculating the cash difference in the report, the code did not account for currency rounding. This could lead to situations where a very small cash difference, due to rounding errors, was not recognized as zero, resulting in the unintended removal of cash moves. opw-5489958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245251
This update resolves an issue where printers would become unavailable for extended periods after disconnecting, leading to user errors and double printing. The change introduces a counter to prevent unnecessary removal of printers from the system, ensuring printers are reliably available and jobs are processed correctly.
Original PR description
On the iot box we check the number of printers connected rarely to avoid spamming the network. This leads to some situations where if a printer is disconnected it becomes unusable for the next 2…
On the iot box we check the number of printers connected rarely to avoid spamming the network. This leads to some situations where if a printer is disconnected it becomes unusable for the next 2 minutes or even more if it disconnects again just before the next get_devices call in the interface. The printers are often not listed by cups for short time which currently leads to them being deleted from our list of connected devices on the iot box. However in reality the printer reconnects faster than 2 minutes and often becomes available again within a couple of seconds. Currently if you print something on it you will get an error when checking the job status but the job will still be queud and printed whenever it reconnects. The user in pos can then press "retry" which will lead to a double printing. This PR adds a counter for the printer disconnections and only removes the printer from our list if it wasn't detected 3 times in a row by cups. Now since not deleted from cups the print job is queud and whenever the printer reconnects it's printed. The user will not get an error anymore which will avoid double printing and the printer will remain available unless it's really disconnected Forward-Port-Of: odoo/odoo#244759 Forward-Port-Of: odoo/odoo#244076
This update addresses a technical issue preventing Odoo from correctly importing a standard exception within the Requests library. The fix involves installing a specific version of Requests and adding a necessary import statement. This resolves an error that was caused by a recent change in the Requests library itself, ensuring Odoo continues to function smoothly.
Original PR description
Installing `requests==2.25.1` and using the following line of code:
from requests.exceptions import JSONDecodeError
It raises the following error:
ImportError: cannot import name 'JSONDecodeError' from 'requests.exceptions' (python3.10/site-packages/requests/exceptions.py)
It was removed from the following commit in the `requests` package:
https://github.com/psf/requests/commit/db575eeedcfdb03bf31285afd3033e301df8b685
This change fixes this error importing the original exception from `json` package
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#245075This update prevents excessive email notifications to managers when employees submit expenses. Previously, managers received emails for every state change, which was causing spam. Now, a weekly email is only sent if a manager has outstanding expenses awaiting approval, streamlining the approval process and reducing unnecessary communication.
Original PR description
When an employee submits an expense and assigns a manager, an approval activity is scheduled. However, email notifications are now disabled to avoid spamming the assigned managers. * Prevent notifying the expense manager when expense state changes. * Email 'Next expense is waiting your approval' is scheduled to be sent to the manager once a week if the manager has any expenses left to approve. task-4676396 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244995 Forward-Port-Of: odoo/odoo#210614
5 changes
Resolved issues and error corrections
This update fixes a calculation error in the VAT sales reports for Vietnam. The previous formula excluded the base amount for 8% VAT transactions, leading to inaccurate sales reporting. This change ensures the total taxable base is calculated correctly, improving financial reporting accuracy.
Original PR description
`VAT_SALES` report line aggregates total untaxed amount from its children lines. Previously, the formula for this line was missing `VAT_SALES_8.amount_untaxed`. As a result, the base amount for 8% VAT transactions was excluded from the total sales base calculation. This commit adds the missing tag to the `VAT_SALES` formula to ensure the total taxable base is calculated correctly. task-5836154 Forward-Port-Of: odoo/odoo#244915
This update fixes a bug where journal entries could be posted even when referencing inactive analytic accounts. The change adds a validation step during posting to ensure all referenced accounts are active, preventing incorrect financial postings. This improves data accuracy and reliability.
Original PR description
**Steps to produce:** - Install the `Accounting` module. - Enable analytic accounting in settings. - Create an analytic account (e.g., "test"). - Create a journal entry and assign the analytic…
**Steps to produce:** - Install the `Accounting` module. - Enable analytic accounting in settings. - Create an analytic account (e.g., "test"). - Create a journal entry and assign the analytic account in the analytic distribution. - Post the entry and export it(Make sure `journal items/account` and `journal items/analytic distribution` are also included). - `Archive` the analytic account. - Import the exported entry `OR` Duplicate the previous created entry. - Try to post the imported entry. **Issue:** - The entry is posted even if the analytic account used in the analytic distribution is inactive. **Root cause:** - The `analytic_distribution` field is stored as JSON. - At [1], the `_str_to_json` method only attempts `json.loads(value)`, and if parsing fails, it raises an error. **Solution:** - Add a validation when posting journal entries to ensure that all analytic accounts referenced in the analytic distribution are active. [1]: https://github.com/odoo/odoo/blob/13e8b462e74f144e085492857bfaa7b0d1f88f93/odoo/addons/base/models/ir_fields.py#L196-L202 opw-5350980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243534 Forward-Port-Of: odoo/odoo#239988
This update removes a restriction that previously limited the ability to use certain journal accounts for reconciliation. This change provides greater flexibility for users to configure their accounting processes, addressing a previous limitation that could restrict account usage. It’s a minor improvement to the system’s flexibility.
Original PR description
Previously, a constraint prevented accounts from being non-reconcilable if they were used as default debit/credit accounts involved in journals. This behavior is too restrictive. This commit removes the constraint. task-5254202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244398
This update resolves a potential infinite loop issue that could occur when generating combinations of product attributes, specifically with multi-checkbox attributes. The fix ensures that lines without attribute values are excluded from the combination process, preventing redundant calculations and maintaining system stability. This change improves the reliability of product configuration.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241557This update fixes a problem preventing successful payments through Stripe. The issue stemmed from incorrect currency decimal rounding during the payment process. The fix ensures accurate amount transmission to Stripe, resolving payment failures and improving the reliability of Stripe transactions.
Original PR description
### Issue: The stripe payments are failing to due setting currency decimals. #### Steps to reproduce: 1- In USD currency form in developer mode, set the rounding factor to `0.001000`, so we have 3…
### Issue: The stripe payments are failing to due setting currency decimals. #### Steps to reproduce: 1- In USD currency form in developer mode, set the rounding factor to `0.001000`, so we have 3 decimal places. 2- From `Decimal Accuracy` set Price Unit to 4 digits. 3- Refresh the page. 4- Create a SO and add a line. Set the price to `200.7647`. 5- Refresh the page again and generate a payment link. 6- Pay through stripe. As you see payments fail. ### Cause: This is due to rounding the amount before sending to stripe: https://github.com/odoo/odoo/blob/824e0c42c62de7f570f106860e7dcbf1f7344c14/addons/payment_stripe/models/payment_transaction.py#L160-L165 We are rounding the amount to the minor currency unit. However, we make a compare between `tx_amount` and the amount paid through stripe: https://github.com/odoo/odoo/blob/824e0c42c62de7f570f106860e7dcbf1f7344c14/addons/payment/models/payment_transaction.py#L726-L732 Which are not equal. We should use minor current unit as `precision_digits` to fix this issue. opw-5496825
14 changes
Enhancements to existing features
This update simplifies how users view and understand tax rules within the Fiscal Position settings. By streamlining the tax list view, users can now quickly inspect tax mappings without navigating through multiple steps, improving efficiency and accuracy.
Original PR description
-Update the list view opened from the “Taxes” stat button to make tax replacement rules easier to inspect. Impact: -Users can review tax mappings directly without extra clicks. Back-port of: https://github.com/odoo/odoo/pull/244002 task-5374524
Resolved issues and error corrections
This update resolves an issue where full invoice payments with staggered payment terms incorrectly generated duplicate cash basis tax entries. The fix adjusts the calculation to accurately reflect the payment percentage, ensuring correct tax amounts are recorded in cash basis accounting. This improves the reliability of financial reporting.
Original PR description
**Steps to reproduce:** 1. Install the `Accounting` module. 2. Enable cash basis taxes in `Accounting → Configuration → Settings → Taxes → Cash Basis`. 3. Create a tax, set `Tax Exigibility` to…
**Steps to reproduce:** 1. Install the `Accounting` module. 2. Enable cash basis taxes in `Accounting → Configuration → Settings → Taxes → Cash Basis`. 3. Create a tax, set `Tax Exigibility` to `Based on Payment`, and assign a `Cash Basis Transition Account`. 4. Create an invoice with the cash basis tax and a payment term such as `30% now, balance in 60 days`. 5. Record a full payment on the invoice instead of just the first installment. 6. Review the generated cash basis journal entries. **Observed behavior:** * Cash basis entries are created for the full tax amount, not proportionally. * Paying the full invoice with payment terms causes duplicated tax entries. **Root cause:** The calculation of `amount_currency` in `_create_tax_cash_basis_moves` used `line.amount_residual_currency` directly. This ignored the actual payment percentage, leading to incorrect full tax amounts. **Solution:** Adjust the calculation to apply the payment percentage when deriving the tax amount. This ensures that cash basis entries correctly reflect the proportion of the payment instead of always using the full tax. opw-5061136
This update fixes an issue where payments were incorrectly grouped, resulting in only one payment being recorded for multiple invoices from different partners. The change ensures that payments are correctly associated with each batch of invoices, improving payment accuracy and reconciliation. Related tests have also been updated.
Original PR description
- Create a misc with 2 receivable lines with different partners - Pay it - You only get a single payment, for the first partner only => We grouped the lines per move, but we should only do that inside a same batch Also fixes some caba tests that were incomplete --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a discrepancy in payroll account testing, reflecting that payments are now processed through different business partners. The change reverts a previous adjustment to ensure accurate test results and maintain the integrity of payroll accounting. This ensures the system correctly accounts for all payment transactions.
Original PR description
This reverts commit 0d34a92a3afb7d488e4637f738a6e43688b58f4b. The tests were actually right, the payments are for different partners
This update allows users to modify stock quantity views through Studio, even without a unique identifier. Previously, a check prevented Studio fields from being used in the 'stock.quant' view. Now, Studio and customized views are correctly recognized, ensuring greater flexibility in managing stock data.
Original PR description
In versions prior to 18.3, the “stock.quant” view did not have an “xml_id”, which prevented it from being modified through Studio. However, starting from version 18.3 and specifically since this commit: https://github.com/odoo/enterprise/commit/f4a4d54d45392c2ba46a123d4951f8b4468c5cba it is now possible to modify views through Studio even if they don't have an xml_id. But in the 'stock.quant' view, we perform a check at creation time to ensure that the field is among the allowed fields. Fields coming from Studio or from a customized view should, however, be ignored by this check and allowed. opw-5107591
This update fixes a calculation error in the VAT sales reports for Vietnam (l10n_vn). The previous formula excluded the base amount for 8% VAT transactions, leading to inaccurate sales reporting. This change ensures the total taxable base is calculated correctly, improving the accuracy of financial data.
Original PR description
`VAT_SALES` report line aggregates total untaxed amount from its children lines. Previously, the formula for this line was missing `VAT_SALES_8.amount_untaxed`. As a result, the base amount for 8% VAT transactions was excluded from the total sales base calculation. This commit adds the missing tag to the `VAT_SALES` formula to ensure the total taxable base is calculated correctly. task-5836154 Forward-Port-Of: odoo/odoo#244915
This update resolves a bug where the color slider in the editor's custom color picker would reset to red when selecting a color from the top of the palette. The fix prevents unnecessary UI updates, ensuring the color picker functions correctly and reliably.
Original PR description
**Current behavior before PR:** In editor's custom gradient picker, if `#FFFFFF` is picked from the very top of picker area, the color slider is reset to color `red`. This happens because when moving picker pointer to the top of area, `selectedColor` prop is updated to `#FFFFFF`, which calls `onWillUpdateProps` callback. As result, `convertRgbToHsl` sets hue value 0 for `#FFFFFF`, setting color slider to red. **Desired behavior after PR is merged:** This commit ensures that in `onWillUpdateProps` callback, `setSelectedColor` should not get called if `newSelectedColor` is the same as `this.colorComponents.cssColor` to prevent updating UI twice while picking the color. task-5170041 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245056 Forward-Port-Of: odoo/odoo#236644
This update prevents visitors from seeing or accessing live chat commands like `/help` or `/leave`. Previously, these commands were visible, which wasn't ideal for user experience. This change ensures a cleaner and more intuitive experience for all users.
Original PR description
**Current behavior before PR:** channel commands like `/help ` or `/leave` are visible to visitors even it is not functional for them. **Desired behavior after PR is merged:** commands are now hidden from visitors. task-4552209 related: [PR](https://github.com/odoo/enterprise/pull/82963) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196737
This update hides potentially confusing live chat commands (like `/help`) from website visitors and guests. Previously, these commands were visible, even though they weren't functional for them. This change enhances the user experience and security of the Helpdesk module.
Original PR description
*= test_discuss_full_enterprise **Before PR:** channel commands like `/help ` or `/leave` and more are visible to visitors or guest even it is not functional for them. **After PR:** all commands are now hidden from visitors/guests. task-4548666 Forward-Port-Of: odoo/enterprise#82963
This update fixes a bug where journal entries could be posted even when referencing inactive analytic accounts. The fix adds a validation step during posting to ensure all referenced accounts are active, preventing incorrect financial postings. This improves data accuracy and reliability within the accounting system.
Original PR description
**Steps to produce:** - Install the `Accounting` module. - Enable analytic accounting in settings. - Create an analytic account (e.g., "test"). - Create a journal entry and assign the analytic…
**Steps to produce:** - Install the `Accounting` module. - Enable analytic accounting in settings. - Create an analytic account (e.g., "test"). - Create a journal entry and assign the analytic account in the analytic distribution. - Post the entry and export it(Make sure `journal items/account` and `journal items/analytic distribution` are also included). - `Archive` the analytic account. - Import the exported entry `OR` Duplicate the previous created entry. - Try to post the imported entry. **Issue:** - The entry is posted even if the analytic account used in the analytic distribution is inactive. **Root cause:** - The `analytic_distribution` field is stored as JSON. - At [1], the `_str_to_json` method only attempts `json.loads(value)`, and if parsing fails, it raises an error. **Solution:** - Add a validation when posting journal entries to ensure that all analytic accounts referenced in the analytic distribution are active. [1]: https://github.com/odoo/odoo/blob/13e8b462e74f144e085492857bfaa7b0d1f88f93/odoo/addons/base/models/ir_fields.py#L196-L202 opw-5350980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243534 Forward-Port-Of: odoo/odoo#239988
This update resolves an issue where invoices generated with the Solution Factible PAC in Mexico were being rejected due to incorrect exchange rate formatting. The fix ensures that all PACs, including Solution Factible, use the required 6 decimal places for exchange rates, preventing invoice rejection and ensuring compliance with Mexican tax regulations.
Original PR description
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request…
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs. Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200) ## Steps to reproduce: [Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing) 1. Navigate to Apps and install l10n_mx_edi. 2. Switch to any of the Mexican companies that appear. 3. Navigate to Accounting > Configuration > Currencies. 4. Click into the USD currency. 5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field). 6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible. [Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing) 1. Navigate to Accounting > Customers > Invoices. 2. Select New to create a new invoice. 3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES). 4. Add the 45 day Payment terms. This should change the payment policy to PPD. 5. Change the currency to USD. 6. Add the product FURN_8220 (or any with the unspsc_code_id set). 7. Set the unit price of the product to 58968.29. 8. Confirm the invoice. 9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again. 10. Select Register Payment, then Confirm Payment. 11. Select the Update Payments smart button. 12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line. Forward-Port-Of: odoo/enterprise#104673 Forward-Port-Of: odoo/enterprise#102557
This update resolves a potential infinite loop issue that could occur when generating product attribute combinations, specifically with multi-checkbox attributes. The fix ensures that lines without values are excluded from the combination process, preventing redundant calculations and maintaining system stability. This improves the reliability of product configuration.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241557This update fixes a visual glitch in the time-off UI for Belgian employees. Previously, sickness relapse fields appeared unexpectedly after certain time-off approvals. The fix adjusts the layout to prevent this overlap and ensure a consistent user experience.
Original PR description
Bug production steps: Select employee works in Belgium company, go to timeoff and approve >= 1 months time off and select new timeoff after 1-2 days and there Sickness Relapse fields occur in the shifted UI. Bug cause: The field sickness_relapse added after attach file part, before there was label for the attach file part and it was occupying 2 columns, after removing column it occupies only 1 and the first part of the boolean sickness relapse fields come next to the attach file part. Bug solution: Make the colspan 2 for the attach file part, by that way the sickness_relapse will start from the below line. task - 5493425 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical issue in the Delivery IoT module that caused tracebacks when processing multiple print job confirmations. The change ensures that print jobs are handled correctly, even when there are discrepancies between the front-end and back-end systems, and improves compatibility with certain IoT devices. This prevents errors and ensures reliable print job processing.
Original PR description
In `delivery_iot`, as reports are fetched in the chatter from the backend, we end up creating one print job in the front end but multiple print jobs can be sent with WebSocket in the backend. We then get a traceback when getting a second confirmation from a print job that has just been deleted from the job list. Additionally, we ensure compatibility with the stable IoT Box, that do not return a `print_id` or `iot_mac`. opw-5464957 Forward-Port-Of: odoo/enterprise#105230 Forward-Port-Of: odoo/enterprise#105194
4 changes
New functionality added to Odoo
This update adds a new tax specifically for income related to work incapacity (sick leave) in Spain. It ensures Odoo accurately reports this income on Form 190, aligning with AEAT requirements and preventing potential tax errors. This improves compliance and traceability for Spanish businesses.
Original PR description
### Description of the feature this PR addresses: **Specific tax on withholdings for incapacity to work created to correctly reflect the amounts derived in Form 190 of the AEAT.** A new tax called…
### Description of the feature this PR addresses: **Specific tax on withholdings for incapacity to work created to correctly reflect the amounts derived in Form 190 of the AEAT.** A new tax called "**100% WHI monies**" has been created with the aim of correctly reflecting the income derived from incapacity for work in the AEAT's Model 190. ### Current behavior before PR: Currently, Odoo does not allow automatic differentiation between monetary payments derived from work incapacity and those not derived from it. This creates a problem when generating Model 190, as the Spanish Tax Agency (AEAT) requires both types of payments to be reported separately (according to the codes and subcodes established in the model). **In practice, this separation is necessary because:** - Income derived from incapacity for work (e.g., sick leave) is considered employment income with differentiated tax treatment. - Withholdings made on these amounts must be declared in specific sections of Form 190. - If they are not separated correctly, the totals on the form may be incorrect or incomplete, affecting the accuracy of the tax information submitted. ### Desired behavior after PR is merged: A new tax has been added to represent “100% Withholding income tax (workers)”, allowing Odoo to: - Correctly identify and calculate the related amounts. - Report them separately in the AEAT Model 190. - A new tax group has also been created to distinguish these withholdings from regular ones. ### Benefits: - It allows you to correctly generate Form 190, separating income derived from and not derived from work disability. - It facilitates the accounting and tax traceability of this type of income. - It ensures consistency with the information structure required by the Spanish Tax Agency (AEAT), avoiding errors in the annual filing. - It improves the flexibility of the Odoo tax system, adapting it to actual tax needs. ### Technical summary: - A **new specific tax** has been created for withholdings associated with incapacity for work benefits. - This tax **allows the amounts corresponding to these benefits to be identified, accounted for, and reported independently.** - In addition, a **new tax group "Whitholdings IRPF Workers" has been added that groups these withholdings together**, allowing them to be clearly distinguished from other withholdings on earned income. The related issue: https://github.com/OCA/l10n-spain/issues/4416 ### Follow-up suggestion: adjust Odoo’s base tax “15% WHI monies” **Proposal:** Change the base tax “15% WHI monies” to 100% and move it to the new “Whitholdings IRPF Workers” tax group. **Why:** The current 15% rate is not aligned with how AEAT Model 190 requires amounts to be computed: the base should reflect 100% of the earnings derived from temporary incapacity, with the withholding rate applied on top of that base. Keeping 15% leads to misclassification and wrong totals in the "_percepciones_" and "_retenciones_" sections. These are variable withholdings, not fixed taxes — each worker’s rate can change monthly depending on their income and number of days worked. Therefore, having a fixed 15% rate is conceptually incorrect and causes misclassified amounts and inaccurate totals, forcing users to adjust values manually after payroll. Ideally, this tax should not have any fixed percentage defined. Since Odoo currently requires a rate, setting the base to 100% is a pragmatic workaround that ensures more accurate and flexible withholding calculations. **Outcome:** - Correct calculation and reporting of **_percepciones derivadas de incapacidad laboral_**. - Clean separation from other withholdings via the new tax group. - Consistency between accounting, payroll, and the 190 export. Would you accept this change? @moduon @rafaelbn @EmilioPascual @chklop @jco-odoo MT-11667 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232515
Resolved issues and error corrections
This update fixes a calculation error in the Vietnam (l10n_vn) sales tax reports. The previous formula excluded 8% VAT transactions from the total sales base, leading to inaccurate reporting. This change ensures that all sales transactions, including those with 8% VAT, are correctly included in the report totals.
Original PR description
`VAT_SALES` report line aggregates total untaxed amount from its children lines. Previously, the formula for this line was missing `VAT_SALES_8.amount_untaxed`. As a result, the base amount for 8% VAT transactions was excluded from the total sales base calculation. This commit adds the missing tag to the `VAT_SALES` formula to ensure the total taxable base is calculated correctly. task-5836154 Forward-Port-Of: odoo/odoo#244915
This update resolves a potential infinite loop issue that could occur when generating product attribute combinations. Specifically, it prevents errors caused by a specific configuration involving multi-checkbox attributes with no associated values. This change ensures stable product configuration and avoids disruptions to the sales process.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241557This update resolves a bug where self-order kiosk tickets were printing blankly when a preparation printer was configured without product categories. The fix ensures that the printer only prints when a product category is defined, aligning with the expected behavior of the self-order system. This prevents blank tickets and ensures accurate order information is printed.
Original PR description
Before this commit: To reproduce (version 17 and >): 1. Install Restaurant 2. In PoS restaurant config allow "Self ordering" in Kiosk mode and enable "Preparation printers" 3. Create a preparation printer with NO categories and set it as a restaurant preparation printer 4. Open the Kiosk 5. Make an order with any product and checkout -> Printer will print a ticket with no product <img width="512" height="415" alt="image" src="https://github.com/user-attachments/assets/31bd08f9-2470-4f72-9e3d-822564b43f70" /> After this commit: No kitchen printer is printed (expected as no category set on the kitchen printer) Forward-Port-Of: odoo/odoo#245193
11 changes
New functionality added to Odoo
This update adds keyboard shortcuts to the Purchase Agreements form, streamlining the process for users. These shortcuts will allow for faster navigation and quicker completion of purchase requests, boosting overall efficiency. This is a minor improvement designed to enhance user experience.
Original PR description
This commit adds some shortcuts to the Purchase Agreements form, allowing users to navigate and work more efficiently. Task: 5420786 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
Enhancements to existing features
This update enhances the way complex salary rule parameters are edited within the system. Previously, these parameters – which can include nested data structures – were difficult to view and modify. Now, a new table preview provides a more user-friendly grid-like view for editing, ensuring accurate rule configuration.
Original PR description
Salary rule parameters may contain complex Python expressions such as nested dictionaries or lists of tuples. Displaying those values directly as raw text makes them difficult to read and edit. This commit introduces a dedicated table preview for such parameters. When a tabular structure is detected, the field displays a "View data" button opening a dialog with a grid-like representation of the data, while simple values keep the standard text field behavior. The dialog allows editing table cells and serializes the result back to a valid Python literal, preserving existing rule evaluation semantics. task-5349178
This update enhances the way complex salary rule parameters are managed. Previously, these parameters – which can include nested data structures – were difficult to view and edit. Now, a new table preview provides a more user-friendly grid-like view for editing, ensuring accurate rule configuration.
Original PR description
Salary rule parameters may contain complex Python expressions such as nested dictionaries or lists of tuples. Displaying those values directly as raw text makes them difficult to read and edit. This commit introduces a dedicated table preview for such parameters. When a tabular structure is detected, the field displays a "View data" button opening a dialog with a grid-like representation of the data, while simple values keep the standard text field behavior. The dialog allows editing table cells and serializes the result back to a valid Python literal, preserving existing rule evaluation semantics. task-5349178
This update standardizes the UOM field names across various Odoo logistics modules, consolidating them to 'uom_id'. Previously, multiple names caused confusion and made it difficult to consistently use UOM fields. This change improves clarity and simplifies development.
Original PR description
Currently, the uom field can have 3 different names in logistic modules: - uom_id - product_uom_id - product_uom This is annoying when we need to use a uom field and we have to check what is its name. So we decided to only keep uom_id as the only name for basic uom fields. Task [5364113](https://www.odoo.com/odoo/project.task/5364113)
This update streamlines the handling of UOM fields across various Odoo modules. Previously, multiple names (uom_id, product_uom_id, product_uom) were used, creating confusion. Now, only 'uom_id' will be used for basic UOM fields, simplifying development and reducing potential errors.
Original PR description
Currently, the uom field can have 3 different names in logistic modules: - uom_id - product_uom_id - product_uom This is annoying when we need to use a uom field and we have to check what is its name. So we decided to only keep uom_id as the only name for basic uom fields. task 5364113
This update simplifies stock management by adding a direct access button to locations within warehouses and clearly marking empty locations during stock transfers. These changes reduce navigation time and minimize errors, leading to more efficient stock operations.
Original PR description
Improves stock usability and clarity by: - Adding a new “Locations” smart button on warehouses to provide direct access to all related internal locations, reducing navigation friction. - Making empty internal locations clearly identifiable during stock relocation by appending “Empty” to destination location names. - Simplifying warehouse and location navigation to avoid manual searching through records. - Reducing the risk of selecting unintended destination locations during relocation. - Improving overall efficiency and decision-making in daily stock operations. Task ID: 4535914
Resolved issues and error corrections
This update fixes an issue where the payment button wasn't appearing on appointment bookings when prices were set via pricelists. The fix ensures the system correctly checks for updated prices, allowing users to complete payment during the booking process. This improves the user experience and ensures accurate pricing.
Original PR description
…t price modified by pricelists **Steps to reproduce:** - Install Appointmeent, Website and Sale - Create a new appointment type - Set up up front payment with 0.0 per booking default price - Set up pricelist according to quantity on the product of the up front payment - Ensure the pricelist is active for the website - Book the appointment on the website - Pay button is not shown when booking on the website (only shows `Confirm Appointment` which bypasses the payment) **Issue:** Payment step button only checks for `appointment_type.product_id.lst_price` (disabled when the price is 0.0), even if pricelists change it to a higher value. **Fix:** Replace the button logic in template in the `website_appointment_sale` module to check for `_get_combination_info` with given quantity. opw-5429963
This update resolves an issue where the message reaction menu remained open even when no reactions were selected. The fix ensures the menu automatically closes when empty, improving the user experience and preventing unnecessary screen clutter. This change contributes to a cleaner and more efficient workflow for users.
Original PR description
Since [1], message reaction menu doesn't close when it's empty. This commit fixes the issue. [1]: https://github.com/odoo/odoo/pull/234161 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
Code cleanup and technical improvements
This update reorganizes the structure of our point-of-sale data models. Separating the `pos_order_line` from the `pos_order` model improves code organization and makes it easier for developers to maintain and update the system. This change enhances overall system stability and efficiency.
Original PR description
*: pos_mrp, pos_sale, pos_self_order In this commit: ------------------ - We have separated the `pos_order_line` model from the `pos_order` model to better organize the files and improve the overall code structure, making the codebase easier to understand, maintain, and navigate. task: 5473161 Related PR: https://github.com/odoo/enterprise/pull/103624
This update reorganizes the structure of our point-of-sale (POS) data models. Separating the `pos_order_line` from the `pos_order` model improves code organization, making it easier for developers to understand and maintain the system. This ultimately leads to more efficient updates and enhancements to our POS functionality.
Original PR description
In this commit: ------------------ - We have separated the `pos_order_line` model from the `pos_order` model to better organize the files and improve the overall code structure, making the codebase easier to understand, maintain, and navigate. task: 5473161 Related PR: https://github.com/odoo/odoo/pull/242738
This update consolidates the code responsible for generating call status information within the Odoo Enterprise system. This change improves code organization and maintainability, ensuring consistent and reliable call status updates across various modules.
Original PR description
We centralize the code that produces call statuses.
23 changes
Enhancements to existing features
This update enhances the tracking of EDI and e-Way Bill requests by storing the original request data as JSON attachments. This improves debugging, auditing, and compliance efforts, providing a clearer record of these transactions.
Original PR description
Before this PR: - Request payloads sent for EDI and e-Way Bill generation were not persisted. making debugging and audits difficult. After this PR: - all EDI and e-Way Bill request payloads are stored as JSON attachments, ensuring better traceability, troubleshooting, and compliance support. Task: 4896516
This update adjusts the font size of the 'amount due' and 'amount by guest' displays on the payment screen within the Point of Sale module. This enhancement improves readability and ease of use for staff processing payments, particularly when dealing with larger transactions.
Original PR description
Little improvement of the font size of amount due and amount by guest on the payment screen. task: 5473324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes how Odoo reports process data, specifically when filtering by related account fields. By grouping similar domain conditions, the system now runs fewer database queries, leading to faster report generation. This change significantly reduces the time it takes to open reports like the Generic Balance Sheet.
Original PR description
Before this commit, the 'domain' engine was never batched: one expression to evaluate caused one SQL query to be run just for it. With this commit, we group domains that could be evaluated together. Essentially, when we have domains targetting the same many2one field of account.move.line (typically account_id, with conditions like 'account_id.code' or 'account_id.account_type'), we run only one SQL query for all of them, targetting all the move lines according to the report filters. Then, we iterate on its result for each domain to evaluate. When iterating over the results, we filter the ones we keep by searching separately on each traversing model (in our example, account.account), to isolate the ones that are actually targetted by each expression. Tested on our prod. With this, opening the Generic Balance Sheet goes from 1min 35s to 36s. opw-5130725 Forward-Port-Of: odoo/enterprise#101725
Resolved issues and error corrections
This update corrects a technical issue related to how payments are processed in the HR payroll system. The fix ensures that multiple payment moves are handled correctly during registration, improving the reliability of payroll calculations. This change enhances the overall accuracy of financial reporting.
Original PR description
There was an error where we weren't batching when we were selecting several moves at the same time when registering a payment. We fixed that and this test needs to be adapted. Forward-Port-Of: odoo/enterprise#104727
This update fixes an issue where customer display QR codes in the Point of Sale (POS) system were generating incorrect URLs. The change ensures the QR code uses the correct base URL configuration for the POS session, improving the reliability and accuracy of customer information displayed through QR codes.
Original PR description
Steps:
- Install point_of_sale.
- Open a POS session on a mobile device.
- Click on the customer display menu.
Issue:
- The QR code for the customer display contains an invalid URL: undefined/pos_customer_display/${config_id}.
Issue:
- The base URL was being accessed from the POS session, where it is not available.
Fix:
- Retrieve the base URL from the POS configuration instead of the session.
task-5792308This update removes the Sign menu item from Odoo's discuss channels. Previously, this menu was incorrectly displayed, which was confusing for users. This change aligns with the functionality of discuss channels, which are designed for mail threads and don't require the Sign feature.
Original PR description
Currently, the Sign menu item is displayed in discuss channels, which is not making sense. This was due to an incomplete check in the isDisplayed method of the SignRequestCogMenu component. To fix this, we enhance the condition to ensure that the menu item is not displayed when the current model is 'discuss.channel'. Discuss channels inherently support mail threads, but should not have the Sign menu item. task-5494751
This update addresses an issue where light-colored dropdown menus in the Discuss app caused eye strain when using the dark theme. A simple adjustment was made to darken these menus, ensuring a more comfortable viewing experience and improved usability in dark mode. This enhances the overall user experience for users of the Discuss app.
Original PR description
Dropdown menu are quite light in dark theme. Outside of discuss not many UI elements require dropdown. However discuss use them a lot, so this becomes a problem to have light background so often. This commit adds `.bg-view` to all discuss dropdown, which is visually unchanged in white theme but in dark theme this makes it darker so easier to read with less eye strain. Task-5492040 Before / After <img width="961" height="671" alt="Screenshot 2026-01-13 at 17 24 12" src="https://github.com/user-attachments/assets/09ab5f8f-5927-4beb-a814-d77cd61f8a01" /> <img width="957" height="667" alt="Screenshot 2026-01-13 at 17 23 56" src="https://github.com/user-attachments/assets/4ec0ef3b-7af5-4b69-b48e-40c3788eb95e" />
This update resolves an issue where the 'Pending' button in manufacturing orders incorrectly stopped productivity records for all employees involved, instead of just the current one. The fix ensures that only the employee actively working on the operation is impacted when the 'Pending' button is clicked, improving workflow efficiency and accuracy.
Original PR description
Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
- Create a new operation OP1
- Create a manufacturing order to produce one unit of P1
- Confirm the manufacturing order
- Log in as Mitchel (admin) and start OP1
- Log in as Marc (demo) and also start OP1
- Click on Pending
Problem:
Both “mrp.workcenter.productivity” records are stopped, instead of stopping only the one linked to
The `button_pending` method was stopping productivity records for all employees linked to the work order.
opw-5453752
Forward-Port-Of: odoo/enterprise#105109
Forward-Port-Of: odoo/enterprise#103553This update fixes a calculation error in the VAT sales reports for Vietnam. The previous formula excluded 8% VAT transactions from the total sales base, leading to inaccurate reporting. This change ensures the correct taxable base is calculated, aligning with Vietnamese tax regulations.
Original PR description
`VAT_SALES` report line aggregates total untaxed amount from its children lines. Previously, the formula for this line was missing `VAT_SALES_8.amount_untaxed`. As a result, the base amount for 8% VAT transactions was excluded from the total sales base calculation. This commit adds the missing tag to the `VAT_SALES` formula to ensure the total taxable base is calculated correctly. task-5836154 Forward-Port-Of: odoo/odoo#244915
This update resolves an issue where the PIN modal was unresponsive while the "clocking in" loader was displayed. Now, the user interface remains fully functional when the PIN modal appears, improving the checkout experience for employees. This ensures smooth and reliable time clock functionality.
Original PR description
We now unblock the UI when the PIN modal appears, as it was unusable behind the loader telling "clocking in". Forward-Port-Of: odoo/enterprise#105039
This update ensures the chatbot answer dropdown only displays answers relevant to the current chatbot script, regardless of whether a search term is entered. Previously, the dropdown incorrectly showed answers from other scripts due to a change in how search filters were processed. This fix corrects a bug impacting the accuracy of chatbot responses.
Original PR description
**Description of the issue/feature this PR addresses:** In the `triggering_answer_ids` searchable dropdown, when no value is entered, the `_search_display_name` method of `chatbot_script_answer` is…
**Description of the issue/feature this PR addresses:**
In the `triggering_answer_ids` searchable dropdown, when no value is entered, the `_search_display_name` method of `chatbot_script_answer` is not called. Instead, the ORM falls back to the field’s default domain and returns all `chatbot.script.answer` records, including those from other scripts. When a value is entered, `_search_display_name` is triggered and the results are filtered correctly.
This behavior changed after PR #201587, where the `operator_optimization` step started executing before `determine_domain`. Since `determine_domain` is the step that triggers `_search_display_name`, it no longer gets called when the domain `('name', 'ilike', '')` is stripped by `operator_optimization`. Therefore, filtering only works when a non-empty filter value is provided.
**Current behavior before PR:**
All `chatbot.script.answer` records are shown in the `triggering_answer_ids` dropdown when no search value is entered, even if they don’t belong to the current chatbot script.
**Desired behavior after PR is merged:**
The `triggering_answer_ids` dropdown only shows answers belonging to the current chatbot script, regardless of whether a search value is entered.
task-[4968490](https://www.odoo.com/odoo/project/1519/tasks/4968490)
Forward-Port-Of: odoo/odoo#245322
Forward-Port-Of: odoo/odoo#228192This update corrects a potential issue where users could inadvertently add special characters to the company registry field when submitting VAT returns via the Intervat API. The change adds a filter to ensure only numeric values are used, preventing errors and ensuring accurate data transmission to the API. This improves the reliability of VAT return submissions.
Original PR description
When submitting vat return to Intervat API, we are using company_registry, which is a computed field based on VAT. It's VAT - Country code But this field remains editable, so user could change it to add special characters, like dots or country code, but the Intervat API's are expecting only numbers. This commit add a regex to remove all special characters and only keep numbers from company_registry to use it for API calls. task-5500052
This update resolves an issue where users attempting to use Intervat were left unable to proceed due to a persistent connection after declining consent. The change automatically closes the connection when consent is not given, preventing a 4-hour lockout and restoring user functionality. This ensures a smoother experience for users interacting with the Intervat module.
Original PR description
During the authentication process of Intervat, the user is asked to give their consent at the very end, just before returning to Odoo. However, in case they do not give consent, the connection remains open, even though they cannot submit a declaration without it. As the connection remains open for 4 hours, the user is stuck during that period and cannot do anything with Intervat. This commit forces the connection to close when Odoo receives an error indicating that the user didn't give their consent. task-5495079
This update resolves an issue where products with multi-attribute options and archived variants would appear grayed out on the website, preventing customers from adding them to their cart. The fix ensures that the system only considers active variant values, preventing inactive variants from impacting product display and availability.
Original PR description
### Issue: When a product has multiple attributes and one variant is archived, the product page may appear grayed out and the product cannot be added to the cart. #### Steps to reproduce (with demo…
### Issue: When a product has multiple attributes and one variant is archived, the product page may appear grayed out and the product cannot be added to the cart. #### Steps to reproduce (with demo data): 1- Create a product with two attributes: - attribute with 3 values - Brand: Adidas 2- Save product to generate variants. Publish the product. 3- From variant list, archive the first variant 4- Back in product page, from attributes & variants tab, remove the first value. This sets `ptav_active` to False. 5- Navigate to website shop page, and add the Brand Adidas to filter 6- This should show the created product active. 7- Open the product. You will see the product is grayed out and it's shown inactive and cannot add it to the cart. ### Cause: In this scenario, `attribute_value_ids` only contains values from the single-value attribute: https://github.com/odoo/odoo/blob/da88d0a72bf4c0ec6887e53d35bf4c28b68a6a2b/addons/website_sale/controllers/main.py#L814-L824 For the multi-value attribute, no ptav matches `attribute_value_ids`, so the code falls back to selecting the first ptav: https://github.com/odoo/odoo/blob/da88d0a72bf4c0ec6887e53d35bf4c28b68a6a2b/addons/website_sale/controllers/main.py#L823 If this ptav corresponds to an archived variant, the resulting combination resolves to an inactive product. ### Fix: Ensure the fallback logic only considers active ptavs, preventing archived variants with prav inactive from being selected. opw-5352224
This update resolves an issue where users lacking specific access rights within Odoo could not submit VAT declarations through the Intervat module. By adding sudo permissions, the update ensures all users can submit, regardless of their access level, improving the usability and reliability of this important business process.
Original PR description
Add few sudo() for vat declaration, to be sure users without access rights to res.company or certificate.certificate can still make a submission. task-5470492
This update corrects a visual issue where 'Danger' and 'Success' action buttons weren't consistently displayed in the portal message action list. The fix ensures that these buttons appear correctly, regardless of whether they're shown in the dropdown or quick action menu, improving the user experience.
Original PR description
PR #224976 fixes the demonstration of an action with a `DANGER` tag in the dropdown menu in the action list. Such an action may not be located in the dropdown, but rather in the quick action menu. This change ensures that the action buttons with `DANGER` or `SUCCESS` tags are demonstrated properly in either case. Steps to reproduce: - Open a document in the portal as a portal user. - Send a message and hover over the message. - The `delete` button is not visible in the action list.
A bug was causing the 'this device' option in the Point of Sale customer display to unexpectedly close and open the POS session in a new tab. This has been fixed by correcting how the URL is generated, resolving an issue with incorrect URL formation and a missing base URL.
Original PR description
Step to reproduce: - start pos - from top-right menu, click on display icon - a dialog will appear, click on "this device" button Observation: - current session will be closed and open in new tab Cause: - Incorrect url formed for redirection which, as a fallback loads currrent pos - base url is `undefined`, as we try to get it from `pos.session`, which now is attribute of `pos.config`. https://github.com/odoo/odoo/blob/06ddce00115c906a4d8396387dd3332482145d7f/addons/point_of_sale/models/pos_config.py#L288 opw-5502812 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change resolves an issue where the system incorrectly prevented users from setting different cost shares for byproducts based on product color variations. The update now correctly validates cost shares for byproducts within a Bill of Materials, allowing for flexible costing based on product attributes. This ensures accurate inventory valuation and reporting.
Original PR description
### Steps to reproduce: - In the settings enable By-Products - Create a product with an color attribute and 2 values: white, black - Create a bom for that products and add 2 by product lines: - 1 x…
### Steps to reproduce:
- In the settings enable By-Products
- Create a product with an color attribute and 2 values: white, black
- Create a bom for that products and add 2 by product lines:
- 1 x comp1 with a cost_share of 50% specific to the white att-value
- 1 x comp2 with a cost_share of 70% specific to the Black att-value
#### > Try to save and you will raise a UserError: The total cost share for a BoM's by-products cannot exceed 100.
### Expected behavior:
The error should not be raised as the total cost_share is 50% for the white variant and 70% for the black one but none of them exceeds the 100% cost share.
### Cause of the Issue:
Currently the constraint does not take attribute values into accounts and simply sums the value of the cost share of all by-product lines: https://github.com/odoo/odoo/blob/bcc1397c7d694dbe61ecbd44d0320b9518df84cb/addons/mrp/models/mrp_bom.py#L201-L202
### Fix:
Just as for the total cost_share on kit products, we rely on the exclusion util and check for each existing product variant if the cost share set up is valid:
https://github.com/odoo/odoo/blob/7e81c528ae350aab4432207f5655dcfadf6ec627/addons/purchase_mrp/models/mrp_bom.py#L20-L23 see 3832793e3ce61aff0c7cf4673de84645a3469b3a
opw-5499773
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where the POS system wasn't correctly grouping products by selected categories. Now, when a category is chosen in the POS interface, products are reliably grouped by that category, ensuring a smoother and more accurate customer experience. This improves the functionality of our point-of-sale system.
Original PR description
Fix an issue in the POS when using `Group products by category` settings with a selected category would not group the product by category anymore. We now make sure that even when we select a category in POS, the products are still grouped by category. task-id: 5481961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where invoices sent to ZATCA (Saudi Arabia's tax authority) were incorrectly including a +03:00 timezone offset. The fix ensures that invoice times are accurately transmitted in the Asia/Riyadh timezone, aligning with ZATCA's requirements and preventing potential processing delays or errors.
Original PR description
The time information added to the date of the invoice post for ZATCA in iso format which adds +03:00. However ZATCA expects the time to be sent as is in Asia/Riyadh timezone. - Set up a ZATCA company and onboard a journal - To simulate the timezone issue, replace the hour value with 23h in the following line: vals['l10n_sa_confirmation_datetime'] = datetime.combine(move.invoice_date, fields.Datetime.now().time()). (use .replace(hour=23))) - Create, confirm, and send an invoice to ZATCA opw-5373067 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#245366 Forward-Port-Of: odoo/odoo#243961
This update resolves a potential infinite loop issue that could occur when generating combinations of product attributes, specifically with multi-checkbox attributes. The fix ensures that lines without attribute values are excluded, preventing redundant calculations and maintaining system stability. This change improves the reliability of product configuration processes.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241557Features or functions removed from Odoo
This update removes outdated Albanian translations from several Odoo modules. This prepares the system for accurate translations when Albanian is reintroduced through our Weblate translation platform, ensuring a consistent and reliable user experience.
Original PR description
Both the po files and the translations were old and out of date. Delete them now so we can start from scratch when the language is added into Weblate.
This update removes outdated Albanian translations from various Odoo modules. This cleanup prepares the system for future language updates by utilizing Weblate, ensuring accurate and current translations moving forward. It's a routine maintenance task to maintain translation quality.
Original PR description
Both the po files and the translations were old and out of date. Delete them now so we can start from scratch when the language is added into Weblate. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
22 changes
Enhancements to existing features
This update improves how product prices are displayed in Odoo. A new method, `_get_price_label_base_str()`, has been added to the product pricelist item model. This change allows for more flexible and customizable formatting of price labels, ensuring consistent and accurate presentation of pricing information.
Original PR description
Add `_get_price_label_base_str()` method in order to exend it @Tecnativa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update switches the directory lookup for Nemhandel from a discontinued CNAME method to a more reliable IAP lookup. This ensures continued functionality with Nemhandel, which is a key partner for Danish businesses. The update also standardizes a component for improved consistency.
Original PR description
We need to switch the lookup on the directory to NAPTR, as the CNAME one is discontinued on January. We now go through IAP to do the lookup. It's also ensuring _check_document_type_support has always the same format as the super() coming from Peppol. task-4486039 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
Resolved issues and error corrections
This update resolves an issue where the system incorrectly attempted to calculate self-billing eligibility when using the oioubl_21 eInvoice format. The fix ensures the system uses the correct method for determining export eligibility, preventing UI access failures and ensuring accurate billing processes. This impacts users configuring partners with the oioubl_21 format.
Original PR description
While computing the self-billing export eligibility, the system called ```_can_export_selfbilling()``` on the EDI builder. However, this method is only implemented for the…
While computing the self-billing export eligibility, the system called ```_can_export_selfbilling()``` on the EDI builder. However, this method is only implemented for the ```account.edi.xml.ubl_bis3``` builder and is not available on other EDI formats such as ```oioubl_21```,
```oioubl_201```.
When a partner is configured to use the ```oioubl_21``` eInvoice format,
this resulted in an ```AttributeError``` during record reads, causing menu crawl and
UI access failures (e.g., Accounting → Vendors → Bills/Refunds).
```sql
Traceback (most recent call last):
File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpznsful5y/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/odoo/18.0/addons/account_peppol_selfbilling/models/account_move.py", line 13, in _compute_can_send_as_self_invoice
if move._is_exportable_as_self_invoice():
File "/home/odoo/src/odoo/18.0/addons/account_peppol_selfbilling/models/account_move.py", line 31, in _is_exportable_as_self_invoice
and edi_builder._can_export_selfbilling()
AttributeError: 'account.edi.xml.oioubl_21' object has no attribute '_can_export_selfbilling'
```
**Steps to reproduce**
1) Install l10n_dk_nemhandel module
2) Set the eInvoice format to oioubl_21 for the partner
3) Create Bill for that partner
3) Confirm the bill
OPW - 5863081
UPG - 3846482
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an inconsistency in how product pricelists are assigned to partners. Previously, EU partners were incorrectly assigned a specific pricelist, while others weren't. This change ensures that EU partners automatically use the default pricelist, streamlining pricing and avoiding manual adjustments.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a way to check the `specific_property_product_pricelist` field; 2. create a pricelist for EU countries; 3. delete all other regional pricelists; 4.…
Versions -------- - 18.0+ Steps ----- 1. Have a way to check the `specific_property_product_pricelist` field; 2. create a pricelist for EU countries; 3. delete all other regional pricelists; 4. create a new partner in a EU country; 5. create a new partner outside a EU country; 6. create a new partner without a country. Issue ----- Inconsistent behavior: - EU partner has no `specific_property_product_pricelist` value set, as it's identical to the default `property_product_pricelist`. - The other partners do have a `specific_property_product_pricelist` value set to the default value, as if a user manually assigned them. Cause ----- In the `_inverse_product_pricelist` method, the `default_for_country` pricelist is an empty recordset if the partner has no `country_id` or none of the pricelists have a country groups with the partner's `country_id` in it. Solution -------- Introduce a `_get_country_pricelist_multi` method that can be used by `_get_partner_pricelist_multi` and `_inverse_product_pricelist` to ensure that they both return the same result for any given country (including none), and use this as the `default_for_country`. > [!Note] > An alternative approach could be to replace the `_inverse_product_pricelist` method with an `onchange` method, as the docstring of the `_get_partner_pricelist_multi` method states: >> First, the pricelist of the specific property (res_id set), this one is created when saving a pricelist on the partner form view. > > This suggests a behavior that more closely resembles the purpose of an `onchange` method, instead of an `inverse`. opw-5385213 Enterprise PR: https://github.com/odoo/enterprise/pull/103116 (only modifies a test)
This update corrects a discrepancy in a sales subscription test. The test previously incorrectly prioritized pricelists based on default settings for partners without country information. The fix ensures consistent ordering by aligning pricelist sequences, resolving a minor technical issue without impacting core functionality.
Original PR description
Versions -------- - 18.0+ Issue ----- Commit a840e4250666 changed a `sale_subscription` test as pricelist ordering was changed. Before, it was `sequence asc, id desc`, now it is `sequence asc, id asc`. However, in the updated tests, it expects the first pricelist created with sequence 4 to be before the second pricelist with sequence 2. This was only happening due to default pricelists getting set as the `specific_property_product_pricelist` if the partner has no country assigned to them. Solution -------- As the behavior is now identical for partners with or without a country assigned to them, we can resolved the test setup by giving both pricelists an identical sequence, making the ordering fall back on `id` like a840e4250666 intended. opw-5385213 Related: https://github.com/odoo/odoo/pull/241736
This update fixes a memory error that occurred when loading website pages, specifically within the page manager. The fix involved optimizing how the system retrieves page information, reducing the amount of data loaded and improving overall performance. This change enhances the speed and stability of the website experience.
Original PR description
Before this commit, loading the list view of the website pages invoked a method called `_get_most_specific_pages`. This method caused a memory error due to loading the field called `key` for the pages being fetched. This field was related to a field called `key` in the model `ir.ui.view`, so a cache miss in the recordset causes a `SELECT *` query for the ir.ui.view potentially causing a memory error if the size of these views are big. A solution for this is to force the ORM to load only the `key` field by invoking **search_fetch** on the `ir.ui.view` model instead. In order to improve the retrieval of a given page key count, we now use a Counter map (=> constant time instead of linear search). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where rounding errors in currency calculations were causing the system to incorrectly remove small cash differences from reports. The fix ensures that even minor discrepancies, resulting from rounding, are accurately identified and reported, preventing unintended removal of cash transactions. This improves the accuracy of our financial reporting.
Original PR description
Before this commit, when calculating the cash difference in the report, the code did not account for currency rounding. This could lead to situations where a very small cash difference, due to rounding errors, was not recognized as zero, resulting in the unintended removal of cash moves. opw-5489958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245251
This update fixes an issue where 0% NT/EXEMPT taxes were incorrectly filtered during downpayment creation in the Arabic localization (l10n_ar). Previously, these taxes weren't properly included, leading to incorrect calculations. This change ensures accurate tax reporting for downpayments, aligning with Arabic tax regulations.
Original PR description
Taxes 0% NT and 0% EXEMPT should not be fixed taxes. This is causing issue in some cases such as downpayments, where those taxes needs to be present, but fixed taxes are filtered at the creation of the downpayment. opw-5815953 Forward-Port-Of: odoo/odoo#245252
This update corrects a user experience issue where demo data included the name "Deco Addict," causing confusion. The name has been updated to "Acme Corporation" to align with standard demo data practices and prevent user misinterpretations. This ensures a cleaner and more reliable demo environment.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502
This update resolves a customer complaint regarding demo data. The name "Deco Addict" has been replaced with "Acme Corporation" to avoid confusion and ensure accurate test scenarios. This change improves the user experience and data integrity within our demo environment.
Original PR description
A company that happens to be named "Deco Addict" has complained some of our users thought they had business with them due to test and demo data containing that name. It will now be named Acme Corporation. task-5865502
This update resolves an issue where pricelist rules weren't being applied to product variants when editing in 'expanded' mode. Previously, rules only applied to the product's template. Now, when a pricelist rule is edited for a variant, it correctly applies the selected price, ensuring accurate pricing in sales quotations.
Original PR description
Description of the issue/feature this PR addresses: - A pricelist rule never apply to a product variant, always its template when edited in "expanded" mode - This is because the `applied_on` field is…
Description of the issue/feature this PR addresses: - A pricelist rule never apply to a product variant, always its template when edited in "expanded" mode - This is because the `applied_on` field is missing on the `product.pricelist.item` form view. Current behavior before PR: - Install `sale_management` - Enable "Pricelist" setting - Go to Sales - Products - Pricelists and create a new "Sample" Pricelist. - Create 3 rules for the same product (template), one with price at 6666, a second one at 6667 and the last one at 3333 <img width="1416" height="649" alt="image" src="https://github.com/user-attachments/assets/1d50499e-cb49-4341-971c-5a2a5111b9ca" /> - Next step, edit 2 first rules for price 6666 and 6667 to set a variant **BUT before starting editing, open the form in expanded mode using two-arrows button** <img width="1416" height="889" alt="image" src="https://github.com/user-attachments/assets/056cb862-3dc6-4868-b6d3-a0917f3e7242" /> - Set the variant to the first price rule (as you can see, the rule name is immediately updated with "Variant: [REF] Product name" <img width="1421" height="428" alt="image" src="https://github.com/user-attachments/assets/168ad5fb-902b-494f-888a-419983324607" /> - Save the price rule (_note that the display name incorrectly resets to default_) <img width="634" height="370" alt="image" src="https://github.com/user-attachments/assets/ec915985-b1a3-4a69-9153-7384abdb190d" /> - Same thing for second rule <img width="695" height="375" alt="image" src="https://github.com/user-attachments/assets/69b9ae62-493c-4f0e-ae87-438975e1bceb" /> <img width="621" height="369" alt="image" src="https://github.com/user-attachments/assets/e1dc0342-7b87-42df-bf7d-6a3aace61253" /> - Create a new sale quotation with pricelist set to our "Sample" - Add product [6666] <img width="1207" height="420" alt="image" src="https://github.com/user-attachments/assets/07d4fb94-03b3-45ae-aeb4-feca4fee9c2c" /> - Add product [6667] <img width="1209" height="431" alt="image" src="https://github.com/user-attachments/assets/03e3a76a-2bb1-44e9-a819-ce3ca35703c7" /> - Incorrect prices in sale order <img width="1415" height="828" alt="image" src="https://github.com/user-attachments/assets/3626028d-31d0-4687-b09d-094c0212042a" /> Desired behavior after PR is merged: - Each variant must have its own price. - The added test simply edit the pricelist item using its own form. - The `applied_on` field is added to the pricelist item form to ensure that its value is saved. - If we edit the rule without expanded mode, it works fine only because the `applied_on` field exists in the list view as an invisible column. _Note 1_: `applied_on` is updated by `_onchange_rule_content` using `update` instead of `write` (for caching ?). But if the `applied_on` field is not on the form, then its value is never sent to low level `_write_multi`. _Note 2_: to clear the field value with the Form test component, we must set `=self.env["product.product"]` instead of `=False` .... --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a limitation in how users manage their consent for online account synchronization. Previously, a short-lived access token caused the synchronization link to break after 30 minutes. Now, a more stable consent token is used, linked to the user, ensuring a consistent and reliable synchronization process.
Original PR description
In this commit:bf5b7d0 we introduce a message on the account_online_link to be able to manage the consent. (one needed fix in this commit:https://github.com/odoo/enterprise/commit/1c84804fd3f0c0d1d23916b9f6a388616f66ac7e) This commit will change the way we manage the consent since the access token is in fact available only for 30 min, so the link in the chatter would not work. We decided to have a consent token which is a uuid4 encoded in base64 (url safe) and link it to the odoofin user. task-5187621 Forward-Port-Of: odoo/enterprise#105202
This update enhances the security and reliability of our Peppol integration by implementing a safer method for server-initiated deregistration. The system now handles deregistration more gracefully, allowing users to re-register after a server-initiated step. This change was prompted by a previous incident and is designed to improve overall system stability.
Original PR description
Reintroduce server-initiated deregistration on `client_gone`, but only for implementations that explicitly handle it. The base proxy client now just raises the error. Peppol opts in by soft-resetting its configuration so users can re-register. See the IAP postmortem for the rationale and incident history. https://github.com/odoo/iap-apps/pull/1317 no-task Forward-Port-Of: odoo/odoo#244575 Forward-Port-Of: odoo/odoo#239254
This update resolves a potential infinite loop issue that could occur when generating product attribute combinations, specifically with multi-checkbox attributes having no values. The fix ensures that lines without values are excluded from the combination process, preventing the loop and improving system stability. This change impacts product configuration and ensures accurate attribute selection.
Original PR description
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end…
Before this commit, having a `product.template.attribute.line` with zero `product.template.attribute.value` records might cause an infinite loop if this **multi-checkbox** attribute wasn't in the end of the list.
Suppose the order was arbitrary and we are generating combinations for two lines (the order here is important):
- Line (A) -> [] (multi checkbox type)
- Line (B) -> [attr_1, attr_2]
- The possible combinations are {(attr_1), (attr_2)}.
After generating the second combination the following 2 procedures happen.
- The value_index_per_line[1] will be resetted to -1,
- The line_index will decrement from 1 to 0.
Now, since the first line doesn't have any values, it will be skipped and the line_index will be incremented to 1.
This results in the redundant generation of the same combination, triggering an infinite loop.
Since this method yields a recordset of `product.template.attribute.value` model and the **multi-checkbox** attribute doesn't have a value being passed to the method anyways, we can exclude the lines that doesn't have values for the algorthim not to be stuck in an infinite loop.
opw-5267179
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241557This update fixes an issue where errors during tax processing in HR payroll could silently fail. It now provides clearer warnings for unsuccessful tax calculations, ensuring accurate reporting and preventing data discrepancies. The changes also improve compatibility with UBL tax extension features.
Original PR description
- Improving error handling for various requests - Adjusting XML generation to not conflict with `account_edi_ubl_cii_tax_extension` if it is installed - Adding a separate test for HR:E category taxes - Replacing skipping import of not successfully fiscalized document with warnings displayed on the moves after import task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a test failure in Odoo's web_studio module caused by a missing dependency. The fix ensures that tests accurately check for the presence of required modules and their associated models, preventing false test failures. This improves the stability and reliability of the web_studio functionality.
Original PR description
`RELATED_MODELS_TO_EXCLUDE` contains `account.edi.document`, which is installed by `account_edi`, which is neither in the `needed_modules` set nor a dependency of any of them. Therefore the test can fail because `account_edi` is not installed even though every module in the set is. Improve the test by checking that the models or fields we're checking for actually belong to the modules we've listed. Also add the missing module in the list.
This update removes outdated test code related to exchange rate precision in the l10n_mx_edi module. The previous fix inadvertently left this older code in place, and this PR ensures the testing environment is clean and consistent. This improves the reliability of the Mexican tax reporting functionality.
Original PR description
The PR #102557 fixed an issue with exchange rate precision for Solution Factible. However, its forward ports for 18 (PR #104195) and saas-18.2 (PR #104673) did not properly delete some of the old test code. This PR deletes that code. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200)
This update fixes an issue where payment references on Italian invoices were incorrectly populated with a unique invoice number. Now, the payment reference field will only be filled with the actual payment reference provided by the partner, simplifying automated payments and aligning with Italian tax regulations. This ensures accurate reconciliation of payments.
Original PR description
Description of the issue/feature this PR addresses: The payment_reference field in invoices was being filled with a wrong field from the imported XML, progressivoinvio is the progressive number of invoices sent by the partner's system, not a partner's requested payment reference. Current behavior before PR: On import, payment_reference was being filled with ProgressivoInvio, making automated payments out to partners harder. Desired behavior after PR is merged: payment_reference is only being filled if partner specifies a payment reference in the EDI, avoiding confusion. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the Fedex rate selection process was failing when the requested currency didn't match the Fedex account settings. The fix ensures the rate request uses 'PREFERRED' as a prefix, aligning with available Fedex rate types and preventing errors calculating shipping costs.
Original PR description
Issue ----- Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the…
Issue ----- Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means `d['rateType'] == rating_result['actualRateType']` is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`. Solution ----- In the request we send, we hardcode `'rateRequestType': ['PREFERRED']` so we can look for a match using 'PREFERRED' as a prefix of `rateType`. The Fedex API lists all possible values of the enum `rateType` https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html <details> <summary>Enum values as per the API</summary> "enum": [ "INCENTIVE", "NEGOTIATED", "PAYOR_ACCOUNT_PACKAGE", "PAYOR_ACCOUNT_SHIPMENT", "PAYOR_CUSTOM_PACKAGE", "PAYOR_CUSTOM_SHIPMENT", "PAYOR_LIST_PACKAGE", "PAYOR_LIST_SHIPMENT", "PAYOR_RETAIL_PACKAGE", "PAYOR_RETAIL_SHIPMENT", "PREFERRED_ACCOUNT_PACKAGE", "PREFERRED_ACCOUNT_SHIPMENT", "PREFERRED_CUSTOM_PACKAGE", "PREFERRED_CUSTOM_SHIPMENT", "PREFERRED_INCENTIVE", "PREFERRED_LIST_PACKAGE", "PREFERRED_LIST_SHIPMENT", "PREFERRED_NEGOTIATED", "PREFERRED_RETAIL_PACKAGE", "PREFERRED_RETAIL_SHIPMENT", "RATED_ACCOUNT_PACKAGE", "RATED_ACCOUNT_SHIPMENT", "RATED_CUSTOM_PACKAGE", "RATED_CUSTOM_SHIPMENT", "RATED_LIST_PACKAGE", "RATED_LIST_SHIPMENT", "RATED_RETAIL_PACKAGE", "RATED_RETAIL_SHIPMENT", "UNKNOWN" ], </details> There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe. ----- Ticket: opw-5482949
This update resolves an issue that previously caused errors when users created inherited views in Odoo. The fix ensures that a validation error is triggered if the XPath syntax is incomplete, preventing the application from crashing and improving user experience. This change enhances the stability of the user interface customization features.
Original PR description
Currently, an error occurs when a user creates an inherited view. **Steps to Reproduce:** - Go to `Settings > Technical > User Interface > Views`. - Create a new view by entering `name` and selecting…
Currently, an error occurs when a user creates an inherited view.
**Steps to Reproduce:**
- Go to `Settings > Technical > User Interface > Views`.
- Create a new view by entering `name` and selecting any `inherited view`.
- In the `Architecture`, enter the below code:
```
<xpath position="replace">
<field name="name"/>
</xpath>
```
- Now save the view.
`TypeError: Argument must be bytes or unicode, got 'NoneType'`
Cause:
As we can see, when the user enters an xpath without the expr attribute, and when it goes to find the inherited node [1]. Since the expr is missing, its value becomes None [2]. Passing this None as an argument [3] causes the error.
This commit ensures that when a user creates or edits a view with an xpath that is missing the expr attribute, a ValidationError is raised indicating that the expr attribute is missing in the XPath.
[1]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L145
[2]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L76
[3]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L78
[4]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/addons/base/models/ir_ui_view.py#L377-L384
sentry-7161414430
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a bug where self-order kiosk tickets were printing blankly when a preparation printer was configured without product categories. The fix ensures that kitchen printers only print when a product category is defined, aligning with the expected behavior of the self-order system. This prevents blank tickets and improves the kiosk experience.
Original PR description
Before this commit: To reproduce (version 17 and >): 1. Install Restaurant 2. In PoS restaurant config allow "Self ordering" in Kiosk mode and enable "Preparation printers" 3. Create a preparation printer with NO categories and set it as a restaurant preparation printer 4. Open the Kiosk 5. Make an order with any product and checkout -> Printer will print a ticket with no product <img width="512" height="415" alt="image" src="https://github.com/user-attachments/assets/31bd08f9-2470-4f72-9e3d-822564b43f70" /> After this commit: No kitchen printer is printed (expected as no category set on the kitchen printer) Forward-Port-Of: odoo/odoo#245193
This update resolves an issue where the UBL export incorrectly interpreted a '/' as a VAT indicator. The change ensures that when a partner doesn't have VAT, the mandatory CompanyID is correctly included, aligning with PEPPOL standards. This improves the accuracy of electronic invoice generation for simplified documents.
Original PR description
To signify that you know a partner does not have vat, we advise using '/'. But we should take care of that in the UBL export, to not consider it a real vat Also, in the cases where we don't have the vat, the CompanyID is supposed to be mandatory. https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-TaxRepresentativeParty/cac-PartyTaxScheme/ So, remove the whole PartyTaxScheme if vat is not present. Zatca does not override that rule (except enforcing that seller must have vat, which raises a constraint), so we modify the tests for the simplified documents. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238499
2 changes
Resolved issues and error corrections
This update fixes an issue where the 19%I tax code (9) was missing from Datev exports for expense journal entries. The problem occurred due to how payment amounts were aggregated, leading to inaccurate data transfer. This ensures consistent and compliant tax reporting for Datev.
Original PR description
Currently, when using 19%I tax in vendor bills, the tax code (9) is shown correctly in the BU-Schlüssel section of the datev export. This however is not the case for expense journal entries. Steps to reproduce: - With DE Company setup - Create an Expense as follows: - Included taxes: 19% I - Paid by: Company - Create report > Submit to Manager > Approve > Post Journal entries - Open General Ledger and export Datev Data Issue: Tax code will be missing from the exported entry. This occurs because, when processing payment move lines, amounts and accounts are aggregated, losing track of the source tax. opw-5388791
This update resolves an issue where some accounts were missing from XLSX exports of the General Ledger due to a NULL value in the 'include_initial_balance' field. This change ensures all accounts are included in the batch export, addressing a reported problem impacting customer reporting.
Original PR description
…LSX export We recently added a batch export for the xlsx file for the General Ledger as the basic export was having a memory error. To handle it, we first determine which accounts are present in the report by running a custom query which uses the computed boolean field include_initial_balance. It appears with some customers' tickets that this field is set to NULL in their databases. This value might potentially come from a legacy artifact from an older Odoo version. I have not found a way to reproduce the issue without running a custom query. For customers having this field set to Null, it results in an incomplete export where these accounts are missing. opw-5787298 opw-5797979