Daily updates from Odoo
Friday, May 8, 2026
32 changes · master
Resolved issues and error corrections
This update corrects a problem in how payslips are calculated for the Hong Kong payroll module. Specifically, a test was failing because the system wasn't correctly accounting for the year of the payslip when running tests in different environments. This ensures accurate payslip generation for all employees.
Original PR description
ir56b._compute_period depends on year_of_employer_return, which is derived from submission_date (defaults to today). If tests are run in a different year (mocked time or different environment), the period won't cover the January 2026 payslip. Forward-Port-Of: odoo/enterprise#116364 Forward-Port-Of: odoo/enterprise#116172
This update fixes an issue preventing users from signing documents containing read-only date fields. The system incorrectly flagged these fields as empty, blocking the signing process. The fix ensures that read-only date fields are properly recognized during document submission, allowing for complete and accurate signing.
Original PR description
Version: - saas-19.2 Steps to reproduce: - Create a sign template with a read-only (constant) date field. - Add at least one more sign item (e.g., text/signature). - Try to sign the document. Issue: - Signing is blocked with warning: “Some required items are not filled”. Cause: - Read-only date fields don’t have a value in `item.el.value`. - The system only checks value, so it treats the field as empty. - Even though the date is visible in the document, it is not picked during submission. Solution: - Update date value extraction to also read from `textContent` when value is empty. - This ensures read-only date fields are correctly considered filled. task-6181883 Forward-Port-Of: odoo/enterprise#116009
This update fixes a crash that occurred when preparing orders for future online food deliveries. The issue stemmed from an incorrect date format, which has now been corrected to ensure the preparation display functions reliably. This improves the stability of the online ordering process.
Original PR description
### In this commit: Fixes a crash in the preparation display when handling future online food delivery orders. The issue was caused by an invalid delivery time format. This is resolved by properly passing the delivery time as a Number in the utils. Task-[5960176](https://www.odoo.com/odoo/project/1737/tasks/5960176) Forward-Port-Of: odoo/enterprise#116558 Forward-Port-Of: odoo/enterprise#108298
This update resolves a duplication issue in the French Profit and Loss report by removing a redundant account (6492) from the calculation. This ensures accurate financial reporting aligned with French accounting standards. The fix builds upon previous work to prevent duplicate accounts in the report.
Original PR description
This commit is an addon to this commit[[1]] where we tried to avoid duplicate accounts in the Profit And Loss report. The problem is that we don't exclude the separated account 6492 from the original one (649). This commit adds the removal of this account in the report formula. task-6053784 Here is the coverage: [Profit and loss account (FR) - Accounts Coverage Report (2).xlsx](https://github.com/user-attachments/files/27011824/Profit.and.loss.account.FR.-.Accounts.Coverage.Report.2.xlsx) The correct separation: <img width="837" height="485" alt="image" src="https://github.com/user-attachments/assets/ebe98976-f689-4389-866a-c9a0c8b50534" /> [1]: https://github.com/odoo/enterprise/commit/4587c49c4b220305652150d2f21a95fb7cfa188d Forward-Port-Of: odoo/enterprise#116319 Forward-Port-Of: odoo/enterprise#114858
This update resolves an issue where the point-of-sale tour was unreliable and produced inconsistent results. The fix ensures the tour is predictable and correctly identifies the order, improving the user experience. A minor typo was also corrected to enhance test reliability.
Original PR description
Remove the `undeterministicTour_doNotCopy` key from `OrderFlowTour` and make the tour deterministic by properly selecting the order. Also, fix a typo in the assertion in `test_01_order_flow`. Task-6065459 Forward-Port-Of: odoo/enterprise#116431 Forward-Port-Of: odoo/enterprise#111915
This update resolves a problem where DIAN XML files (AttachedDocument type) weren't being correctly imported, leading to data loss. The fix ensures the system first identifies the AttachedDocument structure, allowing it to properly process the embedded invoice data as required by DIAN regulations.
Original PR description
### Issue: Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data This issue only occurs for `AttachedDocument` files According to the DIAN…
### Issue: Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data This issue only occurs for `AttachedDocument` files According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf However, no strict validation is enforced, so variants should still be supported ### Cause: When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:` This causes issues with documents structured like: ```xml <AttachedDocument> <CustomizationID>Documentos adjuntos</CustomizationID> <ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID> </AttachedDocument> ``` In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian` As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document ### Steps to reproduce: - Install `l10n_co_dian` - Go in Bills and import the test document: `import_attached_document_2` Before the fix, nothing it extracted from the xml opw-6083523 Forward-Port-Of: odoo/enterprise#115599
This update fixes an issue where the Work Orders Planning Gantt view incorrectly included workcenter downtime in employee duration totals. The change now accurately accounts for workcenter unavailability, ensuring more precise and reliable duration calculations for employee workloads. This improves the accuracy of resource planning.
Original PR description
In the Work Orders Planning Gantt view grouped by employee, the total duration did not consistently respect workcenter unavailabilities. This change ensures workcenter unavailabilities are included in the payload when grouping by employees, allowing the renderer to correctly calculate aggregated totals. Before: - Employee-grouped totals could count duration during workcenter downtime. After: - Employee-grouped totals correctly respect workcenter unavailability. This commit's changes: - In employee Gantt data preparation, added the workcenter unavailability payload by extracting workcenter IDs from the fetched work orders and calling `_gantt_unavailability` on those IDs to retrieve the intervals that should be excluded from the totals. task-6089572 Forward-Port-Of: odoo/enterprise#112805
This update ensures that product and combo product cards in the Point of Sale module now have a consistent visual style. Previously, combo products had a different background, leading to a disjointed look. This change improves the overall user experience and presentation of products within the POS system.
Original PR description
In this commit: --- - Applied the same background styling to combo items as normal product cards. - Ensured visual consistency between product cards on the product screen and in combo configuration popup. | Before | After | | -------- | -------- | | <img width="979" height="447" alt="image" src="https://github.com/user-attachments/assets/6d91e1d7-99d5-47c4-a1bf-6604765d08d5" /> | <img width="979" height="453" alt="image" src="https://github.com/user-attachments/assets/602c9a8f-9e56-4633-84bf-0710cb5debab" /> | task-6103260 Forward-Port-Of: odoo/enterprise#113159
This update resolves an error that was preventing the generation of the Swiss Master Data report. The issue stemmed from a formatting error in the report template, which has now been corrected. This ensures accurate reporting for Swiss payroll data.
Original PR description
Currently, generating the Swiss Master Data report raises an error ### **Steps to reproduce:** 1) Install `l10n_ch_hr_payroll` with demo data. 2) Switch to a Swiss company. 3) Navigate to `Payroll >…
Currently, generating the Swiss Master Data report raises an error ### **Steps to reproduce:** 1) Install `l10n_ch_hr_payroll` with demo data. 2) Switch to a Swiss company. 3) Navigate to `Payroll > Reporting > Master Data`. 4) Create a new report and click Generate Data. ### **Error:** IndentationError: expected an indented block after 'else' statement on line 116 ### **Root Cause:** The QWeb template had a conditional block using `t-elif` followed by an empty `t-else` at [1]. During template compilation, this generated a Python `else` statement without a body, leading to an IndentationError. [1]- https://github.com/odoo/enterprise/blob/b77984b3a9fb1b35c07e152a0f86aaf4d430e2c0/l10n_ch_hr_payroll/report/l10n_ch_wage_type_report.xml#L44 ### **Fix:** This commit prevents the error by removing the empty `t-else` block and ensuring `category_ids` are properly evaluated by computing their codes and checking if they include `BASIC`, `ALW`, or `DED`. **opw-6107565** Forward-Port-Of: odoo/enterprise#113808
This update resolves an issue where the 'Reconcile' button on the bank statement dialog wouldn't work correctly on smaller screens (like mobile devices). The fix ensures the correct data is passed to the dialog component, preventing a validation error. This improves the user experience for mobile users.
Original PR description
When clicking on the "Reconcile" button of a bank statement line on a small screen (ex: mobile) threw an OwlError "Invalid props for component 'KanbanController': unknown key 'bankRecInfo'". BankRecSelectCreateDialog injected `bankRecInfo` into `baseViewProps`, which is spread into the embedded view regardless of its type. On desktop the embedded view is a list (patched to accept `bankRecInfo`), but on small screens SelectCreateDialog falls back to a kanban view, whose controller does not declare that prop, triggering Owl's props validation. Only forward `bankRecInfo` when the inner view is a list by overriding `viewProps` instead of mutating `baseViewProps`. Steps to reproduce: - Enable the developer mode. - Open Bank Reconciliation. - Resize the window to a small/mobile width (or open from a mobile device). - On a statement line, click the "Reconcile" button to open the dialog. - OwlError is thrown opw-6070573 Forward-Port-Of: odoo/enterprise#114298
This update fixes a potential issue where multiple sign actions within a single transaction could silently override role permissions. The change adds a check during the transaction to ensure no conflicting roles are being assigned, preventing incorrect automation setups. This improves data integrity and security within the Sign app.
Original PR description
Before this commit, creating multiple server actions for the Sign app in a single transaction (e.g., when saving an Automation Rule with multiple nested actions) bypassed the `_check_sign_template_conflicts` constraint. Because the constraint only queried the database for existing links, it failed to detect conflicts within the in-memory batch, allowing the save to succeed and causing silent role overrides. This commit introduces an intra-batch check to the constraint. By tracking requested roles in memory during the loop, the constraint now correctly raises a ValidationError if multiple actions in the same transaction attempt to automate the exact same template roles. A test has been added to ensure batch creations are properly validated. Task: 6128909 Forward-Port-Of: odoo/enterprise#115527 Forward-Port-Of: odoo/enterprise#115062
This update fixes an issue where payrun steps could remain in an 'error' state even after an error was resolved. Now, clicking 'Continue' marks a completed step as 'valid,' allowing users to move forward without being blocked by unresolved errors. This ensures payrun steps are consistently tracked and reported.
Original PR description
## Before: - Clicking Continue moved the payrun to the next step, but the previous step could remain in `error` if anomalies were still present. - This made explicitly passed steps (version/time/attendance) look unresolved. ## After: - Continue marks the passed step as `valid`. - because if the user willfully ignore an error, then it's ok to put it as validated. - This is applied consistently for all payrun step state points. Task-6053982 Forward-Port-Of: odoo/enterprise#115279
This update fixes a visual issue where flexible employees (without resource calendars) had blank cells on the Gantt chart. It now correctly displays these employees' time off as greyed-out intervals and accurately calculates progress bar durations based on validated leave hours, rather than defaulting to full periods.
Original PR description
Flexible employees (no resource calendar) had no unavailability intervals computed, leaving all cells white in the Pay Run Time Off gantt. Their progress bar also showed the full period duration (e.g. 744h for a 31-day month) because _get_work_days_data_batch returns 24h/day for calendar-less resources. - Mark the entire gantt interval as unavailable for contract versions with no resource_calendar_id so cells appear grey by default - For flexible employees, compute the progress bar value from their actual validated leave hours instead of scheduled working hours (defaulting to 0h) task-6194344
This update prevents unauthorized users from viewing or modifying assets linked to invoices. Previously, users without the correct access groups could trigger errors, creating a potential security vulnerability. Now, access to assets is restricted to users within specific accounting groups, ensuring data integrity and security.
Original PR description
Only groups `account.group_account_readonly`, `account.group_account_invoice` or higher have access to model `account.asset`, therefore if an user goes to see an invoice with assets and they are not on either group, they will receive an error and won't be able to access said invoice. How to reproduce: - Create a vendor bill - Create an account.asset and link it to said account.move - Go to the form view with an user that it's on group "Purchase: User" for example --> They get a traceback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#116133 Forward-Port-Of: odoo/enterprise#112890
This update fixes a visual issue in the maintenance request form where the 'Block Workcenter' field was incorrectly positioned next to the priority field. The change updates the form's layout to align with recent UI updates, ensuring a cleaner and more intuitive user experience for maintenance request creation.
Original PR description
Issue: ---------------------------- In the maintenance request form view, the 'Block Workcenter' field was displayed near the priority field in the top-right corner. Steps to Reproduce:…
Issue: ---------------------------- In the maintenance request form view, the 'Block Workcenter' field was displayed near the priority field in the top-right corner. Steps to Reproduce: ---------------------------- - Install `mrp_maintenance` module. - Open a maintenance request linked to a work center. - Notice that the 'Block Workcenter' field appears beside the priority field in the top-right section. Cause of the issue: ---------------------------- Following the UI changes introduced in [PR](https://github.com/odoo/odoo/pull/251761), the position of the priority field was updated. However, the inherited XPath used for the 'Block Workcenter' field was still targeting the priority field, causing the field to be inserted at an incorrect position. With this commit: ---------------------------- Update the XPath to match the new form view structure, ensuring that the 'Block Workcenter' field is displayed in the correct location and aligned with the updated UI layout. Forward-Port-Of: odoo/enterprise#116193
This update clarifies the error message displayed during order cancellations. The outdated 'Callback requested instead' message has been replaced with a more helpful 'Contact your provider for support.' This change improves the customer experience and provides clearer guidance during potential issues.
Original PR description
In this commit: ---------------- - Added an extra message, `Contact your provider for support.` and removed `Callback requested instead.` string from the order cancellation error message. Task-4657597
This update resolves issues with inconsistent tour behavior by refining the triggers used to initiate tours. The changes make tours more reliable and predictable, leading to a smoother user experience. This primarily affects the stability of various Odoo modules during tour execution.
Original PR description
Fix undeterministic tours by making some triggers more precise in a few steps.
This update fixes an issue where helpdesk notification emails incorrectly linked to the company's default website instead of the customer's original website. The change ensures that 'View Ticket' buttons now always direct users to the website where their support request was initially created, improving the user experience and routing accuracy.
Original PR description
On a multi-website / single-company setup, helpdesk notification emails posted after the initial confirmation contained a "View Ticket" button pointing to the wrong website, always the company's…
On a multi-website / single-company setup, helpdesk notification emails posted after the initial confirmation contained a "View Ticket" button pointing to the wrong website, always the company's default website instead of the website the ticket was created from. Steps to reproduce: =================== 1. Create two websites W1 (seq 1) and W2 (seq 2) under the same company, with distinct domains. 2. Create two helpdesk teams with "Submit a Ticket" enabled, each bound to one website (Helpdesk1 -> W1, Helpdesk2 -> W2). 3. From W2, submit a ticket on /helpdesk/helpdesk2. 4. In the ticket, send email from the chatter. 5. Inspect the outgoing notification email. => "View Ticket" button points to W1's domain. Root cause: ============ `helpdesk.ticket` has no `website_id`, so `Base.get_base_url` falls through to `company_id.website_id.domain`, i.e. the first website of the company by sequence. The first confirmation message looked right only because it was posted inside a website request, where `website.get_current_website()` provided the correct context; subsequent agent replies are posted from the ticket with no such context, so the fallback kicked in. Override `get_base_url` on `helpdesk.ticket` to prefer `team_id.website_id.domain` when set, so every notification on the ticket links back to the website the customer submitted it from. => "View Ticket" button points to W2's domain (the site the customer is browsing). opw-6071999 Forward-Port-Of: odoo/enterprise#116034 Forward-Port-Of: odoo/enterprise#114693
This update resolves two issues preventing order validation and report downloads for the l10n_co_edi_pos module. The fix addresses a problem where data was incorrectly formatted during export, causing errors. This ensures reliable POS data generation and reporting for DIAN compliance.
Original PR description
Steps to reproduce: --- - Install `l10n_co_edi_pos` and configure it. - Set the POS Serial Number in the POS configuration. - Open a POS session, create an order, and validate it. Issues: --- 1. A traceback occurs while validating the order. 2. After fixing the above issue, another traceback occurs when downloading the Sales Details report from the backend. Causes: --- 1. During UBL DIAN data generation, the `name` field is overwritten with `pos_order.l10n_co_edi_pos_name`, which can be empty. 2. `l10n_co_edi_pos_serial_number` is accessed on an invalid type (ID/list instead of a recordset). Fixes: --- - Preserve the original `name` if `l10n_co_edi_pos_name` is not set. - Ensure `config_ids` is always a recordset and safely compute serial numbers using `mapped`, joining unique values. task-6051285 Forward-Port-Of: odoo/enterprise#111306
This update resolves a bug that prevented users from modifying warehouse routes in the Romanian (RO) SAFT stock module. The issue stemmed from incorrect data handling during route updates, causing a system error. This fix ensures that warehouse routes can now be safely adjusted without disruption.
Original PR description
### Issue: When changing the routes of a Romanian warehouse, an error is raised, blocking any modification of multi-step routes ### Cause: The code attempts to access `in_type_id` from `warehouse_data` However, when updating routes, `warehouse_data` is empty in the method `_create_or_update_sequences_and_picking_types` This leads to a crash because the code assumes that `warehouse_data` always contains `in_type_id` and `out_type_id` Additionally, even if the data were present, it would result in creating duplicate `stock.picking.type` records ### Steps to reproduce: - Install `l10n_ro_saft_stock` with demo data and switch to `RO Company` - Enable `Multi-steps Routes` in Settings - Try to modify Incoming or Outgoing Shipments on a warehouse - When saving, the following error is raised: "Oh snap! in_type_id" odoo-pr: https://github.com/odoo/odoo/pull/257293 opw-5925087 Forward-Port-Of: odoo/enterprise#114166
This update automatically refreshes the payment screen when the PIS (Payment Initiation System) status changes. Previously, users had to manually refresh the page to see the updated status, which is now resolved for a smoother payment process. This improves the user experience and ensures accurate payment information.
Original PR description
There were some buttons like sign payment that were visible even when the PIS status was signed which needed a manual page refresh for the update to reflect, now it's reflected automatically on the PIS status change. task-5417365 Forward-Port-Of: odoo/enterprise#116427 Forward-Port-Of: odoo/enterprise#114299
This update resolves a build error in the l10n_ae_faf module related to how tax views were configured. The fix adjusts a key reference to ensure the module functions correctly without requiring an additional, automatically installed module. This improves the stability and reliability of the AE tax settings.
Original PR description
the inherited tax view form was raising an error since ubl_cii_tax_category_code is in the view under the module account_edi_ubl_cii and this module is not in the resolved dependencies of l10n_ae_faf but is usually autoinstalled. to fix this we are changing the xpath to be something that doesn't need the dependency of the account_edi_ubl_cii but only account. runbot-239123 Forward-Port-Of: odoo/enterprise#116163
This fix resolves an issue where rental dates were incorrectly included in price calculations for non-rental products within rental orders. The update ensures that only the standard date is used when determining prices, improving accuracy and preventing pricing errors. This change focuses on a technical detail to ensure correct rental pricing.
Original PR description
When computing the price of a non-rental product in a rental order, the rental dates are added to the price computation kwargs. However, the rental dates and the date kwargs are incompatible when…
When computing the price of a non-rental product in a rental order, the rental dates are added to the price computation kwargs.
However, the rental dates and the date kwargs are incompatible when fetching applicable rules for a product.
One restricts rules to a range, whereas the other restricts rules to a specific date.
For non-rental products, the rental dates should not be forwarded; only the date argument should be.
```python
Traceback (most recent call last):
File "/Users/lipiraux/dev/odoo/master/odoo/odoo/http/router.py", line 432, in serve_db
return retrying(serve_func, env=request.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
File "/Users/lipiraux/dev/odoo/master/odoo/addons/sale/controllers/product_configurator.py", line 72, in sale_product_configurator_get_values
**self._get_product_information(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
File "/Users/lipiraux/dev/odoo/master/enterprise/sale_renting/models/product_pricelist.py", line 40, in _compute_price_rule
results = super()._compute_price_rule(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/lipiraux/dev/odoo/master/odoo/addons/product/models/product_pricelist.py", line 201, in _compute_price_rule
rules = self._get_applicable_rules(products, quantity, date=date, uom=uom, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/lipiraux/dev/odoo/master/odoo/addons/product/models/product_pricelist.py", line 273, in _get_applicable_rules
self._get_applicable_rules_domain(
File "/Users/lipiraux/dev/odoo/master/enterprise/sale_renting/models/product_pricelist.py", line 242, in _get_applicable_rules_domain
assert not kwargs.get("date"), "Incompatible arguments"
^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Incompatible arguments
```
task-6020137This update resolves an issue where the custom declaration field wasn't automatically filled for international shipments using the World Express Pro service within the BPost module. Now, the necessary customs information is correctly populated, ensuring accurate shipping documentation and compliance with international regulations. This improves the reliability and efficiency of international order processing.
Original PR description
Before this commit, the bpost module was not filling the custom declaration in case of international shipping (World Express Pro) After this commit, the section is filled opw-4932970 Forward-Port-Of: odoo/enterprise#115368 Forward-Port-Of: odoo/enterprise#101476
This update fixes an issue where route planning for resources always started from the user's location. Now, routes begin from the resource's actual location when a location is available, ensuring more accurate and relevant route visualizations. This improves the planning process for field teams.
Original PR description
Currently, the routings per resource are always starting from the current user's location. With this commit: - If the view is not grouped by resource, no routing is shown - If the view is grouped by resource and the user is not located, no routing is shown for that resource - Else, the routing start from the located resource's geolocation task-6176479 Forward-Port-Of: odoo/enterprise#115674
This update addresses an issue where error messages from the Aspone API were not displayed correctly, leading to tracebacks. The change now ensures that error messages are presented to the user, improving the reporting experience for French language reports. This resolves a technical problem that could have impacted report accuracy.
Original PR description
Since the v2 rest api of aspone was implemented, error messages were no more well handled and a traceback was raised while getting one. This commit displays the write errr to the user task-5955980 Forward-Port-Of: odoo/enterprise#116381 Forward-Port-Of: odoo/enterprise#116076
This update addresses intermittent errors in the customer ratings tests within the Odoo Enterprise system. The fix ensures the tests are consistently reliable, preventing potential disruptions to customer feedback processes. This improves the stability and accuracy of customer ratings data.
Original PR description
This commit aims to fix the undeterministic failures of the customer ratings tests. Forward-Port-Of: odoo/enterprise#116053
This update resolves an issue where the Payment Reminder email template would fail to render if the Payment module wasn't installed alongside the account_followup module. The fix ensures the necessary 'payment.method' model exists before attempting to use it, preventing template rendering errors.
Original PR description
Repro steps: 1. Initialize a new DB 2. Install account_followup module without payment module 3. Go to Email templates > Payment reminder 4. Click on Preview You will get an error Failed to render QWeb template for Mail Template: 'Payment Reminder' (ID: 9) Target Model: res.partner Language context: en_US Error: Error while render the template KeyError: 'payment.method' Root cause: The method `_show_pay_now_button` that was being called in the template email_template_followup_1 was using self.env['payment.method'] even tho payment module is not a dependency of account_followup Fix: The introduced fix ensures that 'payment.method' model exists before attempting to use it build_error-243030 Forward-Port-Of: odoo/enterprise#116692 Forward-Port-Of: odoo/enterprise#116079
This update fixes an issue where long text fields in sign documents were not wrapping correctly, resulting in text overflowing and being unreadable in the final PDF output. The fix ensures that text, even with long words or without spaces, is properly wrapped within the designated field, improving the clarity and usability of sign documents. This resolves a previous display problem.
Original PR description
### Steps to reproduce: - Download 'Sign' and 'Contacts' apps - Create a contact with a really long name - Create a sign document template with a multiline text field (Read-only) that has contact…
### Steps to reproduce: - Download 'Sign' and 'Contacts' apps - Create a contact with a really long name - Create a sign document template with a multiline text field (Read-only) that has contact name value - Click 'Sign Now' and put the new contact as the signer - Sign and download > The text appears as a single extended line exceeding field/page boundaries ### Cause of Issue: The textarea and stamp field rendering only handled explicit newline characters (`\n`) and did not account for text that exceeded the field width. https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/sign/models/sign_document.py#L330-L345 When the HTML preview showed wrapped text, the PDF output rendered it as a single line. For continuous text without spaces, the text would overflow the field boundaries entirely. ### Fix: Accounted for long texts that have spaces and long words to show all the information in the PDF opw-6045062 Forward-Port-Of: odoo/enterprise#116658 Forward-Port-Of: odoo/enterprise#114813
This update resolves an issue where duplicate serial numbers appeared in the picking view after scanning a new barcode. The fix ensures the system waits for a necessary process to complete, correctly displaying only the intended serial number. This improves data accuracy and prevents confusion for users.
Original PR description
Problem: When entering the barcode interface from a picking and scanning a different serial number than one already reserved, a new line gets created in certain situations. When exiting the barcode…
Problem: When entering the barcode interface from a picking and scanning a different serial number than one already reserved, a new line gets created in certain situations. When exiting the barcode interface without validating the picking, both serial numbers show up on the picking view. However, the first serial number’s `stock.move.line` was deleted, so only one serial number should be there. When exiting the barcode interface a call to `post_barcode_process` is made, where the extra `stock.move.line` is deleted, but it doesn’t wait for the call to finish. https://github.com/odoo/enterprise/blob/d5a52cb79c9c41d792685d2858cfeb6aee147642/stock_barcode/static/src/models/barcode_picking_model.js#L1896 Purpose: By overriding `beforeQuit` to add the `_onExit` call, the component now waits for the `post_barcode_process` call to finish before navigating back to the picking view. This helps ensure the UI displays the updated data. Steps to reproduce on Runbot: Create a product tracked by serial numbers. Have 2 units on hand: serial 001 with a package, and serial 002 without a package. (This is needed so the barcode app will create a new line). Create a delivery for 1 unit of our test product and mark it as todo. Ensure that serial 001 is reserved. Click the Barcode smart button and scan the barcode for serial 002. Click the back button. Observe that both serial numbers are shown on the picking. Refresh the page and observe only serial 002 is now shown. opw-6105740 Forward-Port-Of: odoo/enterprise#116686 Forward-Port-Of: odoo/enterprise#115491
The budget report now accurately displays data without duplicate analytic lines. This change addresses an issue caused by a recent performance optimization of the budget report query, which inadvertently introduced duplicate entries. The fix ensures correct reporting by using a revised query structure.
Original PR description
#### Issue: The budget report displays duplicate analytic lines. #### Steps to reproduce: In a new company: - Create a budget with one budget line (Analytic Account A). - Create one analytic item…
#### Issue: The budget report displays duplicate analytic lines. #### Steps to reproduce: In a new company: - Create a budget with one budget line (Analytic Account A). - Create one analytic item (linked to Analytic Account A). - Open the budget report and remove the default "open budget" filter. Duplicate amounts appear in the pivot view and duplicate lines appear in the list view. #### Cause: In #104299, the query in `_get_aal_query` was refactored for performance to avoid a single query with an OR condition in the LEFT JOIN. It was replaced by two separate queries combined with `UNION ALL`. This caused some lines to be captured by both queries, resulting in duplicates in the final report. #### Fix: Use three separate queries, each with specific filter conditions to guarantee unique results: Q1 - Analytic lines with no matching budget line. Q2 - Analytic lines matched to a budget line with no company (null-company). Q3 - Analytic lines matched to a company-specific budget line. OPW-6051696 Forward-Port-Of: odoo/enterprise#116612
This update resolves an issue preventing users from correctly booking appointments with multiple participants when flexible scheduling is enabled. The fix corrects a problem where the system incorrectly interpreted a setting, causing a booking error. This ensures appointments can be scheduled accurately with capacity management.
Original PR description
### Steps to reproduce: - Download "Appointment" and "Website" - Configure an appointment to be booked by resource with multiple seats and manage capacity - Set the schedule to be flexible and configure valid time slots - Go to the booking page and select the number of participants > Traceback: cannot unpack non-iterable bool object ### Cause of Issue: The `_get_appointment_slots` method unpacks the `appointment_slots_force_month` directly: https://github.com/odoo/enterprise/blob/4ca3dddaeadeb6c937d555cc4da8fb4bb61fea35/appointment/models/appointment_type.py#L871 Since the `appointment_slots_force_month` value was explicitly set to `False` in https://github.com/odoo/enterprise/blob/4ca3dddaeadeb6c937d555cc4da8fb4bb61fea35/appointment/controllers/appointment.py#L1063-L1070 the unpacking operation failed because it tried to unpack a boolean instead of a tuple. opw-6197653 Forward-Port-Of: odoo/enterprise#116671 Forward-Port-Of: odoo/enterprise#116613