Monday, March 23, 2026
62 changes · saas-19.2
Resolved issues and error corrections
This update resolves a technical issue that prevented the demo data from correctly generating time off allocations when using a future date (2027-01-01) for faketime testing. Updating the demo data ensures the system accurately reflects leave allocation rules, particularly for contracts starting January 1st, and avoids errors during testing.
Original PR description
Issue: The Anita Oliver contract starts on %Y-01-01, so her leave allocation begins from that date. When running with faketime set to 2027-01-01, the system attempts to create leave for the previous month, which results in an error stating that there is no allocation for that time off. Fix: Update the demo data to create the leave and payslip for the first month of the year. This prevents failures when using faketime and ensures it works correctly for real usage of `time off to defer`. task-6026690 Forward-Port-Of: odoo/enterprise#110293
This update resolves a technical issue preventing the tour from correctly displaying the checkout address within the Brazilian localization (l10n_br) module. The fix addresses race conditions introduced by a recent community update to the select menu, ensuring the tour functions as expected.
Original PR description
Because of the community PR that changes the DOM of the select menu, the tour in this commit crashed. This commit adapts the tour and fixes it as races conditions were still present part-of-task-5935511 Forward-Port-Of: odoo/enterprise#111248
This update fixes an issue where the Report Editor in web_studio wouldn't automatically focus on the editable field after deleting a row or column. This change ensures a smoother user experience by immediately placing the user in the editable area, preventing frustration and improving efficiency. The fix was part of a larger community contribution.
Original PR description
PR [1] ensures that editable is focused after deleting row or column from table menu by preventing default while clicking on table menu button. This change causes test [2] to fail if a table menu test runs beforehand, due to browser’s native focus behavior. This commit ensures that editable is focused whenever clicking on t-field. [1]: https://github.com/odoo/odoo/pull/249256 [2]: https://github.com/odoo/enterprise/blob/19.0/web_studio/static/tests/client_action/report_editor/report_editor_dom_edition.test.js#L456-L478 Community PR: https://github.com/odoo/odoo/pull/249256 task-5725593 Forward-Port-Of: odoo/enterprise#111154 Forward-Port-Of: odoo/enterprise#109034
This update resolves an error that occurred when activating the 'hr_expense_stripe' module with unsupported currencies (like INR). The fix prevents the creation of a problematic journal, ensuring the invoicing dashboard can be opened without errors. It now defaults to the company's currency for new databases.
Original PR description
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. Steps to…
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. Steps to reproduce: (19.0) - Install `account` module - Set Company currency to `INR` and deactivate `USD` in currencies. - Install `hr_expense_stripe` - Create New company > Set `Country` and `Currency` (eg: India and INR) > Switch to New company > Open `Invoicing` you will get the error. Steps to reproduce: (saas-19.1) - Install `account` module - Set Company currency to `INR` and deactivate `USD` in currencies. - Install `hr_expense_stripe` > Open `Invoicing` you will get the error. Traceback: `ValueError: Expected singleton: res.currency()` In this [PR], the behavior is such that if `company.stripe_currency_id` is not set, we do not create the "Stripe Issuing". In 19.0, `@template` was executed after the post-init hook, and we were preventing the creation of the [journal] at that stage. However, when a new company is created, the template data is automatically loaded for companies with a matching chart of accounts. As a result, the `stripe_issuing_journal` is created, which leads to the error. However, in saas-19.1, due to recent improvements in a [commit], the `@template` will now loads data for companies without post init hook. As a result, the `stripe_issuing_journal` is being created, and we are encountering an error. Solution: - The`Stripe Issuing` journal will no longer be created on installing the module. - For existing databases, we will use the company currency as a fallback value to ensure that a valid currency is applied. [PR]: https://github.com/odoo/enterprise/pull/96271 [journal]: https://github.com/odoo/enterprise/blob/fea009f98885a97439edfea75376b7323c8c9a03/hr_expense_stripe/models/res_company.py#L186-L187 [commit]: https://github.com/odoo/odoo/pull/228950/changes/21fd14ed5e8bdd2cf203d466069437a62a87f2bd sentry-7284934493 Forward-Port-Of: odoo/enterprise#108436
This update resolves a technical issue related to how Odoo handles geographic data (topoJSON) within its spreadsheet charts. The fix ensures that these charts display correctly and reliably, improving the accuracy of visual reports. This change primarily impacts the Enterprise edition's chart functionality.
Original PR description
test adaptation Counterpart of github.com/odoo/odoo/pull/248847 Task-5224009 Forward-Port-Of: odoo/enterprise#107912
This update resolves an issue where the topbar menu wasn't correctly updated when a menu was opened using the AI Agent. The fix ensures that the topbar menu accurately reflects the currently active menu after an AI Agent interaction, improving the user experience. This change was driven by a bug fix (Task-6017607).
Original PR description
Purpose: -------- When a menu (view) was opened through an AI Agent, the menu in the topbar was not updated. This commit fixes this behaviour by setting the menu when the menu's action has been loaded Task-6017607 Forward-Port-Of: odoo/enterprise#109929
This update automatically calculates and transmits the necessary commission deductions for Swiss payroll (ELM) based on employee data. This ensures accurate tax reporting and compliance with Swiss regulations, streamlining the payroll process. The change corrects a previous issue related to commission calculations.
Original PR description
task-6050810 Forward-Port-Of: odoo/enterprise#111143
This update resolves a problem where the website's tour process was delayed due to timing issues, specifically with loading translations. The change ensures the tour starts correctly, preventing delays and improving the user experience. This was caused by recent changes in Chrome versions.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/enterprise#111013 Forward-Port-Of: odoo/enterprise#110648
This update resolves a test issue where simultaneous data synchronization in the Point of Sale (POS) tax module caused errors. The fix ensures that backend processes complete before the test continues, improving test reliability and preventing disruptions. This enhances the overall stability of the POS tax functionality.
Original PR description
In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps. runbot-error: 238871, 238872 Forward-Port-Of: odoo/enterprise#110341
This update resolves an issue where the map view in the "My Dashboard" sometimes collapsed due to conflicting height settings. The fix removes overly restrictive height rules and adds a minimum height to the map, ensuring it always displays correctly regardless of the number of records shown.
Original PR description
This commit fixes rendering height issues when the map view is displayed inside "My Dashboard". * Removed `height: 100%` from the map and pin list containers. This conflicting rule interfered with the flexbox layout, often causing the map to collapse entirely since it couldn't compute its own height. * Added a `min-height` to the map renderer. This ensures the map always occupies a reasonable amount of space in the dashboard, even when there are few or no records to display. task-6022958 Forward-Port-Of: odoo/enterprise#111195 Forward-Port-Of: odoo/enterprise#110790
This update corrects a bug where changes to view ordering within the Documents module's studio interface weren't consistently applied. The fix involved updating the default order setting to be applied correctly through the designated attribute on the relational model, ensuring view ordering changes are now reliably saved and reflected.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024 Forward-Port-Of: odoo/enterprise#111395 Forward-Port-Of: odoo/enterprise#111091
This update fixes a visual inconsistency in accounting reports. Previously, the company header was grayed out in dark mode. Now, it uses a standard muted color, ensuring a consistent and professional appearance across all Odoo Enterprise environments.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#111509 Forward-Port-Of: odoo/enterprise#110108
This update resolves an issue where long tax amounts in invoices were causing display problems. The fix ensures that tax totals are correctly rendered, regardless of the numerical size, improving the clarity and accuracy of Ke revenue reports. This enhancement ensures consistent and reliable reporting for Kenyan businesses.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#111003 Forward-Port-Of: odoo/enterprise#100319
A technical issue preventing the generation of the Trial Balance report PDF has been resolved. The update corrects a formatting error in the report template, ensuring the PDF can now be successfully printed without errors. This improves the reliability of a key financial reporting tool.
Original PR description
Printing the PDF of the Trial Balance report raises a traceback. Steps to reproduce the error: - Install ``Accounting`` module - Go to Accounting > Reporting > Trial Balance > Click PDF Traceback: ```py AttributeError: 'AccountReportLineData' object has no attribute 'get' ``` https://github.com/odoo/enterprise/blob/ee5be988fd57b9b23265875fec7b42f2a761144f/account_reports/data/trial_balance_template.xml#L28 After Commit [1], line is ``AccountReportLineData`` object instead of disctionary. As a result, accessing line values using ``line.get(...)`` causes the traceback. [1]: https://github.com/odoo/enterprise/commit/6608d5c21a7fb9d57786c2a7618b878e244bd420 sentry-7323693096
This update resolves a technical error that prevented invoices with the ICBPER tax code in Peru from generating correctly. The fix adjusts a configuration setting to avoid a data structure mismatch, ensuring invoices process smoothly and accurately. This improves the reliability of invoice generation for Peruvian clients.
Original PR description
**Steps to reproduce:** 1. Install module `l10n_pe_edi`. 2. Switch company to PE. 3. Create a tax: - Name: ICBPER - Amount type: Fixed - Code: ICBPER - Amount: 0.5(e.g.) - Set the tax group to ICBPER…
**Steps to reproduce:**
1. Install module `l10n_pe_edi`.
2. Switch company to PE.
3. Create a tax:
- Name: ICBPER
- Amount type: Fixed
- Code: ICBPER
- Amount: 0.5(e.g.)
- Set the tax group to ICBPER (In Advance Option)
4. Create a invoice and add a product with ICBPER tax.
5. Post the invoice and click "Process Now" (at header).
**Issue:**
Processing the invoice raises:
AttributeError: 'dict' object has no attribute '_get_downpayment_lines'
**Cause:**
When `fixed_taxes_as_allowance_charges` is True, `_setup_base_lines()` calls `_turn_emptying_taxes_as_new_base_lines()`, which splits fixed taxes (e.g., ICBPER) into separate base lines.
During this process, `base_line['record']` is no longer the original `account.move.line` record. Instead, it becomes a dictionary containing record under `base_line['record']['record']`.
- With the flag enabled: `base_line['record']` -> dict `line._get_downpayment_lines()` -> AttributeError
- With the flag disabled: `base_line['record']` -> `account.move.line``line._get_downpayment_lines()` -> works correctly
The Peru EDI implementation directly accesses `base_line['record']` expecting an `account.move.line`. The the nested dict structure causes the crash during file generation.
**Solution:**
Override `_add_invoice_config_vals()` to explicitly set `fixed_taxes_as_allowance_charges = False`
- Add test to ensure invoices with ICBPER fixed taxes generate XML without error
**opw-5809939**
Forward-Port-Of: odoo/enterprise#108638This update resolves several issues impacting the Field Service planning feature, specifically related to shift generation, data handling, and user interface display. The changes ensure accurate state management during shift duplication and improve the overall usability of the planning tools.
Original PR description
## [FIX] planning_field_service*,worksheet: fixes follow-up This commit fixes and improves field service feature in planning to be sure to not have any regression compared to the previous field…
## [FIX] planning_field_service*,worksheet: fixes follow-up This commit fixes and improves field service feature in planning to be sure to not have any regression compared to the previous field service app. In detail, this commit will: - better handle SOL generation - fix buttons visibility, display name, multi-company issues - fix mix up demo and data - auto install when sale timesheet and field service - display the first slot for today in the stat button - handle multi-company issue in slot conflicts Make partner phone readonly if no Contact access. Hide the Serial/Lot products from the shift catalog if the user has no inventory access - display view itinerary label in mobile - set role in field service product - fix the domain of SO stat buttons related to shifts - fix the default groups of "Planning By ..."" actions. - use a custom search view for 'resource_ids' in kanban of shifts - ask to switch in employee portal - hide by default some fields in list view of shift - avoid recomputing when a worksheet property changed - display message to design worksheet in desktop only - display plan intervention in ticket - recompute allocated hours when break time changed - rename Publish & send button into Publish in form view of planning.slot model - display full form in my planning only ## [FIX] planning: manage state in copy_data Before this commit, when the shift is duplicated, the state is not reset as expected. This commit sets copy=False on state field of planning.slot model, to handle that in copy_data when the shift is splitted because in that case we want to keep the state instead of resetting it. ## [FIX] planning: display notification error when save as template a template Before this commit, since the Save as template button is in the cog menu, it is still displayed even if shift has already generated a shift template. This commit will display a notification in the action of that button when there is already a template linked to that shift. ## [FIX] planning: display planned dates in display_name when empty Before this commit, the display_name of a shift could be empty and displays "Unamed" in the breadcrumb due to project, task, customer and role can be unset on the shift. This commit will display the planned dates of shift when the other fields used in the compute of display name are unset. However, the planned dates are not displayed in the display name if the view is gantt or calendar because the planned dates are already displayed and would be redundant. ## [FIX] worksheet: hide section when separator is folded Before this commit, when the definition of a worksheet defines 2 sections folded by default with some properties inside of each one and the worksheet template is used for a shift, if the user just unfolds one section to fill in just this one and lets the other section unfolded, then the properties in the both sections are displayed in the portal of the shift even if the second section is folded. The reason is because the value of the second separator is not in the properties of the shift because it is untouched. This commit checks if the separator is by default folded if its value is not in the properties of the shift. task-6020304 Co-Authored: Xavier Bol (xbo) <xbo@odoo.com>
This update enhances the payroll system by expanding worker code searches to include DMFA and egov3 codes, in addition to display names. This ensures more accurate and complete worker code identification, improving payroll processing efficiency and data accuracy.
Original PR description
before when searching for worker code it only used display name. now it uses dmfa, egov3 codes. Task#6020172
This update resolves a technical issue that could cause errors when importing bank statements with multiple journals using different currencies. The fix prevents a redundant process from triggering a singleton error, ensuring smoother and more reliable CODA import for businesses operating with multiple currencies.
Original PR description
When having multiple journals with the same IBAN, but different currencies, we could have a singleton error if they are not all configured the same (besides the currency). This happens in the cron that fetches new CODAs as we first fetch all CODAs. Then, for each, we have to dispatch it in the right journal. To do so, we rely on `_parse_bank_statement_file` which is called on `self`, which itself calls `_get_coda_final_statements` that triggers the singleton error. However, at this point, we don't care about calling `_get_coda_final_statements` since we only want to retrieve the IBAN and the currency of the CODA, we don't care about the other details. Thus, the solution here is to ignore this call if we don't need it while just retrieveing the necessary info to match a journal before even creating the statements. opw-5723017 opw-6036909 Forward-Port-Of: odoo/enterprise#111361 Forward-Port-Of: odoo/enterprise#111101
This update corrects a visual discrepancy between how the AI livechat snippet is displayed in the editor and how it appears to users. The fix ensures the snippet's appearance matches the real-time experience, resolving a rendering problem caused by mismatched code structures. This improves the overall user experience for AI livechat setup.
Original PR description
Scenario: - add ai livechat snippet block - switch to mobile - enable "Fallback Button" - save Result: the rendering is different between edition and real usage of AI livechat snippet. Cause: structure and classes don't match Fix: make the structure and classes match. opw-5458575 pr note: I copied `ai_website_livechat.AILivechatComponent` in `ai_website_livechat.s_ai_livechat_edit` but it might make more sense to just render the owl widget with a class that neuter the AI (this way we don't need to update both template at each change) Forward-Port-Of: odoo/enterprise#109569
This update clarifies potential errors (code 9004) that users might encounter when running the Odoo Instagram module. The change provides a helpful explanation to assist users in troubleshooting without needing to contact support. This improves the overall stability and usability of the Instagram integration.
Original PR description
Purpose ======= Explain the possible errors for the code 9004, to help users debugging their Odoo servers without creating a ticket. Task-5972197 Forward-Port-Of: odoo/enterprise#110571 Forward-Port-Of: odoo/enterprise#109319
This update resolves a problem where reports with annotations were failing to export correctly. The previous filtering process was redundant, and this change removes unnecessary date filtering, ensuring reports with annotations now export reliably. This improves the balance sheet report generation process.
Original PR description
[FIX] account_report: Unable to export Report with Annotations Following changes to the date filter in https://github.com/odoo/enterprise/pull/98695, the date options can be missing a date_from (For example, when using period type: "today"). The date were used to filter on the annotations to display during the period of the report. However, we already filter on those date when generating the annotations so this was redondant and can be safely removed. To reproduce: - Open the Balance sheet - Open the chatter of any account and post a message - Click on the "PDF" button to export the report
This update fixes a potential issue where payroll calculations were being applied to outdated payslips, which could have impacted data accuracy. The change now limits these calculations to ongoing payslips, ensuring more precise and reliable payroll processing. This improves the overall stability and accuracy of the HR module.
Original PR description
Before this commit, `_compute_basic_net` was not limited to specific payslips, potentially affecting thousands of records and even more of `hr.payslip.line` records. This commit restricts the compute to ongoing payslips. task-6022499 Forward-Port-Of: odoo/enterprise#111219 Forward-Port-Of: odoo/enterprise#110069
This update fixes an issue where project timesheets didn't accurately reflect changes in manufacturing employees. The fix automatically updates the AAL (analytic accounting line) associated with the work center when an employee is switched, ensuring accurate timesheet calculations and reporting. This improves the reliability of project cost tracking.
Original PR description
### Steps to reproduce: - Create an MTO product and another Service product that create a project and task - Create a quotation with both products - Create two employees with different hourly cost - Go to Manufacturing order - Configure an employee to manufacture the product at a work station. - Observe the project dashboard - Go back to the MO and change the employee on the work station - Notice the project dashboard Timesheets section doesn't have any change on the amount ### Cause: This is happening because when changing the employee we don't modify anything in the AAL linked to the work station. As we only modify the AAL when the duration change. ### Fix: We call _create_analytic_entry when we change the employee on the work station to change the amount and the employee_id for the AAL. opw-5939321 Forward-Port-Of: odoo/enterprise#111040 Forward-Port-Of: odoo/enterprise#109695
This update fixes a usability issue on mobile devices where a key button for loan calculations was hidden within a dropdown. The change ensures a smoother, more intuitive experience when creating new loans on smartphones and tablets, allowing users to easily access necessary features.
Original PR description
Forward-Port-Of: odoo/enterprise#110931 Forward-Port-Of: odoo/enterprise#110120
This update adjusts how Odoo refreshes its GST tokens, moving from automated scheduling to manual triggering. This change ensures compliance and reduces the risk associated with automatic token updates. The process is now controlled by specific actions within the system.
Original PR description
With this PR, the GST token refresh cron interval is updated from 5 hours to 9999 months to effectively disable automatic execution. The cron will instead be triggered manually from `validate_otp` and `_cron_refresh_gst_token` based on the token expiration time. Forward-Port-Of: odoo/enterprise#109937
This update fixes an issue where portal users weren't able to view timesheets linked to projects with 'Invited internal and portal users' visibility. The change expanded the domain to include both 'portal' and 'invited_users' visibility options, ensuring portal users can access timesheets as intended.
Original PR description
Steps to reproduce: - Create Project A with visibility set to `Invited internal and portal users.` - Create a Helpdesk Team and assign Project A to it. - Create a helpdesk ticket. - Log a timesheet…
Steps to reproduce:
- Create Project A with visibility set to `Invited internal and portal users.`
- Create a Helpdesk Team and assign Project A to it.
- Create a helpdesk ticket.
- Log a timesheet on the ticket and share the ticket with the portal user.
- Log in as the portal user and check the timesheet.
- Observe that the timesheet is not visible to the portal user.
Cause:
- After introducing the `invited_users` option in `privacy_visibility`, the portal domain in `_timesheet_in_helpdesk_get_portal_domain` was not updated.
- The domain was still defined as: `('project_id.privacy_visibility', '=', 'portal')`
- As a result, timesheets linked to projects with visibility set to “Invited internal and portal users” were excluded from the portal user’s view.
Solution
Update the domain to include both visibility options: `('project_id.privacy_visibility', 'in', ['portal', 'invited_users'])`
- This ensures timesheets are visible to portal users when the project visibility is either portal or invited_users.
task-5924243
Forward-Port-Of: odoo/enterprise#111548
Forward-Port-Of: odoo/enterprise#107800This update ensures the 'To-Do' feature within Odoo Enterprise works reliably. Previously, uninstalling the 'To-Do' module could cause issues, as the feature remained active. This change guarantees that 'To-Do' is properly installed, resolving potential problems for users.
Original PR description
This commit backports the `project_enterprise_hr_todo` bridge module that ensures that `project-todo` is correctly installed in order to use the todo mail alias feature. Before, this requirement was not enforced so anyone uninstalling To-Do could experience some issue, as the feature would still be part the `project_enterprise_hr` module, even without `project_todo` installed. Forward-Port-Of: odoo/enterprise#109194
This update resolves an issue where payrun creation failed for employees with contracts starting mid-period. The fix ensures the system correctly handles contract start dates, preventing errors and allowing accurate payroll processing. This improves the reliability of pay runs for new hires.
Original PR description
An error is thrown when an employee's contract starts mid-period. ```py Invalid Operation Wrong python code defined for: - Employee: Cesar Osbaldo Cruz Solorzano - Version: False - Payslip: Payslip -…
An error is thrown when an employee's contract starts mid-period.
```py
Invalid Operation
Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Payslip - Cesar Osbaldo Cruz Solorzano - 01/16/2026 - 01/31/2026
- Salary rule: Integrated Daily Wage (Base) (INT_DAY_WAGE_BASE)
- Error: AttributeError("'bool' object has no attribute 'year'") while evaluating
'\nresult = round(payslip.l10n_mx_integration_factor * payslip.l10n_mx_daily_salary, 4)\n
```
Steps to reproduce:
1. Install `l10n_mx_hr_payroll` modules
2. Switch to ESCUELA KEMPER URGATE company
3. Go to Employees and open Cesar Osbaldo Cruz Solorzano
4. Go to Payroll tab, change the start date of contract to 01/10/2026 and save
5. Go to Payroll > Payslips > Payslips and create a new pay run
6. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and Period '01/01/2026 -> 01/31/2026'
7. Click on Continue, select Cesar and click on Select
8. An error is thrown
Problem:
In `_compute_integration_factor` method, `_get_first_contract_date` is called with context `before_date`, it returns `False` as the contract starts after the payslip period. This causes an error when trying to access the `year` field of `start_date`.
Solution:
Add a fallback to call `_get_first_contract_date` without context in case the first call returns `False`.
target: saas-18.4
task-6034836
Forward-Port-Of: odoo/enterprise#111007
Forward-Port-Of: odoo/enterprise#110568This update corrects a problem where appraisal dates weren't being calculated correctly due to a timing issue in the testing process. The fix ensures that appraisal dates are accurately determined based on company settings related to appraisal plans, improving the reliability of employee appraisal scheduling.
Original PR description
Issue: The computation of the next appraisal date for employees depends on setting the appraisal plan for a company or changing the company's settings for `duration_after_recruitment`, `duration_first_appraisal`, `duration_next_appraisal`. Fix: Moving the test employee creation after configuration of the company settings for the appraisal plan. task-6050719 Forward-Port-Of: odoo/enterprise#111345 Forward-Port-Of: odoo/enterprise#111265
This update resolves issues where invoices with global discounts or down payments were incorrectly sending negative values to the Sinvoice system, causing errors. The fix now properly handles these scenarios and includes support for uploading note lines on invoices, ensuring accurate data transmission for Vietnamese tax reporting.
Original PR description
Previously, the invoice logic did not properly handle the following scenarios: - Global discount: when a global discount was applied, negative values were sent to Sinvoice, resulting in a BAD_REQUEST_ITEM_VALUES_NEGATIVE error. - Down payment: when an invoice included a down payment to deduct the amount, negative values were sent to Sinvoice, triggering the same BAD_REQUEST_ITEM_VALUES_NEGATIVE error. - Note lines: note lines on the invoice were not being uploaded/included in the invoice submission. This commit fixes the handling of global discounts and down payments by ensuring negative values are properly transformed before being sent to Sinvoice, and adds support for uploading note lines in the invoice. task-5875158 Forward-Port-Of: odoo/odoo#254796 Forward-Port-Of: odoo/odoo#251913
This update ensures that manufacturing orders are created separately for MTO products that share components. Previously, only one MO was generated, leading to tracking issues. Now, each shared component will have its own dedicated manufacturing order, improving inventory accuracy and production management.
Original PR description
Currently, when a user creates a Sale Order for MTO products that share the same component (which itself has a BOM), the system does not create a separate child MO for each manufacturing order. ##…
Currently, when a user creates a Sale Order for MTO products that share the same component (which itself has a BOM), the system does not create a separate child MO for each manufacturing order. ## Steps to produce: - Install Sales and Manufacturing - Go to Settings and turn on Replenish on Order (MTO). - Create products 'Wooden Arrow' and 'Wooden Rod' with a BOM that includes: - 'Stick', which itself has a BOM with 'Raw stick'. - On each product page, go to Inventory and enable the MTO route, except for 'Raw Stick' . - Create a Sale Order for Wooden Arrow and Wooden Rod for Customer 'Administrator'. - Confirm the Sale Order. - Go to Manufacturing > Open and check both Manufacturing Orders. ## Observed Behavior: Currently, the manufacturing order for 'Wooden Arrow' has a child MO, but the order for 'Wooden Rod' does not. The child MO under 'Wooden Arrow' produces two sticks at once. However, each manufacturing order should have its own separate child MO so that every item is produced and tracked individually. ## Root cause: The issue happens because when a Sale Order is confirmed, [_run_manufacture](https://github.com/odoo/odoo/blob/7c7c6663e28974834d1569b27605f6ce400c7b16/addons/mrp/models/stock_rule.py#L81-L120) is called. This method creates a new MO or updates an existing one based on the domain returned by `_make_mo_get_domain` [1]. For 'Wooden Arrow' and 'Wooden Rod; new MOs are created because no existing MO matches their BOM ID, product ID, or reference. They are added to `new_productions_values_by_company` [2], which is then used to create the MOs [3]. When `_run_manufacture` runs for 'Stick', it is triggered twice since both MOs require it as a component. The first time, no MO matches the domain, so a new one is created. The second time, the domain matches the existing MO (same BOM ID and product ID), so that MO is updated instead [4]. Because of this, `new_productions_values_by_company` is not filled again, and no second child MO is created. [1]- https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L146-L165 [2]- https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L98-L103 [3]- https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L113-L115 [4]- https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/mrp/models/stock_rule.py#L105-L110 ## Solution: To resolve this issue, the domain has been tightened to include the parent production group ID. Since the parent MO’s group ID is passed through the procurement variable when `_run_manufacture` is executed for its component products, this group ID can be used to ensure the correct MO is matched. **Why modify the existing test case?:** With this change, in the `test_sale_mrp_pickings` test case, a new child MO for 'Stick' is created under the MO for 'Arrow' instead of modifying another parent MO for 'Stick'. The test case has been updated accordingly. (Confirmed the new behavior with CRL and TAGO) opw-5480133 Forward-Port-Of: odoo/odoo#248229
This update fixes an issue where kit products in Point of Sale orders were incorrectly displaying a total cost of $0 and inaccurate margin calculations. The fix ensures that the total cost and margin are accurately computed for kit-type products, providing reliable pricing information for these items.
Original PR description
Steps to reproduce: = - Create a product with type = Goods and Track Inventory by Quantity - Go to product category > inventory valuation > costing method -> FIFO - Create a BOM for the product with BOM Type = Kit. - Create and validate a POS order. - Open the order in the backend. Issue: = - The total cost was shown as 0.0 for kit products. Also, the margin amount and margin percentage were incorrect. Fix: = - Ensure that the total cost and margin are correctly computed for kit-type products in POS orders. task-5924559 Forward-Port-Of: odoo/odoo#248137
This update fixes an issue where the phone number input field on mobile devices was difficult to edit due to overlapping buttons. The fix hides the text labels from the utility buttons, allowing the input field to take up the full screen width and improving the user experience. This ensures users can easily and accurately enter phone numbers on their mobile devices.
Original PR description
Steps to reproduce: 1. Install `contacts` 2. Create an individual contact with a phone number 3. Try to edit the phone number on the mobile Issue: - Unable to edit in mobile view Cause: - On mobile…
Steps to reproduce:
1. Install `contacts`
2. Create an individual contact with a phone number
3. Try to edit the phone number on the mobile
Issue:
- Unable to edit in mobile view
Cause:
- On mobile devices, the utility buttons (Call, SMS, WhatsApp) inside the phone widget consume significant horizontal space. Due to the flex layout, this forces the actual phone input field to shrink too much, making it hard/impossible to view or edit the number.
Solution:
- Hide the text labels of the utility buttons to save space, showing only the icons
- make input's width 100% on mobile screens in partner form
<table>
<thead>
<tr>
<th>Before</th>
<th>After</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">
<img
src="https://github.com/user-attachments/assets/a620d417-119e-4e28-a62b-f63031e72598"
alt="Before"
width="500"
/>
</td>
<td align="center">
<img width="500" height="354" alt="image" src="https://github.com/user-attachments/assets/6adc4c77-767d-491d-a468-8463c0f77666" />
</td>
</tr>
</tbody>
</table>
opw-5489021
Forward-Port-Of: odoo/odoo#250256
Forward-Port-Of: odoo/odoo#246295This update fixes an issue where consolidated POS invoices were incorrectly showing a zero payable amount. MyInvois requires the total invoice amount to be accurately reflected, regardless of prior payments. This change ensures the payable amount aligns with MyInvois API requirements, resolving a compatibility problem.
Original PR description
For POS consolidated invoices, the PrePayment Amount was mapped to the payment linked to the document. This incorrectly decreased the Total Amount Payable to 0, since POS orders are already paid at the counter. MyInvois tax officer and helpdesk requires that the Total Amount Payable (cbc:PayableAmount) to reflect the total amount of the issued e-document , regardless of prior payments. This commit forces the PaidAmount to 0 for consolidated documents, ensuring the PayableAmount correctly matches the TaxInclusiveAmount as expected by the MyInvois API. task-[6021698](https://www.odoo.com/odoo/all-tasks/6021698) Forward-Port-Of: odoo/odoo#254183 Forward-Port-Of: odoo/odoo#253499
This update resolves a bug in the demo data for our holiday system. When simulating future dates (faketime), the system incorrectly generated errors related to leave allocations. Updating the demo data ensures accurate leave calculations, particularly when using future date simulations, and prevents errors in real-world usage of the 'time off to defer' feature.
Original PR description
Issue: The Anita Oliver contract starts on %Y-01-01, so her leave allocation begins from that date. When running with faketime set to 2027-01-01, the system attempts to create leave for the previous month, which results in an error stating that there is no allocation for that time off. Fix: Update the demo data to create the leave and payslip for the first month of the year. This prevents failures when using faketime and ensures it works correctly for real usage of `time off to defer`. task-6026690 Forward-Port-Of: odoo/odoo#253295
This update addresses a visual issue where blank space appeared in activity cards after a description was cleared. The fix ensures that the activity note is only displayed when there's actual content, improving the overall user experience and preventing unnecessary blank areas in the interface. This change was part of a larger effort to streamline the Odoo interface.
Original PR description
**Description of the issue/feature this PR addresses:** When an activity description is cleared, the stored value may still contain empty HTML content. The UI was still rendering this as a note,…
**Description of the issue/feature this PR addresses:** When an activity description is cleared, the stored value may still contain empty HTML content. The UI was still rendering this as a note, resulting in unnecessary blank space in the activity card. **Current behavior before PR:** Even when the activity description is cleared and contains only empty HTML, the activity note container is still rendered, leaving visible empty space in the UI. **Desired behavior after PR is merged:** The activity note is rendered only when it contains meaningful content. Empty HTML descriptions are ignored, preventing blank space from appearing in the activity card UI. Before <img width="445" height="84" alt="image" src="https://github.com/user-attachments/assets/f6648bb0-78d9-4063-a347-fe664370106e" /> After <img width="459" height="72" alt="image" src="https://github.com/user-attachments/assets/84c2063a-7c68-4dfe-b729-566ca4b5dcd1" /> task-[4752613](https://www.odoo.com/odoo/project/1519/tasks/4752613) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254936 Forward-Port-Of: odoo/odoo#252139
This update corrects a map data issue that was preventing the accurate display of Russia on the Asia map. It also adds a new Oceania map, ensuring a more complete and accurate geographical representation for our users. This enhancement improves the overall visual experience and data accuracy within the spreadsheet feature.
Original PR description
- Fix Asia map (russia was missing) - Added Oceania map Task-5224009 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#248847
This update resolves an issue where the 'Recipient Bank' field on credit notes wouldn't display partner bank accounts. The system was incorrectly filtering accounts based on invoice types. Now, users can successfully search and add a partner's bank account when creating a credit note.
Original PR description
Description of the issue this commit addresses: The Recipient Bank field in the Other Info tab of the Account Move form view refilters accounts to only show you company's ones. This is expected for invoices but is blocking when doing a credit note. You can't find a partner's bank account to fill that field. --- Steps to reproduce: 1. Install account. 2. Create an Invoice to a partner which has a bank account setup. 3. Create a Credit Note for that Invoice. 4. In the "Other Info" tab, remove the partner's bank account. 5. Try to search for his bank account to add it back. It won't show up. --- Desired behavior after this commit is merged: The Recipient Bank field prefilters bank accounts based on who is expected to be the recipient of the move. --- task-5976951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254850 Forward-Port-Of: odoo/odoo#252961
This update resolves issues with the XML structure generated for Spanish VAT invoices (l10n_es_edi_facturae). Specifically, it now correctly calculates and formats tax outputs, including rounding for accurate tax aggregation. This ensures compliance with Spanish tax regulations and improves the reliability of invoice data.
Original PR description
- Adjusting invoice-level `<TaxesOutputs>` nodes to be generated per tax rather than per line - Enabling rounding for invoice-level tax data aggregation - Adding a second rounding test derived from bug ticket task-6009108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253305
This update resolves a problem where invoices with specific fixed tax configurations (related to 'vidange/consigne') were failing Peppol validation checks. The fix adjusts how fixed taxes are handled during invoice generation to ensure compliance with Peppol standards for VAT breakdowns. This prevents invoices from being rejected by external systems.
Original PR description
**PROBLEM** Here is the client use case: The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the…
**PROBLEM** Here is the client use case: The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the 'consigne/vidange'. When returning the 'consigne', you would create an invoice line, with a product with a price of 0, negative quantity,a 0% tax and the fixed tax for the 'consigne'. When an invoice contains such lines, it fails peppol validations. **STEP TO REPRODUCE** 1. Create a fixed tax used for 'vidange/consigne'. 2. Create an invoice, with a line with unit price of 0, negative quantity, a 0% tax and the fixed tax for the 'consigne'. 3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08]. **CAUSE** Fixed tax (like the one used for vidange) are aggregated in new invoice lines by the function `_ubl_turn_emptying_taxes_as_new_base_lines()`. Let say we have the following invoice: line 1: qty=2, unit_price=3, taxes: 21% & vidange(fixed tax of 1). line 2: qty=-1, unit_price=0, taxes: 0% & vidange. After calling `_ubl_turn_emptying_taxes_as_new_base_lines()`, we got: line 1: qty=2, unit_price=3, taxes: 21%. line 2: qty=-1, unit_price=0, taxes: 0%. line 3: qty=1, unit_price=1(amount of the fixed tax), taxes:None. When generating the VAT breakdown, we have 2 line will end up being tax exempted (line 2 and 3). Because the `tax_exemption_reason` differs, they will not be merged in the same entry in the breakdown, which break the constraint of peppol saying we can only have one VAT breakdown with code 'Exempt from tax'. Line 2 reason comes from: https://github.com/odoo-dev/odoo/blob/de22093ee225df499b2de80e1f07dd281ac686bc/addons/account_edi_ubl_cii/models/account_edi_common.py#L271-L274 opw-5912986 Forward-Port-Of: odoo/odoo#254875 Forward-Port-Of: odoo/odoo#250413
This update resolves an issue where tours on the website were experiencing delays loading translations, particularly with recent Chrome versions. The fix introduces a temporary step to ensure the page is fully loaded before translation checks begin, preventing disruptions to the tour experience.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/odoo#254745 Forward-Port-Of: odoo/odoo#253896
This update corrects a visual issue where menu items on the website weren't aligning correctly based on the chosen mobile view setting (left, center, or right). The fix adjusts how menu elements are styled to ensure they align properly with the selected layout, improving the overall user experience. This change primarily affects the mobile website experience.
Original PR description
Steps to reproduce: =================== 1- Enter the website editor 2- Enable mobile view 3- Edit the alignment of the mobile menu to be center or right aligned The group labels (e.g. "Shop",…
Steps to reproduce: =================== 1- Enter the website editor 2- Enable mobile view 3- Edit the alignment of the mobile menu to be center or right aligned The group labels (e.g. "Shop", "Forum") stay left-aligned regardless of the chosen alignment. This can also be seen on desktop by switching to the sidebar header template. Cause: ====== The class .accordion-button uses `display:flex` and `text-align:left` and that class is used for the menu groups labels. this prevents the alignment from working. Solution: ========= When right-aligned (`text-end`), reverse the flex direction so the arrow moves to the left and the text stays on the right. When centered (`text-center`), let the text span fill the remaining space and center its content via `text-align: center`, keeping the arrow on its position. The default left-aligned case is unchanged. opw-5494765 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244565
This update resolves an issue preventing Odoo from correctly generating UBL invoices for Hungarian partners. The fix automatically builds the VAT number from the Hungarian Tax Number (Adószám) when the country code prefix isn't present, ensuring invoices meet NAV requirements and avoid rejection.
Original PR description
Problem --------- When building the UBL, invoices with Hungarian partners get hit with the following constains: "The VAT of the [role] should be prefixed by the country code". However, Hungary allows for VAT numbers that do no start with the country code. Every Hungarian business is assigned a Tax Number (Adószám) that follows a fixed 11-digit format: NNNNNNNN-Y-CC. Solution --------- Build the VAT number from the Domestic Tax Number if it is not the case. 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#253663
This update resolves an issue where the selection within the HTML editor would reset to the beginning after using the command palette. The change creates an override to refocus the editable area upon closing the command palette, ensuring the user's current selection is maintained. This improves the editor's usability and prevents data loss.
Original PR description
Before this commit: when the whole editable regains the focus, the selection in the editable is reset to the start of it. After this commit: We create a override for hotkey service to open the command palette with an onClose to refocus the editable area without losing the current selection. For the hotkey override, we pass the area option so it's only valid in the editable area. Outside the editable, the command palette is opened in the default way. task-5949705 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254623 Forward-Port-Of: odoo/odoo#250624
This update resolves an issue where salespeople without project access were unable to open sale orders with timesheet entries. The fix uses sudo() to bypass access restrictions when determining button visibility, ensuring all salespeople can manage their timesheet-based sales orders.
Original PR description
to reproduce: ============= - create a user with only user access to timesheet and no access to project - create and confirm a sale order with a timesheet-delivered service product assigned to that salesperson - record some hours on that SO with another user - open the sale order as that salesperson -> AccessError problem: ======== `_compute_show_hours_recorded_button` reads `timesheet_count` and `project_count` on the sale order, which internally query `account.analytic.line` and `project.project` records. a salesperson without all timesheet or project groups lacks read access to those models, causing an AccessError during the compute. solution: ========= use `sudo()` since the result is only used to determine button visibility and does not expose sensitive data to the user. opw-5893324 Forward-Port-Of: odoo/odoo#248026
This update ensures that all worked days on payslips are correctly linked to a work entry type. Previously, creating a public holiday without this link prevented payslips from being generated. This change makes the process more reliable and accurate for payroll processing.
Original PR description
All worked days lines in payslips should be linked to a work entry type. If we create a public holiday without linking it to a work entry type, it won't be possible to generate a payslip. Making the field required fixed the issue. task-6044274 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical error that prevented users from selecting a 'Time Off Type' within the 'New Group Allocation' wizard. The issue stemmed from an outdated reference to a company ID field, which has now been removed. This ensures the allocation process functions correctly for all users.
Original PR description
This error occurs when selecting the `Time Off Type` in the `New Group Allocation` wizard.
Steps to reproduce:
- Install `hr_holidays` module
- Time Off > Management > Allocations > `New Group Allocation`
- Try to select `Time Off Type`
Traceback:
`ValueError: Invalid field hr.work.entry.type.company_id in condition ('company_id', 'in', [1, False])`
In this [commit], the `company_id` field was removed from the `hr.work.entry.type` model; however, it is still referenced in the `_domain_work_entry_type_id` domain.
[commit]: https://github.com/odoo/odoo/commit/d37cf89a6ff134988b4a7c001a97973cd95a2ea8#diff-5cda5340aaeaddd073ac083c1909e0e52d6cbc48cb8d9c8f93ad48fd8a04f00dL68-L69
sentry-7328870622This update ensures that payment methods created within a branch company can be correctly associated with point-of-sale locations, regardless of the primary company. Previously, a validation error occurred when attempting to save a payment method linked to a branch, now this is resolved by adding a company constraint to the payment method model.
Original PR description
Steps to reproduce: ------------------- * Let's say you're on company A, create a pos payment method * Don't assign a pos yet * Create a branch company sub_A * Switch to that branch company * Create…
Steps to reproduce: ------------------- * Let's say you're on company A, create a pos payment method * Don't assign a pos yet * Create a branch company sub_A * Switch to that branch company * Create a pos * Now switch to company A but also select sub_A * In the config of the pos from sub_A, try to add the new payment method and save > Validation error -> Normal * Now instead go to the payment method form * In the point of sales select the pos sub_A * Save > No error * Try opening the pos sub_A > Validation error, same as the first one -> Normal Why the fix: ------------ We already have a contraint on the pos config model checking that the companies match. https://github.com/odoo/odoo/blob/88df50bc96448dfaff28bd37e970ffd18bf8d554/addons/point_of_sale/models/pos_config.py#L469-L473 However when writing on the model pos payment there is no constraint and the ORM currently does not trigger constraints on comodel of the field we're modifying so we need to add this constraint on the pos payment method model as well opw-6000206 Forward-Port-Of: odoo/odoo#253858
A recent test related to product archiving in the Point of Sale module was failing intermittently. This update ensures all test sessions are closed before running the test, resolving the issue where products weren't being properly archived. This improves the reliability of our testing process.
Original PR description
After this commit https://github.com/odoo/odoo/pull/252211/changes/3344bd72b9c5591b466aeca7f9da218da53dee3b the test test_archived_product_removed_and_order_is_refunded was sometimes broken because some session were still opened and the product could not be archived. This commit ensures that all sessions are closed before lauching the test. runbot-error: 241842 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253296
This update prevents unwanted formatting from being pasted into the HTML composer within Discuss. Previously, pasting content could introduce styles and HTML elements that disrupted the composer's intended use. This change ensures a cleaner and more consistent experience for creating HTML content.
Original PR description
When pasting content into the HTML editor composer, we want to ensure that no formatting is retained from the source in Discuss. This is achieved by intercepting the paste event in the clipboard plugin and removing the style and remove tags that we do not want to allow in the HTML editor composer in Discuss. This prevents any unwanted styles or HTML elements from being introduced into the composer in Discuss. task-5364799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238136
This update fixes a bug where customers could modify the global discount line within optional sections of sales orders. The change prevents unauthorized edits to this discount, ensuring accurate order pricing and preventing potential revenue discrepancies. This resolves issue OPW-6045297.
Original PR description
Issue: --- Due to this issue global discount line can be edited by customer. #### Steps to reproduce: 1- Create a SO with SOLs and add a optional section. 2- Add a global discount under optional section. 3- Preview the SO. The quantity of discount can be edited. Cause and Fix: --- In `_can_be_edited_on_portal` we are not excluding the global discount line from being editable. We could fix that by excluding line with company discount product from being editable. opw-6045297 Forward-Port-Of: odoo/odoo#254870
This update corrects a formatting issue in Odoo's Danish (DK) nemhandel XML files. The 'DK' prefix was missing from the CVR nemhandel identifier, which is now correctly added to ensure accurate data transmission. This ensures proper processing of invoices and refunds related to Danish electronic payments.
Original PR description
In this commit af94099c4d74e9c48251a1c1656e3ad11b9f8a70, we made a fix regarding OIOUBL21 XML files, but we forgot to add the 'DK' prefix for CVR nemhandel identifier. The format should be 'DK' + nemhandel_identifier_value. no-task Forward-Port-Of: odoo/odoo#254430
This update addresses several minor issues related to resource management within Odoo, primarily focusing on enhancing the user experience and flexibility. Specifically, the Kanban interface now correctly displays resource search options, and employees without defined schedules are now recognized as flexible resources. These changes ensure a smoother workflow for managing resources.
Original PR description
## [FIX] resource_mail: change placeholder for the many2many_avatar_resource in kanban The default placeholder is "Search users...." which made little sense in the context of searching for resources.…
## [FIX] resource_mail: change placeholder for the many2many_avatar_resource in kanban The default placeholder is "Search users...." which made little sense in the context of searching for resources. ## [FIX] web: give specification to AutoComplete in m2m tags popover Before this commit, when the user uses the quick edit of m2m avatar widget, the specification is not given to props since the popover does not have the specification of the main component. This commit makes sure the specification is given to popover to correctly give them to the Autocomplete widget. ## [FIX] web: allow to change the popover to use in KanbanMany2ManyTagsAvatarFieldPopover Before this commit, it was not possible to change the popover used in KanbanMany2ManyAvatarFieldPopover in the case, we need to extend that popover class used. This commit allows to alter the popover class. ## [FIX] resource_mail: review m2m resource field widgets This commit reviews the code in the different components for m2m resource to use as much as possible the methods defined in the basic m2m avatar widgets defined in web and mail. ## [FIX] resource: make sure resource without calendar set is flexible one Before this commit, when an employee does not have a working schedule set, neither work per day set, this employee is not considered as a resource flexible in resource.resource record associated. This commit makes sure this kind of employee be considered as flexible resource. task-6020304
This update resolves an issue where cross-origin requests with the Range header would fail due to preflight checks. The change adds the necessary header to allow these requests to succeed, improving compatibility with external systems. While future customization is considered, this fix addresses a specific, previously undetected problem.
Original PR description
Previously, specifying the Range header in a CORS request would result in a preflight failure even if cors was enabled on the route. It is sometimes desirable to allow querying ranges even in a CORS context. It may be desirable at some point in the future to allow controllers to customize their preflight responses more thoroughly, but considering this hasn't really be an issue before, it seems premature. Instead, this commit just adds the Range header to the Allow-Control-Allow-Headers response header to allow such requests to succeed. Forward-Port-Of: odoo/odoo#254805
This update fixes visual and functional issues within the SelectMenu component, including highlighting search results and resolving glitches related to dropdown behavior and placeholder display. The changes enhance the user experience and ensure consistent styling across the Odoo interface. This resolves a reported bug and improves the overall usability of the SelectMenu.
Original PR description
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#251992
This update resolves a visual bug in the website builder where certain options groups would disappear unexpectedly when accessed by users with limited permissions. The fix moves the access right filtering step earlier in the process, ensuring the builder correctly displays available options or shows a blank state when none are visible. This improves the user experience for all website builder users.
Original PR description
Since the [website builder refactor], the `OptionContainer` component filters the option based on access right when rendering the list of options, and hides itself if there is no options visible when…
Since the [website builder refactor], the `OptionContainer` component filters the option based on access right when rendering the list of options, and hides itself if there is no options visible when rendered. With [folding of options], the options are rendered only when the group is unfolded. Thus the component can hide itself only if unfolded. Generally, there is at least one option visible when a group is rendered, which appears when the group is unfolded. But when options are filtered because of access right, the filtered list is often empty, and the group disappears when unfolded. This commit moves the filtering slightly earlier, so the options are filtered before rendering. If the filtered list of options is empty, the component shows nothing at all as it knows it has zero options, instead of a folded group. Steps to reproduce: - With a user with only the "restricted editor" access right (and not "editor and designer") - Open website builder on /blog - Click in the title in the cover - Bug: the "Blog Page" options group appears (but it is empty, and disappears when opened) [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 [folding of options]: 64d35ccd6fade9e0473686b8484f561b5f4215ce task-6032728
This update ensures that all required address fields (street, city, zip, state, country) are included when generating seller addresses on e-invoices for Viettel. This change is necessary to meet Viettel's EDI requirements and avoid potential invoice rejection issues, ensuring compliance and accurate reporting.
Original PR description
The seller address on e-invoices was missing some fields. This commit updates the logic to include street2, city, zip, state, and country when generating the seller address, ensuring full address details are provided in compliance with Viettel EDI requirements. task-6040875 Forward-Port-Of: odoo/odoo#254564
This update fixes an issue where the VAT Return (CZ) report was incorrectly displaying negative amounts when invoices with VAT 24 or 23 tax grids were created. Previously, the report showed incorrect VAT calculations. This change ensures accurate VAT reporting for Czech companies using the l10n_cz module.
Original PR description
With l10n_cz company: 1. Create some invoices using the VAT 24 or VAT 23 tax grid on an invoice line containing an amount in credit. 2. Go to the VAT Return (CZ) report 3. The amount shown will be negative instead of positive, which goes against what the report should show. Missed by 17a6117ed88c29b5bc4db0c872bcdbc109a7d98b opw-5978183 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#252243
This update fixes an issue where the table editor lost focus after deleting rows or columns, disrupting the editing workflow and causing confusion. Now, the editor automatically refocuses, ensuring actions like Undo work correctly and improving the overall user experience when managing table data.
Original PR description
**Current behavior before PR:** When a user deletes a row or column from table menu, the editor loses focus. As a result, actions like Undo do not behave as expected and require multiple attempts to restore the original table state. This breaks the editing flow, causes confusion when performing table-related actions. **Desired behavior after PR:** This PR ensures that editable is focused after deleting row or column from table menu. This commit also makes sure that selection is set properly and hint is visible on empty cell after deleting the column. task-5725593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254684 Forward-Port-Of: odoo/odoo#245433
This update corrects a bug where project sharing settings were incorrectly changing after sharing with portal users. The change ensures that project visibility remains as intended, regardless of the sharing method used. This resolves an issue impacting how users access and collaborate on projects.
Original PR description
Steps to reproduce: - Create/open any project - Set visibility to `Invited internal users and portal users`. - Share project with a portal user - Visibility changes to `All internal users and invited portal users`. Cause: - Previously, this behavior was implemented specifically for sharing the project from the cog menu. However, the `Share Project` option has now been removed from the cog menu. - After introducing the new `invited_users` visibility option, the existing share logic was not updated to support this new value; as a result, the project's existing visibility is unintentionally overwritten. Solution: - Remove the hardcoded update of `privacy_visibility` in the `action_send_mail` method. task-5924243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255197 Forward-Port-Of: odoo/odoo#248235
This update corrects a previous issue where half-day leave periods (like 3.5 or 4.5 days) weren't accurately displayed in the calendar view. The system now correctly recognizes and shows these half-day portions, ensuring leave schedules are displayed completely and accurately.
Original PR description
-When the leave includes a half day (for example, 4.5 or 3.5 days), the half-day portion is not displayed on the dashboard. --Rendering logic has been adjusted to count for half-days. Forward-Port-Of: odoo/odoo#255096 Forward-Port-Of: odoo/odoo#250342
This update ensures that all product attributes (like color and size) are accurately reflected when scanning barcodes in the Point of Sale system. Previously, the system only displayed variant-specific attributes, leading to inconsistent order lines. This fix guarantees a more reliable and complete product representation during scanning, improving the customer experience.
Original PR description
Currently, when a product has more attribute values then variant values (some attribue can have only one option), the pos behaves differently depending if you select the product or scan it. Steps to reproduce: ------------------- * Modify the acoustic bloc screen "Attributes & Variants" tab * Have one attribute line Color, only White as values * Have one attribute line Size, S and M as values * Go to the variants, select the one corresponding to the Size S > Observe it also has the attribute White * Set a barcode on this variant * Open shop * Select Acoustic Bloc Screens, select Size S, confirm * Now scan the barcode > Observation: 2 Different pos order lines on the order, the first shows S, White as attributes, the second one only shows S. Why the fix: ------------ We need to use all attribute values, not only the variant values. opw-5932560 Forward-Port-Of: odoo/odoo#255181 Forward-Port-Of: odoo/odoo#252233