Daily updates from Odoo
Tuesday, January 6, 2026
47 changes · master
New functionality added to Odoo
This update simplifies asset management for Odoo users in Indonesia by automatically creating asset models. It also establishes links between assets, expenses, and depreciation, and adds a default tax (TVA) for improved accounting accuracy. This enhances the Odoo application's usability and compliance within the Indonesian market.
Original PR description
As odoo wants to simplify the using of its app for users in Indonesia, the assets models for each asset was added so that the users don't have to register the model manually each time. Also, each fixed asset was linked to an expense account and its corresponding depreciation account, Moreover, a default tax (TVA) was added to each fixed asset. task-5249077 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update introduces new leave types specifically for the Turkish localization, including maternity, paternity, bereavement, and excuse leave. It also incorporates salary rules for annual leave provision and food allowance, ensuring compliance with Turkish regulations and providing employees with a more comprehensive set of leave options.
Original PR description
-Salary rules for Annual leave provision and Food Allowance haven been added. -The following leave types has been added to the Turkish localization: - Maternity leave - Paternity leave - Bereavement leave - Excuse leave. Task #4868680
This update adds key features to the Turkish localization of Odoo's HR payroll module. Specifically, new leave types like maternity, paternity, and bereavement leave have been introduced, along with updated salary rules for annual leave provision and food allowance. These changes align with Turkish labor laws and provide greater flexibility for Turkish businesses.
Original PR description
-Salary rules for Annual leave provision and Food Allowance haven been added. -The following leave types has been added to the Turkish localization: - Maternity leave - Paternity leave - Bereavement leave - Excuse leave. Task #4868680
Enhancements to existing features
This update simplifies the mass mailing process by allowing users to consistently see the exclusion list option, regardless of the mailing source (like events or marketing cards). Previously, this setting was only available on dedicated servers. This change improves user experience and flexibility within the mass mailing functionality.
Original PR description
Purpose ======= At the moment, we can change `use_exclusion_list` only if a dedicated server is used for the mailing. We want to always show the option (except for mailing contact and mailing list). When coming from event, slides or marketing card, we automatically skip the exclusion list. Task-5149177
This update enhances the user interface for inactive accounts within the Odoo system. A new warning indicator will be displayed, alerting users to inactive accounts during configuration settings. This improves clarity and helps ensure accurate financial reporting.
Original PR description
This task will add a widget on account in the configuration to display a warning when the account is inactive. task-5424613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the Point of Sale category system by allowing users to delete categories only when they aren't actively used in POS sessions. It also streamlines product creation from POS sessions, ensuring new products always appear on the relevant POS. Design improvements include a refined form view and enhanced Kanban/List views for better category organization.
Original PR description
**Functional** - Removed the restriction of deleting pos categories while sessions are open and replaced it with a restriction on removing categories which are used by POS. If the category is not in…
**Functional** - Removed the restriction of deleting pos categories while sessions are open and replaced it with a restriction on removing categories which are used by POS. If the category is not in use by any POS deleting it will have no side-effects. - Moved the definition of pos_config_ids from the pos_self_order override of the pos.category to the base class in point_of_sale so it can be always accessed, not only when the self_order is installed. - Creating a new product from a POS session with a category which is not displayed on the current POS session will automatically add the category to the POS session config and reload the data to show the new products. This way when a user creates a new product, it will always show up on their POS from where they created the product. **Design (Categories)** - [Form View] For a better design will align the category title with the rest of the fields on the form view. Also added a placeholder on the pos_restaurant course field. - [Kanban] Improved the kanban view to show the color, parent category and course if they are present directly on the card. - [List] Made the parent category and color display by default. Added the points of sale where the category is used to the list Task - 5172551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows users to schedule invoice and EDI sending from the account move send wizard, providing greater control over delivery timing. It categorizes sending methods (email, EDI, etc.) for efficient scheduling and ensures accurate invoice data is prepared for each scheduled message. Additionally, the system now validates invoice data before scheduling to prevent errors during the sending process.
Original PR description
PURPOSE - The purpose of this commit is to allow users to schedule the execution of the Invoice and EDI sending in the future from the account move send wizard. - Users have control to schedule the…
PURPOSE - The purpose of this commit is to allow users to schedule the execution of the Invoice and EDI sending in the future from the account move send wizard. - Users have control to schedule the e-mail, EDIs, and other sending methods on different dates and times, as there will be separate scheduled messages for all these sending methods and EDI requests. TECHNICAL DETAILS - Introduced basic scheduling functionalities similar to the mail compose message wizard into the account move send wizard. - Categorising the selected checkboxes into 3 categories of scheduled messages: 1. For email sending method 2. For all the selected extra EDIs 3. For all the other selected sending methods (snailmail, peppol, ...) - Classifying the calculated `invoice_data` based on the selected checkboxes and preparing the invoice_data for individual scheduled messages. - Preserving this invoice_data in the `notification_parameter` of the scheduled message to retrieve it later when posting the scheduled messages and calling the actual `_generate_and_send_invoices` process. - Manually added attachments in the scheduled message will also be added to the `mail_attachments_widget` in invoice_data to consider it for the email sending method. Related Enterprise PR: https://github.com/odoo/enterprise/pull/92857 Task: 4677423
This update simplifies the employee search experience by removing redundant fields and filters. The employee list view has also been cleaned up for better clarity and usability. This change focuses on improving user efficiency when managing employee data.
Original PR description
- Reduced and removed employee search fields. - Removed and renamed filters. - Clean up employee list view. task-5441509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the employee search experience by removing redundant fields and filters. The employee list view has also been cleaned up for better clarity and usability. This change focuses on improving user efficiency when managing employee data.
Original PR description
- Reduced and removed employee search fields. - Removed and renamed filters. - Clean up employee list view. task-5441509
This update enhances order reporting within Odoo by allowing users to group orders and order analysis data by hour. This provides more granular insights into sales trends and helps businesses better understand customer behavior and operational efficiency. The change impacts the 'Orders' and 'Order analysis' views.
Original PR description
After this commit: == - Views of `Orders` and `Order analysis` can be grouped by hour. task: 5022973
This update resolves an issue where 'Validate' and 'Discard' buttons in the Quality Worksheet Template form were non-functional, preventing users from easily navigating back. The team has removed these buttons and implemented a Kanban view to enhance visibility and usability, streamlining the template management process.
Original PR description
In the Quality Worksheet Template form view, the "Validate" and "Discard" buttons were non-functional and blocked users when navigating back after designing a worksheet. This commit removes these buttons and adds a Kanban view to improve visibility and usability. These enhancements streamline the interface and make it more intuitive for users managing Quality Worksheet Templates. Task - [4637037](https://www.odoo.com/odoo/project/966/tasks/4637037)
This update enhances the system's ability to process Electronic Data Interchange (EDI) orders by learning from previous order files. It automatically identifies and reuses customer product references, reducing manual effort for sales staff and improving order accuracy. This change streamlines the EDI workflow, particularly for repeat customers.
Original PR description
This commit add functionality to make edi more efficient by learning it from past PO order files extracted. Working: - when we extract file and didn't find any matching products for line then store that customer product reference on SOL after then Sales person will set proper product from his DB or create one and set product then confirm order so On order confirmation we extract product customer reference and store it on `customer.product.reference` then when we extract new file from same customer we look and don't find matching product then we will look for product in `customer.product.reference` and if we find matching product then set that product on SOL. task-4086173
This update automatically sends email notifications to applicants when a recruiter declines their application, provided a pre-defined email template is available for that reason. This streamlines the recruitment process by ensuring timely communication and reduces manual effort for the HR team. The change improves applicant experience and efficiency.
Original PR description
In this commit, we make the toggle button "Send Email" enabled by default whenever the refusal reason has an email template, including the reason selected by default in the wizard. TaskID: 5245023 Forward-Port-Of: odoo/odoo#234759
This update refactors the user re-authentication logic within Odoo, separating the core verification process into the `base` and `web` modules for better maintainability and future development. This change allows for more flexible and efficient user re-authentication, ensuring a smoother user experience.
Original PR description
The `auth_timeout` module contains a user re-authentication mechanism based on presence. This mechanism can be split in order to incorporate the main logic into the `base` and `web` modules. Presence management remains in the `auth_timeout` module. This allows other developments to use the backend and frontend parts of the re-authentication mechanism. Re-authentication occurs when a `CheckIdentityException` exception is raised (handled in the dispatcher's error handling). The `ir.http` model is responsible for verification using two methods: `_must_check_identity` and `_check_identity`. task-4281529
This update enhances the VoIP AI feature by preventing users from enabling transcription without a valid OpenAI API key. Now, a warning message appears in the configuration settings, guiding users to set up their API key. This improves data security and ensures proper functionality.
Original PR description
*: ai, ai_app - Phone -> Configuration -> Providers - Enable transcription => Now display an error if trying to do it without a configured OpenAI key in the settings (with a button to go to the settings) task-5431534
This update enhances the job posting experience by automatically populating job descriptions with the detailed 'description' field from the job form. This replaces a pre-configured summary, reducing user frustration and providing more relevant information to potential applicants. The changes also split the website description into description and rating fields to maintain the existing layout.
Original PR description
- made the value of the job description in the job page change with the description field in the job form view. task-id: 5050599 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances how salary rules are applied to employee payslips by allowing them to be associated with multiple joint committees. The system now intelligently determines which rules apply based on the payslip's joint committee membership, simplifying payroll configuration and improving accuracy. UX improvements were also made to the salary rule views for a better user experience.
Original PR description
In this commit: Salary rules can be associated with zero or more joint committees, A rule will only be applied on a payslip if one of the following applies: - rule applies on all joint committees (no joint committees set on the rule). - version of payslip belongs to a joint committee part of a joint committee set on the rule. A joint committee 'A' is considered part of another joint committee 'B', if the code of 'B' prefixes the code of 'A'. UX improvements were added as well to the views of salary rules. Task-5136867
This update allows users to request appraisal feedback from any contact – not just employees – across different companies. Previously, feedback was limited to internal employees. This broader approach will provide a more comprehensive view of feedback and improve the overall appraisal process.
Original PR description
### Before: - The user could only select employees from the current organization as recipients for appraisal feedback. ### After: - Users are no longer restricted to selecting only employees as recipients for appraisal feedback. - Feedback can now be requested from any contact (res.partner) across any company. ### Impact: - This change allows users to request feedback from contacts in other companies, broadening the scope for gathering feedback. task-4926132
This update ensures the homepage consistently uses the `/` URL as its canonical link, which is crucial for search engine optimization. It also updates the sitemap.xml to accurately reflect the homepage URL, resolving a previous issue where non-homepage URLs weren't included. This improves website visibility and data accuracy.
Original PR description
This PR updates the canonical of a page if it's the homepage. The canonical of a homepage is always `/` now. Also updates the sitemap.xml, if the homepage is not `/`, then the homepage url does not appear in the sitemap.xml. Example: the user selected `/a` as the homepage. 1 - Page `/a` and `/` indicate as a canonical URL `/` 2 - `/a` is not in the sitemap.xml If there are multiple languages installed in the website, the language reference should stay in the canonical url. The canonical URL of `/fr/a` will be `/fr`. task-4563867
This update ensures vehicle contract statuses accurately reflect their real-time state (cancelled or expired) by automatically calculating the status upon creation. The status bar is now non-interactive, relying on contract dates, and new buttons have been added for manual contract cancellation and reactivation.
Original PR description
Only show cancelled or expired states of vehicle contract when the contract is in that state. Also make the status bar non clickable and rely on automatic state updates based on the contract start and expiration dates. Since the state can no longer be changed by clicking on the status bar, this meant that the state should be correct at all times, this lead to a change where the state is computed upon creation (previously, it would go to the default state regardless of the contract start and expiration dates). Also buttons were added to allow the user to manually cancel and reactivate contracts. Task-ID: 5176374 [Related PR](https://github.com/odoo/enterprise/pull/98141)
This update streamlines the calculation of sick leave payments for employees in Saudi Arabia, consolidating previous rules into a single, more straightforward system. The changes ensure accurate deductions or additions based on the type of work entry (calendar or attendance), aligning with labor law requirements. This simplifies payroll processing and improves compliance.
Original PR description
Group all SA sick-leave rules into a single rule. According to the specification: 1. The first 30 days are fully paid. 2. The next 60 days are paid at 75%. 3. Any remaining sick-leave days are…
Group all SA sick-leave rules into a single rule. According to the specification: 1. The first 30 days are fully paid. 2. The next 60 days are paid at 75%. 3. Any remaining sick-leave days are unpaid. Whether the monetary value of the leaves is considered a deduction or an addition depends on the work entry source. If it is a calendar entry, it is treated as a subtraction; if it is an attendance/planning entry, it is treated as an addition. One salary rule was created for the deduction case, and another for the subtraction. According to Article 117 of the applicable labor law, the counting year does not follow the calendar year. Instead, it starts on the anniversary of the employee’s first recorded sick leave. Sick leaves included in a payslip are associated only with their counting year(s). Additionally, they are linked according to the timeline of when the sick leaves were created, not the order in which payslips are generated. This means that creating a payslip in October and then another in November is treated the same as creating one in November and then another in October. Payslip computation considers only the sick leave taken within the payslip period and calculates the deduction/addition amount based on the sick leave’s chronological order. Therefore, taking sick leave in future months before taking leave in the current month will not affect the computation of the current month’s payslip. task-5256311
This update introduces a new salary rule to accurately calculate employee contributions for DEWSEMP in the UAE. The rule has been renamed and hidden from payslips, and a new parameter has been added for configuration. This ensures compliance with local regulations regarding employee deductions.
Original PR description
### changes - Added new salary rule for DEWS employee contribution(DEWSEMP). - Renamed DEWS salary rule to DEWSCOMP with category company contribution. - Hide DEWSCOMP to appear on payslip. - New rule parameter for DWESCOMP. task: 4922217
Resolved issues and error corrections
This update ensures that future leave requests are accurately reflected against an employee's available vacation time, even when they have ongoing accrual allocations. Previously, employees with past accruals wouldn't have their future leaves properly deducted. This change fixes a bug where future leaves weren't counted against available days if an employee could still accrue more time off.
Original PR description
Description of the issue/feature this PR addresses: This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745 In the above ticket, an employee Norbert Loibl had an accrual allocation from Feb.…
Description of the issue/feature this PR addresses: This ticket: https://www.odoo.com/odoo/project/49/tasks/5218745 In the above ticket, an employee Norbert Loibl had an accrual allocation from Feb. 2023 to May 2024. Since then, all his allocations have been regular allocations, so he is no longer accruing vacation days. But, Norbert’s future leaves do not get counted against the “Days Available” displayed on his Time Off Dashboard. Current behavior before PR: If an employee had an accrual allocation (of the relevant type, e.g. past vacation allocations won’t affect sick leave) at any point in time, their future leaves do not get counted against the “Days Available” on their Time Off Dashboard. Desired behavior after PR is merged: If an employee has an accrual allocation between today’s date and the date of a future leave, that future leave does not get counted against the “Days Available” on their Time Off Dashboard. That way, we will count a leave against “Days Available” unless there is a possibility of accruing more days off before the leave. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241216 Forward-Port-Of: odoo/odoo#238977
This update fixes an issue where the DIN5008 invoice report didn't show Incoterm information. The change adds the necessary logic to include Incoterm codes and locations on this specific invoice layout, ensuring compliance with accounting standards. This improves invoice accuracy and reporting for international transactions.
Original PR description
**Steps to reproduce:** 1. Install the modules account and l10n_din5008. 2. Go to Settings and set DIN5008 as the default invoice report template. 3. Navigate to Configuration → Settings and set a default Incoterm. 4. Create a new customer invoice. 5. Print the DIN5008 Invoice Report. **Issue:** The DIN5008 invoice report did not display the Incoterms, while other invoice layouts printed them correctly. **Cause:** This was due to missing logic in l10n_din5008 report to include Incoterm data. Confirmed with TSB that the DIN5008 layout should display Incoterms. **Fix:** This commit adds the Incoterm information to the DIN5008 template data: - Always include the Incoterm code - If an Incoterm location is set, display it as `CODE - LOCATION` **opw-5349267** Forward-Port-Of: odoo/odoo#240688 Forward-Port-Of: odoo/odoo#238682
This update corrects a bug that caused a 'singleton' error when marking Field Service tasks as complete, specifically related to linking timesheets to sales orders. The change ensures the system correctly associates timesheets with the first applicable sales order line when multiple options exist, maintaining consistent functionality. This prevents errors and ensures accurate timesheet tracking.
Original PR description
Steps to reproduce: ------------------------------ 1. Install `industry_fsm_sale` module. 2. Open the settings of the field-service project and open the invoicing page 3. Add one employee on the…
Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done
Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```
Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511
According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554
Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency.
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.
opw-5373018
Forward-Port-Of: odoo/enterprise#101774This update adds the functionality to generate and submit the required annual VAT return for Luxembourg businesses within Odoo. This ensures compliance with local tax regulations and simplifies the reporting process for our Luxembourg clients.
Original PR description
This commit will add the support of return for the annual vat report. task-5145333
This update adjusts how preset options are displayed in the self-order mode, ensuring that available presets are only shown when appropriate (e.g., kiosk or with a table identifier). Previously, a single, unavailable preset was always used as the default. Now, users can see the correct options based on their current context, requiring a slight adjustment to the 'service_at' field for kiosk or mobile menu views.
Original PR description
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset…
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset was not available in self, this preset was used as the default one. But now, it's not the case anymore. We only use it if, and only if, it is available in self. The second thing was to fix the "Dine In" preset availability in the eating location choices. A dine-in preset is a preset which have service_at == table as attribute. If this preset (is `available_in_self`) and has `service_at === table`, we only show it when there is a table_identifier in the URL or when we are in the kiosk. In all other cases, it'll never be shown. If user wants to see this preset in the kiosk or in the mobile menu without table_identifier, user needs to change the `service_at` field at `counter` (or `delivery`) and put the product as `available in self` as well. task-id: 5190541 enterprise pr:https://github.com/odoo/enterprise/pull/103063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241739 Forward-Port-Of: odoo/odoo#234522
This update ensures that preset options are only displayed in self-service modes (kiosk, mobile menu) when they are actually available for that specific order type. Previously, a preset would be shown even if it wasn't suitable for self-service. Users may need to adjust product settings to ensure availability in these modes.
Original PR description
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset…
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset was not available in self, this preset was used as the default one. But now, it's not the case anymore. We only use it if, and only if, it is available in self. The second thing was to fix the "Dine In" preset availability in the eating location choices. A dine-in preset is a preset which have service_at == table as attribute. If this preset (is `available_in_self`) and has `service_at === table`, we only show it when there is a table_identifier in the URL or when we are in the kiosk. In all other cases, it'll never be shown. If user wants to see this preset in the kiosk or in the mobile menu without table_identifier, user needs to change the `service_at` field at `counter` (or `delivery`) and put the product as `available in self` as well. task-id: 5190541 community pr:https://github.com/odoo/odoo/pull/234522 Forward-Port-Of: odoo/enterprise#103099 Forward-Port-Of: odoo/enterprise#103063
This update fixes a problem where payments made on the website weren't correctly reflected in the POS. Now, the POS automatically recognizes and accounts for payments made through ecommerce, creating down payment lines and preventing duplicate payments. Users can still create invoices through the standard Odoo Sale app.
Original PR description
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the…
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment. Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices). Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo. Task-5138081 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230809
This update enhances the preparation display filters in the Point of Sale module, providing more flexible options for managing order preparation. Specifically, it adds multi-select time filters, a multi-select preset filter, and ensures the category filter is always visible, streamlining the process for staff.
Original PR description
- Time filter: * Remove "All" option (now default) * Add "Now" option for unscheduled and next-slot orders * Allow multi-selection - Preset filter: * Add multi-select preset filter * Only shown if related POS configs use presets - Category/Product filter: * Always show pos.category filter (even if no preparation card contains this category) * Move category/product filters below Time and Preset filters task: https://www.odoo.com/odoo/project/1737/tasks/5060221 community PR: https://github.com/odoo/odoo/pull/233920 Forward-Port-Of: odoo/enterprise#103091 Forward-Port-Of: odoo/enterprise#95136
This update fixes an issue where the recruiter selection dropdown in the Job Position form displayed all company users, regardless of their recruitment access rights. The change now restricts the dropdown to only employees with Recruitment Officer or Administrator roles, ensuring recruiters only see authorized candidates.
Original PR description
#### Issue In Recruitment → Job Position form, the Recruiter dropdown lists all company users, including those without recruiter rights. #### Fix - Replace the `user_id` field in `hr.applicant`, `hr_recruitment_reports`, and `hr.job` with `recruiter` for clarity, using `hr.employee` instead of `res.users`. - Restrict the dropdown to employees whose linked users have the correct recruiter access rights (Recruitment Officer or Administrator). - Update SQL queries accordingly. task-5083125
This update fixes an issue where the recruiter dropdown in job postings displayed users without the necessary permissions. The change now restricts the dropdown to only employees with Recruitment Officer or Administrator roles, ensuring recruiters only see authorized personnel. This improves the efficiency and accuracy of the recruitment process.
Original PR description
#### Issue In Recruitment → Job Position form, the Recruiter dropdown lists all company users, including those without recruiter rights. #### Fix - Replace the `user_id` field in `hr.applicant`, `hr_recruitment_reports`, and `hr.job` with `recruiter` for clarity, using `hr.employee` instead of `res.users`. - Restrict the dropdown to employees whose linked users have the correct recruiter access rights (Recruitment Officer or Administrator). - Update SQL queries accordingly. - Update demo data and replace Marc Demo with Mitchell Admin for consistency with domain condition in recruiter selection. #### Additional - Rename recruiter-related fields/classes/tests to make consistent with the changes from `user_id` to `recruiter_id`. task-5083125
This update fixes an issue where deferred accounting for misc entries wasn't correctly handling different account types. The change now analyzes the individual line's account type to determine the appropriate deferred account, providing more accurate and granular accounting. This ensures proper revenue and expense deferral calculations for misc entries.
Original PR description
The commit 42f823d6b8aa3d1cd171ae1603549ee95fc9d0f0 allows to use deferred on misc entries. However, there are many places in the code that were not updated. Usually they were in the form of `if move_type is sale, then deferred_type = income, else expense`. However we cannot rely on the move_type anymore for misc entries, because it will always take the `else` branch of the condition. Instead, if we have a misc entry, we should rely on the account type of the line that is being deferred, so we have more granularity. For this, we now compute the deferral account/journal for each line, and not per move. The logic inside the computation remains the same. Steps to reproduce: 1. Create a misc entry with two deferred lines (one expense, one revenue) 2. Post it 3. Check the generated deferrals, they all use the same deferred account and journal even though we have different account types opw-5194305 Forward-Port-Of: odoo/enterprise#100295
This update fixes a visual issue where the search panel was being cut off when navigating deep within the hierarchy view. The change allows the entire hierarchy to scroll properly, ensuring a fully functional and usable experience for users. This resolves a test failure and maintains the integrity of the UI.
Original PR description
Issue: - The search panel was getting clipped when navigating deep into the hierarchy. - `.o_content` enforced `height: 100%` and `overflow: hidden`, preventing the hierarchy from expanding and blocking vertical scroll. - The JS test "drag node to scroll" queried `.o_content`, which is no longer the actual scrollable container in the hierarchy view, causing intermittent test failures. Fix: - Allow `.o_content` to grow and remove overflow restrictions only in the hierarchy view. - Enable vertical scrolling on `.o_hierarchy_view.o_action` to support large hierarchies. - Update the test to query `.o_hierarchy_view.o_action` so it targets the correct scrollable element. Impact: - Restores proper scrolling behavior. - Prevents search panel truncation and preserves full UI usability. - Stabilizes the hierarchy drag-scroll test without impacting other views. Task: 5326054 Forward-Port-Of: odoo/odoo#236823
This update resolves an issue preventing duplex (double-sided) printing on the Windows IoT device. We've replaced the problematic Ghostscript with SumatraPDF, a simpler PDF viewer that natively supports duplex printing. This ensures reliable and accurate PDF printing for our users.
Original PR description
When printing a PDF using the Windows IoT, first the PDF file is temporarily saved, and then it is printed using Ghostscript which handles parsing the PDF and saving it to the printer. Unfortunately, Ghostscript is unable to print using duplex (double-sided) no matter what settings are provided. To fix this, we replace Ghostscript with [SumatraPDF](https://github.com/sumatrapdfreader/sumatrapdf), which is an open source PDF viewer for Windows, but it is also capable of being used from the command line to print. We simply provide the duplex printing option in the command to SumatraPDF, and it works as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where helpdesk ticket creation would fail due to incorrect access checks across different companies. The change prevents unnecessary fetching of resource IDs in sudo, ensuring users only access resources within their own company. This resolves a potential error when assigning tickets to helpdesk teams with members in other companies.
Original PR description
Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members…
Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members in a helpdesk team from another company than the current one(s). The problem is since the current user does not have access to those resources due to the multi company rule, he will get a traceback when he will try to create a ticket from that helpdesk team if the assignement method is ramdom and a user with resource exists in another company. This commit makes sure the resource_ids field in res.users is not fetched in sudo to correctly determine which user to set to the ticket when the current user tries to create a ticket. Steps to reproduce the issue: ---------------------------- 1. Install helpdesk module 2. Create a new company B 3. Create a new user with helpdesk user access right (or use Marc demo) and give the company B to that user 4. Select that new company created in step and go to helpdesk app. 5. Create an helpdesk team with auto-assignment set to "randomly" and set admin user as members in that helpdesk team 6. log in as the user created in step 3 7. make usre the company selected is the one created in step 2 8. create a ticket in the helpdesk team created in step 5 Expected behavior: ----------------- The ticket should be created without any issue. Actual behavior: --------------- An access error is raised because the current user does not have access to the resource of admin user since it is not in the same company than the current one. opw-5223717 Forward-Port-Of: odoo/enterprise#102910 Forward-Port-Of: odoo/enterprise#102859
This update restricts access to key employee form features like user creation and sensitive data views based on user roles. Previously, HR Officers could perform actions they weren't authorized for, leading to errors. Now, access is correctly controlled, ensuring HR Managers have the necessary permissions and preventing unauthorized actions.
Original PR description
* = hr_work_entry
Steps to reproduce:
- Install 'hr' and 'hr_work_entry'.
- Log in as an HR Officer.
- Open an employee form and click:
- 'Create User'
- 'Work Entries' smart button
- 'History' smart button
Cause:
- 'Create User' was visible to HR Officers, but only users with Settings rights
('base.group_erp_manager') can create 'res.users', causing an AccessError.
- The 'Work Entries' and 'History buttons were visible to HR Officers, but
fields as 'contract_date_start' which only HR Managers can read when
payroll is not installed.
Fix:
- Restricted 'Create User' to 'base.group_erp_manager'.
- Limited the 'History' smart button to 'hr.group_hr_manager'.
- Limited the 'Work Entries' smart button to 'hr.group_hr_manager'.
Task - 5188997
Forward-Port-Of: odoo/odoo#242099
Forward-Port-Of: odoo/odoo#235923This update corrects a previous issue where HR Officers without payroll access could still view and modify salary adjustments data. The changes restrict access to sensitive payroll information and ensure that HR Officers only see data relevant to their role, enhancing data security and user experience. This resolves a potential data access vulnerability.
Original PR description
* = hr_contract_salary Steps to reproduce: - Install 'hr', 'hr_payroll', 'hr_work_entry', and/or 'hr_contract_salary'. - Log in as an HR Officer without payroll access. - On an employee form: -…
* = hr_contract_salary
Steps to reproduce:
- Install 'hr', 'hr_payroll', 'hr_work_entry', and/or 'hr_contract_salary'.
- Log in as an HR Officer without payroll access.
- On an employee form:
- Switch to the 'Salary Adjustments' tab.
- Edit/save a record (tracking reads 'salary_offer_ids').
- Click the 'Work Entries', 'History', or 'Offers' smart buttons.
Cause:
- HR Officers could still reach payroll-only data:
- 'salary_offer_ids' (one2many to 'hr.contract.salary.offer') triggered
tracking reads on a model restricted to HR Managers/Recuriters.
- The 'Salary Adjustments' tab and offer buttons remained visible even when
the user lacked payroll rights.
- The payroll overrides changed 'contract_date_start' to
'hr_payroll.group_hr_payroll_user', so the 'Work Entries'/'History' buttons
show AccessErrors while the buttons stayed visible.
Fix:
- Restricted 'salary_offer_ids' to 'hr.group_hr_manager'.
- Made the 'Salary Adjustments' tab visible only to
'hr_payroll.group_hr_payroll_user' and existing 'Offers' buttons stay for
HR Managers.
- Added dedicated overrides giving 'Work Entries' and 'History' buttons the
'hr_payroll.group_hr_payroll_user' group when payroll is installed.
Task - 5188997
Forward-Port-Of: odoo/enterprise#103276
Forward-Port-Of: odoo/enterprise#99234This update fixes an issue where imported DTE invoices in a multi-company Odoo environment incorrectly assigned tax to the wrong company. The fix ensures that the recipient company's default purchase tax is used, resolving inconsistencies and improving invoice accuracy. This impacts financial reporting and compliance with Chilean tax regulations.
Original PR description
**PROBLEM**
When importing a DTE from mail (using fetchmail) in a multicompany setting, there can be company inconsistencies during the import, i.e. the product created during the import belong to the right company, but the tax on a move line belong to another company.
**STEP TO REPRODUCE**
1. Create 2 CL companies with those VAT number: 22060449-7, 77697621-0
2. Set an incoming mail server for bills
3. Send XML to the mailbox (see in the ticket for the xml, one of them should trigger the bug, it depends on the order you created the companies).
4. Run a fetchmail scheduled action.
**CAUSE**
On the creation of the move line for the DTE bill, we retrieve the default purchase tax using `self.env['account.chart.template'].ref('OTAX_19')`. There is no guarantee this tax belong to the recipient company. We should use the default purchase tax of the recipient company instead.
opw-5378068
Forward-Port-Of: odoo/enterprise#103279
Forward-Port-Of: odoo/enterprise#102274This update resolves a memory error that occurred when processing recurring invoices with a large number of subscriptions. By optimizing how the system retrieves data, the change significantly reduces memory consumption, preventing crashes and improving overall system stability. This results in faster invoice processing and a more reliable system.
Original PR description
A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the…
A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the compute method overwrite `_get_invoiced` in the sale_subscription module can consume a lot of memory. The issue is mostly coming from the search on account.move.line. In case a lot of account.move.lines have a subscription_id, the search to get `all_subscription_ids` is going to return a lot of records. Then, accessing any field on this recordset will prefetch all the prefetchable fields, leading to a MemoryError. This commit fixes that by manually fetching the fields we need on account_move_line. Since `subscription_move_lines` is not used anywhere else and `move_by_origin` only contains ids, the number of queries stays the same while the memory consumption plummets. #### Benchmark In a database with 236 000 account.move.line with a non-null subscription_id, running the schedule action with 5 subscriptions to invoice consumes at least 1.7GB (MemoryError raised). After this commit it consumes 191MB. <img width="1918" height="943" alt="sale_subscription_before" src="https://github.com/user-attachments/assets/e868921f-e691-47c3-8474-edb9a1d22d0b" /> <img width="1920" height="949" alt="sale_subscription_after" src="https://github.com/user-attachments/assets/78e9fc31-4c5f-4369-8bd0-494ca2c693fd" /> Forward-Port-Of: odoo/enterprise#102364
This update resolves an issue that prevented the `website_sale_renting` module from installing correctly. The fix moves a key function to the `sale_renting` module, ensuring compatibility with the installation order and preventing a traceback during setup. This ensures rental pricing functionality works smoothly.
Original PR description
## Steps To reproduce: 1. On a local environment, install **`website_sale_renting`** using `-i website_sale_renting` 2. During installation, the process reaches **`website_sale`**. 3. A traceback is…
## Steps To reproduce: 1. On a local environment, install **`website_sale_renting`** using `-i website_sale_renting` 2. During installation, the process reaches **`website_sale`**. 3. A traceback is raised while loading `website_sale/data/mail_template_data.xml`. --- ## Issue * The installation fails during **`website_sale`** because the mail template calls `_get_rental_pricing_description()` on `sale.order.line`, but the method is not available at that stage. --- ## Cause: * `_get_rental_pricing_description()` existed previously but was defined in **`website_sale_renting`**. * A recent design PR- odoo/odoo#213186 introduced a `t-if="hasattr(combo_line, 'is_rental')"` guard in the `website_sale` mail template. * Since `mail.template`'s body_html data is parsed as HTML, the template cannot be safely extended via XPath in other modules. * Module installation order is: `sale → sale_renting → website_sale → website_sale_renting` * When **`website_sale`** is installed: * `sale.order.line` already has the `is_rental` field (from `sale_renting`) * but `_get_rental_pricing_description()` is not yet present, as it is only loaded with `website_sale_renting` This causes the guard to pass while the method call fails, leading to a traceback during installation. --- ## Solution: * Move `_get_rental_pricing_description()` to the **`sale_renting`** module, alongside the `is_rental` field. * This ensures the method is always available whenever rental logic is enabled and makes `website_sale` mail templates safe regardless of installation order. opw-5454946 Affected Version-saas~19.1 Forward-Port-Of: odoo/enterprise#103138
This update resolves an issue where filtering in Odoo's Kanban views would temporarily lose its settings after opening and closing records. The fix ensures that filtered views remain accurate, even after changes are made to related records, improving data consistency and user experience. It achieves this by more reliably trusting the data returned from filtering operations.
Original PR description
Have a kanban view with progressbar and some records. Click on a progressbar to filter a column. Then open a record and come back. From that point, the data of the filtered kanban is in cache. Now,…
Have a kanban view with progressbar and some records. Click on a progressbar to filter a column. Then open a record and come back. From that point, the data of the filtered kanban is in cache. Now, open a record again, and make a change in the form that will have an impact in the kanban (e.g. that will move a record from a column to another). Come back to the kanban view, which will instantly show the data from the cache, and that will be then updated once the rpc returns. At that point, the view is still correct, but the cache callback has already erased the groups information (in particular, the extraDomain of the filtered column). So, if you open a record and come back a last time, the view is no longer correct: the column that is supposed to be filtered displays all records. Introduced by [1] This commit basically reverts [1] and fixes the original issue differently. When we receive the result of a web_read_group, we can trust it and determine that a group for which we receive records (or groups) is open. [1] https://github.com/odoo/odoo/pull/226312 Task~5387553 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#240593
This update fixes a problem where incorrect error messages were displayed when creating employees with negative fixed allowance values. The fix isolates error handling to payroll validation, ensuring users receive the precise error message needed to correct the issue. This improves data accuracy and simplifies the employee onboarding process.
Original PR description
Issue: * When creating an employee with negative fixed allowance values, the system should show a payroll validation error. * Instead, a leave-related error from hr_holidays always appeared because the module wrapped the entire create() method in a broad try/except, catching all ValidationError messages including those from payroll. Fix: * Restricted the try/except only to the part that actually creates a new leave entries. Impact: * Users now see the correct and relevant error message when the fixed allowance values are invalid. task-5383700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238984
This update fixes an issue where updating the quantity of a parent manufacturing order incorrectly affected the quantity of related child manufacturing orders. The change ensures that quantities are consistently converted to the same UoM (product’s UoM) during calculations, leading to accurate updates for all dependent manufacturing orders. This improves the reliability of production planning.
Original PR description
Problem: When a manufactured product uses a component whose UoM is different from its reference UoM, for example the component’s UoM is dozens but units are used on the BoM line, updating the…
Problem: When a manufactured product uses a component whose UoM is different from its reference UoM, for example the component’s UoM is dozens but units are used on the BoM line, updating the quantity to produce on the parent MO causes the child MO’s quantity to roduce to update incorrectly. This is because the new quantity to produce on the child MO is calculated with quantities in different UoMs. Purpose: To ensure that the child MO’s quantity to produce updates correctly when the parent MO’s quantity to produce is updated. This is achieved by making sure the quantities that get added together are both the same UoM, in this case the product’s UoM. Steps to Reproduce on Runbot: 1. Create product_a with the MTO route and UoM set to pack of 6. 2. Create a BoM for product_a that creates 1 pack of 6 products. 3. Create product_b. 4. Create a BoM for product_b that creates 1 unit and uses 3 units of product_a. Make sure the component line shows 3 units instead of 0.5 pack of 6. 5. Create a manufacturing order for 1 unit of product_b and confirm it. 6. There should be a child MO for 0.5 pack of 6 of product_a. 7. On the parent MO update the production quantity to 2 units. 8. Observe that the child MO is now for 3.5 pack of 6 instead of 1 pack of 6. opw-5414085 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241692
Code cleanup and technical improvements
This update standardizes how the accounting modules access core system functions. Previously, the modules relied on a less efficient internal library. This change improves code consistency and maintainability across the entire accounting suite, ensuring smoother future updates and integrations. It impacts several key accounting features.
Original PR description
`*` includes all the modules related to accounting, including l10n modules PURPOSE - The purpose of this pr is to replace the usage of `odoo.tools._` method with `env._` method from the Environment class in account related module. Related PR: https://github.com/odoo/odoo/pull/240704 PRs for remaining modules - COM: https://github.com/odoo/odoo/pull/241594 - ENT: https://github.com/odoo/enterprise/pull/103020 Task-5431538
This update standardizes the use of `env._` instead of `odoo.tools._` throughout the codebase. This improves code consistency and simplifies access to environment-specific data, leading to more maintainable and efficient development. It impacts a wide range of Odoo modules.
Original PR description
`*` includes all the remaining modules other than accounting PURPOSE - The purpose of this pr is to replace the usage of `odoo.tools._` method with `env._` method from the Environment class in every module. Related PR: https://github.com/odoo/enterprise/pull/103020 PRs for accounting modules - COM: https://github.com/odoo/odoo/pull/240704 - ENT: https://github.com/odoo/enterprise/pull/102688 Task-5431538
This update standardizes the use of `env._` instead of `odoo.tools._` throughout various Odoo modules, improving code consistency and simplifying access to environment-specific data. This change enhances maintainability and reduces potential errors related to outdated dependencies. It impacts numerous modules including sales, accounting, and customer support.
Original PR description
`*` includes all the remaining modules other than accounting PURPOSE - The purpose of this pr is to replace the usage of `odoo.tools._` method with `env._` method from the Environment class in every module. Related PR: https://github.com/odoo/odoo/pull/241594 PRs for accounting modules - COM: https://github.com/odoo/odoo/pull/240704 - ENT: https://github.com/odoo/enterprise/pull/102688 Task-5431538