Daily updates from Odoo
Navigate
Branch
Wednesday, December 24, 2025
136 changes
33 changes
New functionality added to Odoo
This update enhances Odoo's barcode scanning capabilities by adding support for decoding EPCs provided as hexadecimal values. This allows for greater flexibility in reading data from various barcode and RFID devices, expanding compatibility and improving data capture accuracy. A related refactoring is planned for the main Odoo codebase.
Original PR description
Add an EPC decoder as a front-end service. The decoder takes an EPC as a hexadecimal input and return the resulting URI or Element String. On incorrect input or unsupported decoding, the returned value is null. Currently support SGTIN-96, SGTIN-198, SSCC-96, SGLN-96, SGLN-195. This commit also adds support for reading values from an RFID device without requiring a specific mobile app. To achieve this, we use the same entry point as the one used for barcode scanning. As a result, a refactoring of the naming is planned on the master branch. 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
Enhancements to existing features
This update clarifies the filter options within the account follow-up reporting system. It now specifically targets 'Overdue Customer Invoices,' making it easier for finance teams to quickly identify and manage unpaid invoices. This change improves reporting accuracy and streamlines the process of tracking overdue payments.
Original PR description
opw-5232434 Forward-Port-Of: odoo/enterprise#100595
This update allows users to now accurately display the account holder's name alongside bank details, even when it differs from the partner's name. Previously, the account holder name was automatically linked, but this change ensures correct display regardless of name variations, enhancing data clarity and accuracy.
Original PR description
Allow changing of the account holder name in case it is different from the partner name which was the computed default. Task-5222712 [Related PR](https://github.com/odoo/enterprise/pull/98572) Forward-Port-Of: odoo/odoo#233965
This update enhances Odoo's stock management capabilities by adding support for reading data from RFID devices. Instead of needing a dedicated mobile app, users can now scan RFID tags directly, streamlining inventory processes. A related code refactoring is planned for the main Odoo branch.
Original PR description
Now, we have an EPC decoder, we can add support for reading values from an RFID device without requiring a specific mobile app. To achieve this, we use the same entry point as the one used for barcode scanning. As a result, a refactoring of the naming is planned on the master branch.
Resolved issues and error corrections
This update corrects a bug where the 'convert' option repeatedly appeared in the Todo breadcrumb after a task was created from a Todo. This prevented users from correctly managing converted tasks, particularly when changing project assignments. The fix hides the 'convert' option when a project is assigned, streamlining the task management process.
Original PR description
Steps to reproduce: - Create a Todo and convert into task using cog Menu option. - Todo is converted to task and is displayed. - Through breadcrumb go back to Todo - Try to convert it again Issue: - The converted todo is again converted (change of project etc) Fix: - Hiding the convert cog menu when a project is set. task-5075327 Forward-Port-Of: odoo/odoo#240821 Forward-Port-Of: odoo/odoo#230031
This update fixes an issue where opening invalid account return records previously displayed all related `account.move.line` records, even when only one or none matched. The change ensures that the check action is correctly applied, preventing inaccurate record displays and improving data reliability.
Original PR description
Before this PR, opening invalid records from account return checks could show all `account.move.line` records when there were 0 or 1 matching record(s). Technical Reason: In `_get_records_action` domain is only applied when there are multiple records, so without a domain, all records are opened. With this PR, the domain is passed through the method arguments, and also action will be none if there are no records. task-5427746 Forward-Port-Of: odoo/enterprise#102424
This update prevents guest users from seeing the unpin button in the PinnedMessagesPanel, resolving a confusing user experience. Previously, guests could click the button but the server rejected their attempts to unpin, leading to frustration. This change ensures guests only see the functionality they are authorized to use, improving overall usability.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- Currently, guest users in PinnedMessagesPanel can see the unpin button on pinned messages, but…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- Currently, guest users in PinnedMessagesPanel can see the unpin button on pinned messages, but the server correctly rejects their unpin requests. This creates confusion and a poor user experience where external users see functionality that doesn't work for them. **Current behavior before PR:** ---------------------------------------------- - Guest users see the unpin button on pinned messages - Clicking the unpin button results in server rejection - UI shows functionality that guest users cannot actually use **Desired behavior after PR is merged:** ---------------------------------------------- - Guest users cannot see the unpin button on pinned messages - Internal users continue to have full pin/unpin functionality - UI accurately reflects user permissions and capabilities - Better user experience with appropriate access control Task-5033295 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at https://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240979 Forward-Port-Of: odoo/odoo#229211
This update fixes a minor inconvenience where users had to manually refocus the composer after replying to a note. Now, clicking 'reply' automatically brings the composer back into focus, making the note response process smoother and faster. This improves user efficiency and overall usability.
Original PR description
**Current behavior before PR:** When the composer is already open, clicking reply on a note does not refocus the composer. The user must manually click inside the composer before typing. **Desired behavior after PR is merged:** When clicking reply on a note, the composer is automatically focused, even if it was already open, allowing the user to continue typing immediately. task-[5410878](https://www.odoo.com/odoo/project/1519/tasks/5410878) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240666
This update resolves a crash in the Point of Sale mobile view when editing payments and viewing customer information. The fix ensures that necessary data related to customer activity is loaded, preventing the POS from freezing. This improves overall stability and user experience for our POS users.
Original PR description
Steps to reproduce: =================== - Use the POS in mobile view - Complete a payment - Click on "Edit Payment" - Select customer or Edit customer Issue: ====== - POS crashes when rendering the partner kanban view - Frontend error occurs because `activity_state` is missing in the record Cause: ====== - The partner kanban view references activity-related fields - `activity_state` was not loaded when the view is rendered in POS Fix: ==== - Explicitly load `activity_state` in the kanban view (invisible) Task:5406890
This update fixes a bug that caused the ClickEverywhere function to repeatedly test all applications after a page reload. Now, the function correctly stores the application's ID, ensuring it only tests the intended application, improving test reliability and efficiency.
Original PR description
The clickEverywhere function can be executed with one app. To accomplish this, the xmlID should be passed as a parameter to the function. Before this commit, the xmlID of the requested application was not stored in the status of the current execution saved in localStorage. If a reload occurs while the clickEverywhere function is executing, it will lose this information and continue testing all applications instead of only the requested one. runbot.build.error: 234747 Forward-Port-Of: odoo/odoo#240943
This update speeds up the calculation of product quantities, particularly for databases with many products where most have zero stock. By optimizing the computation process, the system now runs significantly faster – reducing processing time by over 50% when dealing with a large number of products. This improves overall system responsiveness and efficiency.
Original PR description
In databases with a large number of products, most of them will have 0 quantities on hand. This commit fast-tracks the computation of 0 qty products, skipping unnecessary `uom_id` and `float_round()` computations in _compute_quantities_dict and skipping unnecessary `__set_item__` in _compute_quantities. Benchmark | `product.product` count | Before this PR | After this PR | | ----------------------- | -------------- | ------------- | | 700,000 | 52.84s | 28.33s | opw-4930856 Forward-Port-Of: odoo/odoo#241017 Forward-Port-Of: odoo/odoo#239687
This update corrects a minor inaccuracy in the documentation for VoIP phone settings. The previous reference to a non-existent method has been updated to accurately reflect the correct method used within the system. This ensures clarity and consistency for users configuring VoIP features.
Original PR description
A mention to `_voip_get_phone_field` appeared in [1] but this seems to never have existed. In any case, `_phone_get_number_fields` was used by the codebase in the end and should thus be the one mentioned. [1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd Forward-Port-Of: odoo/enterprise#102804
This update fixes a problem where taxes weren't correctly applied to Point of Sale transactions, specifically down payments and full settlements. Now, taxes set on Sale Orders are consistently applied to POS transactions, ensuring accurate tax calculations for all sales. Additionally, the color styling of buttons has been updated for a more consistent user experience.
Original PR description
Before this commit: ------------------- - If a tax was set on the Sale Order line, it was not applied on the down payment created from the POS. - If no tax was set on the Sale Order line, the POS settlement incorrectly applied the product’s default tax when settling the order. After this commit: --------------------- - The tax defined on the Sale Order line is now consistently applied to both down payments (partial settlements) and full settlements from the POS. - If the Sale Order line has no tax, then no tax is applied on either partial or full settlements and if have tax the tax will be applied. - Added consistent color styling to all buttons. task: 5269354 Forward-Port-Of: odoo/odoo#238051
This update resolves a restriction preventing users without the 'hr' group from accessing bank account information. Previously, a technical requirement limited access to a related field, causing errors. This fix ensures all users can manage bank accounts correctly.
Original PR description
The field `employee_salary_amount_is_percentage` is computed, but the computation[^1] relies on `hr_employee.salary_distribution`, a field restricted[^2] to members of `hr.group_hr_user`. If you try…
The field `employee_salary_amount_is_percentage` is computed, but the computation[^1] relies on `hr_employee.salary_distribution`, a field restricted[^2] to members of `hr.group_hr_user`. If you try to check a bank account without an hr group, you will get an access error: ``` odoo.exceptions.AccessError: You do not have enough rights to access the field "salary_distribution" on Employee (hr.employee). Please contact your system administrator. Operation: read User: 21 Groups: allowed for groups 'Employees / Officer: Manage all employees' ``` This also happens during the mock crawl test of upgrades if the admin lacks the group. To reproduce in standard: - Install contacts and hr. - Use a user without hr permissions. - Try to create a new bank account. [^1]:https://github.com/odoo/odoo/blob/57573994313988837d89329d77ab1def63a8cfdd/addons/hr/models/res_partner_bank.py#L26 [^2]:https://github.com/odoo/odoo/blob/57573994313988837d89329d77ab1def63a8cfdd/addons/hr/models/hr_employee.py#L147 --- I've also added another commit to make the percentage symbol stick to the salary amount. Before: <img width="366" height="38" alt="image" src="https://github.com/user-attachments/assets/ef890852-50ca-40b1-8c09-07c4aa2d330d" /> After: <img width="219" height="35" alt="image" src="https://github.com/user-attachments/assets/88e4a6c4-bc3f-483e-97f9-3080c6aa85c9" /> I know the number is not formated correctly but I don't think I can do more just from the view. Forward-Port-Of: odoo/odoo#239298
This update resolves a bug that prevented administrators with the 'group_system' access level from editing standard views within the Odoo website. The fix restores the necessary permissions, ensuring all users can manage views correctly. This improves usability and prevents disruptions for administrators.
Original PR description
There was an issue where, if someone was to install `mass_mailing` without `website`, a user with `group_system` could not read `ir.ui.view` records. Steps to reproduce: - install mass_mailing, web_studio - connect as an admin user - try to edit a view (not a snippet) with studio Issue: - access error In a previous [commit], new rules were introduced in `mass_mailing` to allow `group_mass_mailing_user` to handle custom snippet (views). However, a superseding rule for `group_system` was missing in `mass_mailing`, to allow an admin to continue to manage other types of views. [commit]: https://github.com/odoo/odoo/commit/6d39d72453842cf0d22880e14b1fa182c23538e6 task-5436780
This update fixes a minor translation issue within the Odoo accounting modules for Belgium and the Netherlands. Specifically, the English names of certain accounts have been updated to match their correct translations, ensuring accurate reporting and data consistency. This change improves the overall accuracy of financial data within the Odoo system.
Original PR description
Following odoo#227754, a couple of translations for changed accounts need to be updated to correctly reflect their english name. 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#241069
This update corrects a recent change that incorrectly included legal reserves in the Belgian Balance Sheet reports. This change was unnecessary as legal reserve requirements have been removed since 2024. This reversion ensures accurate reporting for our Belgian clients.
Original PR description
In #95062, the BE Balance Sheet was changed to include Legal Reserves. However, since this is not needed since 2024, this change can be reverted. no-task Forward-Port-Of: odoo/enterprise#102766
This update fixes a bug where product templates were incorrectly calculating discounted prices, resulting in inflated prices being displayed. The issue stemmed from a misidentification of product types – specifically, templates were not being recognized correctly. This change ensures accurate discounted price calculations for all product types, including templates, improving price accuracy in the catalog.
Original PR description
Steps to reproduce: 1- Add a product that has variants to a vendor pricelist. 2- Set the vendor's unit for this product to a one different than the product's unit. 3- Create an RFQ with from that vendor. 4- Open the catalog. Issue: `discounted_price` is miscalculated and causes wrong price calculation, it shows the price multiplied by its factor. i.e if a price of pack of 6 is 10$, it will be shown as 60$. Cause: We only check for `product_id` not for `product_tmpl_id` when computing the `price_discounted`, so if its a template, `product_id` is false, and its sent with `_compute_price()` and the same price is returned since there's no unit and after that its sent to `_get_product_price_and_data` where its converted to the new unit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241115 Forward-Port-Of: odoo/odoo#240519
This update simplifies the payment screen by removing the unnecessary guest count field and automatically defaulting the numpad to the last entered value. Discarding the input now correctly maintains the last guest count, streamlining the ordering process for customers. This change improves user experience and reduces potential errors.
Original PR description
after this commit: - The payment screen no longer shows extra guest count. - The numpad will display the last guest count. - Discarding will keep the last guest count unchanged. - Use hotkey handling so Enter confirms input only, ignoring any numpad button currently in focus. task: 5364073 Forward-Port-Of: odoo/odoo#237877
This update ensures users retain their last selected spreadsheet dashboard when navigating back through the application's breadcrumb navigation. Previously, returning to the dashboard reset it to the default. This change improves user experience by maintaining the user's current view.
Original PR description
### Description After [PR#223171](https://github.com/odoo/odoo/pull/223171/), `useSetupAction` `getLocalState` exports the active dashboard through the loader state (`dashboardLoader.activeDashboardId`). The restore path still read `state.activeDashboardId`, so returning via the breadcrumb reset to the first dashboard. Read the saved loader state to keep the last selected dashboard. Task: [5391349](https://www.odoo.com/odoo/project/2328/tasks/5391349) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239172
This update fixes a minor inconvenience for users. Previously, clicking 'Jump to Present' would cause the composer to lose focus, requiring manual adjustment. Now, the composer automatically regains focus on desktop after this action, improving the user experience.
Original PR description
**Current behavior before PR:** clicking "Jump to Present" caused the composer to lose focus, forcing users to manually focus the input before typing. **Desired behavior after PR is merged:** The composer automatically regains focus on desktop after clicking "Jump to Present". task-[5035977](https://www.odoo.com/odoo/project/1519/tasks/5035977) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241113 Forward-Port-Of: odoo/odoo#227781
This update corrects a bug where inactive accounts were incorrectly displayed in financial reports. The change replaced a deprecated field with an 'active' field, which now prevents inactive accounts from being included in report calculations and audits. This ensures accurate reporting for all accounts, regardless of their status.
Original PR description
In replacing the deprecated field with the special `active` field the account_codes prefix engine no longer displays values for accounts that are inactive.
This disables the active test in:
- computing the domain for accounts
- auditing the value (since the domain is `('account_id.code', 'in'...)`
opw-5226153
Forward-Port-Of: odoo/enterprise#101540
Forward-Port-Of: odoo/enterprise#100885This update adds a field to the salary configuration to allow users to specify the correct bank account holder name. This is a security enhancement to prevent payment delays caused by incorrect account holder information, ensuring timely and accurate payroll processing. Related tests and documentation have also been updated.
Original PR description
Law is now more secure and you need to have the correct name on the bank account holder otherwise payment need to be manually confirmed everytime. Therefore a field is added to the salary config to allow the user to set his account holder name separately from his actual name in case it is different. Task-5222712 [Related PR](https://github.com/odoo/odoo/pull/233965) Forward-Port-Of: odoo/enterprise#98572
This update prevents non-member internal users from seeing a misleading close confirmation dialog when closing a livechat window. Previously, this dialog incorrectly suggested they could end the session, leading to a confusing user experience. Now, non-members simply close the window without any prompts, ensuring a clearer and more accurate livechat interaction.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When an internal user who is not a member of a livechat channel opens a chat window for a…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When an internal user who is not a member of a livechat channel opens a chat window for a conversation in “looking for help” mode, closing the window incorrectly displays the Leave Conversation confirmation dialog. This is misleading because non-members cannot actually end the livechat session—the confirmation dialog suggests an action they do not have permission to perform. **Current behavior before PR:** ---------------------------------------------- - Non-member internal users see the close confirmation dialog - The dialog implies they can leave/end the livechat, which is not true - UI shows functionality that does not apply to them - Poor user experience and inconsistent behavior **Desired behavior after PR is merged:** ---------------------------------------------- - Confirmation dialog is shown only to actual livechat members(assigned agent or visitor) - Non-members close the chat window immediately without any prompt - UI accurately reflects real permissions - Clearer and more consistent livechat experience Task-5384846 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at https://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240029
This pull request resolves a bug in the Salary Calculator that prevented it from displaying correctly when an employee had a resource calendar assigned. The fix ensures the calculator functions properly regardless of whether an employee is linked to a calendar, improving payroll accuracy. This impacts all users who utilize the Salary Calculator feature.
Original PR description
This commit fixes an issue in the Salary Calculator where all fields were displayed as empty when selecting an employee with a resource_calendar_id set. Steps to Reproduce : First Change to either…
This commit fixes an issue in the Salary Calculator where all fields were displayed as empty when selecting an employee with a resource_calendar_id set. Steps to Reproduce : First Change to either the default company (MyCompany) or Demo Belgian company Payroll -> Employee -> Salary Calculator -> choose an employee. Bug : All fields in the Salary Calculator view are empty (evaluated as False). Root Cause : Inside _compute_salary, the method _generate_salary_simulation_payslip writes on payslip.version_id using: payslip.version_id.write(new_payslip_vals) Because the is_simulation_offer key was missing from the context, this write triggered a full payslip computation, generating payslip lines. During this computation, compute_sheet() performs an unlink() on existing payslip lines. Since the Salary Calculator view fields are only cached at that point, the unlink causes the cached values to be lost, resulting in all fields being evaluated as False. Fix : Ensure that is_simulation_offer is present in the context when writing to payslip.version_id, preventing payslip line generation and avoiding the unintended unlink() during salary simulation. Task - 5387155
This update fixes a technical error that prevented some users from opening timesheets, specifically when using the demo data. The fix involves adjusting menu sequences and granting necessary access permissions to ensure all users can correctly access and manage their timesheets. Additionally, a problem with fake data generation was resolved to prevent validation errors.
Original PR description
Steps to reproduce: - Login through user who has user:own timesheets only access or group_hr_timesheet_user only (basically `user demo` when demo data is installed). - Open timesheets apps. Issue: -…
Steps to reproduce: - Login through user who has user:own timesheets only access or group_hr_timesheet_user only (basically `user demo` when demo data is installed). - Open timesheets apps. Issue: - Traceback appears. Reason: - Here due to manually pushing `Timesheet Assistant Menu` having lower sequence(7) than `My Timesheets` (default sequence 10), so action is called which tries to search for which a base user will never have access to. Thus a traceback. - Also own timesheets user doesnt have access to `aw.rule` model which is need to open `Timesheet Assistant Menu`. Fixes: - Added sudo to search through action windows which is needed. - Reorder menu items sequence so we have `My Timesheets` in the starting and then `Timesheet Assistant Menu` is loaded. - Added a entry in model access CSV to give read access to aw.rule model records. Another small issue was when we generate fake data using `AwFakeEventsService` we source out all type of projects and tasks, which might cause some errors as they dont have account_id needed to make timesheets thus throwing validation on save. Fixed that by adding domain in fetch non-template data. task-5438048
A technical issue with a test for the HTML editor's link functionality was resolved. The fix addressed a problem where the test wasn't waiting properly, causing the link popover to close prematurely and disrupting subsequent steps. This ensures the link functionality works reliably.
Original PR description
Description of the issue this PR addresses: This test was not awaiting a step properly which somehow moved the selection to the overlay container which made the link popover to close resulting in further steps not working properly. runbot-234926 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a sporadic failure in the stock barcode tour due to timing issues. By adding a check to ensure data is loaded before proceeding, the tour now runs reliably. The changes also simplify the tour and add extra steps to prevent future disruptions.
Original PR description
Test `test_no_split_uncompleted_done_move` is failing non-deterministically after https://github.com/odoo/enterprise/pull/98184 Because it was going too fast and sometimes the lines wouldn't have been loaded by the time its the step's turn. A check was added in order to make sure the lines are loaded before moving onto the next steps This commit also simplifies the tour and adds extra steps to avoid failure. Runbot: 234351 Forward-Port-Of: odoo/enterprise#100329
This update resolves a technical issue related to how the system supports Peppol document types. The old CNAME logic has been removed, aligning with the current Peppol standard (NAPTR). This ensures correct document handling when using the DK Company accounting module.
Original PR description
The function `_check_document_type_support` is extended in `l10n_dk_nemhandel` (from `account_peppol`). The function causes an issue since it contains the old CNAME logic while peppol does not use it anymore; but the newer NAPTR. This commit removes the function - It does not do anything different than the version in `account_peppol` (and it would cause issues if it did) - The function is only called in `account_peppol` - The module does not depend on `account_peppol` Reproduce: - Install `l10n_dk_nemhandel`; check that `account_peppol` is installed - Select `DK Company` - Activate Peppol in test mode - Go to the `DK Company` contact (customers) - Select "By Peppol" and "EU Standard (Peppol Bis 3.0)" - Traceback should appear opw-5232123 Forward-Port-Of: odoo/odoo#241237 Forward-Port-Of: odoo/odoo#241083
A recent update introduced a bug related to currency changes in payment journals. Specifically, when multiple payment methods with different accounting accounts are used, a 'singleton error' occurred. This fix resolves this issue, ensuring accurate currency conversions and preventing payment processing disruptions.
Original PR description
036530a8983e485ac1ad0b9444a6aba01caabc07 introduced a bug, because it can happen to have 2 (or more) payment method lines from the same payment method. If these PML have differents payment accounts, we get a singleton error. Steps: - On Bank journal, add a new outbound payment method line, which use the same payment method as the first default one (it should be 'Manual') - Set two different payment account for each line - Then change the currency of the journal -> Traceback (singleton error) opw-5384042 Forward-Port-Of: odoo/odoo#239521
This update fixes an issue where multiple loyalty programs on a product could cause incorrect discount application during POS orders. By adding a 'mutex' to control program updates, the system now reliably applies all discounts, ensuring accurate order totals. This improves the customer experience and prevents revenue loss.
Original PR description
When adding a lot of loyalty programs with discounts to an order the updatePrograms method could be called multiple times in parallel, that would cause an issue where some of the programs were not…
When adding a lot of loyalty programs with discounts to an order the updatePrograms method could be called multiple times in parallel, that would cause an issue where some of the programs were not applied correctly. Steps to reproduce: ------------------- * Create 7 loyalty programs that apply on the same product, each with a discount reward of 10%. (Give them different name) * Create a POS order with 1 unit of that product. > Observation: Only the 6 first programs are applied. Why the fix: ------------ The issue is happening because the updatePrograms is called multiple times in parallel, and when coming to this block of code : https://github.com/odoo/odoo/blob/f3e74f9b840efef7c567ba31acd6ac61c79b5d6d/addons/pos_loyalty/static/src/overrides/models/pos_store.js#L182-L188 The last program has 2 coupons in the `couponPointChanges`, so it will proceed to delete all the coupons of the concerned program. To avoid this we use a mutex to ensure that only one call to updatePrograms is happening at a time. opw-4974788 Forward-Port-Of: odoo/odoo#241023 Forward-Port-Of: odoo/odoo#239662
This update fixes a visual inconsistency in the Point of Sale (POS) interface. Previously, product images were always displayed in combo product configurations, regardless of the overall image visibility setting. Now, combo product configurations correctly reflect the configured image settings, ensuring a consistent and professional user experience.
Original PR description
Before this commit: ==================== In POS, when product images were configured to be hidden, the setting was correctly applied to normal products. However, in the combo product configurator, product images were still displayed, causing inconsistency with the configured behavior. After this commit: ====================== The combo product configurator now respects the product image visibility configuration, ensuring consistent behavior across all product types in the POS interface. Task-5163955 Forward-Port-Of: odoo/odoo#241257 Forward-Port-Of: odoo/odoo#231366
This update refines the visual appearance of the chat interface within Odoo, specifically in the Discuss app sidebar and chat bubbles. The changes reduce icon sizes and adjust spacing to improve readability and the overall user experience.
Original PR description
- reduce size of livechat status icon, thread icons, and im status in discuss app sidebar - reduce size of livechat status icon, thread icons, im status, and country flag in chat bubble - reduce slightly size of chat bubble and compensate with slightly increased gap between bubbles - fix spacing issue between hidden chat bubbles and visible chat bubbles Before / After <img width="593" height="890" alt="Screenshot 2025-12-24 at 13 36 01" src="https://github.com/user-attachments/assets/3ce8fec0-f842-49d9-9691-fe6d1666cd07" /> Before / After <img width="165" height="418" alt="Screenshot 2025-12-24 at 13 36 14" src="https://github.com/user-attachments/assets/bac55e93-bade-4d09-be51-21a768896675" />
15 changes
Enhancements to existing features
This update clarifies the filter options within the account follow-up reporting feature. It now specifically targets 'Overdue Customer Invoices,' making it easier for users to identify and manage overdue payments. This enhancement improves the accuracy and efficiency of financial reporting.
Original PR description
opw-5232434 Forward-Port-Of: odoo/enterprise#100595
Resolved issues and error corrections
This update resolves a bug where the 'convert to task' option repeatedly appeared for converted Todo items. The fix hides this option when a project is assigned, streamlining the process and preventing unnecessary conversions. This improves user experience and data consistency.
Original PR description
Steps to reproduce: - Create a Todo and convert into task using cog Menu option. - Todo is converted to task and is displayed. - Through breadcrumb go back to Todo - Try to convert it again Issue: - The converted todo is again converted (change of project etc) Fix: - Hiding the convert cog menu when a project is set. task-5075327 Forward-Port-Of: odoo/odoo#240821 Forward-Port-Of: odoo/odoo#230031
This update fixes an issue where the 'late' filter on deliveries was incorrectly showing all outgoing pickings, regardless of their status. The change adds a necessary separator between filters, ensuring that users only see deliveries marked as 'late'.
Original PR description
Issue: ------------------------------------------ When opening deliveries and applying the 'late' filter, the results show: - All `outgoing pickings`, regardless of whether they are `late` or not,…
Issue: ------------------------------------------ When opening deliveries and applying the 'late' filter, the results show: - All `outgoing pickings`, regardless of whether they are `late` or not, and - All `late pickings`, regardless of their `picking type`. In short: `Deliveries OR Late`. The same issue occurs with other picking types as well. How to reproduce: ------------------------------------------ 1. Install stock. 2. Open deliveries through operations menu. 3. Apply 'late' filter. Cause of the issue: ------------------------------------------ There is no `seperator` between `picking_type_code` and `date_category` filters, so OR operator is applied between them. Solution: ------------------------------------------ Added `seperator` between `picking_type_code` and `date_category`. which now shows only the outgoing pickings which are late. In short: `Deliveries AND Late`. This helps users to apply filters like: Find deliveries that are late. Task ID: [4614363](https://www.odoo.com/odoo/project/966/tasks/4614363) Forward-Port-Of: odoo/odoo#201344
This update fixes a minor inconvenience for users. Previously, clicking 'Jump to Present' would cause the composer to lose focus, requiring manual adjustment. Now, the composer automatically regains focus on desktop after this action, improving the user experience.
Original PR description
**Current behavior before PR:** clicking "Jump to Present" caused the composer to lose focus, forcing users to manually focus the input before typing. **Desired behavior after PR is merged:** The composer automatically regains focus on desktop after clicking "Jump to Present". task-[5035977](https://www.odoo.com/odoo/project/1519/tasks/5035977) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240994 Forward-Port-Of: odoo/odoo#227781
This update ensures that product images are hidden in the combo product configurator, aligning with the overall POS settings for product image visibility. Previously, combo products displayed images regardless of the configured settings, creating a confusing user experience. This change improves consistency and simplifies the product selection process for customers.
Original PR description
Before this commit: ==================== In POS, when product images were configured to be hidden, the setting was correctly applied to normal products. However, in the combo product configurator, product images were still displayed, causing inconsistency with the configured behavior. After this commit: ====================== The combo product configurator now respects the product image visibility configuration, ensuring consistent behavior across all product types in the POS interface. Task-5163955 Forward-Port-Of: odoo/odoo#240997 Forward-Port-Of: odoo/odoo#231366
This update resolves a technical issue causing a traceback when using Peppol integration for Danish companies. The outdated CNAME logic has been removed, aligning with current Peppol standards (NAPTR). This ensures proper Peppol functionality and a smoother user experience.
Original PR description
The function `_check_document_type_support` is extended in `l10n_dk_nemhandel` (from `account_peppol`). The function causes an issue since it contains the old CNAME logic while peppol does not use it anymore; but the newer NAPTR. This commit removes the function - It does not do anything different than the version in `account_peppol` (and it would cause issues if it did) - The function is only called in `account_peppol` - The module does not depend on `account_peppol` Reproduce: - Install `l10n_dk_nemhandel`; check that `account_peppol` is installed - Select `DK Company` - Activate Peppol in test mode - Go to the `DK Company` contact (customers) - Select "By Peppol" and "EU Standard (Peppol Bis 3.0)" - Traceback should appear opw-5232123 Forward-Port-Of: odoo/odoo#241083
This update fixes an issue in the Hungarian localization where e-invoices incorrectly used the invoice date to calculate currency exchange rates. The fix ensures the currency rate is based on the invoice delivery date, aligning with Hungarian tax regulations. This ensures accurate e-invoice generation and compliance.
Original PR description
In the Hungarian localization, the currency exchange rate for invoices is based on the delivery date. Steps to reproduce: - With HU localization setup - Create an invoice Issue: Currently, when issuing the e-invoice, the system would compute the currency exchange rate using the invoice date. opw-5126816 Forward-Port-Of: odoo/odoo#240999
This update fixes an issue where the ClickEverywhere function would incorrectly test all applications after a page reload. By storing the specific application's XML ID, the function now accurately targets the intended application, ensuring consistent and reliable test execution. This prevents unnecessary testing and improves the overall stability of the testing process.
Original PR description
The clickEverywhere function can be executed with one app. To accomplish this, the xmlID should be passed as a parameter to the function. Before this commit, the xmlID of the requested application was not stored in the status of the current execution saved in localStorage. If a reload occurs while the clickEverywhere function is executing, it will lose this information and continue testing all applications instead of only the requested one. runbot.build.error: 234747 Forward-Port-Of: odoo/odoo#240943
This update fixes a minor inconsistency in the documentation for our phone number handling features. The previous documentation incorrectly referenced a method that was never actually used. This change ensures the documentation accurately reflects the current codebase, improving clarity for developers.
Original PR description
A mention to `_voip_get_phone_field` appeared in [1] but this seems to never have existed. In any case, `_phone_get_number_fields` was used by the codebase in the end and should thus be the one mentioned. [1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd Forward-Port-Of: odoo/enterprise#102804
This update streamlines the planning process by automatically notifying managers when employee work emails are missing. Instead of being blocked by a manual wizard, users receive a list of employees needing email information, allowing for quick action like removal or escalation to HR. This improves efficiency and prevents delays in sending plans.
Original PR description
Before this commit, when the planning manager wants to send the planning and for some employees the work email is missing, the user is blocked on the wizard to fill the work email on those employees if he does not edit access to employee model. This commit makes sure the wizard to fill in the missing work email is not displayed if the user cannot edit the information of the employees. It also displays a notification listing the employees for which the work email is missing. By doing that, the user can easily remove those employees to continue his flow or ask to HR user or the employees concerned to complete the missing information. task-5090163 Forward-Port-Of: odoo/enterprise#102458 Forward-Port-Of: odoo/enterprise#96111
This update enhances the way Odoo retrieves the IP address of IoT devices. Previously, it relied on a public DNS server, which failed when the device was connected to a router without internet access. Now, it connects to the gateway, ensuring functionality even in offline scenarios.
Original PR description
To get the local IP address of the IoT Box, we used to create a connection to a public DNS server and parsed the output to get the source of the request (our IP). In case the IoT Box is connected to a router, but the router isn't connected to the internet, our solution fails. We now create the connection to the gateway instead, so it can work offline. Forward-Port-Of: odoo/odoo#241051
This update fixes an issue where deferred accounting for misc entries wasn't correctly identifying the appropriate account type. The change now analyzes each deferred line individually, ensuring deferrals are linked to the correct expense or revenue account, enhancing financial accuracy. This improves the handling of complex transactions.
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 critical bug that caused Odoo to crash when sending invoices via Peppol with invoice lines lacking a product name. Now, the system gracefully displays an error message, guiding users to ensure each invoice line has a product or label before sending. This improves invoice processing reliability and prevents data loss.
Original PR description
Before this commit: When sending an invoice via Peppol with an invoice line that has no product name, the system crashes with a TypeError instead of showing a error message. Steps to reproduce: 1. Go to Accounting 2. Navigate to Customers > Invoices 3. Create a new invoice 4. Add an invoice line without entering a product name 5. Click 'Send' 6. Select 'by Peppol (Demo)' 7. Click 'Send' -> TypeError: 'NoneType' object is not subscriptable After this commit: System validates that the product name exists before accessing its text content. Users see a clear, error message: `Each invoice line should have a product or a label.` task-5432061 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240908
This update resolves a technical error that prevented loyalty cards from being correctly applied during POS transactions. The issue stemmed from incorrect data being passed to the system, specifically a list of customer IDs instead of a single ID. This fix ensures loyalty card codes function as expected, improving the customer experience.
Original PR description
Steps: ------------ - Install pos_sale_loyalty. - Create a loyalty program of type loyalty, available for both Sales and POS. - Create a sale order with simultaneous customer creation and confirm it. - Open POS and enter code of the loyalty card generated from the sale order. Issue: ------------ - A traceback occurs with: Error: Invalid ids list. Cause: ------------ - A list of partner IDs was passed, where a single partner ID was expected. Fix: ------------ - Extract and pass the correct partner ID instead of the full partner ID list. Task-5388341 Forward-Port-Of: odoo/odoo#241167 Forward-Port-Of: odoo/odoo#239582
This update resolves a bug that occurred when changing the currency of a journal, specifically when multiple payment method lines used different payment accounts. This prevented accurate recording of payments and could lead to inconsistencies. The fix ensures correct currency handling during journal changes.
Original PR description
036530a8983e485ac1ad0b9444a6aba01caabc07 introduced a bug, because it can happen to have 2 (or more) payment method lines from the same payment method. If these PML have differents payment accounts, we get a singleton error. Steps: - On Bank journal, add a new outbound payment method line, which use the same payment method as the first default one (it should be 'Manual') - Set two different payment account for each line - Then change the currency of the journal -> Traceback (singleton error) opw-5384042 Forward-Port-Of: odoo/odoo#239521
16 changes
Enhancements to existing features
This update clarifies the 'Overdue Customer Invoices' filter within the account follow-up reporting feature. This ensures users can more accurately identify and manage overdue invoices, leading to better cash flow tracking and improved financial reporting. The change is a minor improvement to existing functionality.
Original PR description
opw-5232434 Forward-Port-Of: odoo/enterprise#100595
This update enhances the synchronization of product data within the Point of Sale module. Specifically, the system now uses unique record identifiers (UUIDs) for more accurate data mapping and includes improved category linkage in testing. This ensures data consistency and reliability for Point of Sale operations.
Original PR description
In this commit: --- - Improved `sync_from_ui` function to support record UUID-based relational mapping. - Added `pos_categ_ids` field in product data for better category linkage in tests. task-5225193 Related PR: - https://github.com/odoo/enterprise/pull/98849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the testing process for the POS Restaurant module's preparation display functionality. By adding Hoot tests and a dedicated test environment, the team is ensuring greater reliability and accuracy of this key feature, reducing potential issues before they impact users.
Original PR description
In this commit: --- - Added HOOT test coverage for the POS Restaurant module's preparation display. - Introduced `setupPosPrepDisplayEnv` to mock and initialize the preparation display test environment. - Added test coverage for core components, models, and service logic. - Adjust hoot case for pos_urban_piper. task-5225193 Related PR: - https://github.com/odoo/odoo/pull/234474
Resolved issues and error corrections
This update fixes an issue where the 'late' filter on deliveries was incorrectly returning all outgoing pickings, regardless of their status. The change adds a necessary separator between filters, ensuring that users only see deliveries that are genuinely marked as 'late'.
Original PR description
Issue: ------------------------------------------ When opening deliveries and applying the 'late' filter, the results show: - All `outgoing pickings`, regardless of whether they are `late` or not,…
Issue: ------------------------------------------ When opening deliveries and applying the 'late' filter, the results show: - All `outgoing pickings`, regardless of whether they are `late` or not, and - All `late pickings`, regardless of their `picking type`. In short: `Deliveries OR Late`. The same issue occurs with other picking types as well. How to reproduce: ------------------------------------------ 1. Install stock. 2. Open deliveries through operations menu. 3. Apply 'late' filter. Cause of the issue: ------------------------------------------ There is no `seperator` between `picking_type_code` and `date_category` filters, so OR operator is applied between them. Solution: ------------------------------------------ Added `seperator` between `picking_type_code` and `date_category`. which now shows only the outgoing pickings which are late. In short: `Deliveries AND Late`. This helps users to apply filters like: Find deliveries that are late. Task ID: [4614363](https://www.odoo.com/odoo/project/966/tasks/4614363) Forward-Port-Of: odoo/odoo#201344
This update resolves a technical issue preventing the correct display of tracebacks when using Peppol for DK Company invoices. The outdated CNAME logic has been removed, aligning with current Peppol standards and ensuring proper functionality. This change improves the user experience for Danish customers.
Original PR description
The function `_check_document_type_support` is extended in `l10n_dk_nemhandel` (from `account_peppol`). The function causes an issue since it contains the old CNAME logic while peppol does not use it anymore; but the newer NAPTR. This commit removes the function - It does not do anything different than the version in `account_peppol` (and it would cause issues if it did) - The function is only called in `account_peppol` - The module does not depend on `account_peppol` Reproduce: - Install `l10n_dk_nemhandel`; check that `account_peppol` is installed - Select `DK Company` - Activate Peppol in test mode - Go to the `DK Company` contact (customers) - Select "By Peppol" and "EU Standard (Peppol Bis 3.0)" - Traceback should appear opw-5232123 Forward-Port-Of: odoo/odoo#241083
This update fixes an issue in the Hungarian localization where e-invoices incorrectly used the invoice date to determine currency exchange rates. Now, the system accurately uses the delivery date, as required for Hungarian e-invoice regulations. This ensures compliance and accurate financial reporting for transactions in the Hungarian market.
Original PR description
In the Hungarian localization, the currency exchange rate for invoices is based on the delivery date. Steps to reproduce: - With HU localization setup - Create an invoice Issue: Currently, when issuing the e-invoice, the system would compute the currency exchange rate using the invoice date. opw-5126816 Forward-Port-Of: odoo/odoo#240999
This update fixes an issue where the ClickEverywhere function would incorrectly test all applications after a page reload. By storing the application's XML ID, the function now accurately targets and tests only the intended application, ensuring more consistent and reliable test results. This prevents unnecessary testing time and potential errors.
Original PR description
The clickEverywhere function can be executed with one app. To accomplish this, the xmlID should be passed as a parameter to the function. Before this commit, the xmlID of the requested application was not stored in the status of the current execution saved in localStorage. If a reload occurs while the clickEverywhere function is executing, it will lose this information and continue testing all applications instead of only the requested one. runbot.build.error: 234747 Forward-Port-Of: odoo/odoo#240943
This update resolves an issue where deleting a Point of Sale order didn't properly remove associated order lines from local records. The fix corrects a technical problem related to how data was accessed, ensuring that all related items are now removed during order deletion. This improves data accuracy and prevents orphaned records.
Original PR description
Issue: Deleting an order did not remove its related order lines from local records. Cause: Because of the use of `lazyGetter`, model fields were defined as getters instead of object keys. This caused `Object.entries` to skip some fields, preventing cascade deletion from including child records. Fix: Updated the logic for computing `recordsToDelete` to correctly handle cascade deletion and ensure child records are properly removed. Task-5095578
This update fixes a technical error that prevented loyalty card codes from being properly applied in the POS system. The issue stemmed from incorrect data being passed, which caused an error. The fix ensures loyalty cards are correctly recognized and applied during transactions.
Original PR description
Steps: ------------ - Install pos_sale_loyalty. - Create a loyalty program of type loyalty, available for both Sales and POS. - Create a sale order with simultaneous customer creation and confirm it. - Open POS and enter code of the loyalty card generated from the sale order. Issue: ------------ - A traceback occurs with: Error: Invalid ids list. Cause: ------------ - A list of partner IDs was passed, where a single partner ID was expected. Fix: ------------ - Extract and pass the correct partner ID instead of the full partner ID list. Task-5388341 Forward-Port-Of: odoo/odoo#239582
This update resolves a technical issue where setting zero quantities in the stock module caused unexpected behavior during quantity calculations. The fix ensures the system correctly handles this scenario, preventing potential errors and maintaining accurate stock levels. This improves the reliability of stock management processes.
Original PR description
The foward port https://github.com/odoo/odoo/pull/239918 did not correctly handle the new `skip_qty_available_update` flag when setting 0.0 quantities, causing some side effects when `_compute_quantities` is run. This commit correctly adds the flag in the needed cases. Forward-Port-Of: odoo/odoo#241000
This update enhances how Odoo retrieves the IP address of IoT Boxes. Previously, it relied on a public DNS server, which failed when the IoT Box was connected to a router without internet access. Now, it uses the gateway's IP address, ensuring functionality even in offline scenarios.
Original PR description
To get the local IP address of the IoT Box, we used to create a connection to a public DNS server and parsed the output to get the source of the request (our IP). In case the IoT Box is connected to a router, but the router isn't connected to the internet, our solution fails. We now create the connection to the gateway instead, so it can work offline. Forward-Port-Of: odoo/odoo#241051
This update streamlines the planning process by automatically notifying users when employee work emails are missing. Instead of a blocked wizard, users receive a list of employees needing email information, allowing for quick action like removal or requesting completion from HR. This improves efficiency and prevents delays in sending plans.
Original PR description
Before this commit, when the planning manager wants to send the planning and for some employees the work email is missing, the user is blocked on the wizard to fill the work email on those employees if he does not edit access to employee model. This commit makes sure the wizard to fill in the missing work email is not displayed if the user cannot edit the information of the employees. It also displays a notification listing the employees for which the work email is missing. By doing that, the user can easily remove those employees to continue his flow or ask to HR user or the employees concerned to complete the missing information. task-5090163 Forward-Port-Of: odoo/enterprise#102458 Forward-Port-Of: odoo/enterprise#96111
This update resolves an issue where refunding and canceling orders in Point of Sale (POS) would sometimes lead to a blank screen and errors. The fix ensures that related order data is properly removed when a refund or order cancellation is performed, improving the stability and reliability of the POS system.
Original PR description
Step to reproduce: (try this in 19.0) - open pos and settle a order - refund the same order, from payment screen, go back to product screen - cancel this order - again try to refund the same order…
Step to reproduce: (try this in 19.0)
- open pos and settle a order
- refund the same order, from payment screen, go back to product screen
- cancel this order
- again try to refund the same order
Observation:
- Blank screen with traceback in console
```
Caused by: TypeError: Cannot read properties of undefined (reading 'state')
at Proxy.reduce (<anonymous>)
at get refundedQty
```
Cause:
- refundedQty() reads refund_orderline_ids.order_id.
- On the first refund cancellation, the refund was deleted but its related order_line was not.
- Order deletion relies on localDeleteCascade, which uses Object.entries() to find related records to delete.
- With lazy getters, this fails because Object.entries() does not expose or execute getter-based properties.
Fix:
- as we already have keys `relationsToDelete`, we pull the value, which execute the getter and we will have the needed data.
- Fixed the test, as for new order, we expect the newer orderline, older ones
should be deleted.
opw-5379747
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects a technical issue where unused sign item roles were accumulating in the database, preventing them from being removed. A temporary 'dummy' sign item is now automatically created for each new role, enabling the system to properly clean up these orphaned roles and maintain database efficiency. This ensures a cleaner and more stable sign management process.
Original PR description
Fixes an issue where sign item roles were created but never deleted if they had no sign items linked to them. These orphaned roles were no longer shown in the app and remained in the database indefinitely. To address this, a dummy sign item is now created for each new sign item role. This allows the autovacuum logic to detect and automatically clean up unused roles and dummy items. Without this dummy item, it would be impossible to determine if a role is truly orphaned. task-4971485 Forward-Port-Of: odoo/enterprise#91189
A recent update introduced a bug that caused errors when changing the currency of a journal, specifically when multiple payment methods with different accounts were used. This fix ensures that currency changes are handled correctly, preventing errors and maintaining accurate payment records. The change improves the reliability of our payment processing system.
Original PR description
036530a8983e485ac1ad0b9444a6aba01caabc07 introduced a bug, because it can happen to have 2 (or more) payment method lines from the same payment method. If these PML have differents payment accounts, we get a singleton error. Steps: - On Bank journal, add a new outbound payment method line, which use the same payment method as the first default one (it should be 'Manual') - Set two different payment account for each line - Then change the currency of the journal -> Traceback (singleton error) opw-5384042 Forward-Port-Of: odoo/odoo#239521
This update resolves a recurring test failure in the MRP planning module. The test has been redesigned to manually create the leave, eliminating a specific configuration requirement that triggered the error. This ensures the test consistently runs without failure, improving overall system stability.
Original PR description
Before this commit: Introduced in https://github.com/odoo/odoo/commit/d06dcfbca96273b540c87252b9188603879ac1b4, the test was failing on runbot in some cases. The issue is deterministic, but requires a specific set of modules installed to fail. After this commit: Use a more robust approach in the test, by creating the leave manually instead of computing the number of operations needed. runbot-234638 Forward-Port-Of: odoo/odoo#239717
4 changes
Enhancements to existing features
This update clarifies the filter options within the account follow-up module to specifically target 'Overdue Customer Invoices'. This change ensures that users can more easily identify and manage overdue payments, leading to better cash flow tracking and improved financial reporting. The update was made to enhance the usability of a key reporting feature.
Original PR description
opw-5232434 Forward-Port-Of: odoo/enterprise#100595
Resolved issues and error corrections
This update restores the intended behavior for the Knowledge composer by hiding the GIF and canned response actions. These features were previously visible after a recent update, but this change ensures they are hidden when creating content in Knowledge, streamlining the user experience.
Original PR description
The GIF picker was previously hidden in Knowledge, but became visible again after the composer actions refactor. Commit that introduced the change: https://github.com/odoo/odoo/commit/5e1daafeac231c333ea13369fc208627213d67d4 This commit restores the intended behavior by hiding the GIF action again and also hides the canned response action, as neither feature is relevant when composing content in Knowledge, by applying conditions on the corresponding composer actions. Task-5163888
This update corrects a technical issue within the Web Studio report editor, ensuring accurate data display in reports. The fix resolves a discrepancy in how the system identifies report headers and footers, leading to a more reliable and consistent user experience. This improves the overall quality of reports generated through Web Studio.
Original PR description
Issue: getQwebVariables returns isEditingFooterHeader, but isInHeaderFooter was read from it Cause of the issue: e2eed2b71647de29905bcc1a40c3c540d2a87e47 Forward-Port-Of: odoo/enterprise#102693 Forward-Port-Of: odoo/enterprise#102543
This update resolves a stability issue in our database tests related to sign item roles. By using the record's creation date instead of modification date, the test now consistently identifies and removes outdated roles, ensuring more reliable test results. This improves the overall quality and predictability of our sign functionality.
Original PR description
This PR updates the test_gc_removes_orphan_roles_and_dummy_items test to rely on the create date instead of the write date, ensuring records are treated as old and making the test more deterministic. task-4971485
9 changes
New functionality added to Odoo
This update adds support for filing the GSTR-9 report, a crucial annual GST return required by Indian businesses. It integrates data from previous returns and accounts to ensure accurate reporting for tax compliance by December 31st. This enhancement supports businesses with annual turnover under ₹2 crore, simplifying their GST filing process.
Original PR description
This **PR** introduces support for GSTR-9 report. GSTR-9 is an annual GST return that registered taxpayers, including SEZ units, must file for each financial year. It includes details from previously filed returns (GSTR-1, 2A, and 3B) and the books of accounts. The form covers annual sales, taxable and non-taxable transactions, inward supplies, ITC claimed, and ITC reversals. The GSTR-9 filing is due by December 31st of the following year and is optional for taxpayers with a turnover of less than ₹2 crore. **task**-4169682 **Community PR** - https://github.com/odoo/odoo/pull/179923
Enhancements to existing features
This update streamlines the bank account experience by simplifying data management and addressing inconsistencies across different countries. The changes remove redundant models and ensure key fields are consistently available, leading to a more user-friendly and reliable process for managing bank statements and transactions.
Original PR description
This commit improves the UX of bank accounts by: 1. removing res.bank model 2. removes localizations redundancy 3. some fields in localizations should be available to all companies 4. most countries had missing fields task-5145618
Resolved issues and error corrections
This update fixes a calculation error in the product reporting module for Peru (l10n_pe). The initial product value was incorrectly set to zero, leading to inaccurate out-move reporting. This change ensures that product values are correctly calculated, reflecting the actual cost and improving reporting accuracy.
Original PR description
Since we create a product value with the initial cost of the product we need to adapt this test. Since it creates the product during the setup at date of today. It will register the current value of the product as 0. When you deliver it will take the current cost so 0. Thus the out move won't have any value. Forward-Port-Of: odoo/enterprise#102791
This update strengthens our point-of-sale testing process by ensuring that ticket generation tests accurately simulate real-world scenarios. The tests now correctly initialize tickets and validate them against printer models, leading to more reliable test results and improved product quality. This addresses a previous issue where tests were not fully representative of the actual ticket generation workflow.
Original PR description
Previously, ticket-generation tests relied on manual render calls, bypassing initialization logic and missing key method flows. This update refactors the test utilities to mimic real-life execution: tickets are now initialized via the main generation methods, and the final printed ticket is validated through the printer model. Task-5391327 Related: https://github.com/odoo/odoo/pull/238824
This update improves the customer experience by adding the delivery OTP directly to the receipt. Previously, the receipt only displayed the delivery address, creating confusion for customers. This change ensures customers have immediate access to the OTP needed for delivery.
Original PR description
Before this commit: --------- - Delivery OTP was not shown on the receipt. - Receipt only displayed delivery address without any OTP. After this commit: ------------------- - Display “Delivery OTP ” below the delivery address on the receipt. Task-5048040
This update fixes a minor inconsistency in the documentation for our phone system features. The previous documentation incorrectly referenced a method that was never actually used. This change ensures the documentation accurately reflects the current codebase, improving clarity for our support team and developers.
Original PR description
A mention to `_voip_get_phone_field` appeared in [1] but this seems to never have existed. In any case, `_phone_get_number_fields` was used by the codebase in the end and should thus be the one mentioned. [1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd Forward-Port-Of: odoo/enterprise#102804
This update fixes an issue where opening invalid account return checks could display all `account.move.line` records, even when only one or zero matching records existed. The change ensures that the correct number of records are displayed, preventing unnecessary data loading and improving reporting accuracy.
Original PR description
Before this PR, opening invalid records from account return checks could show all `account.move.line` records when there were 0 or 1 matching record(s). Technical Reason: In `_get_records_action` domain is only applied when there are multiple records, so without a domain, all records are opened. With this PR, the domain is passed through the method arguments, and also action will be none if there are no records. task-5427746 Forward-Port-Of: odoo/enterprise#102424
Code cleanup and technical improvements
This update simplifies the way document folders are displayed in search panels by returning raw data from the model and allowing the client to handle the formatting. This change improves the search panel's performance and maintainability, ensuring a smoother user experience when navigating document folders.
Original PR description
We're choosing to keep the model method cleaner and return the raw field value, and let the client convert to number to construct the folders' tree. We're also setting the method as readonly as it does not modify data. Task-5272030
This update replaces Float fields with Monetary fields across several Point of Sale modules (pos, pos_online_payment, l10n_se_pos, pos_pricer). This ensures accurate and consistent display of currency values in views and improves data integrity for financial transactions. It's a necessary update to align with Odoo's financial standards.
Original PR description
`point_of_sale`, `pos_online_payment`, `l10n_se_pos`, `pos_pricer` before this commit: ============== - Using Float fields to display currency values. - Some views did not display monetary data correctly,. after this commit: ============== - All currency-related fields have been replaced with Monetary fields instead of Float fields. - Views have been updated to follow the new approach for displaying monetary data consistently. Related community PR: odoo/odoo#191740 Related upgrade PR: odoo/upgrade#7298 Task-4424052
9 changes
Enhancements to existing features
This update clarifies the 'Overdue Customer Invoices' filter within the account follow-up reporting feature. This change ensures users can more accurately identify and manage overdue invoices, leading to better cash flow tracking and improved customer relationships. The update was implemented as an improvement to existing reporting functionality.
Original PR description
opw-5232434 Forward-Port-Of: odoo/enterprise#100595
Resolved issues and error corrections
This update fixes an inaccuracy in the documentation for our phone number handling features. The previous documentation incorrectly referenced a method that didn't exist, and has now been updated to accurately reflect the correct method used in the code. This ensures clarity for developers and improves the overall quality of our documentation.
Original PR description
A mention to `_voip_get_phone_field` appeared in [1] but this seems to never have existed. In any case, `_phone_get_number_fields` was used by the codebase in the end and should thus be the one mentioned. [1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd Forward-Port-Of: odoo/enterprise#102804
This update resolves a recurring issue in the MRP barcode tour that was failing intermittently. The fix adds a check to ensure all necessary data is loaded before proceeding, preventing errors caused by timing conflicts. The tour has also been simplified with additional steps to ensure consistent functionality.
Original PR description
Test `test_no_split_uncompleted_done_move` is failing non-deterministically after https://github.com/odoo/enterprise/pull/98184 Because it was going too fast and sometimes the lines wouldn't have been loaded by the time its the step's turn. A check was added in order to make sure the lines are loaded before moving onto the next steps This commit also simplifies the tour and adds extra steps to avoid failure. Runbot: 234351
This update resolves an issue where tax mappings weren't correctly set when upgrading to version 19.0, leading to errors during session closing with Fiskaly. The fix ensures accurate data transmission to Fiskaly, particularly when company names or cash move reasons contain hyphens, preventing transaction failures.
Original PR description
Steps to reproduce: ------------------------- - Upgrade from lower version to 19.0 or higher. - Start a fiskaly registered company's session. - Close the session after transactions. Issue: ------- -…
Steps to reproduce:
-------------------------
- Upgrade from lower version to 19.0 or higher.
- Start a fiskaly registered company's session.
- Close the session after transactions.
Issue:
-------
- Tax mapping used to send data to fiskaly is not set.
- If have `-` in company name or cash move reason and try to do cash move will give a tb.
Cause:
---------
- When the user's database is upgraded, the taxes already exist and the company is already registered. As a result, `l10n_de_vat_export_data` is never set, and since no tax changes occur, `l10n_de_vat_definition_export_identifier` is also not generated. This leads to incorrect values being sent to Fiskaly during the session closing request, causing errors.
- The cash statement name uses - as a separator, the current structure is `{session_name}-{move_type}-{statement_type}-{move_reason}` set from `_prepare_account_bank_statement_line_vals()` If move_reason or company name contains additional `-` splitting the whole name breaks the expected structure.
Fix:
-----
- We have added a check to identify any taxes that are missing their tax mapping If such taxes are found, we filter them and trigger the logic to set their mappings. However, if the main mapping reference value l10n_de_vat_export_data is not set, we first retrieve and update it. Once this reference is available, we update all taxes that were previously unset and then prepare the correct tax data.
As a result, the first session closing after the upgrade will automatically correct all issues both for customers who have already upgraded and for those who upgrade in the future.
- We first remove the `{session_name}-` prefix, then split the rest. Since move_type and statement_type never contain -, we take them directly not user inputs, and then rejoin everything from index 2 onward to reconstruct the correct move_reason.
Additional fixes:
--------------------
- Some places the limit of characters may exceed than what fiskaly is asking than it can give us an error so restricted all places where needed.
- We don't have check if the settlement is present if not getting id directly may cause error.
help ticket: 5362897, 5367425This update resolves an issue with the processing of payroll data (DDP) within the Belgian HR payroll module. The fix ensures accurate calculations and reporting related to employee salaries, improving the reliability of payroll processing. This update primarily impacts the accounting and HR functionalities.
This update expands the functionality of the 'sign' module to align with the official ItsMe service's coverage. Previously, the system only supported itsme in Belgium and the Netherlands. This change ensures compatibility with a wider range of users and streamlines the sign-up process for those countries.
Original PR description
Extend itsme availability beyond BE and NL to match the official itsme coverage: https://www.itsme-id.com/en-BE/business/coverage task-5424818 Forward-Port-Of: odoo/enterprise#102423
This update fixes an issue where deferred accounting for misc entries wasn't correctly identifying the appropriate account type. The change now analyzes each deferred line individually, ensuring deferrals align with the actual account type of the line, leading to more accurate financial reporting. This improves the reliability of deferred accounting processes.
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 restores the ability to generate negative overtime (undertime) in attendance records. Previously removed to avoid financial losses, this feature is now re-enabled based on specific Absence Management settings, ensuring accurate time tracking and reporting for our clients.
Original PR description
…time generation
Miscellaneous changes
This pull request contains temporary changes to the Odoo Enterprise payroll module. These updates primarily involve adjustments to the HR payroll calculations and related views. The changes are awaiting further review and refinement before being fully implemented.
12 changes
Resolved issues and error corrections
This update resolves an issue where overlays disappear after refreshing the website editor in version 18.0 and later. The root cause was identified and corrected to ensure overlays are properly displayed during editor reloads. This improves the user experience when making website changes.
Original PR description
The bug is only observable after 18.4, after the website refactoring, but the root cause has been present since 18.0, so we fix it there in case there are other use cases. Since [1], overlays are no longer visible after an operation that executes `reloadEditor`. Steps to reproduce (observable after 18.4): - On website, go into edit mode - Change header template - After reload, overlays are missing Reason: `WebsiteBuilderClientAction.reloadEditor` sets up the new `Editor` before the old one is destroyed. Consequently, `LocalOverlayPlugin.destroy` removes the newest overlays as well. This commit ensures the plugin only cleans up its specific DOM elements. The order of operations bug will be fixed in a later PR. task-5438306 [1]: https://github.com/odoo/odoo/commit/3cd29fbac2b06566bfff40b5e7ed310cb0ce12c1
This update prevents unnecessary email reminders for timesheet approvals. It ensures reminders are only sent when there are actual timesheets needing attention, and when a user is correctly designated as a manager or approver – even if the employee doesn't have a manager assigned. This reduces email clutter and improves efficiency.
Original PR description
prevent cron from sending approver reminder if no timesheet assigned to approver Send the reminder email if: - there are timesheets to validate - AND if the user is set as either the manager or timesheet approver of an employee with timesheets left to be validated - OR if the said employee has no manager or timesheet approver set Task-3624610 Forward-Port-Of: odoo/enterprise#52355
This update resolves a problem where certain tests in the l10n_mx_edi module were consistently failing due to an incorrect date calculation. The change sets a standard test date in the middle of the year, ensuring all tests run reliably and accurately.
Original PR description
Some tests are making "self.frozen_today - timedelta(days=1)". It means some tests are failing only the first of January. To avoid that, let's make "frozen_today" to be in the middle of the year. Forward-Port-Of: odoo/enterprise#102772
This update corrects a previous error in the Profit & Loss report's Gross Profit calculation, now accurately including stock effects. Additionally, the report's UI has been simplified for better readability and user experience. This ensures more reliable financial reporting.
Original PR description
Previously, the Gross Profit calculation did not include the stock effect, which resulted in incorrect values. With this PR, the Gross Profit is now computed including the stock effect, ensuring accurate results. In addition, some UI adjustments have been made to simplify and improve the readability of the report. task-5357539 opw-5163207 master PR: https://github.com/odoo/enterprise/pull/101650
This update resolves a bug in the calendar functionality that prevented the 'knowledge_calendar_command_tour' tour from working correctly in Chrome 143 and later. The fix ensures events are dispatched properly when the calendar container is attached to a shadow tree, aligning with web standards and resolving a compatibility issue.
Original PR description
Tour "knowledge_calendar_command_tour" fails since Chrome 143 with an error "Cannot read properties of null (reading 'querySelectorAll')". This is due to the fix in Chromium "Fix target/relatedTarget…
Tour "knowledge_calendar_command_tour" fails since Chrome 143 with an error "Cannot read properties of null (reading 'querySelectorAll')". This is due to the fix in Chromium "Fix target/relatedTarget clearing logic during dispatch" [^1] introduced in Chrome 143, to actually match the spec [^2]. To quote the Chromium commit message: > According to the spec, only if the top node is in a shadow tree, both > the target and relatedTarget should be cleared. > However, if the top node is not in a shadow tree and not a document, > the target and relatedTarget are always cleared. Because the current > implementation only checks whether the top node is not a document. > So, this patch fixes the bug by checking whether the top node is in a > shadow tree. In practice, this means that events are now properly dispatched when the FullCalendar container's element is not connected to the document but still to the shadow tree. As a result, the OWL reference to this container can not exist anymore when the event handler is called but FullCalendar's API still has the right reference to this element. Note: Firefox and Safari already implemented the spec properly (aka. it was already broken for them...) [^1]: https://chromium.googlesource.com/chromium/src/+/63178146cd776eae2b466983f0835e86c314d051%5E%21/ [^2]: https://dom.spec.whatwg.org/#concept-event-dispatch
This update resolves an issue where scanning cashier barcodes would cause an error if employee logging was turned off. Now, the barcode scanning functionality works seamlessly regardless of whether employee logging is enabled, ensuring consistent operation for all users. This improves the reliability of the Point of Sale module.
Original PR description
Before this commit, if logging with employee was disabled, scanning a cashier barcode would raise an error. opw-5437310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where setting a Bill of Materials (BoM) and changing the production quantity in a manufacturing order could create duplicate work orders. The fix ensures that work orders are only created once during recalculation, preventing this duplication and streamlining the manufacturing process.
Original PR description
Steps to reproduce:
- Create a storable product "P1"
- Create a BoM with one operation
- Create a manufacturing order for product "P1"
- Do not set any BoM
- Save
- In draft state:
- Set the BoM
- Without saving, update the quantity to produce
Problem:
The same operation is added twice, resulting in duplicate work orders.
Cause:
Work orders are recomputed multiple times when BoM and quantity are changed before saving, and existing (not yet saved) work orders linked to the same BoM are not properly filtered out.
Fix:
Ensure that work orders linked to the current BoM are only created once during recomputation.
opw-5404686This update resolves issues with shared tables across multiple devices, preventing order modification errors and ensuring accurate payment processing. Specifically, it fixes synchronization problems related to online payments and ensures data consistency when managing tables in the Restaurant POS system.
Original PR description
`point_of_sale`, `pos_restaurant`, `pos_loyalty`, `pos_online_payment` ## Issue 1 - sync issue on shared tables across multiple devices ### Steps to Reproduce: - Open POS Restaurant in `two devices`…
`point_of_sale`, `pos_restaurant`, `pos_loyalty`, `pos_online_payment` ## Issue 1 - sync issue on shared tables across multiple devices ### Steps to Reproduce: - Open POS Restaurant in `two devices` (or `two different browsers`). - On Device 1: - Open any table & click on `Book Table`. - Add products & click the `Payment` button. (Do not validate the order) - On Device 2, open the same table and click on `Release Table`. - Back on Device 1 & try to add a payment line, partner, or enable Invoice. ### Issue: - `TB` will occures `Finalized order can't be modified` ### Fix: - Properly tracked and synced order, ensured relevant user notifications are shown. - Fixed TB if customer note not set (it's false value causing TB) ## Issue 2 - prevent traceback when cancelling empty order ### Steps to Reproduce: - Open Restaurant POS. - Click on any table. - Click the Book Table button. - Reopen the same table. - Click the Action button. - Click Cancel Order. ### Issue: - A traceback occurs because the order is undefined. ### Fix: - Added a condition to safely handle cases where no order exists. ## Issue 3 - always sync order before online payments in restaurant ### Steps to reproduce: - Open POS in Restaurant mode. - Open any table and add a product. - Return to the floor screen. - Reopen the same table and add another product. - Proceed to payment and select an online payment method. - Click "Validate". ### Issue: - The "Invalid online payments" dialog appears because the order is partially synced. Due to the current condition, it is not synced again before adding the online payment line, causing the dialog to appear, which is confusing. ### Fix: - Updated the condition to ensure that in Restaurant mode, the order is always fully synced before allowing online payment lines to be added. Task: 4788430
This update fixes an issue where payment differences on UrbanPiper POS orders were incorrectly calculated. The fix recomputes order totals and payments after a payment is added, ensuring the 'amount_difference' accurately reflects the actual payment amount. This prevents discrepancies in financial reporting for UrbanPiper transactions.
Original PR description
When UrbanPiper webhooks create POS orders, all monetary fields are initialized to 0 and _compute_prices() is called before any payment exists. Later, _make_order_payment() adds a payment via the pos.make.payment wizard, but no recomputation is done. As a result, amount_total and amount_paid are correct but amount_difference remains based on the initial 0 values (e.g. 0 - 40 = -40), even on posted orders. Recompute prices/totals after adding the payment so amount_difference reflects the actual paid amount for UrbanPiper orders.
This update fixes an issue where multiple order lines were incorrectly refunded during the Point of Sale refund process. Now, only the selected line is refunded, and deleting a refund order correctly restores the order's status. This ensures accurate refund transactions and a smoother user experience.
Original PR description
Steps to reproduce: - In POS, select a paid order in the ticket screen with multiple lines. - Select the first line, choose a quantity to refund, and click Refund. - Return to the ticket screen, select the same paid order again. - Select another line and quantity, and click Refund. Issue: - In the second refund, all order lines were being refunded, even though only one line was selected. - After deleting a refund order, the ticket screen still showed messages like "Refunding x quantities in xyz order." Fix: - Only the selected lines are refunded. - Deleting a refund order restores the state of the linked order correctly. Task-5095578
This update resolves an error that occurred when a user removed the end date from a planning slot. The fix ensures the system handles the absence of an end date correctly, preventing a technical error and maintaining smooth slot management functionality. This improves the user experience and prevents data inconsistencies.
Original PR description
Currently an error occurs when user tries to remove end date on slot. Steps to replicate: - Install `planning`. - Create a new planning slot and click on a slot template at the top. - Remove the end…
Currently an error occurs when user tries to remove end date on slot.
Steps to replicate:
- Install `planning`.
- Create a new planning slot and click on a slot template at the top.
- Remove the end date (rightmost) and click elsewhere.
Error:
```
File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 423, in _compute_template_id
if slot._different_than_template():
File /home/odoo/odoo18/enterprise/planning/models/planning.py, line 439, in _different_than_template
slot_time = self[slot_field].astimezone(pytz.timezone(self._get_tz()))
AttributeError: 'bool' object has no attribute 'astimezone'
```
Cause:
- When the end date was removed, [compute] was triggered, calling the `_different_than_template()` method, which iterates through the fields in the slot template.
- Since the user removed `end_datetime`, `self['end_datetime']` became false and caused the error at line [1].
Solution:
- Returned from the function call when `end_datetime` is false.
[compute]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L418-L426
[1]: https://github.com/odoo/enterprise/blob/745c1cc0e06f5e0578ec4383439f8be2419adb6b/planning/models/planning.py#L438
No IDThis update resolves an issue preventing regular users from digitizing expense receipts. Previously, users needed specific administrator access. The change now allows digitization for draft expenses, streamlining the expense reporting process. This improvement ensures all users can easily upload receipts, reducing delays and improving efficiency.
Original PR description
When a regular user tries to digitize the receipt attached to an expense, the `UserError(_("You don't have the rights to bypass the validation process of this expense."))` is raised. It seems that currently, the user needs to be in the Expenses Administrator group (`group_hr_expense_manager`) to digitize the receipt, which doesn't seem correct.
This PR solves the issue by skipping the check of the user's group if the expense is in draft state, as suggested by @JulienAlardot: https://github.com/odoo/enterprise/pull/101011#pullrequestreview-3558220264
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr2 changes
Resolved issues and error corrections
This update resolves an issue related to invoice QR codes generated for ZATCA compliance. Previously, the QR code included timezone information, which was incorrect. This change ensures the time data is sent in the correct Asia/Riyadh timezone format, meeting ZATCA requirements and avoiding potential processing delays.
Original PR description
In ZATCA phase 1, after converting the time to Asia/Riyadh timezone, the time information is added to the qr code in iso format which concatenates the timezone ("+03:00"). However, ZATCA expects the time to simply be sent as is in Asia/Riyadh timezone.
Task: 5319097
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update enhances security by ensuring that checks for employee addresses within the account batch payment process are performed with elevated permissions (sudo). Previously, this required users to be part of HR groups, which is now corrected to prevent unauthorized access to employee data. This change addresses a potential security vulnerability.
Original PR description
In commit a6ed1bd, new logic for handling employee addresses was introduced. However, the _get_all_addr function requires employee_ids, which implicitly requires access to the Employees model and, therefore, be in HR groups. During the compute process, _get_all_addr is only used to check whether an employee has an address; no address data is exposed. To fix this issue, the call to _get_all_addr should be executed with sudo(). OPW-5428523