Daily updates from Odoo
Thursday, February 5, 2026
24 changes · 19.0
Enhancements to existing features
This update enhances the booking view in the Odoo Enterprise system by adding breadcrumbs. This provides clearer navigation for users, making it easier to understand their location within the booking process and improving the overall user experience. The change was implemented to streamline workflow and reduce potential confusion.
Original PR description
In this commit: - Enable breadcrumbs for the booking view by explicitly allowing them in the action context. Task:5490961
Resolved issues and error corrections
This update fixes an issue where subscription invoices were being generated prematurely when a section or note was added to the subscription. The fix ensures that invoice dates align with the expected end of the subscription period, regardless of whether a section or note is included. This improves invoice accuracy and consistency for our subscription customers.
Original PR description
**Steps to reproduce** - Have a subscription service product with invoicing policy set to "Based on delivered quantity (manual)". - Create a new monhtly subscription with this product and add a section or a note. - Confirm the subscription. Actual: next invoice date is today. Expected: same as without section/note, next invoice date should be at end of the period. **Cause** `_is_postpaid_line` should only be called on actual product lines. Related: https://github.com/odoo/enterprise/commit/d8a7f7cc2d9d11e42ed24db1b0f7a3c08c7fac1c opw-5478394 Forward-Port-Of: odoo/enterprise#104892
This update resolves an issue where subscriptions with zero-sum quantities resulted in invoices being generated with the initial start date instead of the correct invoice date. The fix ensures accurate invoice date calculations by handling negative quantities correctly, preventing incorrect invoice generation.
Original PR description
### Issue: When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date. ### Steps to reproduce: - Install…
### Issue: When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date. ### Steps to reproduce: - Install 'sale_subscription' - Create a new Subscription with two lines and a tart data several months in the past - One with a quantity of 1 and a higher price - The other with a quantity of -1 - It can be the same service product with invoicing based on ordered quantity - Confirm the Subscription - Click "Create Invoice" and confirm the invoice - Back to the Subscription, the next invoice date was not updated. ### Cause: In `_get_max_invoiced_date()` to compute the invoiced periods we check the quantity corresponding to this period. But if an invoice has two lines with opposite quantities, they will cancel each other out at this line: https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move_line.py#L131 So the method will return not return the date in `invoice_dates`. Later, if `_get_max_invoiced_date()` returns nothing for `last_invoice_end_date` then `next_invoice_date` is set to `start_date`: https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move.py#L66-L67 ### Solution: The goal was to not include invoices that were fully refunded for the `last_invoice_end_date`. This is why `_get_max_invoiced_date()` substract the quantities from refunds. To make this work we can take the absolute value of the quantity returned by the compute method before giving it the wanted sign based on if it's an invoice or a refund. opw-5360930 Forward-Port-Of: odoo/enterprise#106364 Forward-Port-Of: odoo/enterprise#103705
This update corrects an issue where project forms, accessed through SmartButtons, were initially displayed as uneditable. The fix removes a setting that was incorrectly preventing editing, ensuring users can now fully interact with project forms. The reason for this initial setting remains unclear.
Original PR description
Issue: When navigating to any form view related to an FSM Project via
SmartButtons, they are loaded as uneditable
Solution: Remove "edit":False in _update_action_context method
Note: It is unknown why this was added in the first place, since
removing it does not cause any crashes
opw-5413753
Forward-Port-Of: odoo/enterprise#105225This update resolves an issue where toggling the Studio feature in Odoo Enterprise would sometimes disrupt the layout of form stat buttons. Now, the stat button layout remains consistent regardless of whether Studio is active, ensuring a better user experience when designing and editing forms.
Original PR description
**Before this commit:** Toggling Studio could break the layout of form stat buttons. **After this commit:** The stat button layout remains intact when Studio is toggled. task-5480309
This update resolves a technical problem with the way sale commission IDs were generated, preventing errors caused by IDs exceeding JavaScript's maximum safe integer limit. The change increases the range of IDs allowed for the 'plan_id' field, significantly expanding the number of commissions that can be tracked without causing errors. This improves system stability and scalability.
Original PR description
Issue: 10^13 was too big of an exponent as such the id generated were bigger than JS limit `Number.MAX_SAFE_INTEGER`, this resulted in the id being rounded to the nearest reprentable integer. Which resulted in a traceback as we were fetching records that didn't exist. This fix allow a bigger margin for the plan_id while keeping the collusion risk equal, as we have the following: - user_id margin is 10^5 - date is in YYMMDD format, so it occupies at most 6 integer - plan_id can thus occupy the space after which is 5 + 6 so 10^11 Only issue possible left with this id generation would be to have user that are 1000 id apart, with same date and same plan. Or that we have too much plan that we exceed the JS limit. Number of plan that can be handled with this change goes from ~900 -> ~90000 which seems reasonable.
This update corrects a technical issue causing duplicate Worldline receipts to be generated in POS transactions. The fix ensures receipts are only added when a transaction is fully completed, improving the accuracy of sales records. This resolves a reported problem impacting transaction reporting.
Original PR description
This PR fixes the issue where Worldline receipts were sometimes added twice to the pos receipt by only modifying the receipt if the transaction has been finished (currently we modify the receipt no matter the message type (cancellation/payment failed etc.)) ticket-5342655
This update fixes an issue where appraisal templates couldn't select departments without a linked company. The fix ensures all departments are visible in the dropdown, improving usability and preventing employees from being restricted to departments with company associations. This resolves a bug impacting template configuration.
Original PR description
### Issue:
On the appraisal template form view, the dropdown of "Departments" does not show departments with no company.
### Steps to reproduce:
- In the Employee app create a new Department with no company
- Go in Appraisals > Configuration > Appraisal Templates
- Click on a template, remove it's company if it has one
- Try to change the Department of the template
- The new department does show
### Cause:
The field `department_ids` on `hr.appraisal.template` have this domain: `(company_id and [('company_id', 'in', [company_id, False])] or [('company_id', 'in', allowed_company_ids)])` It excludes departments with no company when the template have no company because `allowed_company_ids` doesn't contain `False`.
### Solution:
Add `False` in `allowed_company_ids`.
opw-5354581This update resolves a critical issue preventing the legal validation of annual VAT reports for Luxembourg. The fix adds missing required fields to the XML export, ensuring compliance with reporting regulations. This ensures accurate tax reporting and avoids potential delays or penalties.
Original PR description
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields:…
### Issue: The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export ### Cause: This PR add some required fields: https://github.com/odoo/enterprise/pull/93357 However, for file validation, the following parent fields are mandatory if certain child fields are present: ``` - Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197 - Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198 - Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199 - Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200 - Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162 ``` 164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171 ### Note: This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785 It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict ### Steps to reproduce: - Install `l10n_lu_reports` and switch to LU company - Open the Tax Report `Annual VAT Declaration` - Export the XML - Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing opw-5119920 Forward-Port-Of: odoo/enterprise#106457 Forward-Port-Of: odoo/enterprise#105143
This update ensures that freight costs are accurately reflected on international delivery customs documents generated by SendCloud. Previously, these costs were missing, leading to potential discrepancies in customs declarations. This change aligns with SendCloud's API specifications and improves the accuracy of international shipping documentation.
Original PR description
Issue ----- For international deliveries, the customs document does not include the freight costs. Steps to reproduce ----- - Create an international sale (eg BE -> US) - Validate delivery - Open the commercial invoice > Freight costs is set to 0 Change ----- The `freight_costs` should be included in the `customs_information` field of the request (along with all customs-related data, as other fields have been deprecated) https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/parcels/operations/create-a-parcel#:~:text=object%2E-,customs%5Finformation ----- Ticket: opw-5486742 Forward-Port-Of: odoo/enterprise#106387 Forward-Port-Of: odoo/enterprise#105543
This update resolves an error that occurred when employees were linked to multiple commission plans using the same payslip input. The fix ensures accurate currency conversion for each commission, preventing a system error and guaranteeing correct pay calculations for employees with multiple commission agreements. This improves the reliability of payroll processing.
Original PR description
Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input. **Steps to Reproduce:** 1. Install the…
Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input. **Steps to Reproduce:** 1. Install the hr_payroll_sale_commission module. 2. Create a user and link to an employee. Set a contract for the employee. 3. Create two commission plans for the same user: - Use the same Payslip Input in both plans. - Set the Target Frequency to "Monthly" for both. 4. Generate a payslip for the employee. Ref: [Video](https://drive.google.com/file/d/1HhtUL2xznS_Aoi9ePL0OJLdGaXU8ZFZR/view?usp=sharing) **Error:** `ValueError - Expected singleton: sale.commission.report(30026010100009, 40026010100009)` **Cause:** When multiple commission records belong to the same payslip input, it tries to convert the commission amount using `coms.commission`, where coms has multiple recordsets. This leads to a singleton error during currency conversion. **Fix:** This commit ensures the currency conversion is applied per commission and prevents the singleton error. sentry-7187854690 Forward-Port-Of: odoo/enterprise#106124 Forward-Port-Of: odoo/enterprise#104464
This update resolves an issue that prevented the 'hr_expense_stripe' module from installing correctly in countries without Stripe integration (like Romania). The fix removes a redundant constraint that triggered the error, ensuring proper installation and functionality across all supported localizations.
Original PR description
[FIX] hr_expense_stripe: error when installing loca not supported Step to reproduce the bug: - install 'hr_expense_stripe' - try to install a localization where Stripe is not available (e. g. Romania) - The error raise This is due to an @api.constrains that can be removed no-task
This update adjusts the scheduling of a daily report generation process. By extending the cron interval to 9999 months, the automatic execution is disabled, preventing unnecessary database activity and improving system performance. This change ensures the real-time, trigger-based workflow remains efficient.
Original PR description
The cron interval is updated from 1 day to 9999 months to effectively Disable automatic execution. The workflow is fully real-time and trigger-based, and running this cron Daily would unnecessarily wake up registries and databases. task-5885482
This update fixes an issue where WhatsApp messages to blacklisted numbers weren't being blocked correctly when the recipient's country differed from the sender's company country. The fix ensures that all blacklisted numbers, regardless of recipient location, are properly blocked, improving communication security and preventing unwanted messages.
Original PR description
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country. ### Steps to reproduce 1. Configure a…
Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country.
### Steps to reproduce
1. Configure a WhatsApp account.
2. Set the Company's country to Germany (+49).
3. Create a Contact with a Belgian phone number (e.g. +32456001122).
4. Send a template message to this contact.
5. Have the contact reply with "STOP" to opt-out (this correctly adds +32456001122 to the blacklist).
6. Send another message to the contact.
- Expected: The message is blocked.
- Actual: The message is sent successfully.
### Root cause
The blacklist search logic relies on implicit phone number sanitization which behaves incorrectly for international numbers without a `+` prefix.
1. `whatsapp.message` stores numbers as `CountryCode + NationalNumber` without a `+` (e.g. "32456001122").
2. `phone.blacklist` stores numbers in E.164 format with a `+` (e.g. "+32456001122").
3. When searching `phone.blacklist` with "32456001122", the system interprets it as a local number for the Company's country (Germany) because of the missing `+`.
4. It reformats the search term to German E.164 ("+4932456001122").
5. The query fails to match the actual blacklisted number ("+32456001122"), allowing the message to pass.
### Fix
Explicitly prepend a `+` to the recipient's number before searching the blacklist. This forces the validation logic to parse the number as international (E.164), bypassing the company-country bias and ensuring the search term matches the stored blacklisted number.
opw-5401789
Forward-Port-Of: odoo/enterprise#106395
Forward-Port-Of: odoo/enterprise#104556This update fixes an issue where the quantity displayed after exiting a barcode MRP operation was not accurately reflecting the remaining quantities. Specifically, the system incorrectly handled move quantities when the operation was completed, leading to display discrepancies. This ensures accurate quantity tracking within the MRP process.
Original PR description
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty…
**Issue** When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities. **Steps to reproduce** - Create a product with a BOM using a component with qty 6. - Create an MO producing qty 1. - Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed). - Click “+1”. - Edit the component qty from 6 to 3. - Exit the operation. - Re-enter the operation. -> The component shows 3/3 instead of 3/3 and 0/3. **Cause** On exit, `_onExit`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489 calls `post_barcode_process()`, which triggers `split_uncompleted_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16 correctly creating a `stock.move.line` with qty 3. However, `_truncate_overreserved_moves`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40 then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49 This happens because the newly created move line is initialized with `reserved_uom_qty = 0`: https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256 leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6. opw-5166763 Forward-Port-Of: odoo/enterprise#104199 Forward-Port-Of: odoo/enterprise#100314
This update resolves a bug that incorrectly flagged journal entries with mixed expense and revenue accounts (without deferred dates) as invalid. Previously, the system enforced a strict rule about matching deferred entry generation methods. Now, the validation only applies when actual deferred dates are configured, improving usability for common miscellaneous operations.
Original PR description
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc…
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc entries with both expense and revenue accounts but no deferred dates configured. https://github.com/odoo/enterprise/blob/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b/account_accountant/models/account_move.py#L150-L151 Steps To Reproduce: 1. Go to Settings → Accounting and set different "Generate Entries" methods for deferred expenses "On bill validation" and deferred revenues "Manually & Grouped". 2. Go to Accounting Dashboard and create a new Miscellaneous Operation. 3. Create 2 journal items: one with an expense account and one with a revenue account (neither configured for deferred entries). 4. Try to post the entry. 5. Error appears: "Having different deferred entries generation methods for expenses and revenues is not supported..." The validation should only apply when lines actually have deferred dates set, not for all misc entries with mixed account types. Commit that caused the issue: https://github.com/odoo/enterprise/commit/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b Ticket [link](https://www.odoo.com/odoo/project.task/5486114) opw-5486114 Forward-Port-Of: odoo/enterprise#104476
This update resolves a bug where the POS ID wasn't correctly sent to the blackbox during v1 CleanCash integration. The fix ensures accurate data transmission, and a related change restricts blackbox device selection in the POS configuration, improving data integrity and security.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. Another small fix was made to only allow selecting blackbox devices in the Fiscal Data Module field in the POS config settings. task-5077448 Forward-Port-Of: odoo/enterprise#106431
This update fixes a potential issue where bank reconciliation cron jobs would fail if notification emails couldn't be sent. Now, notifications are queued for later delivery, ensuring the cron job completes successfully and avoids rescheduling the next day. This improves the reliability of bank statement reconciliation.
Original PR description
[FIX] account_accountant: cron auto reconcile - mail notification concurency The aim of this commit is to prevent the cron from failing due to an issue in sending notification in the post_commit hook. Context: The issue was spotted on odoo.com while import bank statement transaction Before this commit: Failing to write on mail_notification during the post_commit hook could make the entire cron fail and be reschedule to the next execution date. (The next day by default) After this commit: The mail_notification are put in the mail queue to be sent later on. Task-id: None
This update resolves an issue where changes made to spreadsheets were lost after deleting archived revisions. Now, reloading the spreadsheet after deleting archived revisions correctly applies the most recent changes, ensuring data integrity and preventing data loss.
Original PR description
Steps to reproduce - create a spreadsheet - do a few changes - leave the spreadsheet (to snapshot) - reopen the spreadsheet - do a few more changes - from another tab, go to Settings/Technical/Revisions - delete all archived revisions - reload the spreadsheet => the last changes are lost and new changes are no longer saved.
This update resolves an issue where sign requests created on older Odoo versions (prior to 16.0) would fail due to missing communication company information. The fix automatically uses the user's company date format in these cases, ensuring sign requests can be processed without errors.
Original PR description
For old databases that were created before 16.0, existing sign request might not have a communication company set. Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to…
For old databases that were created before 16.0, existing sign request might not have a communication company set.
Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to open such sign request will result in a crash:
```
Traceback:
...
File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 354, in get_document
context = self.get_document_qweb_context(request_id, token)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 88, in get_document_qweb_context
date_format = posix_to_ldml(lang.date_format, locale=locale)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/saas-18.3/odoo/tools/misc.py", line 606, in posix_to_ldml
for c in fmt:
TypeError: 'bool' object is not iterable
```
This commit fallback to the create user's company to determine the date language when there is not communication company set.
no-task (from feedback pad)
Forward-Port-Of: odoo/enterprise#87526This update resolves an issue where products with a zero price were being sent to UrbanPiper during menu synchronization, causing problems on their end. The change now excludes these zero-price charge products from the sync process, ensuring smoother integration with UrbanPiper.
Original PR description
Before this commit: --- - During menu sync, charge products with a price of zero were sent to UrbanPiper which caused issues on the UrbanPiper side. After this commit: --- - Exclude charge products with a zero price from the menu sync. task-5867272 Forward-Port-Of: odoo/enterprise#106491 Forward-Port-Of: odoo/enterprise#105861
This update resolves a problem with Indian GST reports where test cases were failing due to a recent community fix. The test cases have been updated to correctly reflect the new label format that includes the bill reference, ensuring accurate reporting.
Original PR description
Before: - Test cases in Indian GST reports were failing because they expected payable line labels like `installment #1`, but after the community fix (Task: 4982864), payable lines are now populated with the bill reference when Payment Reference is empty, resulting in labels like `TEST/0001 installment #1`. After: - Modified test cases to expect the new label format that includes the bill reference. Related PR (Community) : https://github.com/odoo/odoo/pull/221491 Task: 4982864 Forward-Port-Of: odoo/enterprise#106468 Forward-Port-Of: odoo/enterprise#91535
This update resolves a technical issue related to how time off is reported to the next month. A rounding error was causing incorrect work entries, preventing employees from properly deferring time off. This fix ensures accurate reporting and avoids potential payroll discrepancies.
Original PR description
STEP TO REPRODUCE: ------------------ 1- Set to an employee a schedule of 7h36 hours per day 2- Create a payslip for him on february and pay it 3- Create a time off from 28th debruary to 4th of march 4- Approve it and click on the button "Report to Next Month" You will have an issue but you should be able to do it REASON: ------- A rounding issue caused the creation of work entry of 1*10^-15 hours
This update fixes a bug that prevented users from accessing the signature request feature on mobile devices. The issue stemmed from a difference in how the action was displayed on mobile versus desktop, specifically related to the search view. This change ensures that all users can now initiate signature requests via the mobile app.
Original PR description
Steps:
- Install `industry_fsm`
- Be on mobile (via dev tools it's ok)
- Have minimum one task
- Go to My tasks
- Click on the first kanban record
- Cog Menu -> you don't have "Request signature"
- If you do the same on Desktop (or with a bigger screen) you will
In mobile view, the action only has the form view, so the search view is not loaded. This means that the condition checking that “message_ids” is in the search view does not work on mobile. This commit fixes the problem by using the model in the environment via `env.model.root.fields` to find `message_ids`.
opw-5485720