Daily updates from Odoo
Thursday, November 27, 2025
162 changes
10 changes
Resolved issues and error corrections
This update resolves a technical issue that previously caused crashes when creating binary files within the Web Studio module. The fix prevents a problem with parallel field creation, ensuring stable operation of this key feature. This improves the reliability of the Web Studio interface for users.
Original PR description
Before this commit and subsequently to commit odoo/enterprise@75db3379655dc889b31ad34c66332f5a21f8cff4 creating a related binary field crashed because of the parallel creation of the filename related field. After this commit, this is fixed. opw-5237866
This update fixes a translation error in the Netherlands (l10n_nl) module, specifically regarding the description of the 9% ST tax. The incorrect translation 'TVA' was corrected to the accurate 'ST tax' description, ensuring proper reporting and compliance with Dutch tax regulations. This ensures accurate financial reporting for Dutch customers.
Original PR description
The traduction of te description of the 9% ST tax was wrong and was TVA to get back on a sale tax task-5217323 Forward-Port-Of: odoo/odoo#237467 Forward-Port-Of: odoo/odoo#236655
This update fixes a bug where the 'Late,' 'Today,' and 'Future' filters in the Activity Menu didn't correctly display Approval requests. The fix adds necessary filters to the Approvals search view, ensuring these filters now function consistently and align with other Odoo modules.
Original PR description
Issue: - In the Activity Menu, clicking "Late", "Today", or "Future" did not filter Approval requests and always returned all records. - The Approvals search view lacked the activity filters that these context defaults rely on. Fix: - Added the invisible activity filters (overdue, today, upcoming_all) to the Approvals search view. - Filters use `my_activity_date_deadline` to match Odoo's standard deadline-based activity filtering. Impact: - Activity Menu filtering now works correctly for Approvals and aligns with behavior in other modules. Task: 5261406 Forward-Port-Of: odoo/enterprise#100514 Forward-Port-Of: odoo/enterprise#99632
This update resolves a visual issue where the course search dropdown was incorrectly positioned above the search input on the homepage. The fix ensures the dropdown appears correctly within the search form layout, improving the user experience.
Original PR description
Scenario: go to homepage > Courses > one "View all" > type in search Result: dropdown with result is shown over the search input Issue: search form is in flex layout, but the dropdown is displayed in absolute so it is outside of flex flow and is positionned at the top-right of the form container. History: - before bootstrap 4 (odoo 15): the search form had a flex layout, but bootstrap dropdown used "top:100%" so were positionned at the bottom of it. - as of bootstrap 5 (odoo 16): the form kept a flex layout, but bootstrap dropdown now used "position: absolute" with unset top putting them below the search item in a block container, but over it in a flex layout. Fix: when the search bar is displayed, display it as block. opw-4735257 Forward-Port-Of: odoo/odoo#206909
This update adjusts the spacing between message text and reactions in notifications, resolving a previous issue where the UI appeared cramped. By removing a negative margin, the notification design is now cleaner and more visually comfortable for users. This improves the overall user experience.
Original PR description
Before this commit, the spacing between the text content of a message of type notification and the reactions was too small and resulted in the UI feeling cramped. This commit fixes the issue by removing the negative top margin in message reactions for messages that don't have enough padding. | Before | After | | ------------- | ------------- | | <img width="207" height="223" alt="Pasted image 20251124144956" src="https://github.com/user-attachments/assets/f23c070c-6253-440a-8b93-7b546daabda3" /> | <img width="202" height="236" alt="image" src="https://github.com/user-attachments/assets/e366a2ba-f851-4676-b108-bebf2fb12ec8" /> | task-5344759 Forward-Port-Of: odoo/odoo#237120
This update fixes an issue where search results on the website were not displaying correctly when the number of results exceeded the page limit. The system now automatically redirects users to the last page of results, ensuring all relevant information is shown. This improves the user experience and prevents missed data.
Original PR description
Scenario: - enable website_studio - go to contact -> open studio -> website - add a listing and open it on website - go to page 2 and search a specific terms with less than 20 results Result: we see "5 results" in the search bar, but no result are shown and the pager is hidden. Cause: the pager is hidden since there is only one page, and we are currently displaying the records of page 2 that do not exist. Fix: if we detect that we are on a page over the last page, redirect to the last page. Eg. if there is 2 pages and we are in page 500, redirect to page 2. opw-5008556 Forward-Port-Of: odoo/odoo#236600 Forward-Port-Of: odoo/odoo#223447
This update fixes an issue where Shift + Click within a table cell didn't correctly select text, resulting in an incorrect selection range. The fix ensures Shift + Click behaves like a standard browser, providing a consistent and expected text selection experience. Additionally, the issue of selection flickering during table resizing has been resolved.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Create a table - Write a sentence in one of the cell - Put your caret somewhere in your sentence (e.g. "He[]llo wold") - Shift + click in the same sentence (e.g. "Hello wor[]ld") The expect result should be "He[llo wor]ld", but it's "[Hello wor]ld". This issue happens because in `onMousedown` method of table_plugin, cursor is set to the starting of `anchorNode`, which leads to wrong selection on shift + click. **Desired behaviour after PR:** This PR ensures that Shift + Click sets the selection in the same way as the default browser behavior. task-5152807 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237168 Forward-Port-Of: odoo/odoo#230716
This update corrects a technical issue that prevented users from sending E-Factura (SPV) invoices in the Romanian localization (l10n_ro_edi) module. The problem stemmed from a mismatch in how bank information was accessed, leading to an error. This fix ensures smooth E-Factura processing for Romanian invoices.
Original PR description
Same issue already fixed for 18.4+ here: https://github.com/odoo/odoo/pull/231399 Issue: When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an…
Same issue already fixed for 18.4+ here: https://github.com/odoo/odoo/pull/231399 Issue: When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for res.bank. Repro Steps: 1- Create invoice for romanian localization. 2- Link payment account to invoice. 3- Add bank to payment account. 4- Confirm and send invoice with "Send E-Factura SPV" checked. Cause: The state field is defined differently for res.bank and res.partner. res.partner uses state_id, while res.bank uses state. The code that retrieves addresses assumes the same field for both, leading to an exception when accessing state for res.bank. Fix: The fix checks the type of the input and selects the appropriate field (state or state_id) accordingly. opw-5362000 (cherry picked from commit a2af8d434bfc7f77008959c8179e8f158bcf9e93) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237615
This update adds a warning message to bank statement lines when an analytic distribution is required. Previously, users weren't alerted to this requirement, potentially leading to errors. Now, users will receive a clear warning, guiding them to set up the necessary analytic distribution plan.
Original PR description
When setting the account on a bank statement line, analytic distribution might be required due to a mandatory plan. Before this commit, the user had no idea if the analytic is required or not. After this commit, lines that required analytic distribution will have a warning directing the user to set it. task-5055351 This is a backport of: https://github.com/odoo/odoo/commit/c337d97a3e06db37a316c4020261a797df4c6a1d Enterprise PR: https://github.com/odoo/enterprise/pull/100494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237368
This update adds a warning to bank statement lines when an analytic distribution is required. Previously, users weren't alerted to this requirement, potentially leading to incorrect accounting. Now, users will receive a clear warning, guiding them to set up the necessary analytic distribution plan.
Original PR description
When setting the account on a bank statement line, analytic distribution might be required due to a mandatory plan. Before this commit, the user had no idea if the analytic is required or not. After this commit, lines that required analytic distribution will have a warning directing the user to set it. task-5055351 This is a backport of: https://github.com/odoo/enterprise/commit/00396d24114b8747ff73ae60f032b630ce88c7a4 Community PR: https://github.com/odoo/odoo/pull/237368 Forward-Port-Of: odoo/enterprise#100494
2 changes
Resolved issues and error corrections
This update adds a warning message to bank statement lines when an analytic distribution is required. Previously, users weren't alerted if this was necessary, leading to potential errors. Now, users will receive a clear notification to set the correct analytic distribution, ensuring accurate financial reporting.
Original PR description
When setting the account on a bank statement line, analytic distribution might be required due to a mandatory plan. Before this commit, the user had no idea if the analytic is required or not. After this commit, lines that required analytic distribution will have a warning directing the user to set it. task-5055351 This is a backport of: https://github.com/odoo/odoo/commit/c337d97a3e06db37a316c4020261a797df4c6a1d Enterprise PR: https://github.com/odoo/enterprise/pull/100494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds a warning message to bank statement lines when an analytic distribution is required. Previously, users weren't alerted if this was necessary, leading to potential errors. Now, users will receive a clear warning, guiding them to set up the correct analytic distribution plan.
Original PR description
When setting the account on a bank statement line, analytic distribution might be required due to a mandatory plan. Before this commit, the user had no idea if the analytic is required or not. After this commit, lines that required analytic distribution will have a warning directing the user to set it. task-5055351 This is a backport of: https://github.com/odoo/enterprise/commit/00396d24114b8747ff73ae60f032b630ce88c7a4 Community PR: https://github.com/odoo/odoo/pull/237368
9 changes
Resolved issues and error corrections
This update resolves an issue where users wouldn't see signed documents after a request was completed. The fix ensures that both the requester and signer automatically receive 'view' access rights to the signed document, preventing access restrictions and improving document visibility.
Original PR description
To reproduce: ============= - as a User U with Admin rights on Documents (not Sys Admin) - create a folder at the root of the company - create a Sign Request template using this folder as signed document folder - send the Sign Request to another user O and sign it with that user O - go to Documents app with user U and check the folder where the signed document should be - the signed document is not there Problem: ======== when creating signed documents, the access rights for the requester are not set, causing the requester to not see the signed document Solution: ========= give `view` access right on signed documents to both the requester and the signer if they don't already have `edit` access right on it or ownership opw-[5087233](https://www.odoo.com/web#id=5087233&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#97132
This update resolves a previous issue where installing the UK Construction Industry Scheme (l10n_uk_reports_cis) would trigger an error due to duplicate account codes. The fix ensures the scheme correctly handles companies with branches, allowing for successful installation and reporting.
Original PR description
Before this commit: Steps 1) Create a UK localization company 2) Create a branch for that company 3) Try to install UK - Construction Industry Scheme (l10n_uk_reports_cis) => A Validation Error is raised with the message `Account codes must be unique. You can't create accounts with these duplicate codes: 220001, 220101, 220201`, This occurs because the `_l10n_uk_reports_cis_post_init()` method is creating accounts for each UK company even if they aren't root companies (branch). After this commit: UK - Construction Industry Scheme (l10n_uk_reports_cis) is installed successfully with UK companies that have branches. opw-5326079 Forward-Port-Of: odoo/enterprise#99901
This update resolves a technical issue that was causing a traceback when accessing the Documents app on mobile devices. The problem stemmed from an adaptation oversight during the forward port of a recent update. This fix ensures a stable and functional experience for users accessing the Documents app.
Original PR description
Steps to reproduce =================== 1. Toggle mobile view. 2. Open documents app. List prop is replaced by groupByField here https://github.com/odoo/odoo/pull/189109/commits/b5e821f0383caf6126a0d3c915cb4bccc8345b2b in 18.2. Here https://github.com/odoo/enterprise/pull/90647, we missed adapting the code in the forward port. Task-5363758
This update ensures that Point of Sale orders in Mexico correctly utilize the customer's CFDI usage setting, rather than defaulting to 'G03'. This fix addresses a previous issue where the CFDI usage wasn't being applied, ensuring compliance with Mexican tax regulations for PoS transactions.
Original PR description
When making an order in the PoS in Mexico, if the customer has a CFDI usage set on their partner, it should be used for the order instead of the default one. Steps to reproduce: ------------------- * Install l10n_mx_edi_pos * Create a partner with a CFDI usage different than 'G03' * Open the PoS, select the partner and make an order * Validate the order and check the order in the backend > Observation: The CFDI usage is 'G03' instead of the one set on the partner. opw-5018288
This update fixes an issue where documents and moves were incorrectly linked across companies in a multi-company setup. By explicitly including the company ID during attachment creation and searching, the system now accurately assigns documents to the correct company, preventing errors and ensuring data integrity. This improves the reliability of our multi-company accounting processes.
Original PR description
Behavior before: In a multi-company setup, fetching documents could include records from different companies based on VAT numbers. When creating attachments or searching for existing moves, the company ID was not properly considered, leading to incorrect company assignments and failed move creation. Behavior after: Documents and moves are now created and searched within the correct company context by explicitly including the company ID. Root Cause: The company ID was missing in both the attachment creation and the domain used to search for existing moves, causing cross-company mismatches. opw-4929985 Forward-Port-Of: odoo/enterprise#99192
Previously, the document control panel only processed the first 40 files selected, regardless of the total number uploaded. This update ensures that all selected documents are considered for actions like duplication or deletion, improving usability and data management. The fix addresses a limitation in how record selection was handled.
Original PR description
Steps to Reproduce =================== 1. Upload more than 40+ files in a folder. (One page displays upto 40 docs) 2. Use the checkbox to select all files on the page (this selects only 40 files) 3.…
Steps to Reproduce =================== 1. Upload more than 40+ files in a folder. (One page displays upto 40 docs) 2. Use the checkbox to select all files on the page (this selects only 40 files) 3. Click the 'Select All' button in the control panel to select all 40+ files. 4. Now, try duplicating or moving them to the trash. => Only the first 40 selected files (on the single page) are considered for action, not all the selected files. Technical ========== For documents control panel action we have custom handling for selecting records and executing action. We use `model.root.selection` which only consider records in current page, case of select all records from other pages is missed here. After this PR ================== - All selected records are considered for the actions - Added custom `getResIds` method to get filtered `resIds` as per domain. Note: `getResIds` in DynamicList doesn't have custom domain feature so create our own as per use case Task-4700841 Forward-Port-Of: odoo/enterprise#87634
This update corrects a labeling issue within Odoo's document access rights settings. Previously, labels were unclear, now they clearly indicate the associated user groups providing access. This ensures better clarity and easier management of document permissions.
Original PR description
This commit fix the label of documents access rights which now shows a helper for each documents res.groups. Task-5186096 Forward-Port-Of: odoo/enterprise#98890
This update corrects a calculation error in rental order quantity tracking, specifically when returns are processed within linked pickings. The previous issue resulted in incorrect inventory counts for rental products. This fix ensures accurate tracking of product quantities during rental transactions.
Original PR description
Steps to reproduce: - Enable multi-step & Rental transfers - Set warehouse to 2 steps reception/delivery - Create a rental order for a product with a qty of 5 - Process the PICK - Change the quantity in the rental order to 3 and save - Change the quantity back to 5 and save again Issue: The Rental IN picking has now a `product_uom_qty` of 1. This is due to a wrong computation of incoming/outgoing moves when there are returns (e.g. here a return PICK) in the linked pickings. opw-5028794 Forward-Port-Of: odoo/enterprise#98473
This update fixes an issue where the customer portal wasn't correctly displaying daily subscription billing periods. The system now dynamically fetches billing periods from the subscription plan, ensuring accurate display and compatibility with custom subscription types. This improves the user experience and portal stability.
Original PR description
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the…
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the billing_period_unit selection field via inheritance. However, this customization causes an error (a KeyError) when accessing the customer portal at /my/subscriptions/<int:order_id>. This is because the controller logic relies on a hardcoded list of periods and does not account for the new custom "day" value. - Screenshot Order with plan Daily: <img width="1246" height="483" alt="image" src="https://github.com/user-attachments/assets/5dc5ca0d-a2f2-434d-8183-15a0424d9f34" /> - Screenshot when trying to get in order on the website: <img width="1250" height="776" alt="image" src="https://github.com/user-attachments/assets/5b10504e-71e2-4c13-8611-39e8a41e05d1" /> Proposed Solution -------- This PR improves the subscription portal by dynamically retrieving billing periods instead of using a hardcoded list. The portal now reads the available options directly from the billing_period_unit field's selection (i.e., self.env['sale.subscription.plan']._fields['billing_period_unit'].selection). This improves maintainability, as future changes to the field's selection will be automatically reflected without requiring code modifications. This makes the portal robust and automatically compatible with any custom periods added via inheritance. - <img width="1331" height="752" alt="image" src="https://github.com/user-attachments/assets/4f7be6c3-d96b-4525-8e23-6e1323adabde" /> Forward-Port-Of: odoo/enterprise#99207
3 changes
Resolved issues and error corrections
This pull request resolves a technical issue (runbot error 234028) within the Web Studio module. The fix improves the stability and reliability of Web Studio's automated testing processes, preventing potential disruptions to users' ability to customize their Odoo applications. This ensures a smoother experience for Odoo Enterprise users.
Original PR description
runbot-error-234028
This update fixes an issue where the EC Sales List menu was incorrectly placed within the application views. The menu has now been moved to the data folder, ensuring it appears correctly within the Odoo interface. This improves the user experience for reports related to sales in Ecuador.
Original PR description
The menu record was wrongly stored under views. It is now moved to the data folder.
This update adjusts the appearance of checkboxes in the Enterprise version of Odoo. Previously, checkboxes had sharp corners. This change now utilizes Bootstrap's default border radius, creating a more modern and visually appealing design. This is a minor improvement to the user interface.
Original PR description
Before this commit, checkboxes had square corners with a border radius of 0. This commit removes the override and uses Bootstrap's default border radius value. requires: https://github.com/odoo/odoo/pull/231860 task-5136827
19 changes
Resolved issues and error corrections
This update fixes a bug where time logs were incorrectly assigned to the user marking work orders as done, instead of the assigned employee. Now, time logs accurately reflect the employee who actually worked on the order, improving data accuracy and reducing user confusion. This ensures proper tracking of labor costs.
Original PR description
## **Issue Before This Commit:** When a work order is assigned to an employee (not linked to the current user), and the current user marks it as done, the time log is wrongly created under the…
## **Issue Before This Commit:** When a work order is assigned to an employee (not linked to the current user), and the current user marks it as done, the time log is wrongly created under the current user’s employee instead of the assigned one. This behavior caused confusion for the user as the wrong person was shown as working on the order. ## **Steps to Reproduce:** - Create an MO with work orders and confirm it. - Assign another employee to a work order. - Mark the work order as done with the current user from the work order line. - Open the workorder and notice that the time log is created for the current user’s employee. ## **Cause of the Issue:** The bug was introduced in PR (https://github.com/odoo/enterprise/pull/84790), where the logic for assigning the main employee was overridden, ignoring the case of an already assigned employee. ## **With This Commit:** The time log is now created for the assigned employee, This resolves the confusion by ensuring the right person is tracked on the work order. TaskID: 4983514 Forward-Port-Of: odoo/enterprise#100467 Forward-Port-Of: odoo/enterprise#93378
This update corrects an issue where the Odoo system was sending incorrect data in electronic invoices to the Hungarian tax authority (NAV). The system now adheres to specific documentation requirements, omitting the state name and only sending the required province code as defined by the ISO standard. This ensures compliance and accurate invoice submissions.
Original PR description
Purpose: According to documentation, in region tag in address details, we need to send that county's province code as per the ISO 3166-2 alpha 2 standard. E.g. 'HU-BU'. But we were sending state's name E.g. 'Budapest'. But since region tag is not mandatory for edi, we choose not to send that. Before this commit: In region tag, state's name was sent. After this commit: We stopped sending region tag. EDI Documentation(page-87): https://onlineszamla.nav.gov.hu/files/container/download/2025.10.09.%20EN_Online%20Invoice%20System%203.0%20Interface%20Specification%20.pdf task-5270199 Forward-Port-Of: odoo/odoo#236218
This update adds a notification to inform users when they are utilizing the Chorus Pro feature but haven't installed the necessary module. This ensures they receive all the required checks and functionality, preventing potential errors or omissions in their accounting processes. It's a proactive measure to maintain data integrity and user experience.
Original PR description
This commit will add an alert when the customer use Chorus pro but don't have the module installed, and so don't have all the additional checks <img width="982" height="242" alt="image" src="https://github.com/user-attachments/assets/fc35d4ee-9a8b-41b8-8ee3-cbc32b266379" /> task-5223874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237201 Forward-Port-Of: odoo/odoo#236856
This update enhances the portal experience for subcontractors by granting them the necessary permissions to create and manage serial numbers, view related stock movements, and register components for multiple manufacturing orders. The changes include security enhancements and database optimizations to ensure seamless operation for this user group. This improves efficiency and accuracy in subcontracting workflows.
Original PR description
Make sure that portal subcontractors can do what they need to: - create new serial numbers and assign them to SMLs -> new ACL for sequences (READ and WRITE) -> new ACL for mrp.production.serials to open the wizard - see SML serials in the Detailed Operations popup -> add context to portal view - open the MO list view for registering components for multiple MOs -> add the missing js file in the manifest - save the changes on the DB -> call `_has_workorders` before doing some workorder operations -> add sudo for MO unlink because a portal user doesn't have DELETE ACL -> add sudo for MO assign when using lots/serials -> skip writing the state field if there's no record to write - correctly increment sequence -> added the changes from https://github.com/odoo/odoo/pull/227095 to the subcontracting serial wizard task 5107873 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents Odoo from automatically canceling workorders when a subcontracting manufacturing order (MO) is created or modified through the portal. Previously, this caused unnecessary MO duplication. Now, the system correctly avoids workorders on subcontracted MOs, aligning with the intended product structure.
Original PR description
When adding/changing serial number on a subcontracting MO via portal view, Odoo will cancel and unlink the old MO(s) to recreate new ones. This include cancelling workorders, which a portal user doesn't have access to. Since subcontracted MO should not have workorders because the bom should not have operations, this PR adds a call to `_has_workorders` before searching for workorders.
This update fixes an issue where portal users couldn't properly unsubscribe from leads marked as spam. It now allows users to access and manage tags on leads when they identify them as spam, ensuring a smoother unsubscribe process and improved user experience. This change enhances the portal's functionality for managing unwanted communications.
Original PR description
Allow a portal user to read tags on the lead when he mentions that it is spam. Correct access for the unsubscribe process with child partner for the commercial partner of the portal user. task-5347166
This update resolves a bug that occurred during Odoo upgrades when a default confirmation template wasn't available. The error stemmed from incorrectly attempting to use a boolean value (False) as if it were an object with an 'exists' method. This fix ensures a smoother and more reliable upgrade process.
Original PR description
When there is no default confirmation template,
An error is raised:
AttributeError: 'bool' object has no attribute 'exists'. This happens because default_template is False,
So calling default_template.exists() results in the error. The issue occurs during the upgrade process.
```
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3142, in _init_column
value = field.default(self)
File "/home/odoo/src/odoo/19.0/addons/website_sale/models/website.py", line 52, in _default_confirmation_email_template
if default_template.exists():
AttributeError: 'bool' object has no attribute 'exists'
```
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-prThis update resolves an issue that occurred when users deleted all overtime rules before installing the 'hr_work_entry_attendance' module. The fix prevents a parsing error by intelligently handling the absence of required records, ensuring smooth module installation. This improves the user experience and avoids installation failures.
Original PR description
Currently a `ParseError` arises when the user installs the `hr_work_entry_attendance` module after deleting all `Overtime Rules' in the 'Rulesets` Configuration. Steps to reproduce: --- - Install…
Currently a `ParseError` arises when the user installs the `hr_work_entry_attendance` module after deleting all `Overtime Rules' in the 'Rulesets` Configuration.
Steps to reproduce:
---
- Install `hr_attendance` module(without demo)
- Attendance > Configurations > Overtime Rulesets
- Delete all `Overtime Rules` in `Default Ruleset`
- Now install `hr_work_entry_attendance` module
Traceback:
---
```py
Exception: Cannot update missing record 'hr_attendance.hr_attendance_overtime_employee_schedule_rule'
ParseError
while parsing /home/odoo/src/enterprise/19.0/hr_work_entry_attendance/data/hr_attendance_overtime_rule_data.xml:4, somewhere inside <record id="hr_attendance.hr_attendance_overtime_employee_schedule_rule" model="hr.attendance.overtime.rule">
<field name="work_entry_type_id" model="hr.attendance.overtime.rule" eval="obj()._get_default_work_entry_type_id()"/>
</record>
```
The error occurs because the user deleted all `Overtime Rules` and then installed the `hr_work_entry_attendance` module. which requires particular records.
This commit solves the above issue by using `noupdate="1"`and `forcecreate="0"` to skip the creation of record if it doesn't exists.
https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/odoo/tools/convert.py#L364-L366
sentry-7023182659This update ensures the change line (difference between paid and total) is correctly displayed on the receipt when using languages other than English in Point of Sale. Previously, the system incorrectly skipped this line when the payment line was translated, leading to inaccurate receipts. This fix guarantees accurate receipt totals regardless of the POS user's language setting.
Original PR description
When using another language than english, the change line wasn't displayed on the receipt. Steps to reproduce: ------------------- * Set the POS user language to fr_BE (or any none english) * Pay an order in cash with an amount greater than the total. > Observation: Change line was not visible on the receipt Why the fix: ------------ The frontend was checking `paymentLine.name !== "return"`, so once the backend translated the name to “Retour”, the change line was skipped. By checking `is_change` we get the correct amount and we ensure `order.showChange` still returns true even when the “return” payment line is translated (e.g. in fr_BE). opw-5247079
This update fixes a technical error that occurred when validating online payments with invoices in the Point of Sale (POS) system. The fix involved correcting how invoice PDF downloads and cashbox actions were handled, ensuring smoother online payment processing for customers. This resolves a previous error that prevented successful order validation.
Original PR description
steps to reproduce: - Create an Online Payment payment method. - Open POS, create an order, and validate it using the Online Payment method with Invoice enabled. issue: - A traceback error is displayed after validating the order. fix: - Fixed the `invoice PDF download` actions so it use the correct service. - Also, corrected for the cashbox action. task: 5269502
This update corrects a calculation error related to PFA (Pension Funds Account) computations within the Belgian payroll module. The fix ensures accurate tax deductions are applied, improving the reliability of payroll processing for Belgian employees. This change addresses a previously identified issue and enhances compliance.
Original PR description
This commit refactors and fixes the PFA computation. task-5103485
This update corrects a technical error in how Odoo processes webhook events related to expense reports using Stripe virtual cards. Specifically, the system was incorrectly interpreting 'None' shipping values as dictionaries. This fix ensures accurate data handling and prevents potential disruptions to expense reporting workflows.
Original PR description
Add a fix to a pattern of error found in webhook events where virtual cards whose shipping value is "None" would be accessed as dict
This update removes a redundant filter in the HR work entry system, resolving an issue that caused problems with localization (l10n_BE). The change ensures accurate leave calculations by allowing the system to correctly handle variations in work entry types.
Original PR description
This filter was not necessary and was causing some issues in l10n_BE as the work entry type can change depending on various reasons. If it changed, the leave_id would not be copied to the new work entry. task-5103485 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 restores the ability for users to manually mark financial moves as 'to review' within the Odoo system. Previously, this functionality was hidden, but this change ensures users can accurately track and manage moves requiring review. This improves workflow efficiency for financial processes.
Original PR description
This commit restores the visibility of the `Reviewed` boolean on account.move (Other Info) so users can manually uncheck it and mark moves as 'to review'. Applies only to 19.0. task-5361487
This update resolves an error that occurred when setting a partner on a bank statement line, specifically when dealing with draft invoices lacking an invoice date. The fix ensures the system correctly compares invoice and statement dates, preventing a 'TypeError' and allowing for accurate reconciliation. This improves the stability of bank statement processing.
Original PR description
Currently, an error occurs when a user sets the partner on a statement line. **Steps to Reproduce**([video](https://drive.google.com/file/d/1ZQBBh4yjSljeqqL_jT8dh_QJ6LtFZdPb/view)): - Install the…
Currently, an error occurs when a user sets the partner on a statement line.
**Steps to Reproduce**([video](https://drive.google.com/file/d/1ZQBBh4yjSljeqqL_jT8dh_QJ6LtFZdPb/view)):
- Install the `account_accountant` module.
- Go to `Invoices` and create `two invoices` with the `same partner` and the `same total amount` by adding
an `invoice line`.
- Go to the `Dashboard` and click `Last Statement` under the `Bank journal`.
- Create a `new statement line` with the `same amount` as the `invoice amount`.
- Click `Set Partner` and select the `same partner` used in the invoices.
`TypeError: '<=' not supported between instances of 'bool' and 'datetime.date'`
After [this commit], when a user sets the partner on the statement line, the system attempts to automatically reconcile the line. It then searches for a single invoice matching the statement line amount [1] and tries to select the one with the closest prior or equal date. However, draft invoices have not an invoice_date, and when the system attempts to filter on this field, and the error is raised [2].
This commit ensures that the comparison between invoice date and statement date occurs only when the invoice date is present.
[this commit]: https://github.com/odoo/enterprise/pull/98269
[1]- https://github.com/odoo/enterprise/blob/84ccb807852ab6b118466d12c8f02ea4da7fa3db/account_accountant/models/account_bank_statement.py#L585
[2]- https://github.com/odoo/enterprise/blob/84ccb807852ab6b118466d12c8f02ea4da7fa3db/account_accountant/models/account_bank_statement.py#L249
sentry-7063516380This update ensures selection fields in list views can now be cleared to display an empty state, mirroring how many2one fields behave. Previously, clearing a selection field caused an error. This change provides a more consistent user experience and allows users to accurately represent the absence of a value.
Original PR description
Steps: - Install studio - Open any list view - Make sure multi_edit is enabled (or edit the view with debug menu) - Add a new selection field to the list view with studio with several values - Get…
Steps: - Install studio - Open any list view - Make sure multi_edit is enabled (or edit the view with debug menu) - Add a new selection field to the list view with studio with several values - Get back to the list view, select at least two record and edit the new selection field - Put any value, it will edit all selected record correctly - select at least two record and edit the field again - Try to clear the value (to have it empty) - Traceback Since this change https://github.com/odoo/odoo/pull/214422, selection fields no longer display “empty” values, to be consistent with many2one fields. Now, to set a selection field to a null value, you have to clear it, just as you would clear a many2one field. The problem arose because when you clear an input, `onInputClear` is called and triggers an onchange with the value `null`, but the `selection_field` code expects to receive a `false` if there is no value otherwise it searches for the value in the list of possible choices which is why the traceback is raised when `null` is received, because it is not in the list of choices. This comimt change the onchange of `selection_field` to change the value to `false` if it is equal to `null`. opw-5226200
This update resolves a bug where Google Calendar events weren't syncing correctly when created by a user with Google sync disabled, even if another user had it enabled. Previously, events created by one user wouldn't appear in the organizer's Google Calendar. The fix ensures the event sync is triggered based on the organizer's Google sync status, improving event visibility.
Original PR description
**Issue** Events were not synchonized if created by a user with google synchronization stopped, for a user with an active google synchronization. To reproduce: - Have user A with google synchronization stopped and user B with google synchronization enabled. - With user A, create an event with user B as the organizer. - Open the Google calendar of user B and notice the event is not present. In our own database, it was causing issues for meetings booked from website and created by the public user. **Change** The user returned by `_get_event_user` is the one who needs to perform the sync to google, so we check the status of its google sync. opw-4795476
This update resolves a bug that prevented POS orders with products using different units of measure from being correctly settled. Previously, the system would encounter errors. Now, POS orders with mixed units of measure can be settled successfully, ensuring accurate order processing and preventing disruptions to the sales process.
Original PR description
When a POS order contains products with different units of measure, the system was unable to settle the order properly, leading to errors. opw-5357109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where inserting a form snippet (like a 'Contact us' form) into an existing form created a broken HTML structure. The fix prevents this nesting, ensuring valid HTML and preventing errors when editing fields within the inserted form. This improves the stability and usability of the website builder.
Original PR description
When a snippet containing a `<form>` (e.g. “Contact us” form) is dropped inside an existing form element, the inner form is invalid HTML (see [1]). Steps to reproduce: =================== 1- Go to a…
When a snippet containing a `<form>` (e.g. “Contact us” form) is dropped inside an existing form element, the inner form is invalid HTML (see [1]). Steps to reproduce: =================== 1- Go to a Shop page and open a Product page. 2- Drag and drop a “Contact us” form snippet inside the existing product form (e.g. in description_ecommerce, which is an HTML field with `sanitize_form=False`). 3- Save the page, re-enter edit mode. 4- Click on any field of the inserted “Contact us” form. → traceback. Cause: ====== HTML does not support nested `<form>` elements. As soon as the browser parses the dropped snippet inside an existing `<form>`, it normalizes the DOM and strips or moves the inner `<form>` tag, keeping only its contents. The inner form therefore loses its attributes (action, method, data-model_name, etc.). When editing a field, `fetchAuthorizedFields` needs the form’s model it used to rely directly on `formEl.dataset.model_name`, which is missing in this broken structure, causing a crash. Solution: ======== Prevent dropping the snippets that contain a form inside another form, by filtering out the `selectorSiblings/Children` (which are used to make the dropzones appear) that are in forms, when they are dragged. This commit also uses the `getModelName(formEl)` helper wherever we need the form model instead of accessing `dataset.model_name` directly. [1]: https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/How_to_structure_a_web_form opw-5256576
15 changes
Resolved issues and error corrections
This update fixes a crash that occurred when releasing a table in the Restaurant POS module. The issue stemmed from deleting the order prematurely when switching screens, causing the system to attempt to access non-existent order data. Now, the order is deleted after returning to the main screen, preventing the crash and ensuring a smoother user experience.
Original PR description
### Steps to reproduce: - Open the Restaurant POS. - Select a table and add a product. - Click order button. - Reopen the same table and remove all order lines. - Click "Release Table". ### Issue: - A blank screen appears and an error is shown in the browser console. ### Reason: - This happens because the order is deleted before switching screens, so the system tries to access order that no longer exists. ### Fix: - The order is now deleted after switching back to the main screen. Related PR: https://github.com/odoo/enterprise/pull/89715 Task: 4899160
This update resolves an issue where releasing a table in the Restaurant POS module would cause a crash. The team added a test case to ensure stability when removing orders from a table, preventing unexpected errors and improving the user experience. This ensures smoother operation for restaurant staff.
Original PR description
## In this commit: - Testcase added to ensures that no traceback occurs when releasing a table after deleting a synced order. ## Steps to reproduce: - Open Restaurant POS - Select a table and add a product - Click the order button - Reopen the same table and remove all order lines - Click "Release Table" Related PR: https://github.com/odoo/odoo/pull/216336 Task: 4899160
This update fixes a visual issue where the comparison price for subscription products wasn't displayed on the product page. The fix involves updating how the product page renders pricing dynamically, ensuring the comparison price is correctly shown to customers. It addresses a technical limitation with client-side rendering and formatting.
Original PR description
Steps to reproduce: 1. Install website_sale_subscription 2. Enable Comparison Price from the settings 3. Create a Subscriptions product with a recurring plan and 'compare to price' > recurring price…
Steps to reproduce: 1. Install website_sale_subscription 2. Enable Comparison Price from the settings 3. Create a Subscriptions product with a recurring plan and 'compare to price' > recurring price 4. Go to product page via smart button Issue: - The comparison price is not visible beside the recurring plan. Cause: - The product page updates the pricing display dynamically using client-side rendering when the subscription plan information is loaded. The XML template `website_sale_subscription.SubscriptionPricingSelect` used the <field> tag `<field name="product.compare_list_price"/>` to render the comparison price. The <field> tag is a server-side QWeb element and is not supported by the client-side Owl engine, causing the rendering to display nothing. Additionally, client-side templates do not have automatic access to server-side field formatting (like currency symbols) when simply escaping raw values. Solution: - In `variant_mixin.js`, extract the already formatted comparison price text from the existing DOM element (the `<del>` tag inside the pricing selector) before the element is replaced and pass this formatted string to the rendering context. Update the XML template to use `t-esc` to display this pre-formatted string instead of using `<field>` before: <img width="426" height="79" alt="image" src="https://github.com/user-attachments/assets/fe34b4c5-5cd6-4877-80e3-9ed4481cd86f" /> After: <img width="392" height="115" alt="image" src="https://github.com/user-attachments/assets/ed043fef-bfd3-46de-aeb2-1a48cacc89ed" /> opw-5248297
This update fixes a bug where sales made through the Point of Sale (PoS) system weren't reflected in event sale reports. The fix modifies the report's data query to include these sales, ensuring a more accurate record of event revenue. This improves reporting accuracy for event organizers.
Original PR description
Add event registration sold through PoS to the event sale report. Steps to reproduce: ------------------- * Create an event with tickets * Sell a ticket through the PoS * Go to the event sale report > Observation: The ticket sold through PoS is not included in the report Why the fix: ------------ We modify the SQL query of the event sale report to include event registrations sold through PoS. We also make sure to remove duplicates from the original query. opw-4935195
This update fixes an issue where Point of Sale (POS) picking wasn't correctly generating items when selling BOM kits with variant-specific components. Previously, it only considered one variant, even with multiple orders. Now, the system accurately creates picking lists for all variant combinations, ensuring complete order fulfillment.
Original PR description
When selling a bom kit that have some components that applies on specific variants only, the picking was not correctly created. It would only take one kit variant into account, even if you sold 2…
When selling a bom kit that have some components that applies on specific variants only, the picking was not correctly created. It would only take one kit variant into account, even if you sold 2 kits with different variants. Steps to reproduce: ------------------- * Create a product P * For product P, create an attribute with type "No variant" and values V1 and V2 * Create a BoM Kit for product P, with 3 components C1 C2 and C3 - C2 applies only for variant V1 - C3 applies only for variant V2 * Create a POS order with 2 lines of product P: - 1 with variant V1 - 1 with variant V2 * Validate the order and check the created picking > Observation: Only C1 and C2 are in the picking, C3 is missing Why the fix: ------------ When creating the picking, the code was grouping the order lines by product only, and not by product variant. Therefore, the 2 lines would be grouped together, and only one of the variant-specific components would be taken into account. opw-5051289
This update resolves a bug where a previously unlinked call continued to appear in the Odoo softphone. The fix ensures that calls are immediately removed from the softphone interface when they are no longer linked, improving the user experience and data accuracy.
Original PR description
A call that was unlinked previously remained visible in the VOIP softphone. This fix ensures that the call is correctly removed from the softphone view as soon as it is unlinked. Task-5262162 Forward-Port-Of: odoo/enterprise#100036
This update fixes a security vulnerability where Portal and Internal users could create private knowledge articles without the necessary permissions. The fix restricts article creation to users with 'Create' access, improves the user interface by hiding creation buttons when access is denied, and adds new tests to ensure proper access control.
Original PR description
How to Reproduce : 1. Remove 'Create' access on the 'Knowledge Article' model for Portal and Internal users. 2. Now log in as a Portal. 3. Try to create a new private article. 4. Log in as an…
How to Reproduce : 1. Remove 'Create' access on the 'Knowledge Article' model for Portal and Internal users. 2. Now log in as a Portal. 3. Try to create a new private article. 4. Log in as an Internal user. 5. Try to create a new private article. Both Internal and Portal users can still create private articles even after 'Create access' is removed. Article creation logic in `knowledge.article` was bypassing the usual access rights because of `sudo` (mainly to add the creator as a member, since creation rights on the member model are not granted). This allowed users to create private articles even without create access. This commit introduces: 1. Model-level access check in `create`. Sudo the creation of articles only when the user has create rights. 2. UI imp to hide the '+' button in the sidebar and the `New` button in the topbar when the user doesn't have create access. 3. New test cases to verify that model-level access rights are respected when creating an article. task-4916280 Forward-Port-Of: odoo/enterprise#93034
A recent update to the stock management system introduced a bug that caused errors when creating new stock lots. This fix resolves the issue where the system couldn't properly process newly created lots, preventing certain stock operations from functioning correctly. This ensures all stock transactions, including new lot creation, are processed reliably.
Original PR description
### Description: With the commit 72a87353f76bfa31561bed5eb21377b8e95cb7ee, `_find_delivery_ids_by_lot` has been replaced with another method more optimized. However, it introduces a bug when triggering the compute on a new lot. When `self` is not an existing lot but rather a new lot, it throws an error since the lot doesn't have an ID. ### References: 72a87353f76bfa31561bed5eb21377b8e95cb7ee opw-5355952 Forward-Port-Of: odoo/odoo#237621
This update prevents refund amounts from exceeding original order totals when using global discounts in the Mexican localization (l10n_mx_edi_pos). Previously, this caused errors during global invoice generation. The fix limits refunds to the original order amount, specifically for the Mexican module, to ensure accurate invoicing.
Original PR description
When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to…
When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to generate a global invoice for the mexican localization. Steps to reproduce: ------------------- * Activate the global discount option in any PoS * Open PoS and make a sale with a global discount * Refund the sale without including the discount * Go to the backend * Go to the order list and select the 2 orders you made * Now try to create a global invoice > Observation: The global invoice is in error because the negative lines cannot be distributed correctly. Why the fix: ------------ To avoid this issue with the global invoice we simply prevent the user to generate a refund with a greater amount than the original order. We only apply this limit to the mexican localization because it's the only module that is affected by this issue. Other localizations can still refund without restrictions even if this work flow does not really make sense. opw-4899501
This update fixes an issue where the course search dropdown was overlapping the search input field on the homepage. The fix ensures the dropdown is correctly positioned within the search form layout, providing a better user experience for finding courses.
Original PR description
Scenario: go to homepage > Courses > one "View all" > type in search Result: dropdown with result is shown over the search input Issue: search form is in flex layout, but the dropdown is displayed in absolute so it is outside of flex flow and is positionned at the top-right of the form container. History: - before bootstrap 4 (odoo 15): the search form had a flex layout, but bootstrap dropdown used "top:100%" so were positionned at the bottom of it. - as of bootstrap 5 (odoo 16): the form kept a flex layout, but bootstrap dropdown now used "position: absolute" with unset top putting them below the search item in a block container, but over it in a flex layout. Fix: when the search bar is displayed, display it as block. opw-4735257 Forward-Port-Of: odoo/odoo#206909
This update fixes an issue where the tax amount on invoices wasn't correctly updated after deleting and adding a line. Specifically, deleting a taxed line followed by an untaxed line would result in an incorrect tax total. The fix adjusts the system's logic to properly recalculate tax amounts in these scenarios.
Original PR description
**PROBLEM** If in an invoice you delete a taxed line, and then add an untaxed line the tax amount might not be up to date. **STEP TO REPRODUCE** 1. create an invoice with 2 lines both taxed. 2.…
**PROBLEM** If in an invoice you delete a taxed line, and then add an untaxed line the tax amount might not be up to date. **STEP TO REPRODUCE** 1. create an invoice with 2 lines both taxed. 2. remove one of the line, and create a new line which is untaxed. 3. confirm the invoice and notice the tax amount is not correct (= to the tax amount with the 2 taxed lines). Be sure to not click on the "journal items" tab, else the bug will not occur. **ISSUE** In _sync_tax_lines(), there is checks to know if we should recompute the tax amount, or keep the old one. We enter the check that checks the changed lines and determine if we should recompute the tax amount. This check doesn't take into account the fact that a line could have been deleted. Because we are in a elif chain, we don't do other checks. **FIX** Moving up in the elif chain the check that test if a base line with tax was removed and recompute the tax amount if that's the case. [opw-5157090](https://www.odoo.com/odoo/project/49/tasks/5157090)
This update resolves an issue where the system was incorrectly creating multiple bank accounts from UBL invoices. The fix filters out duplicate account numbers, ensuring accurate bank information is imported into the system. This prevents data inconsistencies and improves the reliability of financial transactions.
Original PR description
Currently `_import_retrieve_and_fill_partner_bank_details` may try to to create multiple res partner bank with the same account. This can i.e. happen in case there are multiple `cac:PaymenMeans` nodes in the XML. After this commit we filter out duplicate bank accounts numbers. opw-5149621 Forward-Port-Of: odoo/odoo#236676
This update resolves a translation issue in the Odoo accounting module for Marathi-speaking users. The tax report data was incorrectly translated, leading to potential inaccuracies in reporting. This fix ensures accurate tax reporting for our users in India.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237711
This update fixes an issue where vendor bills created through the Documents module incorrectly defaulted to the company's currency instead of the vendor's. Now, when a vendor is selected in the Documents module, the bill automatically uses the vendor's currency, ensuring accurate financial reporting. This improves the reliability of vendor billing transactions.
Original PR description
**Issue:** When creating a vendor bill or vendor refund through the Documents module after selecting a supplier, the currency defaults to the company's currency instead of the vendor's. However, if the supplier is selected later in the Accounting module, the correct supplier currency is applied. **Steps to reproduce:** - In Documents, upload a bill. - Click on the bill and assign a vendor (whose supplier currency is different from the company's currency). - Click on "Create Vendor Bill". The used currency isn't that of the supplier. opw-4406074 Forward-Port-Of: odoo/enterprise#78380
The Original Bills report was failing to generate due to complexities in how Odoo creates the report's PDF. To resolve this, the studio interface has been configured to simply blacklist this specific report, preventing errors. This ensures users can access other reports within studio without interruption.
Original PR description
Steps to reproduce ================== - Install account_accountant,web_studio - Go to Invoices - Open studio - Click on "Reports" - Select the "Original Bills" report => The report is empty Cause of the issue ================== The Original Bills is a very specific report. Multiple streams are created and then combined to make the final PDF See: odoo/odoo#85150 Solution ======== Since studio cannot handle this usecase, we blacklist this report opw-5108198 Forward-Port-Of: odoo/enterprise#100729
4 changes
Resolved issues and error corrections
This update fixes a bug that caused the system to crash when users attempted to validate signatures on employee contracts. The issue stemmed from a missing field in the HR employee model after the 'hr_contract_sign' module was uninstalled. The fix adds a graceful bypass to handle the missing field, ensuring a smooth user experience.
Original PR description
The system will crash with an error when the user tries to validate the signature.
**Steps to produce:**
- Install `Sign, Employee Contracts, and Documents` apps with demo data.
- Go to Apps and uninstall the `hr_contract_sign`module.
- Send any employee a sign request for a document.
- When the employee tries to validate and send the document, the error appears.
**Error:**
`KeyError: 'sign_request_ids'
ValueError: Invalid field hr.employee.sign_request_ids in condition ('sign_request_ids', 'in', [1])`
**Cause:**
- When `sign` route is called, then we try to search field `sign_request_ids` in `hr_employee`. but we can see the field `sign_request_ids` is defined in `hr_contract_sign` module.
- And user removed the `hr_contract_sign` module, so the field no longer exists. in the hr_employee model.
**Solution:**
- Added a graceful bypass when `sign_request_ids` is missing,
**sentry-6819182542**This update ensures that all B2C invoices generated through our Saudi Arabia localization (l10n_sa) module now correctly display 'Simplified Tax Invoice' as the invoice title. Previously, this requirement was only applied to phase 2 ZATCA invoices. This change aligns with regulatory requirements and improves invoice consistency.
Original PR description
For B2C invoices, the invoice's title must be "Simplified Tax Invoice". This was only applied to phase 2 ZATCA in "l10n_sa_edi". This change makes sure to apply the same requirement for phase 1 invoices. Task-5322118 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
The Original Bills report in Odoo Studio was producing empty results due to a complex report generation process. To resolve this, the Studio team has blacklisted this specific report, preventing it from being created within the Studio interface. This ensures Studio focuses on reports it can reliably handle.
Original PR description
Steps to reproduce ================== - Install account_accountant,web_studio - Go to Invoices - Open studio - Click on "Reports" - Select the "Original Bills" report => The report is empty Cause of the issue ================== The Original Bills is a very specific report. Multiple streams are created and then combined to make the final PDF See: odoo/odoo#85150 Solution ======== Since studio cannot handle this usecase, we blacklist this report opw-5108198
This update resolves a visual issue in check printing for US layouts, where the payment date would overlap with the table below. The fix ensures the date is always positioned correctly in the generated PDF, improving the presentation of vendor bills and payments.
Original PR description
In the Accounting app, users can print checks created to pay Vendor Bills. When using any of the US Checks Layout (from `l10n_us_check_printing`), the payment date would overlap the table beneath it…
In the Accounting app, users can print checks created to
pay Vendor Bills. When using any of the US Checks Layout (from
`l10n_us_check_printing`), the payment date would overlap
the table beneath it when the journal's manual sequencing option was
disabled.
<img width="1201" height="624" alt="image" src="https://github.com/user-attachments/assets/cd3aa46a-1952-4652-9034-e4bc2ea9a44d" />
This occured because the `.summary_line` container collapsed to a height
of 0 whenever its first child wasn't displayed, as the remaining child
elements are absolutely positioned and therefore do not contribute to
the parent's height.
https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/l10n_us_check_printing/report/print_check.xml#L24-L34
By assigning a minimum height to the `.summary_line` class, we make sure
that it always occupies space above the table, even when only the date
is shown.
### Steps to reproduce:
**/!\ To reproduce the bug locally, you must have a version of wkhtmltopdf with patched qt. Use `wkhtmltopdf -V` and make sure that _"(with patched qt)"_ is specified after your wkhtmltopdf version.**
1. Install Accounting (`accountant`) and US Checks Layout (`l10n_us_check_printing`)
2. In Settings > Accounting, toggle on *Checks* if it is not, and set *Check Layout* to any "US" layout.
3. Go to Accounting > Vendors > Bills
4. Create a new Vendor Bill:
- Set any Vendor
- Set any Bill Date
- Add any Product (with a positive price, the total price of the bill must be positive)
- Confirm
5. Click *Pay*, set the *Payment Method* to *Checks* and click *Create Payment*
6. Click on the *Payments* smart button
7. Click *Print Check* > *Print* (> *Continue*)
8. In the generated PDF, the date overlaps the table beneath it.
This fix moves the date right above the table.
<img width="1189" height="634" alt="image" src="https://github.com/user-attachments/assets/8858098e-b39b-4ad2-aa65-cc0cea550343" />
opw-5165112