Daily updates from Odoo
Friday, March 6, 2026
268 changes
16 changes
Enhancements to existing features
This update addresses changes required for the new 2026 Spanish tax format. Specifically, a new field for petrol information has been added, and the layout of certain Casillas (sections) has been adjusted to align with the updated reporting requirements. This ensures compliance with Spanish tax regulations.
Original PR description
Forward-Port-Of: odoo/enterprise#109260
This update optimizes accounting reports by using more efficient data structures. Specifically, accounting reports now automatically convert data to JSON, reducing the amount of data transmitted and improving report loading times. This results in a faster and more responsive user experience.
Original PR description
To reduce the memory footprint of accounting reports, we now use different data structures for lines, columns, etc. These structures are sent to the web client and therefore need to be JSON-serializable. This change allows dataclasses to be returned directly; they are now automatically converted to dictionaries. task-5404869
This update optimizes the performance of key financial reports, particularly those handling large datasets, by reducing memory usage and improving data processing. The team removed unused code and refactored report generation to enhance stability and speed, addressing a critical issue impacting report generation times.
This update simplifies the meeting chat by removing irrelevant actions and consolidating member management. The chat title now clearly indicates it's for in-call conversations, improving clarity and focus during meetings. This change streamlines workflows and enhances usability.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- The meeting chat UI exposed a generic three-dot (more actions) menu that grouped actions which…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- The meeting chat UI exposed a generic three-dot (more actions) menu that grouped actions which are not relevant in the context of short-term, in-call conversations. At the same time, member management and invitation actions were split across different entry points, and pinned messages were only accessible through a separate panel, reducing their visibility during a call. Additionally, the chat panel title did not clearly reflect that the conversation was happening in the context of an ongoing meeting. **Current behavior before PR:** ---------------------------------------------- - The meeting chat displayed a three-dot (more actions) menu with actions that are not relevant during in-call conversations - Member listing and invitation actions were exposed through a dedicated Invite button, separate from the members view - Pinned messages were accessible via a separate panel instead of being visible directly in the chat message flow - The chat panel title was displayed as “Chat”, regardless of the in-call context **Desired behavior after PR is merged:** ---------------------------------------------- - The three-dot (more actions) menu is removed from the meeting chat, simplifying available actions and reducing visual noise during calls - The Invite button is replaced by a unified Members button, allowing users to view current members and invite new participants from the same interface - Pinned messages are integrated directly into the chat message flow, making them immediately visible alongside regular messages during a meeting - The chat panel title is updated from “Chat” to “In-Call Messages” to better reflect its purpose in the meeting context Together, these changes streamline the meeting chat experience, focus the UI on actions relevant during a call, and improve visibility of both pinned messages and participant management. Task-5382645 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update fixes a bug preventing warnings on the EC Sales List report when dealing with customers outside of Europe. Specifically, the report now correctly identifies customers with 'Intra-Community' fiscal positions in European companies and those using non-European delivery addresses, ensuring accurate reporting and compliance. This ensures accurate sales reporting for international transactions.
Original PR description
The warnings partner_same_country and partner_no_ec_country on the EC Sales List are never showed. To Reproduce (for partner_same_country warning): - Create a company in Belgium - Create a customer in Belgium with "Intra-Community" as a Fiscal Position - Create an invoice with this customer - Go to the EC Sales List - The customer doesn't appear in it, so the warning is not present. For the partner_no_ec_country, do the same but with the country of the customer being one outside of Europe. Forward-Port-Of: odoo/enterprise#107139
This update fixes a potential issue where user information wasn't consistently being sent, leading to unexpected behavior across several Odoo modules (mail, HR, Portal). Specifically, the system now always includes the `partner_id` with `main_user_id` to ensure accurate identification and data flow. This improves reliability and prevents potential errors.
Original PR description
`main_user_id` should always be sent with its `partner_id` to avoid subtle issues. Indeed the `partner_id` inverse is on `user_ids` not on `main_user_id`. It is indirectly assumed `partner_id` should be set on `res.users`, in particular when using `partner.main_user_id.partner_id`. https://github.com/odoo/enterprise/pull/109364 Forward-Port-Of: odoo/odoo#252320 Forward-Port-Of: odoo/odoo#251641
This pull request corrects a minor issue in the German localization (l10n_de) module where tags were incorrectly formatted in the account data file. This ensures accurate reporting and categorization of financial transactions for German-speaking customers. The fix was verified and approved as part of a standard process.
Original PR description
Commit db0d499952192ede0def2a070e103ba67952387c inverted some tags which is wrong opw-5415426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250744
This update fixes an issue where tax report tags were incorrectly sorted, preventing proper auto-completion functionality. The team has also improved testing to prevent similar errors in the future. This ensures accurate reporting for German tax compliance.
Original PR description
Commit https://github.com/odoo/odoo/commit/db0d499952192ede0def2a070e103ba67952387c inverted some tags which is wrong Tags must be sorted for the auto complete to work properly Improving tests to catch more errors opw-5415426 Forward-Port-Of: odoo/enterprise#108848
This update removes a display field ('Visible Internally Only') from the customer rating form in the Helpdesk module. This field was no longer needed since customer ratings are no longer visible on the website. This change improves the user experience and reduces unnecessary data display.
Original PR description
**Steps to reproduce:** - Open a Helpdesk ticket with a customer rating. - View the rating form. - Observe the field ‘Visible Internally Only’ still showing. **Issue:** - The field is displayed even though ratings are no longer shown on the website. **Reason:** - The field is now irrelevant but still present in the view. **Fix:** - Invisible the ‘Visible Internally Only’ field from the customer rating form in the affected version. **Task id - 5359052** Forward-Port-Of: odoo/enterprise#109287 Forward-Port-Of: odoo/enterprise#100686
A bug causing duplicate 'New' and 'Create New' buttons in the task list has been resolved. This change ensures users only see a single 'New' button when creating tasks, streamlining the process and preventing confusion. The fix addresses a technical issue related to a ControlPanel refactoring.
Original PR description
Steps to Reproduce --- 1. Enable Task Dependencies in Project settings 2. Create project with no task templates 3. Open task form -> Blocked By tab -> Add a line 4. Observe duplicate "New" and "Create New" buttons Issue --- - The task list view displays both “New” and “Create New” buttons, resulting in duplicated creation actions. Current Behaviour --- - Two different creation buttons are displayed simultaneously Expected Behaviour --- - Only a single “New” button should be displayed Root cause --- - ControlPanel refactoring removed props.showButtons without adding !env.inDialog check to task views. Fix --- - Add !env.inDialog check , this prevents the ProjectTaskTemplateDropdown component from rendering in dialog contexts, eliminating the duplicate button issue. Related - https://github.com/odoo/odoo/pull/220325 task - 5403917 Forward-Port-Of: odoo/odoo#241628
This update adds a temporary field to the burndown chart in the project module. This resolves a technical issue that would have prevented a safe upgrade to the latest version of Odoo. It ensures future updates to the burndown chart functionality can be implemented without disrupting existing data.
Original PR description
Add an empty `python_method` field to the burndown chart embedded actions as a preparatory change for a safe upgrade path. Without this, replacing `action_id` with `python_method` in master would temporarily violate the SQL constraint on `ir.embedded.actions` that prevents both from being set simultaneously. references: #239000 task-5347524 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252145
This update resolves an issue where a backlog of PEPPOL messages caused a recurring cron job loop, leading to processing delays. The fix addresses a race condition in token refreshing, preventing errors and ensuring consistent communication with the PEPPOL network. This improves the reliability of Odoo's integration with PEPPOL.
Original PR description
Fix two issues observed on Odoo production. 1) When more than 50 messages from this odoo db/client are queued to be sent on peppol-ap, all client-side messages remain in `processing` If the send queue stays saturated, the retrigger logic repeatedly schedules the cron, causing an infinite `ir_cron_peppol_get_message_status` loop. 2) Each cron refreshes the authentication token, which allows concurrent threads to refresh it in parallel. Due to the `REPEATABLE READ` isolation level, a long-running cron may continue using the old token while another thread has already refreshed it. This leads to `invalid-signature` responses and incorrectly marks the connection as out of sync on one thread, even through the long-running transaction fails on trying to commit. Thus, simply flushing the cursor will block the transaction in such a situation no-task Forward-Port-Of: odoo/odoo#252177
This update fixes a discrepancy in how inventory values are calculated. Previously, the system incorrectly assumed midnight when determining the 'As of' date for valuation reports, leading to inaccurate results. This change ensures that inventory values are calculated through the end of the day, aligning with established business logic and improving reporting accuracy.
Original PR description
### Problem: If `_compute_quantities` is called with only a date specified in `to_date` context (no timestamp), Odoo will assume midnight (00:00:00) instead of end of day (23:59:59). This contradicts logic in other places, such as `_compute_total_value`, which opts for the convention that "As of \<date>" means "through \<date>". ### Solution: We will run `_compute_quantities` with `to_date` at 23:59:59. ### Steps to replicate (Runbot 19): 1. Receive a valued and tracked product (you can make the impact more obvious by setting the cost very high) 2. Backdate the receipt to some day in the past using the method of your choice (inspector tool, server action) 3. Go to the Inventory Valuation report, set "As of" date to the backdated receipt date, note that the value of the validated receipt is not there 4. Set "As of" to the day AFTER the receipt date, note the value is now shown opw-5893999 Forward-Port-Of: odoo/odoo#251253
This update addresses a bug where changing the popup backdrop color or hiding/showing the popup would unexpectedly cause it to disappear. The fix ensures the popup's visibility is correctly tracked during history operations, preventing these disruptions. This improves the user experience when customizing popup appearances.
Original PR description
Steps to reproduce in 18.4: - Add a popup on the page - Click on the popup - Change the backdrop color - Hide the popup by clicking on its entry in "Invisible Elements" - Undo - Redo - Bug: The popup disappears Steps to reproduce in 19.0: - Add a popup on the page - Click on the popup - Hover a color in the colorpicker of the backdrop option of the popup - Stop hovering the color - Bug: The popup disappears Forward-Port-Of: odoo/odoo#251849 Forward-Port-Of: odoo/odoo#244213
This update resolves an issue where customers using customized account settings would receive empty depreciation schedule reports. The fix ensures accurate report generation by granting administrative access to verify compatibility with Odoo's accounting rules, preventing incorrect report output.
Original PR description
Following odoo/enterprise@ece0405785, in case a customer modified the `account.move.line` record rules in a way which is incompatible with the AML shadowing, user will only get an empty deprecation schedule report. This commit as a sudo, to ensure we get a correct report, access rights being already check for `account.asset` records. Forward-Port-Of: odoo/enterprise#108901
This update fixes an issue where link popovers in the preview mode were excessively large, particularly when titles were long. Now, the popover size is consistently maintained, providing a cleaner and more user-friendly preview experience. This ensures consistent visual presentation across different content lengths.
Original PR description
Before this commit: the link popover is oversize when the preview has long title. After this commit: the link popover retains its size. task-6000052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252045
25 changes
Enhancements to existing features
This update enhances the generation of WPS files for Odoo Enterprise customers in the UAE, focusing on compliance and ease of use. Key changes include stricter data validation, improved bank account linking, and the ability to export WPS reports in Excel format, ensuring accurate payroll reporting.
Original PR description
This commit aims to make the generation of wps files for AE companies more compliant and intuitive for the user, by: - Updating string for l10n_ae_employer_reference field - Domaining the company's salary bank account to accounts that belong to the company - Enabling the export of xlsx wps report - Preventing negative values in EVP section of the wps file - Adding constrains to the employer code as per expected format - Changing the names of allowance inputs - Adding a new category for evp rules - Making sure clearing number is only 9 digits as per expected format task-5884696 Forward-Port-Of: odoo/enterprise#107218
This update enhances the accuracy of interest rate calculations for loans within the Enterprise module. Previously, interest rates were limited to two decimal places. Now, users can specify interest rates with up to ten decimal places, providing greater flexibility and precision for financial reporting.
Original PR description
Allowing more precision on the interest rate for loans. By default the display uses 2 decimals, but if a user decides to add more precision they can up to 10 decimals. task-5913175 Forward-Port-Of: odoo/enterprise#107163
This update enhances logging for transactions processed by the Codabox integration (_l10n_be_codabox). These improved logs will assist the support team in quickly identifying and resolving any issues related to transaction processing, leading to faster problem resolution. This change primarily benefits internal support operations.
Original PR description
This commit will improve the logs of _l10n_be_codabox_fetch_coda_transactions to help the support team to debug possible problem. task-5436868 Forward-Port-Of: odoo/enterprise#109534 Forward-Port-Of: odoo/enterprise#107779
Resolved issues and error corrections
This update resolves an issue where users received an empty depreciation schedule report if customers had customized their accounting rules. The fix ensures accurate report generation by granting administrative access to verify asset data, addressing a potential reporting discrepancy.
Original PR description
Following odoo/enterprise@ece0405785, in case a customer modified the `account.move.line` record rules in a way which is incompatible with the AML shadowing, user will only get an empty deprecation schedule report. This commit as a sudo, to ensure we get a correct report, access rights being already check for `account.asset` records.
This update fixes an issue where link popovers in the preview mode were excessively large when titles were long. Now, the popover size is consistently maintained, ensuring a cleaner and more professional look for previews with longer titles. This improves the overall user experience.
Original PR description
Before this commit: the link popover is oversize when the preview has long title. After this commit: the link popover retains its size. task-6000052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refines the visual style of polls within the Discuss feature, enhancing readability and user experience. The changes include adjustments to spacing, text and icon sizes, and the removal of a misleading subtitle when a poll is closed. These improvements contribute to a cleaner and more intuitive interface.
Original PR description
- improved spacing (around card, between items, etc.) - small size and opacity / muted tweaks on text and icons - don't show "Select" subtitle when poll has closed Before / After <img width="1618" height="578" alt="Screenshot 2026-03-04 at 18 33 44" src="https://github.com/user-attachments/assets/bef827cd-d9f6-4067-8f77-4f3e17f6f73f" /> <img width="1581" height="571" alt="Screenshot 2026-03-04 at 18 32 51" src="https://github.com/user-attachments/assets/aeb9af94-5095-4784-8b87-d06876c52ba3" />
This update fixes an issue where sick leave days weren't accurately counted across months and the basic salary rule was incorrectly applied when no work entries existed. The changes ensure accurate calculation of sick leave and basic salary, particularly for leaves spanning multiple months or payslips with no work data.
Original PR description
### Issue: - Sick leaves were calculated using the leave record dates, so leaves that started in one month and continued into another month were not counted correctly. - The Basic salary rule was applied even when there were no `WORK100` work entries on the payslip. ### Fix: - Updated the leave filtering logic to consider leaves whose `request_date_from` or `request_date_to` overlaps with the payslip period year, instead of relying solely on the leave start date. - Adjusted the Basic salary computation to execute only when `WORK100` exists in `worked_days_line_ids`, preventing calculation when no effective worked entries are present. ### Impact: - Ensures sick leave days are correctly accounted for in the relevant payslip period, even when the leave spans across months. - Prevents incorrect Basic salary computation on payslips with no `WORK100` work entries, resulting in accurate payroll calculations. --- task-5462380
This update fixes errors preventing users from searching for job titles within the employee directory. Previously, access restrictions based on HR version models caused issues for certain users. The changes now allow all users to search for job titles, resolving both the initial access error and a separate issue related to resume searches.
Original PR description
[FIX] hr: fix job title search access error Bug reproduction: Select marc demo -> employee app -> try to search something for job title -> Access error appears for no hr ones Bug cause: Only…
[FIX] hr: fix job title search access error Bug reproduction: Select marc demo -> employee app -> try to search something for job title -> Access error appears for no hr ones Bug cause: Only users/managers can access to hr_version model and since marc demo has not, it receives this error. Bug solution: I put store=True and compute_sudo for job_title and by that way everyone can search for job_title without access. In the task [MOHF] showed another traceback about job title search. I fixed that in this commit as well. Bug 2 reproduction: employee app -> try to search something for resume -> it will give error (there is no version_ids) Bug 2 cause: There is no version_ids in the employee.public model, in the search version_ids.job_title is used but job_title can be used directly. Bug 2 solution: I used job_title in the search instead of using version_ids.job_title. task - 6000488 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 resolves an issue where invoice content overlapped with the header on subsequent pages when invoices had many lines. The fix prevents a technical problem with how wkhtmltopdf handles tables across pages, ensuring the header and invoice content are properly spaced.
Original PR description
**Steps to reproduce:** * Install `Accounting` module. * Create an invoice with enough lines to span multiple pages. * Print the invoice to PDF (or use the 'Print' action). **Observed behavior:** *…
**Steps to reproduce:** * Install `Accounting` module. * Create an invoice with enough lines to span multiple pages. * Print the invoice to PDF (or use the 'Print' action). **Observed behavior:** * On the second page (and subsequent pages), the invoice table rows overlap with the company header (logo, address). * This regression was introduced in saas-19.1 after the flexible document layout refactoring (commit). **Cause:** * The invoice's main table (`o_main_table`) is wrapped in a `<div class='table-responsive-sm'>`. * `table-responsive-sm` applies `overflow-x: auto` at narrow viewports, which creates a Block Formatting Context (BFC). * In wkhtmltopdf's WebKit engine, a BFC container does not participate in normal page fragmentation. When the table spans multiple pages, the content bleeds into the next page without respecting the header spacing defined by `--margin-top` and `--header-spacing`. * This causes the continued table rows (and any repeated `<thead>`) to render at the very top of the content area, overlapping with the page header. **ref:** https://github.com/odoo/odoo/commit/15697add5751181544fb61302ddb745a354a2935#diff-c85e75bc27fc841662ca0598c09a22670e0a0b4e5120815934c0a50999ff02bfR172 with this commit `table-responsive-sm` added to invoice pdf layout. **Fix:** * Add `overflow: visible` on the `table-responsive-sm` wrapper div to prevent the creation of a scroll container / BFC. * This ensures wkhtmltopdf can properly fragment the table across pages and respect the header spacing on all pages. **Before:** <img width="874" height="250" alt="image" src="https://github.com/user-attachments/assets/2da0a82a-abc9-49d6-9788-c8e89283e4b2" /> **After:** <img width="872" height="256" alt="image" src="https://github.com/user-attachments/assets/cd38b7e3-b2b6-4c03-a1d8-5ac31cad0925" /> opw-5949713
This update allows all live chat agents with access to modify the description of a channel, regardless of their membership status. Previously, only channel members could make these changes. This enhancement improves agent flexibility and efficiency in managing live chat conversations.
Original PR description
…cription **Before this PR**, only users who were channel members could edit the description of a live chat conversation. With this change, agents who have live chat access can now edit the channel description **even if they are not members** of that specific live chat channel. task-5046015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses instability in the HTML editor's automated tests. The issue stemmed from the toolbar being a popover, making it susceptible to timing inconsistencies during testing. The team adjusted timeouts and addressed dependencies to ensure more reliable test results.
Original PR description
Forward-Port-Of: odoo/odoo#252130 Forward-Port-Of: odoo/odoo#251122
This update resolves a crash occurring when posting expense entries with the Avalara Avatax integration. The change adjusts how Avatax handles move types, specifically addressing a 'KeyError' related to 'in_receipt'. This ensures smoother expense processing for US-based employees using the Avatax feature.
Original PR description
Currently, the expenses flow with Avatax integration crashes when posting the expense entry. Steps to reproduce: - Have an employee with an address in the US. - Enable 'Detect Automatically' in the Avalara fiscal position. - Create an expense for the employee, paid by Employee. - Submit > Post Journal entry > Post Expense. Action will be blocked by a traceback reporting error `KeyError: 'in_receipt'` Analysis: After [1] expense journal entries are now 'in_receipt'. The dictionary in account_avatax does not take into account this move type. This provides a fallback to 'Any' for any other move types [1] https://github.com/odoo/odoo/commit/f835ac0c8adb49d04bed746fd624b8976cc32991 opw-5872768 Forward-Port-Of: odoo/enterprise#109381
This update resolves a JavaScript error that occurred when reloading the shopfloor app, specifically during MO process runs. The fix disables the automatic focus of the search bar, preventing the 'Cannot read properties of null' error and ensuring a smoother user experience. This improves stability and reliability of the shopfloor functionality.
Original PR description
Steps to reproduce:
- Open the shopfloor app
- Reload or duplicate the page where the MO process is running
Issue:
A JavaScript error occur during reload:
UncaughtClientError > TypeError
Uncaught Javascript Error > Cannot read properties of null (reading 'blur')
Occured on 101125414-19-0-all.runbot180.odoo.com on 2026-02-16 04:59:28 GMT
TypeError: Cannot read properties of null (reading 'blur')
at https://101125414-19-0-all.runbot180.odoo.com/web/assets
/9d8abcf/web.assets_web.min.js:36280:459
Cause:
This happens when the search bar component attempts to call `blur()` on `inputRef.el` while the element is not yet available or has already been destroyed during the component lifecycle.
Fix:
Disable the search bar autofocus in the shopfloor
`env.config.disableSearchBarAutofocus = true`.
opw-5902675
upg-3894728
Forward-Port-Of: odoo/enterprise#107491This update resolves an issue where avatars in collaborative list views (like 'To Do' notes) were consistently positioned on the first line, regardless of where the user focused within the list. The fix ensures avatars now dynamically follow the user's cursor movement, improving the visual experience and usability of collaborative lists. This enhancement was implemented as a bug fix.
Original PR description
Since [1] when using collaboration, the position of the avatar for list items is always displayed on the first line - instead of following the user's focus. This commit fixes this by only applying the patch of [1] when inside an embedded component. Steps to reproduce: - Go to a "To do" note - Add a checked list with indented items - Access the same note from another window - Move around the checked list and observe avatar in other window => Avatar remained on first line while moving around list items [1]: https://github.com/odoo/odoo/commit/9863cb25d6dfdba224897f21634bdaaf3eca91a7 task-5930388 Forward-Port-Of: odoo/odoo#248438
This update fixes an issue where negative values were appearing in tax reports for carried over amounts (specifically lines 81-88). The change ensures that tax report XML files accurately reflect tax calculations, preventing potential reporting discrepancies. This improves the accuracy of financial reporting.
Original PR description
When generating the xml for tax report, negative values should not be present in the xml for carried over lines (81, 82, 83, 86, 87, and 88) Steps: - Create a RBILL for today - 1 month, add an invoice line with tax using one of the following tags: -81, -82, -83, -86, -87 or -88 in its base refund repartition line - Open the tax report on the month of the RBILL - Generate the xml, either by the dedicated button, or by creating and posting the closing entry -> there is line(s) for negative amounts opw-5955323 opw-5428395 Forward-Port-Of: odoo/enterprise#109568 Forward-Port-Of: odoo/enterprise#108916
This update resolves an issue where rounded corners and background colors weren't consistently applied in the Mass Mailing app's email templates. The fix adjusts table styling to ensure accurate preview and rendering of card elements, improving email design consistency.
Original PR description
**Steps to reproduce:** - Go to mass_mailing app - Add Columns block with multiple content size - Increase Round Corners (e.g. 20 px) - In "Vert. Alignment" field > Select the "Stretch to Equal…
**Steps to reproduce:**
- Go to mass_mailing app
- Add Columns block with multiple content size
- Increase Round Corners (e.g. 20 px)
- In "Vert. Alignment" field > Select the "Stretch to Equal Height" option
- Add color background for the columns
- Save the record and send test mail
- Round corners are not applied
- Background color doesn't expand to the bottom of the body
**Issue:**
Default table style used for the inline conversion of
`await toInline($(editableClone), { $iframe: $(iframe), wysiwyg: this.wysiwyg });` in `mass_mailing_html_field`,
has its 'border-collapse' attribute set to 'collapse' by default in `enforceTablesResponsivity`.
This attribute doesn't work with `border-radius` and the resulting display differs from the preview of the editor.
Relevant links:
https://stackoverflow.com/questions/628301/the-border-radius-property-and-border-collapsecollapse-dont-mix-how-can-i-use https://stackoverflow.com/questions/36035461/what-is-the-difference-between-border-collapse-collapse-and-border-spacing-0
**Fix:**
Use `'border-collapse': 'separate'` and `'border-spacing': 0` but this can
introduce border stacking inside the table element where the original collapse
was needed.
Add back the `overflow` inherited by the card attributes to ensure
inside border are visually properly contained inside the border (but not
sure as to why it was removed 4 years ago).
Also set the height of table sub-elements to `100%` to ensure background
property is properly applied on the whole card body.
opw-5218581
Forward-Port-Of: odoo/odoo#251863
Forward-Port-Of: odoo/odoo#242001This update fixes an issue where 'ship later' orders were incorrectly showing a zero total cost due to stock moves not yet being valued. The fix now uses the product's standard price when stock moves are unvalued, ensuring accurate order totals for FIFO/AVCO orders with a shipping date. This improves the reliability of order pricing.
Original PR description
When "ship later" is selected, stock moves are created at order time but not yet valued. This caused `_compute_total_cost` to set `total_cost = 0` for FIFO/AVCO order lines because `_get_price_unit()` returns 0 on unvalued moves, and the existing fallback to the refunded line's cost only covered the refund case. Fix by also falling back to `product.standard_price` when the move cost is zero, `shipping_date` is set, and the line is not a refund. opw-5997872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251799
This update fixes an issue where combo items weren't always printed to the preparation printers if their category didn't match the main combo product. Now, items are printed based on their own category, ensuring all combo components are correctly prepared for self-order orders. This improves the accuracy and efficiency of the POS system.
Original PR description
Previously, combo choice items with categories assigned to a preparation printer were skipped when their category differed from the combo parent product’s category. This commit ensures that items are printed to the preparation printer based on their own product category. Task: 5902389 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249859
This pull request addresses a minor technical issue in the German localization (l10n_de) of Odoo. Specifically, a problem with how tags were being defined in the account account tags data file was corrected. This ensures accurate reporting and categorization of financial transactions for German-speaking users.
Original PR description
Commit db0d499952192ede0def2a070e103ba67952387c inverted some tags which is wrong opw-5415426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250744
This update corrects a bug where tags in German financial reports were incorrectly sorted, preventing proper auto-completion functionality. The team has also improved testing to catch similar errors in the future. This ensures accurate reporting for our German-speaking customers.
Original PR description
Commit https://github.com/odoo/odoo/commit/db0d499952192ede0def2a070e103ba67952387c inverted some tags which is wrong Tags must be sorted for the auto complete to work properly Improving tests to catch more errors opw-5415426 Forward-Port-Of: odoo/enterprise#108848
This update removes a display field ('Visible Internally Only') from the customer rating form in the Helpdesk module. This field was no longer needed as customer ratings are no longer visible on the website. This change improves the user experience and simplifies the Helpdesk interface.
Original PR description
**Steps to reproduce:** - Open a Helpdesk ticket with a customer rating. - View the rating form. - Observe the field ‘Visible Internally Only’ still showing. **Issue:** - The field is displayed even though ratings are no longer shown on the website. **Reason:** - The field is now irrelevant but still present in the view. **Fix:** - Invisible the ‘Visible Internally Only’ field from the customer rating form in the affected version. **Task id - 5359052** Forward-Port-Of: odoo/enterprise#109287 Forward-Port-Of: odoo/enterprise#100686
This update fixes a technical problem that prevented Odoo from reliably sending messages to the Peppol network. Specifically, a backlog of messages caused a recurring cron job loop and token issues, leading to connection errors. This change ensures smoother and more consistent communication with the Peppol network, improving data synchronization.
Original PR description
Fix two issues observed on Odoo production. 1) When more than 50 messages from this odoo db/client are queued to be sent on peppol-ap, all client-side messages remain in `processing` If the send queue stays saturated, the retrigger logic repeatedly schedules the cron, causing an infinite `ir_cron_peppol_get_message_status` loop. 2) Each cron refreshes the authentication token, which allows concurrent threads to refresh it in parallel. Due to the `REPEATABLE READ` isolation level, a long-running cron may continue using the old token while another thread has already refreshed it. This leads to `invalid-signature` responses and incorrectly marks the connection as out of sync on one thread, even through the long-running transaction fails on trying to commit. Thus, simply flushing the cursor will block the transaction in such a situation no-task Forward-Port-Of: odoo/odoo#252177
This update ensures that One Stop Shop (OSS) invoices for intra-EU B2C sales in Italy comply with Italian Revenue Agency regulations. Previously, invoices were rejected due to the way foreign VAT was presented. Now, the system correctly generates invoices by separating VAT into distinct lines, meeting the required format for electronic invoicing.
Original PR description
This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate). Current behavior:…
This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate). Current behavior: Invoices for intra-EU B2C sales (OSS) are generated with a single line containing the foreign VAT rate. This is rejected or considered non-compliant by the SDI because foreign VAT cannot be typically exposed in the standard way for Italian electronic invoices. New behavior: The XML generation logic has been updated to follow the specific codification required for OSS operations: 1. Invoice Lines (`DettaglioLinee`): - The product line is reported with 0% VAT and Nature 'N7' (VAT paid in another EU member state). - A new, separate line is injected to represent the VAT amount, classified with Nature 'N2.2' (Non-taxable/Other). 2. Tax Summary (`DatiRiepilogo`): - The original foreign tax lines are excluded from the summary. - Synthetic summary lines are added for the 'N7' (Taxable Base) and 'N2.2' (VAT Amount) categories. Implementation details: - Added `_l10n_it_is_oss_tax` helper to identify OSS taxes. - Modified `_l10n_it_edi_get_line_values` to split OSS lines. - Modified `_l10n_it_edi_get_tax_values` to adjust the tax summary. task-4711509 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252216 Forward-Port-Of: odoo/odoo#243740
This update fixes a discrepancy in how inventory values are calculated. Previously, Odoo incorrectly assumed midnight when processing dates for inventory valuation, leading to inaccurate reports. This change ensures that inventory values are calculated through the end of the day, aligning with standard business practices and improving reporting accuracy.
Original PR description
### Problem: If `_compute_quantities` is called with only a date specified in `to_date` context (no timestamp), Odoo will assume midnight (00:00:00) instead of end of day (23:59:59). This contradicts logic in other places, such as `_compute_total_value`, which opts for the convention that "As of \<date>" means "through \<date>". ### Solution: We will run `_compute_quantities` with `to_date` at 23:59:59. ### Steps to replicate (Runbot 19): 1. Receive a valued and tracked product (you can make the impact more obvious by setting the cost very high) 2. Backdate the receipt to some day in the past using the method of your choice (inspector tool, server action) 3. Go to the Inventory Valuation report, set "As of" date to the backdated receipt date, note that the value of the validated receipt is not there 4. Set "As of" to the day AFTER the receipt date, note the value is now shown opw-5893999 Forward-Port-Of: odoo/odoo#251253
This update fixes an issue where changing the popup backdrop color or hiding/showing the popup would unexpectedly cause it to disappear. The fix ensures the history plugin correctly tracks backdrop changes, preventing these inconsistencies and improving popup stability. This resolves a reported bug impacting user experience.
Original PR description
Steps to reproduce in 18.4: - Add a popup on the page - Click on the popup - Change the backdrop color - Hide the popup by clicking on its entry in "Invisible Elements" - Undo - Redo - Bug: The popup disappears Steps to reproduce in 19.0: - Add a popup on the page - Click on the popup - Hover a color in the colorpicker of the backdrop option of the popup - Stop hovering the color - Bug: The popup disappears Forward-Port-Of: odoo/odoo#251849 Forward-Port-Of: odoo/odoo#244213
1 change
Resolved issues and error corrections
This update removes a display field ('Visible Internally Only') from the customer rating form in the Helpdesk module. This field was no longer needed as customer ratings are no longer visible on the website. This cleanup improves the user experience and reduces unnecessary complexity.
Original PR description
**Steps to reproduce:** - Open a Helpdesk ticket with a customer rating. - View the rating form. - Observe the field ‘Visible Internally Only’ still showing. **Issue:** - The field is displayed even though ratings are no longer shown on the website. **Reason:** - The field is now irrelevant but still present in the view. **Fix:** - Invisible the ‘Visible Internally Only’ field from the customer rating form in the affected version. **Task id - 5359052** Forward-Port-Of: odoo/enterprise#109287 Forward-Port-Of: odoo/enterprise#100686
1 change
Resolved issues and error corrections
This update fixes an issue where Romanian customers without a company registry were incorrectly assigned the default VAT scheme. The change removes a faulty condition, ensuring that customers without VAT receive the appropriate default VAT scheme as intended. This ensures accurate tax calculations for Romanian businesses.
Original PR description
Problem --------- In a recent fix, in the Tax Scheme customer node, the scheme type was recomputed correctly depending on the companyID node. However, during the fix, a condition was wrongly introduced. This will lead to some issue: when a customer has no VAT, he should be given the default VAT. However, due to condition, the customer gets given the Default VAT only when he does not have a vat NOR A COMPANY REGISTRY. Solution --------- Remove the condition no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252475
4 changes
Enhancements to existing features
This update enhances the accuracy of interest rate calculations for loans within the Enterprise module. Previously, interest rates were displayed with only two decimal places. Now, users can specify up to ten decimal places for greater precision, improving financial reporting and analysis.
Original PR description
Allowing more precision on the interest rate for loans. By default the display uses 2 decimals, but if a user decides to add more precision they can up to 10 decimals. task-5913175 Forward-Port-Of: odoo/enterprise#107163
Resolved issues and error corrections
This update resolves an issue preventing users with multiple companies from successfully setting up their Amazon accounts. The fix allows access to all company data during the onboarding process, eliminating a mismatch error. This ensures a smoother and more reliable experience for all users.
Original PR description
The onboarding return route is a website route with access restricted to the website company only. This causes an error when the company doesn't match the Amazon account being connected. This commit allows users to access all their companies during Amazon account setup to avoid this mismatch error. opw-5944078 Forward-Port-Of: odoo/enterprise#109590
This update resolves an issue where printing basic receipts would fail if the point-of-sale (POS) name exceeded a certain length. The fix ensures that receipt printing works correctly regardless of the POS name's length, preventing errors and ensuring accurate receipt generation. This improves the reliability of the POS system for Italian users.
Original PR description
When printing a basic receipt, if the pos name is too long a traceback will occurs when printing the basic receipt. Steps to reproduce: * Create a pos with a name of 46 character or more * Setup the italian fiscal printer * Enable Basic Receipt printing * Open point of sale * Create an order and validate it * Try "Print Basic receipt" Traceback: RangeError: Invalid count value: -15 at String.repeat () If the data being printed is longer than the maximum number of character in a line (MAX_CHARS = 46), paddingLeft becomes negative which cause an error in repeat(). [Similar solution](https://github.com/odoo/enterprise/blob/18.0/l10n_it_pos/static/src/app/fiscal_printer/commands/print_rec_message/print_rec_message.js#L35) [opw-5270697](https://www.odoo.com/odoo/project/49/tasks/5270697) Forward-Port-Of: odoo/enterprise#109527
This update fixes an issue where reconciling batch payments with bank statements would fail due to currency exchange rate discrepancies. The system now correctly handles changes in exchange rates, ensuring that bank reconciliations complete successfully. This improves the reliability of financial reporting.
Original PR description
…tion Currently, under certain conditions, reconciling a batch payment with a bank statement may not be possible as the system tries to create an unbalanced move. Steps to reproduce: - Have the main…
…tion Currently, under certain conditions, reconciling a batch payment with a bank statement may not be possible as the system tries to create an unbalanced move. Steps to reproduce: - Have the main company in USD and EUR as foreign currency - Have a bank journal with currency EUR (Bank EUR) - Create an xchange rate for today (1.1) - Make a Payment (EUR), it should not have an associated move - Put the payment in a batch - Update the exchange rate for today (1.2) - Create a Bank transaction in the journal Bank EUR matching the payment amount - Open the bank reconciliation screen and reconcile the transaction with the batch Expected result: Everything is reconciled. Actual result: User gets an error message saying that the account move is not balanced. Analysis: The issue occurs because the reconciled payment amount is converted to the company currency using the date provided in the payment. However the rate was changed in the meanwhile, so it does not match the amount that was used to create the exchange entry values. opw-5164405 Forward-Port-Of: odoo/enterprise#98495
5 changes
Enhancements to existing features
This update streamlines the process of setting up tests within Odoo, focusing on several core modules including accounting and payroll. By centralizing test setup, the team has improved the reliability and efficiency of our automated testing process, leading to more robust software.
Original PR description
Forward-Port-Of: odoo/enterprise#109679 Forward-Port-Of: odoo/enterprise#108739
This update enhances logging for transactions processed by the Codabox integration (l10n_be_codabox). These improved logs will assist the support team in quickly identifying and resolving any issues related to data synchronization. This proactive logging improvement reduces potential delays and improves overall system stability.
Original PR description
This commit will improve the logs of _l10n_be_codabox_fetch_coda_transactions to help the support team to debug possible problem. task-5436868 Forward-Port-Of: odoo/enterprise#109534 Forward-Port-Of: odoo/enterprise#107779
This update enhances the accuracy of loan interest rates within the Enterprise module. Users can now specify interest rates with up to 10 decimal places, providing greater flexibility and precision in financial calculations. This change improves reporting and ensures more accurate tracking of loan interest.
Original PR description
Allowing more precision on the interest rate for loans. By default the display uses 2 decimals, but if a user decides to add more precision they can up to 10 decimals. task-5913175 Forward-Port-Of: odoo/enterprise#107163
Resolved issues and error corrections
This update resolves an issue where commission reports were incorrectly calculating amounts due to how large numbers (bigints) were handled between Python and the JavaScript framework. By ensuring the full ID is always used, the system now accurately reflects commission amounts, preventing data conflicts and ensuring reliable reporting.
Original PR description
In commission report, we need unique ids for achievements and commissions. We avoid using row_number because it becomes really slow when the amount of records increases. That's why we need reliable unique ids, build from the account move line/sale order line/sale order log, user_id, commission rules. As it represents a lot of information stored inside a unique integer, bigint are necessary. It works great in python because int() can be used to handle bigint but JavaScript is not great with that. It will cast the value sent by the ORM silently and as a result, when the ORM is called back by the JS framework, it will pass a truncated id that either conflict with another record or may not exists (ids are generated using recipe). This commit ensure that the full id is always accessible and is used to browse records when the framework js contact methods. task-5973128 Forward-Port-Of: odoo/enterprise#109646 Forward-Port-Of: odoo/enterprise#108751
This update fixes an issue where the softphone displayed an incorrect format for keypad keys. The system now correctly handles key data, ensuring a cleaner and more accurate display of keys in the softphone interface. This improves the user experience and visual consistency.
Original PR description
Since [1] ([IMP] voip: fine-tune the PiP window), `keypadKeys` now returns objects (`{ key, letters, icon? }`) instead of plain strings.
`onClickKeypadKey` was still handling the payload like a string in part of the flow, which caused `[object Object]` displayed in the main softphone.
[1]: https://github.com/odoo/enterprise/commit/71ad3b98f25a4eb215d4aece9f1c4cb2f5ddcc765 changes
Resolved issues and error corrections
This update fixes a display issue where part-time flexible employees were showing incorrect total hours (based on full-time requirements) in their attendance schedules. The change ensures that the system now accurately reflects the employee's defined weekly hours (`hours_per_week`) when generating attendance intervals, improving accuracy and usability for flexible scheduling.
Original PR description
### Issue: When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.…
### Issue:
When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.
Steps to reproduce:
- Have an employee with a part-time flexible schedule
- `full_time_required_hours`: 40
- `hours_per_week`: 24
- `hours_per_day`: 8
- Go in Attendances
- Hover the employee
- It shows ...h/40h but it should show ...h/24h
Cause:
In `_attendance_intervals_batch()` we build theoretical attendances for flexible employees. Starting at the start of the week, we add an attendance of `hours_per_day` each day until we reached `full_time_required_hours`.
In the case above, we would return five attendances of 8h, ignoring `hours_per_week`.
Then `_get_attendance_intervals_days_data()` counts the hours to display them in the Gantt view.
Solution:
In `_attendance_intervals_batch()` we use `hours_per_week` instead of `full_time_required_hours` as the weekly limit of hours per week.
A lot of tests needed to be adapted, as they were specifying `full_time_required_hours` but not `hours_per_week` when creating calendars.
opw-5973117This update fixes an issue where marketing emails weren't correctly configured, ensuring the proper HTML content is generated. The change adds a dependency to the email field, making it required based on the email content, and improves the overall reliability of automated email campaigns. It also includes a minor adjustment to tour sequences to ensure proper form cleanup.
Original PR description
Prior to this commit, `body_html` was hard-coded as a dependency of the `mass_mailing_html_field`, and that dependency lacked the `required` attribute, which should depend on the value of `body_arch`. The dependency is now added in the related views, and the field is now generic. As HtmlField now mark the record `dirty` `onChange`, some tours should ensure that the form view is properly discarded before finishing. task-5976348
This update resolves an error that occurred in the Gantt view when grouping service projects by project. The issue stemmed from an outdated date parsing method. The fix utilizes a newer, compatible method to correctly handle dynamic dates, ensuring the Gantt view functions reliably.
Original PR description
### Issue: When in the Gantt view of service projects, grouping by project results in a traceback. ### Steps to reproduce: - Create another field service project - Create a task in the new project and add start and end dates - Go to Field service > my tasks > gantt view > group by project - Error with traceback `time data 'today' does not match format '%Y-%m-%d %H:%M:%S'` ### Cause: This [commit](https://github.com/odoo/odoo/commit/d1ea43f6721116914762ea323d8a5987f043e87f) added the possibility to use dynamic dates in domains. Then all domains were changed in 42b1fca8e127926a06f503d79c8baeddf7d5ae82 But `_expand_domain_dates()` is trying to parse the dates as if they were written in ISO format: https://github.com/odoo/enterprise/blob/be853cc1ee544dda580960d94417cfdff2c8a7db/project_enterprise/models/project_task.py#L626 ### Solution: We use the method `parse_date()`, which was added with dynamic dates, to parse them. opw-5955317
This update removes a display field ('Visible Internally Only') from the customer rating form in the Helpdesk module. This field was no longer needed as customer ratings are no longer visible on the website. This change improves the user experience and simplifies the Helpdesk interface.
Original PR description
**Steps to reproduce:** - Open a Helpdesk ticket with a customer rating. - View the rating form. - Observe the field ‘Visible Internally Only’ still showing. **Issue:** - The field is displayed even though ratings are no longer shown on the website. **Reason:** - The field is now irrelevant but still present in the view. **Fix:** - Invisible the ‘Visible Internally Only’ field from the customer rating form in the affected version. **Task id - 5359052** Forward-Port-Of: odoo/enterprise#109287 Forward-Port-Of: odoo/enterprise#100686
This update automatically removes related articles from the Knowledge app when an audit report is deleted. This prevents workspaces from becoming cluttered and ensures users only see relevant information. It improves the overall user experience and maintains a cleaner, more organized Knowledge environment.
Original PR description
When a user deletes an audit report, the articles linked to that report currently remain visible in the Knowledge app. This can lead to cluttered workspaces and confusion about which articles are still relevant. To keep workspaces clean, these linked articles will now be automatically moved to the trash when the audit report is deleted. Task-5902448
10 changes
New functionality added to Odoo
This update adds comprehensive tests to ensure the correct synchronization of Gelato products into Odoo and the seamless purchasing of Gelato products. These tests improve the reliability and stability of the Gelato integration, allowing for more accurate product listings and order processing.
Original PR description
Tests for synchronizing Gelato products with Odoo and buying Gelato products are added. task-4527206
Resolved issues and error corrections
This update corrects a bug where timesheets were being created for employees even when the associated public holiday didn't apply to their company. The change ensures that timesheets are only generated for employees within the companies where the public holiday is active, improving accuracy and reporting.
Original PR description
**Steps to reproduce** - Have 2 companies A and B - Use a single working schedule (needs to have no company on it) for both companies and their employees - Create a public holiday with company A, while having company B in the selected companies - There's a timesheet for the public holiday created for employees of company B, even though the public holiday will not apply for them. **Change** Only generate the timesheets for employees belonging to the companies of the public holidays. opw-5498462
This update resolves an issue where customers without a company registry were incorrectly assigned the default VAT instead of the standard VAT. The fix removes a redundant condition that caused this misbehavior, ensuring accurate VAT assignment for all Romanian customers.
Original PR description
Problem --------- In a recent fix, in the Tax Scheme customer node, the scheme type was recomputed correctly depending on the companyID node. However, during the fix, a condition was wrongly introduced. This will lead to some issue: when a customer has no VAT, he should be given the default VAT. However, due to condition, the customer gets given the Default VAT only when he does not have a vat NOR A COMPANY REGISTRY. Solution --------- Remove the condition no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that the analytic distribution set on a sale order is correctly transferred to the associated purchase order. Previously, the distribution wasn't being applied, leading to inaccurate cost tracking. This fix corrects a critical flow within the sales and purchase processes.
Original PR description
Steps to reproduce: - Enable analytic distribution in Accounting settings - Create a storable product "P1": - Routes: MTO + Buy - Vendor: add any supplier - Create a Sale Order: - Add 1 unit of P1 -…
Steps to reproduce: - Enable analytic distribution in Accounting settings - Create a storable product "P1": - Routes: MTO + Buy - Vendor: add any supplier - Create a Sale Order: - Add 1 unit of P1 - Set any analytic distribution - Confirm the Sale Order Result: A Purchase Order is created, but the analytic distribution is not propagated to the purchase order line. Problem: When the Sale Order is confirmed, `_action_launch_stock_rule()` is triggered. It creates and confirms the corresponding stock move with values from the sale order line. Since the product uses the MTO route, the procurement rule is executed. The rule prepares procurement values from the stock move, but the analytic distribution is not included in these values: https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L1539 Later, `_run_buy` is triggered. It uses the procurement values coming from the stock move to find an existing purchase order line candidate or to create a new one. Because the analytic distribution is missing from the values, the created (or matched) purchase order line does not contain the analytic distribution: https://github.com/odoo/odoo/blob/621a93b7b723999d943f1c4da78547763498c008/addons/purchase_stock/models/stock_rule.py#L113 Solution: Propagate the analytic distribution from the sale order line through the stock move so it can be included in the procurement values and correctly applied to the purchase order line. opw-5936971
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (2 installments per bill). It also resolves a bug where the 'group payment' button was incorrectly visible in certain scenarios. This ensures accurate payment tracking and a better user experience.
Original PR description
[FIX] account: right number of payments skipped in send wizard Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803
This update fixes an issue where the SEPA payment wizard incorrectly displayed the number of payments being skipped. Specifically, it now accurately reflects that only the first installment of each bill is being paid when using the SEPA payment method. Additionally, a visual bug related to the 'group payment' button has been resolved.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803
This update fixes an issue where new timesheets weren't correctly linking to the appropriate Service Offering Level (SOL) when using multi-company billing rates. Now, the system automatically selects the correct SOL based on the user's active company and linked employee, ensuring accurate time tracking and invoicing.
Original PR description
****Behavior:**** **Current:** In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific…
****Behavior:**** **Current:** In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific task, creating a new timesheet for the project does not set the correct SOL. This only happens if the sale is happening from a company that does not have an employee linked to the user. **Expected:** The new timesheet should be able to connect the current user to the related employee in the billing rates to find the right SOL. In the situation in which multiple companies have created an employee for the same user, and more than one of these has been linked to a SOL in the billing rates (unlikely workflow): We choose the SOL linked to the employee record created for the currently activated company, otherwise, we default to the first employee in the list. **Steps to reproduce:** - Be in a multicompany environment: company A and B - Create User with access to both but only one employee record for company A - Switch to company B - Create 2 services product, both creating a task in the same project. - Activate Billable Rate Indicators in the settings - Create a quote with both services and confirm - Go to the related project, and in the Invoicing tab, link employee from company A to SOL2 - As the user, check both companies but set company B as current active - Go to timesheet and create a new timesheet, when setting the project from the quote, you should see SOL1 by default, however we would want SOL2 as it was configured. opw-5159195
This update resolves an issue where an error related to E-waybills would incorrectly overwrite another error during the E-invoice process in Russia. The fix ensures that errors are handled properly, preventing data inconsistencies and improving the reliability of invoice generation. This update is a critical fix for accurate tax reporting.
Original PR description
If user do E-invoice and after E-waybill then error of E-waybill is overwrite by by one wrong condition So in this commit fix that wrong condition --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252251
This update resolves an issue where the batch view in stock_picking_batch displayed multiple 'Validate' buttons, causing confusion. The fix ensures that only one 'Validate' button is visible, streamlining the batch creation process and improving user experience. This change corrects a visual inconsistency.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871
This update resolves an issue where the batch view in the Enterprise module incorrectly displayed multiple 'Validate' buttons. The fix ensures that only one 'Validate' button is visible, streamlining the batch creation process and improving user experience. This change corrects a visual inconsistency.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871
1 change
Resolved issues and error corrections
This update resolves an issue where an incorrect condition was overwriting error messages related to E-waybills after an E-invoice was processed. The fix ensures that E-waybill errors are handled correctly, preventing data inconsistencies and improving the invoicing process for users in Russia. This change was made as part of a standard bug fix.
Original PR description
If user do E-invoice and after E-waybill then error of E-waybill is overwrite by by one wrong condition So in this commit fix that wrong condition --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252251