Daily updates from Odoo
Tuesday, March 3, 2026
201 changes
24 changes
Enhancements to existing features
This update introduces a simpler way to run Odoo tests by allowing users to use the '-t' alias for the --test-tags command. This change streamlines the testing process and makes it more convenient for developers. It's a minor improvement that enhances developer workflow.
Original PR description
Backport of https://github.com/odoo/odoo/pull/234287 <img width="408" height="151" alt="image" src="https://github.com/user-attachments/assets/7f22826f-6887-432b-8baf-8a6778b9cadf" /> Forward-Port-Of: odoo/odoo#250283 Forward-Port-Of: odoo/odoo#249123
This update enhances the testing process by clarifying documentation related to specific error codes (E8502 and E8505). The changes provide clearer explanations and examples, ensuring consistent and accurate testing of Odoo's translations.
Original PR description
- Update documentation link for E8502. - Clarify why E8505 is in place and give an example. Forward-Port-Of: odoo/odoo#251444
Resolved issues and error corrections
This update adjusts the size of custom snippet titles within Mass Mailing to ensure they are easily readable. A recent update to the preview snippet selector required a change in font size for these titles. This fix maintains the original appearance of custom snippets at the new scale, improving user experience.
Original PR description
In Mass Mailing, users can save modified snippets as Custom Snippets, allowing for their later reuse. These snippets can be found in the Custom category. However, their title was too large. This is due to d2b56435736e8d507434c1378cb68fae23e8511f rescaling the preview snippet selector, allowing for better readability of each snippet's text from the selector. As the default builder font size for custom snippet titles was set for the previous scale (50px at 0.3 scale), it has to be halved to restore its previous appearance at the new scale (25px at 0.6 scale). task-5959033 Forward-Port-Of: odoo/odoo#250609
This update corrects a technical issue in the Hungarian tax audit export process. Previously, changes to invoice data were unintentionally saved to the database, causing potential errors. The fix ensures data is properly cleared from the cache before and after savepoints, preventing these unwanted database updates.
Original PR description
At the moment, the Hungarian tax audit export wizard's `action_export` creates a savepoint with `flush=False`. The intention of this savepoint is to roll back the changes to `l10n_hu_edi_invoice_chain` once the savepoint exits. But because the changes to `l10n_hu_edi_invoice_chain` stay in cache, and the cache is not flushed before the savepoint is created nor cleared afterwards, those changes end up being committed to DB. Which is precisely what the savepoint was there to prevent. Solution: we use `flush=True` to make sure the cache is flushed before and cleared after the savepoint. task-none Forward-Port-Of: odoo/odoo#251322 Forward-Port-Of: odoo/odoo#250971
This update fixes an issue where the lot number for products tracked by lot in POS sales orders wasn't consistently displayed. The fix ensures that the correct lot number is accurately reflected across all product lines within the POS interface. This improves order accuracy and traceability for products with lot tracking.
Original PR description
When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others Steps to reproduce:…
When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others Steps to reproduce: ------------------- 1. Create a Product A tracked by lot, create lot 111 and add 1 unit to location A and another one to location B 1. Create a sales order 2. Add two units of the product to the sale order 3. Confirm the sales order 4. Open the transfer, make the transfer retrieve the product from several location with the same lot. 5. Save the transfer 6. Open the sales order in POS 7. Load the SN/lots -> Two line of qty 1 appear for the product A but only the first one has the lot number Additional Issue: 8. Change the number of the product for the first line to 2 and erase the second line 9. Confirm and Pay 10. Close POS 11. Open move lines for this product (Inventory>product>In/out) -> It moves 2 product from one location (when there is only product) Observation: ------------- When loading the SO in POS, we will retrieve the SO: https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/pos_sale/static/src/app/order_management_screen/sale_order_management_screen/sale_order_management_screen.js#L104 While retrieving the SO, we will also retrieve the SOL, with additional information: https://github.com/odoo/odoo/blob/d9b2e5ee730a4e79586bfd3f09adfb794d2dc1f3/addons/pos_sale/models/sale_order.py#L79 -> Issue is that when several moves_line have the sale lot_id.name, their quantity will be overwritten. Addition Issue : When closing pos, all the move will be processed, when processing those moves, the origin only check if the quantity is more than 0 and not if there is enought units. https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/point_of_sale/models/stock_picking.py#L293-L297 opw-5347992 Forward-Port-Of: odoo/odoo#251270 Forward-Port-Of: odoo/odoo#243347
This update fixes a display issue in the website editor where an incorrect 'Custom URL' field was appearing. The change prevents this field from showing when the website URL doesn't support customization, ensuring a cleaner and more accurate SEO experience for users. This improves the usability of the website editor.
Original PR description
This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not…
This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not contain any modifiable slug. However, the value was not take into account since the route of the page did not expect slug. Reproduce: With an admin user, activate the website editor on an appointment page. Clicking on "Optimize SEO" in the "Site" dropdown menu, a form containing the "Cutsom Url" field is displayed. This field should represent the current page's URL but with fillable field instead of the editable URL part. In this case, this is not correct as the URL is repeated before and after the fillable field, which does not represent the current URL. Also, the URL is not modified with the value entered in the fillable field. After the fix: The "Custom Url" field must not be displayed when URL does not contain a customisable slug. Task-5114394 Forward-Port-Of: odoo/odoo#251294 Forward-Port-Of: odoo/odoo#231609
A recent update to the Document linking dialog caused a minor error when users tried to add documents via the command palette. This fix updates a key part of the software's code to correctly identify the 'Add as link(s)' button, ensuring the dialog functions as intended. This resolves a display issue and improves the user experience.
Original PR description
How to reproduce: Open any record, go to the Activity, select Document, then type “/File” in the command palette and click it. An error is raised. Issue: The xpath expression `contains(., 'Paste Link')` cannot locate the element because the button label was renamed to `Add as link(s)` in commit a4ca17329d7c21be487a53c5e0b9afa39e6dad3a. Resolution: Update the xpath to correctly target the new button definition `Add as link(s)` instead of the old label, preventing the element lookup failure and restoring proper dialog rendering. Task-5946396
This update resolves an issue where archived employees were still visible in the attendance Gantt view. The change ensures that only currently active employees are displayed, improving the accuracy and clarity of the attendance reporting tool. This prevents confusion and outdated information.
Original PR description
Steps to reproduce: 1. install `hr_attendance_gantt` 2. create an employee 3. make attendance records for the employee in the previous months 4. archive the employee When opening the gantt view of the attendance, a row appears for the archived employee, with no attendance showing up. This commit adds a constraint to only show the active employees. opw-5490119 Forward-Port-Of: odoo/enterprise#107972 Forward-Port-Of: odoo/enterprise#106486
This update resolves an issue where a security check was incorrectly performed on multiple records within the account module. The fix ensures the check is now executed only once, strengthening the system's security posture. This change improves the reliability and efficiency of user trust validation.
Original PR description
In some cases, the check was done on multiple records, though the method should be called on one and only one record. Forward-Port-Of: odoo/odoo#251589 Forward-Port-Of: odoo/odoo#251457
This update corrects a bug where the removal date for products with expiration dates was incorrectly recalculated after modifications. The fix allows users to directly edit the removal date, ensuring accurate tracking of product expiration. This resolves a previous issue impacting inventory management accuracy.
Original PR description
version : saas-18.4+e Steps to reproduce ------------------ Create a product tracked by lots and enable the expiration date use (use_expiration_date = True). Create a receipt with this product and mark it as to do. Open the stock.move.line list view using the "Details" button on the receipt form and try to modify expiration date, it should modify the removal date due to the compute method. Then, try to modify the removal date and save the modifications. If you reopen the list view, the removal date has been computed again and its value changed. The fix ------------------ We explicitly set the readonly field to False for the removal_date field from the stock.move.line model in product_expiry. opw-5368007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251256 Forward-Port-Of: odoo/odoo#241659
This update corrects a display issue where vendor product names and codes were appearing twice in the purchase receipt descriptions. The root cause was a redundant addition of vendor information during the receipt generation process. This change ensures accurate and consistent product descriptions in purchase receipts.
Original PR description
Version : saas-18.4+e Steps to reproduce ------------------ Create a product and add a line in the purchase tab with a “Vendor Product Name” and/or a “Vendor Product Code”. Create a purchase order…
Version : saas-18.4+e Steps to reproduce ------------------ Create a product and add a line in the purchase tab with a “Vendor Product Name” and/or a “Vendor Product Code”. Create a purchase order for this product with the right vendor and confirm it. Go to the delivery receipt, the vendor code and/or name are added twice in the description. Why is it happening ------------------ The _compute_description_picking method from stock.move, which is overridden in purchase_stock module, adds the vendor code and name to the description. However, if no description_picking has been set on the product, the description is already defined as the vendor code and name. Solution ------------------ I propose to remove the code and the name from the vendor_reference variable if the original description already contains them. opw-5392855 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251337 Forward-Port-Of: odoo/odoo#242075
This update fixes a JavaScript error that occurred when users closed the signing certificate wizard without saving. The fix ensures the system correctly handles wizard dismissals, preventing a crash and improving stability. This resolves a potential disruption for users completing the certificate signing process.
Original PR description
**Issue:**
Closing the signing certificate wizard without saving triggers a client-side traceback (`UncaughtPromiseError: Invalid ids list: [object Object]`).
**Cause:**
When the wizard dialog is discarded, Odoo's dialog manager passes a dismissal object (`{dismiss: true}`) to the `onClose` callback. The existing code only checked if the payload was truthy (`if (cert_id)`), causing it to attempt to update the `signing_certificate_id` Many2one field with the event object. The framework's validation (`validatePrimitiveList`) expects an integer or array of integers, resulting in a crash when it tries to parse the object.
**Fix:**
Updated the `onClose` callback to strictly verify the type of the payload (`typeof cert_id === 'number'`). The record is now only updated when the wizard successfully returns a valid primitive integer ID.
task: 5975643
Forward-Port-Of: odoo/enterprise#108864This update fixes an issue where the VAT exigibility mention was incorrectly shown on French invoices. The change ensures that the mention is only displayed when required by French tax regulations – specifically, when a service VAT uses invoice-based tax exigibility. This ensures compliance and accurate invoice presentation.
Original PR description
The VAT exigibility mention on French invoices was incorrectly displayed. - For goods, VAT on debits is the default regime, therefore the mention is not mandatory and must not be shown. - For services, VAT is normally due on payment. The mention “TVA payée sur les débits” must be displayed only when a service VAT uses tax exigibility based on invoice. This commit updates the logic to display the mention only in this specific case and omits it otherwise. Task:5418502 Forward-Port-Of: odoo/odoo#248588
This update fixes a visual issue with the API documentation tooltips, ensuring they display correctly and consistently. The changes align the text, improve how tooltips are hidden, and prevent empty tooltip content from appearing, resulting in a cleaner and more reliable user experience for developers.
Original PR description
In api_doc, the method parameters tooltips were broken. This commit fixes them by: - aligning the text to the left - improving the hideTooltip behavior - preventing `undefined` tooltip content from being displayed task-5246075 Forward-Port-Of: odoo/odoo#248289
This update ensures that loyalty rewards are correctly applied to orders loaded from the TicketScreen, even after switching to other orders. Previously, the system didn't properly refresh loyalty state when loading an order, causing rewards to disappear. This fix guarantees rewards are accurately reflected in loaded orders.
Original PR description
Reward disappeared from an order when it was loaded from the Orders tab (TicketScreen) in restaurant mode after working on other tables. Steps to reproduce: ------------------- * Configure a Buy X Get Y (or similar) loyalty program and open a POS restaurant session. * On table A, create an order that triggers the program and confirm the reward line is applied. * Leave table A, create or edit another order on a different table (so another order becomes current). * Go to the Orders tab (TicketScreen), select the order from table A and click "Load Order". > Observation: The order from table A is loaded without its reward line, even though it was present when the order was first created. Why the fix: ------------ TicketScreen’s "Load Order" flow was only switching the current order without refreshing loyalty state, so after changing tables and coming back, later loyalty recomputations could drop the existing reward lines. opw-5909899 Forward-Port-Of: odoo/odoo#248000
This update corrects a problem where the system wasn't properly tracking the status of batch payments processed in the background for Danish accounting (l10n_dk). This fix ensures that all payment attempts are accurately recorded and managed, improving the reliability of financial transactions. It addresses a technical issue impacting payment processing functionality.
Original PR description
State is not being correctly managed in case of background processing. task-5963885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251219
This update fixes a visual issue where group names in list views were being cropped due to incorrect column spanning. The change ensures group names have sufficient space, regardless of the list's content, improving readability and the overall user experience. This resolves a minor aesthetic problem that could have impacted how users viewed grouped data.
Original PR description
Have a grouped list view with no aggregate fields. Before this commit, the colspan of the first `th` in group header rows wasn't optimally computed. These `th` can span to the very last cell…
Have a grouped list view with no aggregate fields. Before this commit, the colspan of the first `th` in group header rows wasn't optimally computed. These `th` can span to the very last cell (excluded), which may contain a cog menu. However, they only spanned to the second to last cell. As a consequence, in a list with only 2 columns, e.g. a handle and a name, the groups' name only got a few px available, and were hence cropped. The issue came from successive reworks of the group header row, leading to the pager being finally moved from its own column (after the last aggregate column), to the group name cell (with ms-auto). The logic is easier now, as a group header row looks like this: - a single `<th colspan="n">` (n >= 1) to display the group name: spans to the first aggregate column excluded or to the last cell excluded if no aggregate (colspan + 1 if rows have selectors) - one `<th colspan="1">` for each aggregate column - optionally one `<th colspan="m">` (m >= 1) for all columns after the last aggregate column - a single `<th colspan="1">` for the potential cog menu (optional dropdown column) opw~5730396 Before <img width="1918" height="471" alt="image" src="https://github.com/user-attachments/assets/8f55322b-1603-42cc-a48b-a2010ff12e25" /> After <img width="1909" height="423" alt="image" src="https://github.com/user-attachments/assets/0bca4865-88a1-424d-a1af-1523dbfa911c" /> Forward-Port-Of: odoo/odoo#251411
This update corrects a bug where the invoice section was disappearing when the product price was hidden. The fix also resolves a related issue where removing tax caused a duplication of the invoice subsection. This ensures invoices are correctly rendered in previews and PDFs, providing accurate financial information.
Original PR description
**STEP TO REPRODUCE** 1. Create an invoice, with: - Section A - Subsection 1 - product a, with tax Click on hide price on section A, and preview the invoice. Notice the Section A is missing from the preview/pdf. If you remove the tax on product a, there will also be a bug where Subsection 1 is duplicated, with one copy with no children lines below it. opw-5927563 Forward-Port-Of: odoo/odoo#251344 Forward-Port-Of: odoo/odoo#249808
This update resolves an issue where planners couldn't see available shifts for resources with no scheduled shifts. The fix removes a filter that was incorrectly limiting the shift options in the planning dialog, ensuring planners have full visibility to assign resources effectively. This improves scheduling efficiency and reduces wasted time.
Original PR description
Steps to Reproduce ------------------ 1. Open the Planning Gantt view. 2. Click a cell that belongs to a resource with **no** scheduled shifts. 3. The Plan dialog opens with an empty list. Issue…
Steps to Reproduce ------------------ 1. Open the Planning Gantt view. 2. Click a cell that belongs to a resource with **no** scheduled shifts. 3. The Plan dialog opens with an empty list. Issue ----- A previous change keeps the clicked resource in the dialog context; the Gantt model turns it into a default search filter, so only shifts already linked to that resource are shown. Unassigned shifts are therefore hidden, preventing planners from assigning them by role or availability. Current Behaviour ----------------- The Plan dialog is always filtered by `resource_id`, which returns no results for unscheduled resources, even when they have the right roles. Expected Behaviour ------------------ The dialog should list all unscheduled shifts that match the resource’s roles, or every unscheduled shift if the resource has no roles, while still preserving full context for scheduling once a shift is selected. Fix --- Remove the automatic resource filter from the dialog context in `getSelectCreateDialogProps()`. This prevents the unwanted search restriction; role defaults remain, so the dialog now displays the correct shifts. Task-4922525 Issue – https://github.com/odoo/enterprise/pull/87424/commits/a218a7cedce61f992fbe76284c273be8f937d28d Forward-Port-Of: odoo/enterprise#92100
This update fixes an issue where Point of Sale session messages were consistently displayed in English, regardless of the user's selected language. The fix ensures that all cash-related messages within POS sessions are now translated accurately based on the user's language preference, improving the user experience for international customers.
Original PR description
**Problem:** When opening or closing a POS session, chatter messages display untranslated English text regardless of the user's language setting. **Steps to reproduce:** 1. Set user language to any non-English language (e.g., Spanish) 2. Open a POS session and register cash in/out operations 3. Close the session 4. Check the chatter messages - labels appear in English **Current behavior:** Messages display in English: "Opening cash difference", "Opening cash expected", "Opening cash counted", "Closing difference", etc. **Expected behavior:** Messages should be translated according to the user's language setting. **Cause of the issue:** The hardcoded strings were not wrapped in the translation function `_()`, preventing them from being translated. **Fix:** Wrap the concatenated strings with `_()` to enable proper translation of all cash details messages. opw-5185310 Forward-Port-Of: odoo/odoo#248982 Forward-Port-Of: odoo/odoo#244501
This update resolves a technical issue where the new booking view for POS appointments was interfering with other modules. By restricting the view's usage to the POS system, this fix ensures compatibility and prevents disruptions to other parts of the Odoo platform. This improves stability and prevents potential conflicts.
Original PR description
The list view in pos appointment would replace the original list view on calendar event and break other modules. This PR will add the `primary` mode for the new view so it is only used inside the POS Runbot Error: [234914](https://runbot.odoo.com/odoo/runbot.build.error/234914) Forward-Port-Of: odoo/enterprise#107132
This update fixes a problem where archived employees incorrectly retained their appraisal dates, causing scheduling conflicts. The change ensures that archived employees are excluded from appraisal calculations, preventing date conflicts and ensuring accurate appraisal plan management. This improves the stability and usability of the appraisal feature for all companies.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002 Forward-Port-Of: odoo/enterprise#109115 Forward-Port-Of: odoo/enterprise#100437
This update fixes an issue where newly hired employees were incorrectly receiving their private email address as their work email. The fix clears the employee's work_email field during the contract signing process, ensuring it reflects the correct work email from the salary configurator. This prevents confusion and ensures accurate employee record information.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797 Forward-Port-Of: odoo/enterprise#109074 Forward-Port-Of: odoo/enterprise#106974
This update prevents users from canceling subscriptions if they don't have access to the associated invoices. Previously, a sales representative could cancel a subscription even if they lacked visibility to the invoices. Now, the system ensures a user must see the invoice before they can initiate a cancellation, improving subscription management accuracy.
Original PR description
Before this commit, when a user had access to an invoiced subscription but not to the invoiced, he could cancel the subscription. Step to reproduce: - create a subscription in company A, with a pricelist available in company B. Sales person A belong to company A. - invoice the subscription and confirm the invoice - update the company (company B) and sales person of the subscription (B). The new salesperon don't see the invoice in the stat button. After this commit salesperson B can't cancel the subscription. task-5907345 Forward-Port-Of: odoo/enterprise#108550 Forward-Port-Of: odoo/enterprise#106441
13 changes
Enhancements to existing features
This update ensures the IEPS tax breakdown is correctly displayed on Mexican CFDI invoices, aligning with SAT regulations. Specifically, it now accurately shows IEPS based on whether the invoice is a 'global invoice' or uses tax object 07, resolving inconsistencies in previous behavior.
Original PR description
This commit targets to modify the behaviour of IEPS breakdown on CFDI to follow on what is specified on SAT cfdi Tax Object Catalog. Now the IEPS will be displayed only considering if the CFDI is a global invoice, the value of the tax object and whether the check is set. The general idea is: - Is a global invoice? -> show IEPS - Is tax object 07? -> show IEPS - Has ieps breakdown but is not tax object 08? -> show IEPS - Anything else, don't. task-5953499 target: saas-18.4 -> master Forward-Port-Of: odoo/enterprise#108555
Resolved issues and error corrections
This pull request addresses several issues within the Hoot testing framework, focusing on improving test reliability and execution speed. Specifically, it fixes errors in test logging, ensures proper test failure reporting, and cleans up test environment setup to prevent issues between tests.
Original PR description
Fixes for tests and testing framework. See commit messages for details. Enterprise: https://github.com/odoo/enterprise/pull/107286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251363 Forward-Port-Of: odoo/odoo#247137
This update resolves an issue where test scripts were incorrectly triggering events on elements, causing test failures. The fix ensures that test environments are properly cleaned up after each test run, preventing potential performance problems and ensuring the stability of the Odoo Enterprise system. This improves the reliability of our testing process.
Original PR description
Adapt tests failing due to keydown events being applied to the current active element. Community: https://github.com/odoo/odoo/pull/247137 Forward-Port-Of: odoo/enterprise#109149 Forward-Port-Of: odoo/enterprise#107286
This update resolves a technical issue that caused the Point of Sale system to hang during startup. Specifically, a race condition in the indexed database initialization process was corrected, preventing delays and ensuring a smoother POS launch. The fix also ensures the indexedDB is properly populated upon initialization.
Original PR description
There were 2 issues when `serverDateTime` was lower than `lastConfigChange` which triggered a reset on the indexedDB. The first issue was that we would try to await dbInstance.deleteDatabase request.…
There were 2 issues when `serverDateTime` was lower than `lastConfigChange` which triggered a reset on the indexedDB. The first issue was that we would try to await dbInstance.deleteDatabase request. But it returns a request object and then executes the delete asynchronously. This would cause a race condition on the init where we would trigger the init of the indexedDB at the same time as we were trying to delete it and it would hang for ~10 seconds before finally launching the POS.
The second more important issue is that after the reset there is a `localData = []`. This would cause the line in `synchronizeServerDataInIndexedDB` `JSON.parse(JSON.stringify(serverData));` to return an empty array so no new models would get created in the indexedDB and the POS would launch with an empty indexedDB.
This commit changes the `indexed_db.reset()` method to return a promise and awaits it before reinitialising the indexedDB. And resets the `localData` to `{}` which fixes the `synchronizeServerDataInIndexedDB`
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#246476This update fixes an issue where the 'Request Signature' option wasn't consistently appearing in the cog menu on certain task forms. The change ensures the menu item only shows when a chatter is present, improving the user experience and ensuring all users have access to this important feature.
Original PR description
****Behavior:**** **Current:** When selecting the cog menu on certain forms, the request signature item doesn't always show even though it should. The expected behavior of this menu item is to appear only on form views with a chatter, but the way the chatter's presence was verified is inconsistent. **Solution:** On form views with a chatter, we can check its presence directly from the viewArch using the selector from the compiler registry. **Steps to reproduce:** From Timesheets: - Go to Timesheets - Open a task - The cog menu will not contain "Request Signature" From Project: - Go to Project - Select a project and open a task - The cog menu will contain "Request Signature" opw-4817423 Forward-Port-Of: odoo/enterprise#108935 Forward-Port-Of: odoo/enterprise#97401
This update prevents tracebacks that occurred when users clicked on images configured to open in a popup. The fix addresses an issue where a specific slideshow component wasn't correctly initialized, leading to errors. Now, image popups function smoothly without causing technical problems.
Original PR description
Problem: Clicking on an image configured to open in a popup triggers a traceback. Cause: The `ImagePopUp` interaction renders `o_slideshow` without controls due to `shouldShowControls`. As a result, `carousel-indicators` and their children are not rendered. This makes `GallerySlider.liEls` `undefined`, which later causes a traceback in `hide`. Solution: Since `ImagePopUp` always displays a single image, `GallerySlider` is not needed in this case. Exclude `o_image_popup` from initializing `GallerySlider` to avoid accessing undefined elements. Steps to reproduce: - Drop an Image snippet. - Enable “popup on click”. - Save the page. - Click on the image. - Observe the traceback. opw-5974260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where tip and discount amounts in the Point of Sale interface were not correctly formatted when using a different decimal separator. This change ensures that users see accurate tip and discount values, reducing potential confusion and improving the overall user experience. The fix addresses a minor usability concern.
Original PR description
Before this commit, when the decimal separator was not a dot, the amount in the tip and the discount number popup was not correctly formatted, which could lead to confusion for the user. opw-5921256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that custom messages displayed in website shop pages are now retained after saving. Previously, a technical issue caused these messages to be overwritten with default ones. This change corrects a regression introduced during a recent update to the website builder, improving the user experience for customizing website content.
Original PR description
Steps to reproduce: - Open the website shop page in edit mode. - Drag and drop a block in the shop header dropzone. - Save the page and re-enter edit mode. - Check the shop header dropzone message.…
Steps to reproduce: - Open the website shop page in edit mode. - Drag and drop a block in the shop header dropzone. - Save the page and re-enter edit mode. - Check the shop header dropzone message. => The custom message is replaced by the default one. Before this commit, `SetupEditorPlugin.cleanForSave()` removed `data-editor-message` and `data-editor-message-default` on the saved HTML clone, including custom messages defined in website templates. This cleanup was originally introduced in `web_editor` in [1]. Since the builder refactor in [2], website page saves now use the shared `html_builder` save cleanup flow and wrongly inherited that behavior, which introduced this regression in website. This commit removes that cleanup from `html_builder`, as it does not provide useful value in this save flow and drops custom dropzone messages. After this commit, custom dropzone messages are preserved after saving website pages. [1]: bab673488e185ddd7792aedecc3870663290fed3 [2]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5921283 Forward-Port-Of: odoo/odoo#250874
This update ensures that timesheet updates accurately reflect the cost of tasks associated with sales orders, regardless of the invoice policy used (ordered_prepaid, delivered_manual, or delivered_milestones). Previously, updates were prevented for 'ordered_prepaid' invoices, leading to incorrect cost calculations. This change improves the accuracy of sales order costing and reporting.
Original PR description
Originally, timesheet updates for tasks associated with sale order lines would cause the cost (purchase_price) to be recomputed. However, this was prevented if the invoice policy was 'ordered_prepaid.' This should also apply to 'delivered_manual' and 'delivered_milestones.' Otherwise, any timesheet updates will recompute the sales.order.line purchase_price field. Steps to reproduce: 1. Create a service product that creates a project/tasks 2. Create a sales order with the product and manually set the cost 3. Assign the timesheets of the task to an employee 4. Have the employee update their timesheet for the task 5. The cost on the sales order line gets recomputed to the default product price task-5902688 related-pr-205415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250495
This update fixes a bug where multiple physical gift cards added to a single Point of Sale (PoS) order were not being created in the backend. The issue stemmed from a misidentification of the gift card code key, which has now been corrected. This ensures that all gift cards added to a PoS order are properly recorded.
Original PR description
When selling mutliple physical gift cards in the same PoS order, no gift cards were created. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on the gift card line and set a physical gift card with a value of 100€ * Add another gift card to the order * Click on the gift card line and set a physical gift card with a value of 50€ * Validate the order > Observation: No gift card is created in the backend Why the fix: ------------ When looking for the `oldChanges` we tried to retrieve the gift card code as `gift_code` but the key name is `code`. Because of this the `pointsCount` was wrong. opw-5928320 Forward-Port-Of: odoo/odoo#251339 Forward-Port-Of: odoo/odoo#249066
This update resolves an issue where the system was incorrectly checking user trust permissions on multiple records. The fix ensures that this check is performed accurately on a single record, improving the reliability of account-related processes. This change enhances data integrity and reduces potential errors.
Original PR description
In some cases, the check was done on multiple records, though the method should be called on one and only one record. Forward-Port-Of: odoo/odoo#251589 Forward-Port-Of: odoo/odoo#251457
This update simplifies the process of running Odoo tests by introducing an alias for the `--test-tags` command. Previously, users had to explicitly specify test tags, now they can use a simpler alias, streamlining the testing workflow and reducing potential errors. This change enhances the reliability and efficiency of our automated testing procedures.
Original PR description
Backport of https://github.com/odoo/odoo/pull/234287 <img width="408" height="151" alt="image" src="https://github.com/user-attachments/assets/7f22826f-6887-432b-8baf-8a6778b9cadf" /> Forward-Port-Of: odoo/odoo#250283 Forward-Port-Of: odoo/odoo#249123
This update resolves an issue where stock reporting (Inventory / Reporting / Stock) displayed incorrect values due to a lack of company filtering during last product value searches. Previously, all companies were considered, leading to inaccurate unit costs, total values, and on-hand quantities. This fix ensures accurate reporting by correctly filtering results based on the selected company.
Original PR description
Before this fix, when searching for the last product value, we don't check the company. We search for the last product.value among all companies, even when only one company is selected. As a result, we end up with strange values when going to Inventory / Reporting / Stock. For instance, we may end up with: unit cost 10, total value 100, on hand quantity 0. OPW-5957947 Forward-Port-Of: odoo/odoo#251413
7 changes
Resolved issues and error corrections
This update resolves a crash issue that occurred when viewing pay runs on mobile devices. The fix ensures the system correctly identifies and interacts with the Kanban view, preventing unexpected errors and improving stability for users. This change maintains the existing mobile layout while addressing a critical functionality problem.
Original PR description
**Steps to Reproduce:** 1. Open Payroll->Payslips->Pay Runs 2. Click on a Pay Run in Mobile View (Width < 600px). 3. Return to the previous view using the breadcrumb. 4. The system crashes with Traceback: TypeError: Cannot set properties of null (setting 'scrollLeft') **Bug Cause:** The custom 'hr_payroll.PayrunKanbanRenderer' template overrode the 'class' attribute of the root div. By setting it only to 'o_payrun_kanban', the standard 'o_renderer' class was removed. The Kanban controller's scroll restoration logic (introduced in recent lazy-loading updates) relies on the '.o_renderer' selector to find the scrollable container. When missing, querySelector returns null, leading to a traceback. **Solution:** Updated the XML template to explicitly include 'o_renderer' in the class list. This restores the functional hook required by the JavaScript controller for scroll restoration while maintaining the custom 'o_payrun_kanban' layout. Task: 5971861
This update resolves an issue preventing the export of Eco-Voucher reports from the Belgian Payroll App. The change addresses a technical update related to versioning, specifically removing a deprecated 'state' field and aligning data with the new version module. This ensures accurate Eco-Voucher exports for Belgian companies.
Original PR description
Since the switch from contracts to versions, exporting Eco-Vouchers to excel has not been functional, this commit fixes this. **Steps to reproduce:** - Open Payroll App as a Belgian company - Under Reporting Menu, select Eco-Vouchers - Try exporting with XLSX **Issue:** Since introduction of versions, version module does not contain state field anymore which was present in contracts **Fix:** Removed the state field and replaced it with the corresponding field in version. task:5163668
This update resolves an issue where rapidly clicking the 'Back' button during barcode internal transfer creation resulted in duplicated quantities being added to the transfer. The fix prevents multiple 'save' calls, ensuring accurate quantity tracking.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By…
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By Quantity** and set some *barcode* * Update the on-hand quantity for the product and assign it to one packages. * Open *Barcode > Operations > Internal Transfer* and create a new transfer. * Click the *gear icon* in the top-right corner to open the barcode scanning flow. * manually enter the created product barcode and apply it. * Click the **Back** button multiple times in quick succession. * Go to the backend and open the created internal transfer. **Observed behavior:** * The internal transfer is created with *double quantities* compared to what was added in the barcode interface. **Cause:** * When clicking the *Back* button, the following flow is triggered: `exit()` → `beforeQuit()` → `save()`. https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483 * If the button is clicked multiple times rapidly, `exit()` is called again before the previous `save()` RPC completes. * This results in multiple `save()` calls being executed, causing duplicated quantities on the picking. reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74 **Fix:** * Prevent rapidly clicking the Back button multiple times does not multiply quantities. --- opw-5375899 Forward-Port-Of: odoo/enterprise#109013 Forward-Port-Of: odoo/enterprise#103130
This update addresses a potential issue in the Swiss payroll reporting process. Specifically, it now displays a warning instead of an error when the AVS (Authorized Vendor System) value is negative, improving the user experience and preventing disruptions to payroll calculations. This change ensures accurate reporting and avoids unnecessary alerts.
Original PR description
Forward-Port-Of: odoo/enterprise#109046
This update corrects an issue where the display of shift durations in the Planning app was inaccurate when shifts spanned across multiple days. The fix removes outdated logic that truncated shift names, ensuring correct hour representation regardless of the shift's length. This improves the accuracy of shift scheduling and reporting.
Original PR description
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an…
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an employee from 3pm to 2am (over two days) - The hours of the shift are displayed - Modify the shift end to 3am - The hours of the shift aren't displayed ### Cause: Before the refactor adapting the gantt view to OWL, when a shift spanned over two days less than three hours, then the gantt view truncated the pill to display it in only one day. (see [`_snapToGrid()`](https://github.com/odoo/enterprise/blame/a16b2ef569903c0ae5803c169dbd68acd0141fe1/web_gantt/static/src/js/gantt_row.js#L1044-L1072)) The same logic was done for the computation of the pill's name in [this commit](https://github.com/odoo/enterprise/commit/98a86cbacf484646f486e4648788cfa53cc9648c). But as the pills are no longer truncated since 17.0, the computation of pill names is faulty. ### Solution: We remove the checks of the 3-hour margin. This also makes the variable `spanMoreThanOneDay` useless, so we delete it. opw-5881532 Forward-Port-Of: odoo/enterprise#109217 Forward-Port-Of: odoo/enterprise#107233
This update corrects an issue where payments for invoices paid within 30 days (PUE) were incorrectly sent to the Mexican tax authority (CFDI). By disabling a specific function, we now ensure that only payments meeting the required 30-day term are processed for CFDI submission, improving compliance and accuracy.
Original PR description
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm…
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm - Duplicate (Invoice B) - Confirm - Duplicate again (Invoice C) - Set Payment Terms to "30 days" - Confirm - Go to Invoice A - Pay it. It should appear as "Paid" - Send it to CFDI - Go to Accounting > Customer > Invoices - Select Invoice B and C - Pay and select the "Group Payments". They should appear as paid. - In every invoice, click the "Update Payment" button Current behavior: - In Invoice A -> Sheet CFDI: A button "Force CFDI" allow sending the payment to CFDI - In Invoice B/C -> sheet CFDI: Click on the "Download" part of the Payment line, the XML that was sent to CFDI include both invoice B and C Expected behavior: - It shouldn't be possible to send payment for invoice A to CFDI. - Payment for invoice B shouldn't be sent to CFDI Cause: Payment for invoice paid in less than 30 days, referred as PUE, shouldn't be sent to CFDI. Solution: Disable the force sending to CFDI About tests: l10n_mx_edi_cfdi_invoice_try_update_payments already send payment to CFDI for PPD invoices. Calling action_force_payment_cfdi was pointless and causing a mess. opw-5381600 Forward-Port-Of: odoo/enterprise#109105 Forward-Port-Of: odoo/enterprise#104628
This update corrects a problem with how leave periods are tracked, specifically related to time zone differences. By using a new date field, the system now accurately reflects leave interruptions, ensuring correct payroll calculations and reporting. This resolves potential scheduling discrepancies.
Original PR description
This commit fixes the leaves work interruption constraint by replacing `date_from` and `date_to` with `request_date_from` and `request_date_to`, thereby resolving any inconsistencies that may arise from time zone differences. task-5966780 Forward-Port-Of: odoo/enterprise#109114 Forward-Port-Of: odoo/enterprise#108541
12 changes
Enhancements to existing features
This update clarifies the documentation for two key gettext error codes (E8502 and E8505). Specifically, it provides a clearer explanation of E8505 and includes an illustrative example to improve understanding and usability for developers.
Original PR description
- Update documentation link for E8502. - Clarify why E8505 is in place and give an example. Forward-Port-Of: odoo/odoo#251444
Resolved issues and error corrections
This update fixes an issue where taxes weren't correctly applied when the tax's fiscal position was set to 'all'. The change ensures that taxes with this setting are now applied appropriately, aligning with the expected behavior. This resolves a discrepancy between the sales order's fiscal position and the actual tax application.
Original PR description
### Issue: No tax will be applied if in taxes, fiscal position is set to all. #### Steps to reproduce: 1- Create a tax, and in the tax form, leave `Fiscal Position` field blank, which in this case…
### Issue: No tax will be applied if in taxes, fiscal position is set to all. #### Steps to reproduce: 1- Create a tax, and in the tax form, leave `Fiscal Position` field blank, which in this case `all` will be shown in placeholder. 2- Set Domestic FP to be applied automatically, and set the country to `US`. 3- Create a Partner with `US` country_id. 4- Create a product, and apply the created tax to sale taxes. 5- Create a SO with created partner and the created product. 6- As you see, the tax is not applied to the line, while if you check SO's fiscal position, it is set to Domestic. Expected: As tax's fp is set to all, we expect this tax being applied with Domestic fp. ### Cause: In this line, if no `tax_ids` is set, it means fp has not tax_ids: https://github.com/odoo/odoo/blob/0c3ae7f78d313885984c99a4e57485d9660dd974/addons/account/models/partner.py#L154-L158 However, this might also mean the tax has no fp because `fp.tax_ids` is a Many2Many relation. In the forms, `tax.fiscal_position_ids` being empty is shown as `all` in the placeholder, which means when no tax applied to fp, we expect all taxes to be mapped. ### Fix: This can be fixed by making sure the fp.tax_ids is not empty because there is no `tax.fiscal_position_ids` set. ### Remark: In this fix we rename `TestInvoiceTaxes._create_invoice` to `_create_invoice_taxes_per_line` to avoid override of `AccountTestInvoicingCommon._create_invoice`. This is already done on saas-19.1+. opw-5463245
This update resolves an issue where related fields within many2one chains were incorrectly displaying the wrong related model. Specifically, when creating chains with duplicate field names, the popover would show incorrect field options. This change ensures accurate field selection and improves the usability of many2one relationships.
Original PR description
You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if the related model you are trying to show has a many2one with the same name as the field that was selected. Steps to reproduce 1. Create two many2one fields with studio that have the same name, one of the fields must link to the model the other field is on. i.e. `model_a.x_studio_test(relation=model_b), model_b.x_studio_test(relation=other_model)`. 2. Create a related field on model_a and click the related icon for the test field. 3. The popover will now be displaying the fields for other_model instead of model_b. Cause: This behavior was introduced by adding support for properties in this [pr](https://github.com/odoo/odoo/pull/189841). Solution: Check if `fieldDef` is a property or not in order to decide what to pass to `loadPath`. opw-ticket 5459944
This update fixes a technical issue that caused a traceback when using the chatbot while the website editor was active. The fix ensures the necessary data fields are available in all Odoo contexts, preventing the error and improving stability. This resolves a potential disruption for users interacting with the chatbot.
Original PR description
Using a chatbot while the website editor is active triggers a traceback. The issue occurs because bus notifications containing `Chatbot` model data are also received by the backend bundle. In the backend bundle, the `Thread` model did not define the `chatbot` field, so the inverse thread relation on the `Chatbot` model could not be resolved, leading to a crash. This commit adds the chatbot field to the core bundle so it is available in all contexts and prevents the traceback. Steps to reproduce: - Goto localhost:8069/@/contactus - Start chatbot - Answer any question -> traceback task-5924295
A bug causing a division-by-zero error in the 'Split' wizard has been fixed. This issue occurred when the 'Max Batch Size' was set to zero, preventing users from correctly splitting manufacturing orders. This fix ensures the wizard functions reliably.
Original PR description
Steps to reproduce: - Install `mrp` module - Create a Manufacturing order - Server Action > Open the `Split` wizard - Set the `Max Batch Size` to `0` Traceback: `ZeroDivisionError: float division by zero` Backporting this [commit], as the error still exists in older versions. [commit]: https://github.com/odoo/odoo/pull/208275/changes/5546689200b7349754cf77bf4dbe7151315a3bfa
This update resolves an issue where the system was incorrectly checking user trust permissions on multiple records instead of a single one. This change ensures accurate authorization processes within the accounting modules, improving data integrity and security.
Original PR description
In some cases, the check was done on multiple records, though the method should be called on one and only one record. Forward-Port-Of: odoo/odoo#251589 Forward-Port-Of: odoo/odoo#251457
This update resolves an issue where filtering by 'Analytic Distribution' in Journal Entries and Purchase Orders was unreliable, returning incorrect results when using 'is set' or 'is not set' filters. The fix ensures accurate filtering by properly handling the 'False' value, preventing invalid queries and improving data accuracy.
Original PR description
**Problem:** When filtering by "Analytic Distribution" in views, using "is set" or "is not set" filters (or searching for False) returns incorrect results. When the filter is 'set' it returns all…
**Problem:** When filtering by "Analytic Distribution" in views, using "is set" or "is not set" filters (or searching for False) returns incorrect results. When the filter is 'set' it returns all records (even the ones without an analytic distribution) and when the filter is 'not set' it returns no records (even the ones without an analytic distribution). **Steps to reproduce:** 1) Go to Accounting > Journal Entries. 2) Apply a filter for Invoice lines > Distribution Analytic Account. 3) Select "is set" or "is not set". 4) Check records. Issue is also reproduceable on Purchase Orders. **Cause:** The `_condition_to_sql` method correctly converts '=' and '!=' operators to 'in' and 'not in', but there is no handling for when the value is [False], so it results in an invalid Query. **Solution:** - We need to handle the case when we have False in the value on it's own. opw-5478688 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247777
This update fixes an issue where flexible calendar employees were incorrectly displaying grayed-out days in planning and related modules. The change ensures that only public holidays and leaves are reflected as unavailable, providing a more accurate representation of employee availability. This improves the usability of the planning app for employees with flexible work schedules.
Original PR description
### Issue: When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible…
### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.
### Steps to reproduce:
- Create a new work schedule:
- Flexible Hours
- 24 hours per week
- 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out
### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).
### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.
To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.
Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.
In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.
In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.
opw-4879481
Forward-Port-Of: odoo/odoo#251002
Forward-Port-Of: odoo/odoo#245741This update fixes an issue where employees with flexible calendars displayed incorrect grayed-out days in planning and related modules. The change ensures that flexible calendar employees only show unavailable days for public holidays, improving the accuracy of scheduling and resource allocation. This resolves a visual discrepancy impacting how availability is presented.
Original PR description
### Issue: When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible…
### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.
### Steps to reproduce:
- Create a new work schedule:
- Flexible Hours
- 24 hours per week
- 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out
### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).
### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.
To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.
Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.
In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.
In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.
Forward-Port-Of: odoo/enterprise#108937
Forward-Port-Of: odoo/enterprise#105521This update corrects an issue where payments for invoices paid within 30 days (PUE) were incorrectly sent to the Mexican tax authority (CFDI). The fix disables a feature that allowed this, ensuring accurate CFDI reporting and compliance. This resolves a potential reporting error.
Original PR description
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm…
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm - Duplicate (Invoice B) - Confirm - Duplicate again (Invoice C) - Set Payment Terms to "30 days" - Confirm - Go to Invoice A - Pay it. It should appear as "Paid" - Send it to CFDI - Go to Accounting > Customer > Invoices - Select Invoice B and C - Pay and select the "Group Payments". They should appear as paid. - In every invoice, click the "Update Payment" button Current behavior: - In Invoice A -> Sheet CFDI: A button "Force CFDI" allow sending the payment to CFDI - In Invoice B/C -> sheet CFDI: Click on the "Download" part of the Payment line, the XML that was sent to CFDI include both invoice B and C Expected behavior: - It shouldn't be possible to send payment for invoice A to CFDI. - Payment for invoice B shouldn't be sent to CFDI Cause: Payment for invoice paid in less than 30 days, referred as PUE, shouldn't be sent to CFDI. Solution: Disable the force sending to CFDI About tests: l10n_mx_edi_cfdi_invoice_try_update_payments already send payment to CFDI for PPD invoices. Calling action_force_payment_cfdi was pointless and causing a mess. opw-5381600 Forward-Port-Of: odoo/enterprise#109105 Forward-Port-Of: odoo/enterprise#104628
This update addresses a potential issue in the transmission of Swiss payroll data. Specifically, a warning message was previously displayed for negative AVS (Authorize Payment Verification System) scores, which could be misleading. This change ensures a standard warning level is used, improving the clarity and reliability of the reporting process.
Original PR description
Forward-Port-Of: odoo/enterprise#109046
This update fixes an issue where the fiscal position for Brazilian customers was incorrectly linked to the US company setting. This resulted in errors when creating tasks and adding products. The change ensures that each customer's fiscal position is correctly associated with the company where it was created, resolving inconsistencies and preventing errors.
Original PR description
Issue ===== The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors. Steps to Reproduce ================== 1. Install…
Issue ===== The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors. Steps to Reproduce ================== 1. Install `industry_fsm_sale` and `l10n_br`. 2. In the US company: - Create a Brazilian customer. - Set a fiscal position on the customer. 3. Switch to the Brazilian company: - Open the same customer. - Set a fiscal position on the customer. 4. Still in the Brazilian company: - Create a task for that customer in the Field Service app. - Add a product to the task. Result ====== An error is raised because the fiscal position from the US company is used, which is not valid for the Brazilian company. Root Cause ========== When reading the fiscal position from the partner, the value is fetched in the environment of the company in which the partner record was originally created (US company). If no company is explicitly specified, the fiscal position is read in that original environment, even when the user is operating under the Brazilian company. Solution ======== Explicitly enforce the current company context when reading the fiscal position from the partner to ensure the correct company-specific value is used. opw-5270522 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250115 Forward-Port-Of: odoo/odoo#249482
1 change
Resolved issues and error corrections
This update corrects a reporting issue related to Swiss payroll transmissions. Specifically, it now displays a warning instead of an error when the AVS (authorized verification system) value is negative, ensuring accurate reporting and avoiding potential disruptions to payroll processing. This change improves the reliability of financial data for Swiss businesses using Odoo Enterprise.
Original PR description
Forward-Port-Of: odoo/enterprise#109046
24 changes
Enhancements to existing features
This update introduces stateful AI agents capable of updating records directly, enhancing user interaction and automation. Agents now preview changes and require confirmation before updates, improving data accuracy and streamlining workflows. Key improvements include batch record updates, support for Gemini 3.5 Flash, and optimized prompting for reasoning tasks.
Original PR description
Purpose: --------- Allow the agents to update records. Agents will always show a preview of the changes that will be done and require the user to confirm the suggested changes before updating the…
Purpose: --------- Allow the agents to update records. Agents will always show a preview of the changes that will be done and require the user to confirm the suggested changes before updating the records. To achieve this the agents framework has been refactored: The previous LLMApiService was entirely stateless, resulting in several significant functional and efficiency issues. This PR introduces the concept of an AI Session to hold the complete conversation history, thus resolving these problems and enabling new features like user-interactive tools. The primary issues resolved are: - Redundant tool calls: tools and their results were not included in the history, resulting in the LLM calling the same tool with the same args multiple time for the same context. - Inefficient reasoning: LLMs with reasoning capabilities would restart their thought processes on every new message because thinking signatures were lost. - Missing interactive tools: It was impossible to design tools that required pausing and confirmation from the user mid-flow. Technical Changes: ------------------ - Added a transient `ai.session` model, designed to store the complete history of user and model messages, including tool calls, tool responses, and model thinking signatures. This model is designed to be overridable to support different providers (e.g., ai.session.openai and ai.session.google). - The ai dict available inside every tool has new capabilities It carries (among others) - a `state` dict which enables tools to store and retrieve data across multiple tool calls - a `tool_request_message` used to store a message that will be shown to request usage of the tool to the user - a `tool_request_confirmed` boolean used to check if the user confirmed usage of the tool - the 'res_model' and 'res_id' of the record the session is linked to (when session is opened from a form view for example) - a `final_message` string allowing to "short-cut" and post a response as if it was the LLM's answer - Record information has been removed from the instructions to prevent prompt injection, and because the record data is dynamic. Instead, the record info is added as a context message along with the user message (that context message is not stored in the session history) - The "Is Ask Ai" and related code has been removed. Instead of searching for a potential agent that could do the "Ask AI" job, we use the one associated with the "systray" interface key for consistency Usage: ------- There are several ways to query a LLM depending on the needs: 1. ai_session `get_direct_response()` for basic one shot requests, without configurability from the UI. 2. ai_agent `generate_single_response()` for one shot requests, but with configurability through the usage of an agent and thus with support of agent related features (rag, topics, ...). Requests can be made from the frontend using the `/ai/generate_response` route (with an `interface_key` used to get the right agent) 3. ai_composer `action_launch_ai_chat()` for multi-turns interactions with the llm through a discuss channel. Sessions can be initialized from the frontend using the `launchAiChat` command. Task-5014794
This update bumps the default version of the website generator to 2.4 to ensure compatibility with recent changes in the 19.2 release. This ensures the website continues to function correctly and reliably. The change is driven by necessary updates to website snippets.
Original PR description
Since some snippets changed in 19.2, we up the version to support them Forward-Port-Of: odoo/enterprise#109044
This update modifies tests related to payroll to support the new automatic filling of work entries. This change ensures that work schedules are correctly populated with data from the company's source, streamlining the payroll process. It’s a key improvement for accurate payroll calculations.
Original PR description
In order to allow the automatic filling of work entries from the source work schedule of a company, some tests needed to be modified in order to cater for the new business logic. Task: 5949961
This update automatically updates the employee's sex and birthday fields in the UI when the NISS (National Identification System number) is changed. This ensures data consistency and accuracy, particularly when managing multiple companies within Odoo. The update only occurs if the new NISS value is valid.
Original PR description
The `sex` and `birthday` fields are defined in `hr` and cannot be overridden or converted to computed fields without breaking multicompany consistency. Add an `onchange` on `niss` to update `sex` and `birthday` in the UI when the NISS is modified. The update is performed only if the NISS is valid. Task: 5959156
This update improves the Employee Kanban view to display the employee's first contract date instead of the most recent contract date. This provides a clearer and more accurate view of an employee's tenure within the company. The change ensures consistency and simplifies tracking employee start dates.
Original PR description
Description of the issue/feature this PR addresses: On kanban, you see the start_contract_date of the latest version, but it should be the first contract date in the company Current behavior before PR: Desired behavior after PR is merged: . Display first contract date start on Employee Kanban view instead of start contract date of the latest version task-5481072 I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This update incorporates changes required by the Uruguayan tax authority (DGI) regarding Electronic Fiscal Receipts (CFE). Specifically, a new export option is added for mandated sales, and the transmission of key invoice details (amount, currency, exchange rate) from existing invoices is now required to ensure legal compliance.
Original PR description
Purpose: The DGI introduced changes in CFE version 25. The following changes below needs to be implemented for legal compliance.
Required Changes:
- Introduce a new selection value,("91", "Export under Mandate")for field, l10n_uy_edi_cfe_sale_mode. This option is required when documenting export operation performed as a mandating entity, where the definitive export will be carried out by a third party.
- The reference document(credit note or debit note) of an existing account move will need to send:
- Amount (MntCFEref)
- Currency (TpoMonedaRef)
- Exchange Rate (TpoCambioRef) if the currency is not Uruguayan Pesos
task-5419331
task-5419331
Forward-Port-Of: odoo/enterprise#108430
Forward-Port-Of: odoo/enterprise#103881Resolved issues and error corrections
This update resolves an issue where the arrow button within the Urban Piper settings was not functioning correctly. The fix involved ensuring the arrow was properly enclosed within a button tag, allowing users to navigate to the correct settings. This ensures a smooth and functional experience for users managing Urban Piper configurations.
Original PR description
In the settings, under the Urban Piper section, the arrow was not clickable. This is because the arrow was not inside a button tag. task: 5972833
This update resolves an issue where users were encountering errors when processing after-departure payments. Now, a clear and informative message is displayed if a previous payslip isn't linked, guiding the user to correctly set up the payment. This improves the user experience and prevents data inconsistencies.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607 Forward-Port-Of: odoo/enterprise#108980 Forward-Port-Of: odoo/enterprise#107386
This update resolves an issue where the scheduling dialog was incorrectly filtering out unscheduled shifts for resources. The fix removes a default filter, ensuring planners can now see and assign all available shifts, improving scheduling efficiency. This change corrects a previous bug that prevented accurate shift assignment.
Original PR description
Steps to Reproduce ------------------ 1. Open the Planning Gantt view. 2. Click a cell that belongs to a resource with **no** scheduled shifts. 3. The Plan dialog opens with an empty list. Issue…
Steps to Reproduce ------------------ 1. Open the Planning Gantt view. 2. Click a cell that belongs to a resource with **no** scheduled shifts. 3. The Plan dialog opens with an empty list. Issue ----- A previous change keeps the clicked resource in the dialog context; the Gantt model turns it into a default search filter, so only shifts already linked to that resource are shown. Unassigned shifts are therefore hidden, preventing planners from assigning them by role or availability. Current Behaviour ----------------- The Plan dialog is always filtered by `resource_id`, which returns no results for unscheduled resources, even when they have the right roles. Expected Behaviour ------------------ The dialog should list all unscheduled shifts that match the resource’s roles, or every unscheduled shift if the resource has no roles, while still preserving full context for scheduling once a shift is selected. Fix --- Remove the automatic resource filter from the dialog context in `getSelectCreateDialogProps()`. This prevents the unwanted search restriction; role defaults remain, so the dialog now displays the correct shifts. Task-4922525 Issue – https://github.com/odoo/enterprise/pull/87424/commits/a218a7cedce61f992fbe76284c273be8f937d28d Forward-Port-Of: odoo/enterprise#92100
This update fixes a minor discrepancy in the Gantt chart's progress display for flexible employees. The issue stemmed from an incorrect timezone setting in the test environment, leading to an inaccurate progress percentage. The fix ensures the chart accurately reflects employee attendance by standardizing the timezone to UTC.
Original PR description
[FIX] hr_attendance_gantt: fix gantt progress with flex emp test
Bug reproduction:
1 - Install and update hr_payroll,hr_contract_salary,l10n_us_hr_payroll,hr_attendance_gantt modules in localhost (version >= saas-19.2)
2 - Run test_gantt_progress_with_flexible_employees test and the expected result is 8 but it gives 9.
Bug cause:
Timezone of the test employees was UTC+1 and they should be UTC to match the range parameter of _gantt_progress_bar
Bug solution:
Change the timezone of the test employees to UTC.
task - 5865307
Forward-Port-Of: odoo/enterprise#109201This update fixes an error in how holiday pay recovery is calculated for employees in Belgium with non-standard working schedules. Previously, the system used a default 38-hour week, leading to inaccurate deductions. Now, the system correctly uses the employee's actual weekly hours (40) to ensure accurate holiday pay recovery amounts.
Original PR description
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount…
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount holiday n-1 4 - Set 10 days in recovery day holiday n-1 5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February and validate it 7 - Do one payslip for this employee for December Current behaviour : - the holiday n-1 amount for February = 824.80 - the holiday n-1 amount for December = 742.32 Expected behaviour : - the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80 **Reason** - The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules. **Solution** - Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied. Forward-Port-Of: odoo/enterprise#109069 Forward-Port-Of: odoo/enterprise#106205
This update fixes an issue where salary rules were incorrectly reducing both employee and employer costs. A new ‘Net Cost’ salary rule has been added to accurately reflect employer contributions, ensuring correct cost calculations for payroll reporting.
Original PR description
## Before: - Setting appears_on_employee_cost_dashboard to True on a salary rule uses the rule’s sign to compute employee cost. - For rules like Social Insurance Employee Contribution and DEWS Employee Contribution, the sign must be negative to deduct the amount from the employee, which incorrectly reduces the employer cost as well. ## After: - Introduced a new salary rule “Net Cost” to correctly reflect employer cost. - This allows employee contribution rules to keep a negative sign for deductions while still increasing the employer contribution amount. Task-5912761 Forward-Port-Of: odoo/enterprise#107090
This update corrects a bug that prevented payslip PDFs from being created correctly during pay run validation. The change ensures PDFs are generated for pay runs with 5 or fewer payslips, addressing a previous limitation that only triggered PDF creation for single payslips. This improves the reliability of payslip document generation.
Original PR description
Due to a missplaced argument in the js definition of the Validate button of the Pay Run view, context indicating the need for the creation of the pdfs of the payslips was not passed correctly, resulting in their missed creation, both immediately and later by the cron. Also, previously the pdfs were only computed right away if the pay run included only 1 payslip, which almost never happens. Here we change that condition to computing the pdfs if there are <= 5 payslips. Task: 5498819
This update corrects a technical issue where the new booking view for POS appointments was inadvertently replacing standard calendar event views, causing compatibility problems with other modules. By restricting the new view to use 'primary' mode within the POS, this fix ensures proper functionality and avoids disruption to other parts of the system.
Original PR description
The list view in pos appointment would replace the original list view on calendar event and break other modules. This PR will add the `primary` mode for the new view so it is only used inside the POS Runbot Error: [234914](https://runbot.odoo.com/odoo/runbot.build.error/234914) Forward-Port-Of: odoo/enterprise#107132
This update fixes a problem where archived employees caused errors when managing appraisal plans. The change ensures that archived employees are no longer considered for appraisal dates, preventing date conflicts and improving the accuracy of appraisal settings. This ensures a smoother experience for users managing employee appraisals.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002 Forward-Port-Of: odoo/enterprise#109115 Forward-Port-Of: odoo/enterprise#100437
This update prevents users from canceling subscriptions if they don't have access to the associated invoices. Previously, a sales representative could cancel a subscription even without seeing the invoices. Now, the system ensures cancellation is only possible when the representative has full visibility of the invoices, improving subscription management reliability.
Original PR description
Before this commit, when a user had access to an invoiced subscription but not to the invoiced, he could cancel the subscription. Step to reproduce: - create a subscription in company A, with a pricelist available in company B. Sales person A belong to company A. - invoice the subscription and confirm the invoice - update the company (company B) and sales person of the subscription (B). The new salesperon don't see the invoice in the stat button. After this commit salesperson B can't cancel the subscription. task-5907345 Forward-Port-Of: odoo/enterprise#108550 Forward-Port-Of: odoo/enterprise#106441
This update addresses a potential issue in the payroll transmission process for Switzerland. Specifically, it now displays a warning instead of an error when the AVS (Automatic Valuation System) value is negative, providing clearer guidance to users. This improves the reliability of the reporting and reduces the risk of misinterpretation.
Original PR description
Forward-Port-Of: odoo/enterprise#109046
This update fixes an issue where newly hired employees' work email addresses were incorrectly populated with their private email from the salary configuration. The fix ensures that the employee's work email field is properly cleared during the onboarding process, aligning with standard data practices. This prevents data inconsistencies and improves the accuracy of employee records.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797 Forward-Port-Of: odoo/enterprise#109074 Forward-Port-Of: odoo/enterprise#106974
This update streamlines the configuration for automatic extra time off allocation in Odoo Enterprise. The previous redundant toggle has been removed, and the feature is now controlled by a selection field, improving the user experience and simplifying management. This change focuses on internal efficiency and ease of use.
Original PR description
Streamline the configuration by removing the redundant boolean toggle 'hr_contract_timeoff_auto_allocation'. The feature is now driven directly by the 'hr_contract_timeoff_auto_allocation_type_id' field. Remove boolean field from res.company and res.config.settings. Update settings view to remove checkbox and improve explanation text. Adjust _update_version_on_signature to trigger based on the Many2one value. Add placeholder to the Many2one field for better UX. Task: 5445784
This update fixes an issue where the salary calculator incorrectly used a default full-time calendar, leading to inaccurate calculations when simulating employees with different work schedules (e.g., 40h/week vs. 20h/week). The fix ensures the calculator now correctly applies the selected resource calendar for simulation offers, providing accurate salary projections.
Original PR description
Steps to reproduce: 1- Go to Payroll > Employees > Salary calculator 2- Put a yearly cost of 10000 3- Select the "40h/week calendar" 4- Check the yearly cost 5- Change to "20h/week calendar" Cause of the bug: _get_version inside ContractSalaryOffer would take the default calendar from the version if it exists (in our case it will always be the full time for the simulation employee) Fix done: Keep the condition as it is for normal offers, and for simulation offers change the default to the selected resource calendar task-5431216 Forward-Port-Of: odoo/enterprise#108949 Forward-Port-Of: odoo/enterprise#103159
This update fixes an issue on mobile devices where the 'Share' button was incorrectly displayed on top of the calendar sidepanel. The change ensures the button is hidden when the sidepanel is open, resulting in a cleaner and more intuitive user experience. This improves usability for mobile users.
Original PR description
Purpose ======= On mobile, prevent displaying the appointment Share button on top of the calendar sidepanel. Specification ============= On mobile, when opening the calendar sidepanel, the panel covers the entire calendar. However the appointment Share button has a z-index set to the modal level ($zindex-modal) which makes it so that the button is always displayed on top of the calendar sidepanel. Fixing that by making sure the appointment Share button is hidden when the calendar sidepanel is opened on mobile. Task-5717052
This update resolves an issue where payslips wouldn't generate correctly when an employee changed contracts within a pay period. The fix ensures the system uses the employee's initial contract start date for accurate calculations, preventing errors related to holiday entitlements and year-of-service calculations. This improves payroll accuracy for employees with multiple contracts.
Original PR description
An error is thrown when we try to generate a payslip for an employee that changed contract on a period before the contract change Steps to reproduce: 1. Install l10n_mx and l10n_mx_hr_payroll modules…
An error is thrown when we try to generate a payslip for an employee that changed contract on a period before the contract change
Steps to reproduce:
1. Install l10n_mx and l10n_mx_hr_payroll modules
2. Switch to INNOVACION VALOR... company
3. Go to Employees and open Cecilia Miranda Sanchez
4. Go to Payroll tab, set the end of the contract to Jan 31 and save
5. Create a new contract from Feb 1
6. Go to Payroll > Payslips > Payslips and create a new pay run
7. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and Period 'Jan 1 -> Jan 15'
8. Click on Continue, select Cecilia and click on Select
9. An error is thrown
Problem:
In `_compute_integration_factor` we try to compute the number of years the employee has worked by accessing the start date on the employee but this date might be earlier than the start date of the employee's current contract if the employee has changed contract. This will throw an error when we try to access the holidays count for 0 year because `payslip._rule_parameter('l10n_mx_holiday_tables')` doesn't have an entry for 0
Solution:
Use the start date of the first contract of the employee, take gaps in between the employee's contracts into consideration to correctly compute the number of years worked
opw-5931355
Forward-Port-Of: odoo/enterprise#108495This update makes the Gantt chart's date selection more responsive, updating the displayed date range immediately as the user adjusts the picker. Previously, the date range only updated after clicking 'Apply'. This change provides a smoother and more intuitive user experience when working with Gantt charts.
Original PR description
- Previously, the Gantt scale selector only updated the displayed date range after the "Apply" button was clicked. This was because the template was bound to the component props rather than the local state. - This commit binds the date picker display to the local pickerValues state. Now, when a user selects a date in the picker, the UI updates immediately, while the actual data fetch remains deferred until "Apply" is clicked. Task: 5932671 Forward-Port-Of: odoo/enterprise#107380
Code cleanup and technical improvements
This pull request involves refactoring the VoIP codebase to better prepare it for upcoming changes. These internal adjustments improve the code's structure and flexibility, enabling easier future development and integration with new features. This work supports the broader task of improving our VoIP functionality.
Original PR description
We refactor the code in order to be able to extend it for task-4917399
7 changes
Enhancements to existing features
This update enhances the generation of WPS files for Odoo Enterprise companies operating in the UAE, ensuring greater compliance with local regulations. The changes include improvements to data formatting, bank account linking, and report export capabilities, ultimately streamlining the payroll process for UAE-based businesses.
Original PR description
This commit aims to make the generation of wps files for AE companies more compliant and intuitive for the user, by: - Updating string for l10n_ae_employer_reference field - Domaining the company's salary bank account to accounts that belong to the company - Enabling the export of xlsx wps report - Preventing negative values in EVP section of the wps file - Adding constrains to the employer code as per expected format - Changing the names of allowance inputs - Adding a new category for evp rules - Making sure clearing number is only 9 digits as per expected format task-5884696
Resolved issues and error corrections
This update resolves a technical issue where a test XML file was incorrectly being included in the translation process. By moving the file to the correct testing directory and updating the translation files, the system now exports only the necessary test data, improving efficiency and accuracy.
Original PR description
In this commit[^1], the same XML test file (e-invoice) was added both to the regular `tests/assets` directory as well as to the `static/src/tests/assets` directory. The latter is a path that is visited by the translation extractor, extracting its strings to the POT file. This didn't make sense at all. This commit fixes that by moving the XML file in the tour test our of the `static/src` directory, into `static/tests`. This path doesn't get its files extracted. We meanwhile update the POT file to remove the irrelevant entries. [^1]: https://github.com/odoo/enterprise/commit/673311b0b8ac6f7e224da8315a302afb7905f9e7
This update resolves a minor issue preventing users from editing date inputs within the payroll form. By adding a brief delay, the system now correctly opens the associated popover before clearing the input, ensuring the form remains fully functional. This improves the user experience and prevents data editing problems.
Original PR description
With this additionnal step in tour, we ensure the popover is opened before clear the input. If we not wait for this, the input can be no longer editable. runbot-error-id~234440
This update corrects a test case within the quality control module to reflect recent changes in how Odoo handles stock moves. Specifically, the test now accurately assesses scenarios where stock transfers merge into existing ones only when a 'stock reference' is present. This ensures the quality control process aligns with the latest Odoo functionality.
Original PR description
Fix the test case to align with the updated picking move merge behavior, where the next transfer merges into an existing one only when a stock reference is set TaskID-5242340 Forward-Port-Of: odoo/enterprise#108399 Forward-Port-Of: odoo/enterprise#99342
This update allows Odoo Leaders to automatically launch appraisal campaigns for all their employees without needing to manually select individuals. Previously, a campaign required specific employee selection. This simplifies the process for Leaders and ensures all employees are included in the appraisal cycle.
Original PR description
. Allow the Leader to launch an appraisal campaign for all their employees by default when no specific employees are selected in the list. task-5347755
This update corrects an issue where payments for invoices paid within 30 days (PUE) were incorrectly sent to the Mexican tax authority (CFDI). By disabling a specific function, we now ensure that only payments meeting the required 30-day term are processed, aligning with Mexican regulations and improving data accuracy.
Original PR description
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm…
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm - Duplicate (Invoice B) - Confirm - Duplicate again (Invoice C) - Set Payment Terms to "30 days" - Confirm - Go to Invoice A - Pay it. It should appear as "Paid" - Send it to CFDI - Go to Accounting > Customer > Invoices - Select Invoice B and C - Pay and select the "Group Payments". They should appear as paid. - In every invoice, click the "Update Payment" button Current behavior: - In Invoice A -> Sheet CFDI: A button "Force CFDI" allow sending the payment to CFDI - In Invoice B/C -> sheet CFDI: Click on the "Download" part of the Payment line, the XML that was sent to CFDI include both invoice B and C Expected behavior: - It shouldn't be possible to send payment for invoice A to CFDI. - Payment for invoice B shouldn't be sent to CFDI Cause: Payment for invoice paid in less than 30 days, referred as PUE, shouldn't be sent to CFDI. Solution: Disable the force sending to CFDI About tests: l10n_mx_edi_cfdi_invoice_try_update_payments already send payment to CFDI for PPD invoices. Calling action_force_payment_cfdi was pointless and causing a mess. opw-5381600 Forward-Port-Of: odoo/enterprise#109105 Forward-Port-Of: odoo/enterprise#104628
This update ensures the IEPS tax breakdown is correctly displayed on Mexican CFDI invoices, aligning with SAT regulations. Specifically, it now accurately shows IEPS based on whether the invoice is a 'global invoice' or uses tax object 07, resolving inconsistencies in previous behavior.
Original PR description
This commit targets to modify the behaviour of IEPS breakdown on CFDI to follow on what is specified on SAT cfdi Tax Object Catalog. Now the IEPS will be displayed only considering if the CFDI is a global invoice, the value of the tax object and whether the check is set. The general idea is: - Is a global invoice? -> show IEPS - Is tax object 07? -> show IEPS - Has ieps breakdown but is not tax object 08? -> show IEPS - Anything else, don't. task-5953499 target: saas-18.4 -> master Forward-Port-Of: odoo/enterprise#108555
6 changes
Resolved issues and error corrections
This update fixes an issue where negative values were appearing in tax reports for carried over tax lines (-81, -82, etc.). The change ensures that the XML generated for tax reports accurately reflects tax calculations, preventing potential reporting errors and improving data accuracy. This resolves a previous bug reported by internal teams.
Original PR description
When generating the xml for tax report, negative values should not be present in the xml for carried over lines (81, 82, 83, 86, 87, and 88) Steps: - Create a RBILL for today - 1 month, add an invoice line with tax using one of the following tags: -81, -82, -83, -86, -87 or -88 in its base refund repartition line - Open the tax report on the month of the RBILL - Generate the xml, either by the dedicated button, or by creating and posting the closing entry -> there is line(s) for negative amounts opw-5955323 opw-5428395 Forward-Port-Of: odoo/enterprise#108916
This update corrects a display issue where proforma vendor bills were incorrectly shown when accessing or downloading bills through the customer portal. The fix now ensures that proforma bills are only presented for invoices and credit notes, aligning with standard billing practices. This improves the accuracy and clarity of bill information for customers.
Original PR description
When accessing to a bill via the portal, we display a proforma vendor bill, same when we download from the portal, it should not be the case Steps: - Create and confirm a vendor bill - Via the menu action, click on "Share" and copy the link - Open the link -> a proforma vendor bill is displayed - Download the bill -> we get a proforma vendor bill Fix: Allow proforma only for invoices/credit notes opw-5882732 Forward-Port-Of: odoo/odoo#248443
This update resolves a potential data error that could occur when moving folders linked to settings to the trash. The fix prevents a database conflict during the automatic cleanup process, ensuring data integrity and stability. This improves the reliability of the Documents module.
Original PR description
When a workspace(folder) linked to a folder setting is moved to the trash and the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate. Steps to reproduce the error: - Install ``documents_account`` module - Go to Documents > Configuration > Files Centralization > Enable Accounting > Select any workspace > Save > - Click on Journals > Create a new > Select any Journal > Create a Workspace A > Save - Go to Documents > Click on Workspace A > Actions > Move to trash - Run the ``Base: Auto-vacuum internal data`` cron Traceback: ```py ForeignKeyViolation: update or delete on table "documents_document" violates foreign key constraint "documents_account_folder_setting_folder_id_fkey" on table "documents_account_folder_setting" ``` solution: override the ``_get_gc_clear_bin_domain`` method to exclude folders linked to folder settings, preventing their deletion during the garbage collection. sentry-7193540869
A test within the Nilvera e-invoice module failed due to an incorrect invoice data format. This update corrects the test by using the standard sending settings, preventing potential errors and ensuring the invoice generation process works as expected. This ensures the e-invoice functionality remains stable and reliable.
Original PR description
In the `test_which_service_to_call` test, we are calling `_call_web_service_before_invoice_pdf_render` with invoice_data. But invoice_data is just a dict with `invoice.read()` and the extra key extra_edis. Instead of manually building invoice_data, we should call `_get_default_sending_settings`, which is meant to be used in the base `account.move.send` flow. Why this fix? Because by not calling `_get_default_sending_settings`, we risk changing the expected invoice_data format used in `_call_web_service_before_invoice_pdf_render`, which could lead to KeyErrors. Spotted while developing https://github.com/odoo/enterprise/pull/80590, the test failed, raising the ['invoice_edi_format'] key error. no-task
This update resolves an issue where the Sendcloud shipping API required product weights to be at least 0.00099. This commit ensures that product weights are now a minimum of 0.001, preventing errors and ensuring accurate shipping calculations through Sendcloud. This improves the reliability of our shipping process.
Original PR description
The Sendcloud API do not allow parcel details to have a weight value less than 0.00099 . This commit makes sure the products weights are at least 0.001. ref: <img width="1850" height="689" alt="image" src="https://github.com/user-attachments/assets/10242315-3c4d-4670-b77d-8cb429e00891" />
This update resolves an issue where early payment discounts weren't correctly processed when generating invoices in the Factur-X format. The change adds the necessary handling for 'early payment discount' (EPD) information, ensuring accurate invoice generation and compliance with accounting standards. This improves the reliability of our invoicing process.
Original PR description
Added the handling of early payment discount in the factur-x format. opw-5265981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244659
6 changes
Resolved issues and error corrections
This update resolves an issue where disabled records were incorrectly flagged as blacklisted, potentially blocking legitimate users. The change ensures that disabled records are ignored when determining blacklist status, improving user access and functionality. This fix was driven by a Loom demo and related internal ticket MT-13153.
Original PR description
Same as https://github.com/odoo/odoo/pull/249466, but for v17 and with tests. > When computing wether the user is blacklisted, disabled records must be ignored. > > https://www.loom.com/share/41ea437477f8416f8b50f9ef979d82bf > > > --- > I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr > > @moduon MT-13153 OPW-5952301
This update corrects a problem where QR codes generated in self-ordering mode (for pickup zones) contained incorrect URLs. The fix ensures QR codes accurately reflect the order without including table identifiers, improving the reliability of order downloads. This resolves an issue reported in opw-5095607.
Original PR description
Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right there below these configs) Observation: - in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be. - QRs do not have table_id Cause: - there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone" Fix: - we only use table_id when ordering_mode = 'table'. **Before:** <img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" /> **After** <img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" /> opw-5095607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where product catalogs weren't correctly converting currency when displaying products or adding them to purchase orders. Now, the catalog accurately reflects the vendor's currency, ensuring consistent pricing across all sales channels. This improves accuracy and avoids discrepancies in purchase order calculations.
Original PR description
When a product is sold by a vendor in a different currency from the PO currency, the product catalog did not correctly convert the currency when displaying the product or when adding it to the PO. This was inconsistent with the backend form view, which does convert the currency when the product is added. This fix is a backport of: https://github.com/odoo/odoo/commit/aadb877f971c638bc39e91136bfe7f8dc2fce500 opw-5266131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where changes made to email HTML within the code view weren't automatically saved. Now, when switching back to the editor view after editing HTML, the field is correctly marked as dirty, ensuring all changes are saved seamlessly. This improves the Email Marketing workflow for users.
Original PR description
Problem: In Email Marketing, switching to code view, editing the HTML, and then switching back to the editor view does not mark the field as dirty. As a result, changes cannot be saved unless an additional modification is made directly in the editor. Solution: Explicitly mark the field as dirty when switching from code view back to editor view, ensuring HTML changes are properly detected. Steps to reproduce: - Create a new Email Marketing record. - Drop any snippet. - Switch to code view. - Modify the HTML. - Switch back to editor view. - Observe that the field is not marked as dirty and changes cannot be saved unless further edits are made in the editor. opw-5999752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that timesheet changes consistently recalculate the cost of sale order lines, regardless of the invoice policy (ordered_prepaid, delivered_manual, or delivered_milestones). Previously, this calculation was inconsistent, leading to potential discrepancies in sales reporting. This fix improves the accuracy of cost tracking for sales orders.
Original PR description
Originally, timesheet updates for tasks associated with sale order lines would cause the cost (purchase_price) to be recomputed. However, this was prevented if the invoice policy was 'ordered_prepaid.' This should also apply to 'delivered_manual' and 'delivered_milestones.' Otherwise, any timesheet updates will recompute the sales.order.line purchase_price field. Steps to reproduce: Create a service product that creates a project/tasks Create a sales order with the product and manually set the cost Assign the timesheets of the task to an employee Have the employee update their timesheet for the task The cost on the sales order line gets recomputed to the default product price Duplicate of pr-250495 task-5902688 related-pr-205415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A bug in the stock forecast report was causing a runtime error when processing delivery transfers involving sublocations. This change temporarily prevents the error, ensuring the report functions correctly. The original fix will be implemented in a subsequent commit.
Original PR description
This reverts commit 2b2d73df420baee4fec1c51c28250666d80b48b8. ## How to reproduce (in runbot): - Create Product P - Create Delivery transfer from 'WH/Stock/Shelf 1' - Open Forecast report: =>…
This reverts commit 2b2d73df420baee4fec1c51c28250666d80b48b8.
## How to reproduce (in runbot):
- Create Product P
- Create Delivery transfer from 'WH/Stock/Shelf 1'
- Open Forecast report:
=> RuntimeError: dictionary changed size during iteration
The original fix will be redone in another commit.
---
## Traceback:
```
File "/data/build/odoo/addons/stock/report/stock_forecasted.py", line 21, in get_report_values
'docs': self._get_report_data(product_ids=docids),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/stock/report/stock_forecasted.py", line 128, in _get_report_data
res['lines'] = self._get_report_lines(product_template_ids, product_ids, wh_location_ids, wh_stock_location)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/stock/report/stock_forecasted.py", line 359, in _get_report_lines
for product_id, location_id in currents:
RuntimeError: dictionary changed size during iteration
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr