Daily updates from Odoo
Wednesday, January 28, 2026
198 changes
18 changes
New functionality added to Odoo
This update introduces a new version of the Partner Ledger report specifically tailored for Indonesia. It now groups transactions by the PAN entity, a key requirement for Indonesian tax reporting. Previous duplicate code has been removed to improve report efficiency and accuracy.
Original PR description
Backport of :- https://github.com/odoo/enterprise/pull/105011 task-4975468
Enhancements to existing features
This update allows tooltips in the Odoo application to now include newlines, improving readability and making them easier to understand for users. This change was driven by a need to better organize information within tooltips, enhancing the overall user experience. It's a minor improvement that addresses a usability concern.
Original PR description
We need to have a new line in tooltips. related task-5367117 Allow to have a new line in tooltips strings --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the Point of Sale interface by providing a clear view of LNA permission status. A new button in the navigation bar displays the current status and opens a popup with detailed information, ensuring users understand access rights related to LNA functionality. This improves transparency and operational efficiency.
Original PR description
Before this commit it was not possible to know if LNA permission was granted, denied or not yet granted from the POS interface. This commit adds a button in the navbar to show the current LNA status and open a popup with more information. taskId: 5874947 Forward-Port-Of: odoo/odoo#245668
Resolved issues and error corrections
This update resolves a problem where users with custom tax groups (like PPH) would prevent EFaktur printing. The change ensures that only the six standard Odoo tax groups are considered, allowing invoices with custom groups to print correctly. It also corrects how tax values are calculated for invoices with mixed tax groups.
Original PR description
Description of the issue/feature this PR addresses: This issue occured because in the previous update we add a condition to restrict multiple tax groups excluding the STLG. Apparently there is a case…
Description of the issue/feature this PR addresses: This issue occured because in the previous update we add a condition to restrict multiple tax groups excluding the STLG. Apparently there is a case where some users create their own tax groups (for example for PPH) so when they want to print an efaktur it will raise an error. Current behavior before PR: If a user create their own tax with a new tax group (outside of the 6 groups defined in `l10n_id`) and use it in invoice line along with one of the 6 tax groups excluding the STLG then it will blocked the print efaktur because it will raise an error Desired behavior after PR is merged: - The restriction in tax groups only applied for the 6 tax groups in l10n_id so if an invoice line has multiple tax groups as long as there no more than one of the 6 tax groups excluding the STLG then it should be able to print the efaktur. - Also when building the efaktur coretax value, the new tax group should not be included in the regular_tax variable which will cause the value to be 11/12 of the original value. - Add new condition to block the print efaktur if there is a tax inside the invoice but none of it belong to the 6 ppn tax groups (there is already a condition to block if no tax is given, but now since there are cases where they use tax group outside of the defined tax groups then it will print the efaktur) - If an invoice line does not have any ppn_tax_groups but there are other line in the same invoice that has it then it will still be able to print the efaktur, but the line without the ppn tax will have the OtherTaxBase and VATRate set to zero which will calculate the VAT as 0 too. [5434656](https://www.odoo.com/odoo/project.task/5434656) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245951 Forward-Port-Of: odoo/odoo#241979
This update corrects a previous change that prevented the system from automatically selecting a default shipping method when available. It now allows the system to choose a suitable carrier from the list of options, ensuring a smoother and more efficient order fulfillment process. This resolves an issue where users were restricted from utilizing the system's intelligent shipping suggestions.
Original PR description
https://github.com/odoo/odoo/pull/203955, by wanting to ensure no unallowed carrier was set as default, removed the possibility to set one. This PR puts back the possibility of having a default shipping method if part of the available carriers. opw-5263540 Forward-Port-Of: odoo/odoo#242867
This update enhances the monitoring of our AI-powered features by changing key logs from 'debug' to 'info' for easier tracking by our team and database administrators. Additionally, the system now accurately reports LLM token usage, providing a more precise understanding of AI service consumption. This improves operational efficiency and cost management.
Original PR description
In this commit we change some important llm api usage logs from debug to info so they can be more easily monitored by us and database admins. We also change the usage reporting from a naive estimation (which greatly under-reported the token usage) to the actual token usage given to us by the LLM prodivers in the response.
This update resolves an issue where Time-Off Responsibles lacked the ability to refuse fully accepted leaves, resulting in an access error. The fix ensures they can correctly unlink related calendar entries, aligning with existing approval workflows and improving usability.
Original PR description
****Behavior:**** When a user who is Time off Responsible but not Officer or Admin and is marked as responsible for an employee tries to refuse a fully accepted leave an access error occurs. This…
****Behavior:**** When a user who is Time off Responsible but not Officer or Admin and is marked as responsible for an employee tries to refuse a fully accepted leave an access error occurs. This occurs because approving a leave creates a resource.calendar.leave linked to the hr.leave, and when refusing it, the system will try to unlink it. https://github.com/odoo/odoo/blob/72e8a29dd0edb0ca3d464142ce869f38f96c730a/addons/hr_holidays/models/hr_leave.py#L896-L901 According to access rules of r.calendar.leaves, Time-off Responsibles are not allowed any access for entries of other employees. Approving them doesn't cause an error because the create operation uses sudo(), assuming that the user must have had valid rights to access the function. This is not the case for the unlink. **Solution:** This fix checks wether the user has write access to the related hr.leave record, then uses sudo(). The idea is that if they are allowed to modify the state of the leave, they can refuse the leave, and therefore should be able to go through the following operations. This is in a similar fashion as the behavior for approving the leaves. ****Steps to Reproduce:**** - Create a Leave Type that requires validation from a manager, and assign one to an employee. - Remove any access rights to Time-Off for the user, but leave Time off Responsible checked. - Assign the user as time-off responsible for the employee - Log in as the user and approve the leave - When refusing the leave, you should get an access error. opw-5178783 Forward-Port-Of: odoo/odoo#243405 Forward-Port-Of: odoo/odoo#238205
This update ensures accurate payslip updates by implementing a necessary security measure – running operations with elevated permissions (sudo). This prevents errors related to users modifying their own payroll information and resolves a technical issue that was previously causing system instability. It improves the reliability of payroll processing.
Original PR description
From a previous PR (103147), the payslip update logic was moved to the write function which gets called when a field is changed. In doing so, a sudo call is necessary to avoid problems with users modifying their own record (and not having access rights to read slip_ids). This also applies to tests and solves the following runbot error: Runbot Error: 237743 Forward-Port-Of: odoo/enterprise#105287
This update resolves an error that occurred when a repair order's scheduled date was updated without a product assigned to a move line. The issue stemmed from incorrect calculations related to unit of measure, preventing the update from completing successfully. This ensures repair orders can be scheduled reliably.
Original PR description
An error occurs when the product is not set in the repair move line, and the Scheduled Date is being updated. **Steps to Reproduce:** - Install the **Repairs** module. - Create a new **Repair Orders**. - Add a product and confirm the repair. - In the **Parts** tab, **add a new line** and change the **demanded** quantity without selecting a product. - Update the **Scheduled Date**. **Error:** `AssertionError: precision_rounding must be positive, got 0.0` `ValueError: Expected singleton: uom.uom()` (v19.0) When the move line has no `product_id`, its Unit of Measure (uom_id) is also empty. Updating the scheduled date triggers a computation, which leads to the error. Forward-Port-Of: odoo/odoo#246011 Forward-Port-Of: odoo/odoo#244179
This update resolves an issue where Odoo would crash when receiving Stripe webhook notifications for transactions that didn't exist in the system. Now, Odoo gracefully handles these events, logging a warning and returning a standard response to Stripe, preventing payment disruptions. This ensures continued reliable online payments.
Original PR description
Prior to this commit, receiving a Stripe webhook notification for a transaction that does not exist in Odoo (e.g., Point of Sale "card_present" payments) would cause an Internal Server Error (500). The issue occurred because the controller attempted to call `_verify_signature(tx_sudo)` even when `tx_sudo` was empty. Inside `_verify_signature`, accessing `tx_sudo.provider_id` on an empty record triggered a "ValueError: Expected singleton" crash. Consequently, Stripe would interpret these 500 errors as a server failure and automatically disable the webhook endpoint, breaking online payments. This commit fixes the issue by checking if `tx_sudo` exists before proceeding with signature verification. If no transaction is found, Odoo now logs a warning and returns a 200 OK status to gracefully acknowledge and ignore the extraneous event. opw-5439528 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245777
This update corrects a problem where new work entries didn't properly remove older entries, and incorrectly linked versions. The fix ensures work entries are accurately generated and nullified across different Odoo versions, improving the reliability of the HR work entry process. This resolves inconsistencies in regeneration behavior.
Original PR description
Problem ---------- 3 issues : - If you generate work entries for a new version it will not nullify the already generated work entries for the previous active version. - The version_id on the work entry is not set to the active version at the date of the work entry - The regenerate hasn't the same behavior if you call it from the wizard or from the front. Fix ---------- Remove the skip of versions that ends before the date_start of the generation. To go through the nullify process. Remove the double nullify in the regenerate in the case we have slots (we don't come from the wizard) Correct the `_set_current_contract` to give the good version for the date. Forward-Port-Of: odoo/odoo#245863
This update fixes an issue where the tour pointer was appearing in unwanted locations, like above dialogs, creating a confusing user experience. Now, the pointer only appears when the trigger element (like the 'My Profile' menu) is actively visible, ensuring a cleaner and more intuitive tour experience.
Original PR description
POC for task-5490670 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245949 Forward-Port-Of: odoo/odoo#243852
This update resolves an issue where the Gantt chart's date range controls would overlap with other UI elements, particularly on smaller screens. The fix adjusts the scale selector to prevent this overlap, ensuring a cleaner and more usable Gantt chart experience. This improves usability for all users.
Original PR description
Steps to reproduce ================== - Switch to dutch - Emulate an iPhone SE viewport in the browser settings - Open a project - Switch to the gantt view - Use a custom date range -> The gantt controls are displayed on top due to the daterange format being to long Note ==== The fix is in the ViewScaleSelector component, but only the gantt view uses a custom scale opw-5340869 Forward-Port-Of: odoo/odoo#245552
A recent update to the hr_expense_stripe_demo module caused a problem when users attempted to connect a demo account. This fix corrects an error in how system parameters were updated, ensuring the demo account setup now functions correctly. This resolves a minor disruption for users exploring the demo.
Original PR description
Forward port wasn't done right, and the way to get the system parameter changed. To reproduce: - Install hr_expense_stripe_demo - confirm agreeing to the terms - Save - click on "Connect (Demo)"
This update resolves an issue in the website editor where deleting snippets could cause a selection error, specifically in Chrome. The fix ensures that offsets are validated when retrieving selection data, preventing errors when the selection becomes invalid due to user actions like deleting snippets. This improves the stability and reliability of the website editor.
Original PR description
**Description of the problem** In the website editor, the user can manipulate the page in such a way to generate a problematic `SelectionPlugin.activeSelection`, which still points to an existing…
**Description of the problem** In the website editor, the user can manipulate the page in such a way to generate a problematic `SelectionPlugin.activeSelection`, which still points to an existing `anchorElement`, but has an invalid `offset`. **How to reproduce** This seems to be reproducible only on Chrome. 1. Enter in the website edit mode 2. Drop the `s_newsletter` snippet 3. Drop the `s_popup` snippet 4. Click on the popup, and delete it 5. Click on the blank space inside the `s_newsletter` snippet 6. Delete the `s_newsletter` snippet 7. The error occurs Notes: 1. Snippet different than `s_newsletter` can be used to reproduce the problem, as long as they contain a blank space. 2. It is important to make sure that the movement of the mouse pointer does not trigger any preview when going from step 5 to step 6. **Why the problem happens** On Chrome, clicking on a blank area can cause `document.getSelection()` to return a selection with a null `anchorNode.` When this happens, `SelectionPlugin.getSelectionData()` will use the already existing `activeSelection` if `activeSelection.anchorNode` is still connected. Before this commit, this method only checked that `anchorNode` was connected, without validating offsets. This leads to the following edge case: 1. The user removes the `s_popup` 2. At this point, `document.getSelection()` would point to the `s_newsletter` snippet, so if the user just deletes the snippet nothing bad would happen. But instead, if: 3. The user clicks on a blank area in `s_newsletter`, `document.getSelection()` will now return a null `anchorNode` 4. The user delete the `s_newsletter` snippet, and `SelectionPlugin.getSelectionData()` is called by an handler after the deletion 5. At this point: `document.getSelection()` has a null `anchorNode`, so the method will check if `activeSelection.anchorNode` is still connected, WITHOUT validating the offsets. 6. Since `anchorNode` is still connected, this selection will be used, and an error will be triggered shortly after, because the offset is too high (pointing to `s_popup` which does not exist anymore). **Fix** After this commit, when `SelectionPlugin.getSelectionData()` checks that `activeSelection.anchorNode` is still connected it also checks that the offsets are valid (meaning that they are smaller than the number of nodes). task-5430500 Forward-Port-Of: odoo/odoo#245818 Forward-Port-Of: odoo/odoo#244331
This update improves the reliability of the IoT Box upgrade process. Previously, a failed upgrade could cause the box to repeatedly attempt the upgrade on subsequent starts. Now, the system checks if the upgrade command was successful before renaming the branch, preventing unnecessary and potentially disruptive restarts.
Original PR description
If the upgrade fails, the branch name can already be set to the target one. Making the IoT Box not upgrading on next start. We now check `git` method return value, to ensure the command succeeded, before renaming the branch. Forward-Port-Of: odoo/odoo#245875
A recent issue prevented the Point of Sale appointment tour from working correctly when tests were run close to midnight. The fix ensures appointments are scheduled and displayed accurately, regardless of the time of day. This improves the reliability of the appointment booking process for users.
Original PR description
The `test_pos_restaurant_appointment_tour_basic` test was failing when run late in the day. The test creates an appointment 30 minutes in the future and expects a corresponding label to appear underneath the table in the POS floor plan. However, if the test is executed near midnight (e.g. 23:45 UTC), the appointment is scheduled for the following day. Since the Point of Sale frontend only displays appointments for the current day, it filters the booking out, causing the tour to timeout while waiting for the label. runbot-232601 Forward-Port-Of: odoo/enterprise#105738
This update fixes a technical issue preventing users without WhatsApp access from viewing WhatsApp conversations in Discuss. The problem stemmed from a configuration error that caused access issues when retrieving message status. This ensures all users can access and view WhatsApp conversations.
Original PR description
Steps to reproduce: - Open any WhatsApp conversation in Discuss. - post a message. - Invite an internal user who does not have WhatsApp access (e.g., Marc Demo). - Log in as the invited user. - Open the invited WhatsApp conversation. => it shows `An error occured while fetching messages` Since [1], this happens because `sudo()` was accidentally removed while storing `whatsappStatus` on messages, leading to an access error. This commit fixes the issue. [1]: https://github.com/odoo/enterprise/pull/100237 Task-5794783
5 changes
Resolved issues and error corrections
This update hides live chat commands (like `/help`) from website visitors and guests. Previously, these commands were visible, potentially leading to confusion or misuse. This change enhances website security and the user experience for standard visitors.
Original PR description
**Before PR:** channel commands like `/help ` or `/leave` and more are visible to visitors or guest even it is not functional for them. **After PR:** all commands are now hidden from visitors/guests. task-4548666 Forward-Port-Of: odoo/enterprise#105133 Forward-Port-Of: odoo/enterprise#82963
This update corrects a technical issue preventing accurate payslip updates, particularly for employees. By adding a 'sudo' call, the system now correctly accesses necessary data, resolving a previous error and ensuring payroll information is updated reliably. This improves the stability and accuracy of payroll processing.
Original PR description
From a previous PR (103147), the payslip update logic was moved to the write function which gets called when a field is changed. In doing so, a sudo call is necessary to avoid problems with users modifying their own record (and not having access rights to read slip_ids). This also applies to tests and solves the following runbot error: Runbot Error: 237743 Forward-Port-Of: odoo/enterprise#105287
This update ensures that sign templates created in languages other than English automatically use the correct document name. Previously, templates defaulted to 'New Template' regardless of the selected language. This fix corrects a translation issue, guaranteeing accurate template naming across all supported languages.
Original PR description
## Steps to reproduce: 1. Upload a new PDF document to be signed. 2. Select it in the Documents app to sign it. 3. Check the name of the sign template created. ## Issue: When creating signature templates in languages other than English, the template name would stay as "New Template" instead of updating to the actual document name. This happened because the code was comparing the template name against a translated version of "New Template", but the template was initially created with the English default value. Since "New Template" ≠ "Nueva Plantilla" (Spanish), the comparison failed and the name never got updated. The fix ensures we always compare against the original English default value, so the template name gets properly updated to match the document name regardless of the user's language. Related commit: 4254542 opw-4980747 Forward-Port-Of: odoo/enterprise#92682
This update resolves an issue where the IoT Box was incorrectly downloading standard drivers, potentially causing conflicts and outdated versions. A new setting allows custom drivers to be downloaded, but this change has been adjusted to avoid overwriting existing drivers and introducing previous bugs. This ensures a more stable and reliable IoT Box experience.
Original PR description
The stable IoT Box uses drivers from git repository: it doesn't download them from the database as it used to do. However, sh/on premise clients might want to develop custom drivers that the IoT Box would download. For that, they have to enable a checkbox on the IoT homepage, making the IoT Box download handlers as before. The issue is it will also download standard drivers that are already present on the IoT Box: on newer databases it would simply overwrite them, but on older ones, it would duplicate as names might have changed. Also, it would introduce issues back that were already fixed. To avoid this, we avoid adding drivers from standard modules to the downloaded archive, to prevent issues with the main ones. Forward-Port-Of: odoo/enterprise#105686 Forward-Port-Of: odoo/enterprise#105531
A recent bug in the Point of Sale appointment tour was causing it to fail when tests were run close to midnight. This was due to the system scheduling appointments for the next day, which the POS frontend then filtered out. This fix ensures the tour functions correctly regardless of the time of day.
Original PR description
The `test_pos_restaurant_appointment_tour_basic` test was failing when run late in the day. The test creates an appointment 30 minutes in the future and expects a corresponding label to appear underneath the table in the POS floor plan. However, if the test is executed near midnight (e.g. 23:45 UTC), the appointment is scheduled for the following day. Since the Point of Sale frontend only displays appointments for the current day, it filters the booking out, causing the tour to timeout while waiting for the label. runbot-232601 Forward-Port-Of: odoo/enterprise#105738
8 changes
Resolved issues and error corrections
This update fixes an issue where new CRM contacts created via quick create didn't automatically inherit the address of the associated company. The fix ensures that company address information is correctly applied during contact creation, improving data accuracy and consistency within the CRM.
Original PR description
**Steps to reproduce:** - Install Sales/CRM apps - Go to CRM app - Create new opportunity card - Set a company (`commercial_partner_id`) - Create a new contact using `quick_create` - The new contact is linked to the company but it doesn't inherit the company address **Issue:** Kanban quick create of crm app was modified to allow a company field, which is used as `default_parent_id` when creating a new partner from the card. This properly set the partner `parent_id` and `commercial_partner_id` but without applying the logic of `_fields_sync()` which also added the address (only for quick_create). **Fix:** Use `_add_missing_default_values` to check if a default value was given for `parent_id` in `_fields_sync()`. related: https://github.com/odoo/odoo/commit/a6c3ebc21c066ab4d5711f535ca5fc858e6485b0 opw-4932114
This update resolves an issue where Odoo couldn't connect to printers with overly long device names. The fix automatically shortens these names to comply with CUPS's 127-character limit, ensuring consistent printer functionality. This prevents connection errors and improves printer availability.
Original PR description
CUPS has a limit on printer names of 127 characters, which means that if a device has a very long device URI, it can exceed this limit and cause an error when we try to add it to CUPS:
```
Failed to add printer 'dnssdPhotosmart%207520%20series%20%40%20Guillaume%E2%80%99s%20MacBook%20Air%20(2)_ipp_tcplocalcups?96d0de60-096c-3d08-5e2d-893393e10c2b'
Traceback (most recent call last):
File "/home/pi/odoo/addons/iot_drivers/iot_handlers/interfaces/printer_interface_L.py", line 242, in set_up_printer_in_cups
self.conn.addPrinter(name=device['identifier'], device=device['url'], **ppdname_argument)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cups.IPPError: (1024, 'client-error-bad-request')
```
We fix this error by truncating the identifier to 127 characters maximum.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245910This update resolves an issue where embedded actions within documents were disappearing from the interface, preventing users from managing or deleting them. The fix ensures embedded child actions remain visible and accessible, streamlining the document action management process. This improves usability and reduces potential user frustration.
Original PR description
Server actions that were standalone (not a child) and embedded onto a documents folder cannot be executed anymore when they are linked to a parent action. Before saas-18.3, the embedded child action…
Server actions that were standalone (not a child) and embedded onto a documents folder cannot be executed anymore when they are linked to a parent action. Before saas-18.3, the embedded child action would still be in the documents' `available_embedded_actions`, and couldn't be removed, such that a fix was necessary. From saas-18.3 onwards, children embedded actions are no longer visible. As this precise case wasn't explicitly tested, we continue the FW-port with the (adapted) test. Furthermore, we add a garbage collection of the embedded actions for children actions, as they cannot be executed anymore. Initial FIX: ### ISSUE Certain embedded actions inside a folder may not appear in the folder’s server actions list (accessible via the gear icon), making them impossible to find or delete through the interface. This occurs because documents.document.get_documents_actions applies overly broad filtering that removes all child server actions, regardless of whether they are embedded in the folder. As a result, if two embedded actions are created in a folder and one is later set as a child of the other, the embedded child action disappears from the visible list but remains embedded in the folder, leaving no way to remove it from the UI. ### SOLUTION The method has been updated to exclude only non-embedded child actions. Embedded child actions are now preserved and correctly displayed in the folder’s actions list, allowing them to be managed and deleted as expected. opw-5213881 Forward-Port-Of: odoo/enterprise#101527 Forward-Port-Of: odoo/enterprise#100395
This update fixes a visual issue where the Gantt chart's date range controls would overlap with the user interface, particularly when using custom date ranges in Dutch on smaller screens. The fix ensures the Gantt controls are displayed correctly, improving usability and preventing a confusing user experience. This resolves a reported problem impacting the Gantt chart functionality.
Original PR description
Steps to reproduce ================== - Switch to dutch - Emulate an iPhone SE viewport in the browser settings - Open a project - Switch to the gantt view - Use a custom date range -> The gantt controls are displayed on top due to the daterange format being to long Note ==== The fix is in the ViewScaleSelector component, but only the gantt view uses a custom scale opw-5340869 Forward-Port-Of: odoo/odoo#245552
This update fixes a technical issue in the stock orderpoint module that prevented accurate filtering of records based on the current orderpoint. The fix ensures that the system correctly restricts records to the current orderpoint, improving data accuracy and efficiency. This resolves a silent error that could have impacted orderpoint management.
Original PR description
Description of the issue/feature this PR addresses:
This PR fixes an incorrect domain construction when restricting records to the current recordset.
The existing code attempted to combine domains using expression.AND() but did not apply the result, and referenced an invalid domain field.
Current behavior before PR:
- expression.AND() was called without assigning its return value, so the combined domain was never applied.
- The domain condition used ('ids', 'in', self.ids), which is not a valid searchable field.
- As a result, the intended filtering by the current recordset was silently ignored.
Desired behavior after PR is merged:
- The domain is correctly rebuilt and assigned using expression.AND().
- The filter uses the valid field instead of ids
- Records are properly restricted to the current recordset
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242799This update fixes a discrepancy in Odoo's Balance Sheet reports for several localized versions (CO, EC, KR, TW, and ZM). It ensures that 'Other Expenses' are correctly included in the unallocated earnings calculation, providing more accurate financial reporting. The change was triggered by a previous update and required adjustments to the localization-specific report data.
Original PR description
*= co, ec, kr, tw, zm Currently, the `Other Expense(expense_other)` account type, introduced in saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, even though it's…
*= co, ec, kr, tw, zm Currently, the `Other Expense(expense_other)` account type, introduced in saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, even though it's correctly implemented in the standard reports. **Steps to reproduce:** - Install the `l10n_co_reports` and `accountant` modules. - Switch to `CO company `and navigate to Accounting > Reporting > Balance Sheet. - Ensure the `report` smart button is set to `Balance Sheet (CO)`. - Equity > Previous Years Unallocated Earnings and click the `info icon`. - Observe the formula of `balance_domain`. **Observation:** The formula does not include the `expense_other` account type. **Root Cause:** After PR [1], at [2] `expense_other` was added to the Previous Years Unallocated Earnings balance domain only in the main `account_reports` module. The corresponding localization reports mentioned above were not updated accordingly, resulting in incomplete Balance Sheet formulas. **Fix:** This commit updates the Balance Sheet report and includes the `expense_other` account type in the Previous Years Unallocated Earnings balance domain, aligning them with the standard reports. [1]: https://github.com/odoo/enterprise/pull/101591 [2]: https://github.com/odoo/enterprise/blob/316a5965e5fae83bd7d901929160c87eb28d13cf/account_reports/data/balance_sheet.xml#L205 opw-5491639
This update resolves an issue where auto-batching wasn't triggered for deliveries with partially assigned moves. The fix ensures that a batch transfer is automatically created when a delivery is ready, regardless of the initial stock levels, improving inventory management efficiency. This change corrects a bug impacting delivery processing.
Original PR description
### Steps to reproduce: - In the settings enable: Batch, Wave & Cluster transfers - Inventory > Configuration > > Warehouse Management > Operation types - Enable Auto-batches, Batch grouping by…
### Steps to reproduce: - In the settings enable: Batch, Wave & Cluster transfers - Inventory > Configuration > > Warehouse Management > Operation types - Enable Auto-batches, Batch grouping by partner on Delivery orders - Create and confirm a delivery for 2 units of a storable product that you do not have in stock. - Change the quantity of the move to 1 unit #### > The delivery is not auto-batched ### Expected behavior: As the delivery becomes ready a batch transfer containing your delivery should be created. This is by the way what happens if you had at least 1 unit in stock when you confirm the deliver. ### Cause of the issue: The auto-batching is suppose to be applied on assigned pickings via the `_find_auto_batch` method: https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L194-L198 That being said a picking is only batchable if it is Ready hence his state is 'assigned'. Now, the issue is that the `_find_auto_batch` is only callable in two places in our workflow: First at confirmation: https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L138-L142 Which will fail in our case but wokrs in the use case where you have at least one unit in stock since the delivery is respectively not "assigned" or "assigned" at this point. And, else, wehn the sate of a move of the delivery is assigned: https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_move.py#L30-L38 Now, the only issue with this call is that the picking becomes assigned if a move is partially assigned: https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock/models/stock_picking.py#L841-L845 But since the move is not "assigned" but only "partially_vailable" this will not trigger a call of the `_find_auto_batch`. opw-5441718 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245542
This update fixes an issue where Odoo incorrectly exported negative discounts in Peppol BIS 3 invoices. The change ensures that negative discounts are now correctly classified as surcharges, aligning with PEPPOL standards and preventing calculation errors. This ensures accurate invoice generation and compliance with regulatory requirements.
Original PR description
In Peppol BIS 3 (UBL 2.1), negative discounts are logically treated as Surcharges (Charges) rather than Allowances. Previously, Odoo exported negative discounts as an Allowance with a negative amount and a numeric reason code (95). This violated: BR-CL-20 / PEPPOL-EN16931-CL003: Coded charge reasons must belong to the UNCL 7161 (alphabetic) list when ChargeIndicator is 'true'. PEPPOL-EN16931-R120: The line net amount calculation failed due to the negative sign in the calculation. Solution: Dynamically toggles ChargeIndicator based on the discount sign. Swaps AllowanceChargeReasonCode to 'ADK' (Surcharge) for negative discounts. task-5432024 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245136 Forward-Port-Of: odoo/odoo#244679
1 change
Resolved issues and error corrections
This update corrects a problem where payroll data wasn't being accessed correctly due to permission restrictions. By adding a 'sudo' call, the system now reliably retrieves the necessary data for payroll updates, preventing errors and ensuring accurate reporting. This resolves a previous technical issue.
Original PR description
From a previous PR (103147), the payslip update logic was moved to the write function which gets called when a field is changed. In doing so, a sudo call is necessary to avoid problems with users modifying their own record (and not having access rights to read slip_ids). This also applies to tests and solves the following runbot error: Runbot Error: 237743 Forward-Port-Of: odoo/enterprise#105287
38 changes
New functionality added to Odoo
This update adds a required tax report (SICORE) for companies operating in Argentina, ensuring compliance with government regulations following the implementation of withholding taxes. Users can now generate this report and export it as a .txt file, providing a detailed record of earnings tax withholdings.
Original PR description
Purpose: The SICORE report is necessary for company to submit to the government monthly to comply with legal requirements since withholding was implemented for AR. The SICORE report is a tax report…
Purpose: The SICORE report is necessary for company to submit to the government monthly to comply with legal requirements since withholding was implemented for AR. The SICORE report is a tax report that provides a detailed overview of the withholdings performed in a given period. The user will also be able to export the report as a .txt file, containing formatted information about the earnings tax withholdings. Specification (this specification can be found in the SICORE application of the SIAP application): | No. | Desde | Hasta | Long | Tipo dato | Descripción | |-----|-------|-------|------|-----------|-----------------------------------------------------| | 1 | 1 | 2 | 2 | Entero | Código del comprobante | | 2 | 3 | 12 | 10 | Fecha | Fecha de emisión del comprobante (DD/MM/AAAA) | | 3 | 13 | 28 | 16 | Texto | Número del comprobante | | 4 | 29 | 44 | 16 | Decimal | Importe del comprobante | | 5 | 45 | 48 | 4 | Entero | Código de impuesto | | 6 | 49 | 51 | 3 | Entero | Código de régimen | | 7 | 52 | 52 | 1 | Entero | Código de operación | | 8 | 53 | 66 | 14 | Decimal | Base de cálculo | | 9 | 67 | 76 | 10 | Fecha | Fecha de emisión de la retención | | 10 | 77 | 78 | 2 | Entero | Código de condición | | 11 | 79 | 79 | 1 | Entero | Retención practicada a sujetos suspendidos según: | | 12 | 80 | 93 | 14 | Decimal | Importe de la retención | | 13 | 94 | 99 | 6 | Decimal | Porcentaje de exclusión | | 14 | 99 | 109 | 11 | Fecha | Fecha de emisión del boletín | | 15 | 110 | 111 | 2 | Entero | Tipo de documento del retenido | | 16 | 112 | 131 | 20 | Texto | Número de documento del retenido | | 17 | 132 | 145 | 14 | Entero | Número certificado original | task-4837110 Closes #86648
This update introduces a new tool to help companies comply with the EU's CSRD reporting requirements. The AI-powered tool guides users through the reporting process, leveraging existing Odoo data and providing intelligent suggestions for ESG data points and materiality assessments. This improves sustainability reporting accuracy and comparability.
Original PR description
In this PR, we add the possibility to create a complete CSRD reporting tool, integrated with AI. The Corporate Sustainability Reporting Directive (CSRD) is a legal framework in the EU that requires…
In this PR, we add the possibility to create a complete CSRD reporting tool, integrated with AI. The Corporate Sustainability Reporting Directive (CSRD) is a legal framework in the EU that requires companies to report on their sustainability performance. It aims to standardize ESG reporting across the EU and make the information more comparable and reliable for investors and other stakeholders. Our tool will guide the user towards the different steps of that specific report while using information they already have in Odoo (like scope 1,2 and 3 emissions, employee data, suppliers, clients or fleet). The tool is divided in multiple steps: - General: A complete description of the company (size, revenues, activity, etc) must be provided in order to give as much context as possible to the AI agent that will provide help and suggestions. To go to the next step, an action is available to generate relevant ESRS data points for the next step, and suggesting for each, some IROs (Impact, Risk, Opportunity) using AI generation. - ESRS: List of all relevant ESRS data points and their IROs for our company. We can add, remove, modify this list as we please. To go to the next step, an action button is provided in order to generate Double Materiality Assessement (AI generation), it will generate scores. - Materiality: List of relevant ESRS data points, their IROs and scores. The scores will help to know if a topic is material or not (useful to justify why it's the case in the report). There is also the possibility to ask stakeholders for reviews of those data points and score them, we will take the average of those score into account to compute the stakeholder score. A topic is considered as material if its `score >= (((impact_severity_score + financial_materiality_score) / 2) + stakeholder_score) / 2` Again, another action button is added to go to the next step and generate Quantitative data - Quantitative Data: Contains some interesting data about the company's emissions (scope 1, scope2, scope 3), HR related data (number of employees, pay gap, turnover rate, etc), environmental data, etc. It's interesting to mention this data in the final report. - The last step is simply the CSRD report generation, integrated with AI suggestions given all the data and context previously given. The generated report will be created as Knowledge articles (Introduction, General Disclosures, Environmental Disclosures, Social Disclosures and Governance Disclosures).
This update allows businesses to easily export sign request data in bulk for reporting and analysis. A new feature generates a linked Odoo Spreadsheet with responses, streamlining audit processes and eliminating manual data aggregation. The system automatically organizes these reports and ensures data persistence.
Original PR description
Businesses frequently need to extract sign request data in bulk for audit reporting and external analysis. Previously, users had to manually aggregate data from individual signature requests. This commit introduces a "View Answers" action on sign templates and a multi-record action on sign requests to generate a linked Odoo Spreadsheet. Key technical features: - Dynamic Schema: Automatically maps sign items (fields) to columns ordered by document position (Page, Y, X). - Static Data Injection: Data is injected as a static snapshot into the spreadsheet JSON to ensure performance and data persistence. - Auto-Organization: Stores generated reports in a dedicated 'Sign Request Answers' folder within the Documents app. - Multi-Tab Support: Handles multi-document templates by creating individual sheet tabs per document. Security: users can only export sign request that acl allows them to do so. task: 5424006
Enhancements to existing features
This update enhances the usability of ECOs by streamlining the creation process and ensuring consistent product version visibility. Additionally, a change was made to prevent document uploads and removals once an ECO is applied, improving data integrity. This work addresses minor usability issues and improves the overall product management experience.
Original PR description
Improves ECO usability by: - Prefilling ECO type during creation - Making product version consistently visible on product and BOM forms and list views - Replacing date radio buttons with a clearer date field and placeholder - Replacing “Apply on” radio buttons with a selection field prefilled by context - Showing both Product-type and BOM-type ECOs in the product smart button - Fixing incorrect ECO count on the BOM smart button Improve Product Document: - Disable document upload and removal once an ECO is applied. - This is achieved by relying on `widget.deletable`: when an applied ECO is opened, it is in readonly mode, so the related documents kanban is also readonly; as a result, `widget.deletable` evaluates to false (`!props.readonly`), which hides the remove and undo actions. Task ID: 5358428
This update enhances the clarity of settings related to group discussions within Odoo Enterprise. The PR has updated the help text across these settings to be more user-friendly and consistent. This improves the overall user experience and makes it easier for users to configure and manage their discussion groups.
Original PR description
**Description of the issue this PR addresses:** Revamp Discuss Settings **Desired behaviour after PR is merged:** This PR includes: - Updated help strings across settings for consistent and user-friendly phrasing. Community PR: https://github.com/odoo/odoo/pull/234674 part of - [5227387](https://www.odoo.com/odoo/project/1519/tasks/5227387) **Before**: <img width="556" height="524" alt="image" src="https://github.com/user-attachments/assets/7d853b01-68b7-4591-9492-604fc9c01ee2" /> **After**: <img width="554" height="500" alt="image" src="https://github.com/user-attachments/assets/11175f5c-3875-4e57-96fe-3ff81be86bec" />
This update enhances the user experience for the 'itsme' authentication method in Odoo Sign by providing clearer visibility into available IAP credits and streamlining the process for purchasing more. The changes include a direct link to manage credits, a more informative email notification, and visual indicators in the Sign Editor, making it easier for users to complete transactions.
Original PR description
Prior to this commit, the integration of 'itsme' in Odoo Sign lacked visibility regarding IAP credits. Users could not easily see their balance when configuring roles, and the "insufficient credits"…
Prior to this commit, the integration of 'itsme' in Odoo Sign lacked visibility regarding IAP credits. Users could not easily see their balance when configuring roles, and the "insufficient credits" email was generic without actionable steps. Additionally, the Sign Editor sidebar did not visually distinguish between authentication methods (SMS vs itsme).
This commit improves the UX for the 'itsme' flow through the following changes:
1. Role Configuration (sign.item.role):
- Updates the form view to display the current available credits when 'itsme' is selected as the authentication method.
- Adds a direct link to the IAP service to manage credits.
2. Email Notification (mail.template):
- Refactors the 'sign_template_mail_not_enough_credits' template to use clearer wording ("due to insufficient credits") for all auth methods.
- Adds a specific condition for 'itsme': if verification fails due to lack of credits, the email now includes a direct link to the IAP purchase page.
3. IAP Account View (iap.account):
- Customizes the IAP account form specifically for the 'itsme_proxy' service.
- Relocates the credit balance display to a more prominent position under the account title.
- Hides the standard boolean status badges for this specific service to reduce clutter.
4. Sign Editor Sidebar (JS/XML):
- Adds visual badges to the signer list in the sidebar to indicate the selected authentication method (e.g., specific icon for itsme).
- Updates the backend model to inject 'auth_method' data into the sidebar props.
- Ensures the itsme badge remains visible in dark mode using inline styling.
Task: 5862540This update replaces outdated inline links with proper button elements in the Odoo Enterprise interface. This change improves the user experience and aligns with best practices for interactive web elements, ensuring a more consistent and accessible design.
Original PR description
This commit is based on the community one which introduces the `.btn-link-inline` class to reproduce the inline styling of a `<a href="...">` tag as a variant of Bootstrap's `.btn.btn-link`. This allows to properly uses `<button>` element for interactive DOM elements instead of relying on a "hacky" and non-semantic `<a href="#">` (tl;dr: `<a>` HTML tag are for navigation, `<button>` are for interactivity). task-4380519
This update adds a new side panel to the Gantt view, mirroring the Calendar's scheduling features. Users can now easily schedule and unschedule tasks by dragging and dropping records between the list and the timeline, streamlining project management workflows.
Original PR description
This commit introduces a side panel to the Gantt view that mirrors the functionality of the Calendar view's scheduling section. The new panel displays a list of unscheduled records and supports drag-and-drop interactions, allowing users to easily: - Schedule records by dragging them from the list onto the Gantt timeline. - Unschedule records by dragging them from the timeline back into the side panel. task-5259058
This update simplifies the process of creating new accounting journals. Previously, a confusing 'New' button on the dashboard led to a separate wizard. Now, users can access the journal creation process through the cog menu on the dashboard or directly from the journal list view, streamlining the workflow.
Original PR description
In the accounting dashboard, clicking the "New" button would open the new journal creation wizard which was confusing, the button was completely removed and can now be accessed from the cog menu, the wizard is now also applied on the journal list view task-5422121
Resolved issues and error corrections
This update enhances the website editor by ensuring all images attached to a website are accessible, not just those automatically included. This prevents lost images from being unavailable to users, improving website content management and flexibility. It's a simple change to ensure a more complete and user-friendly experience.
Original PR description
Make it so that every image attachment is accessible in the website editor instead of just the ones present in the generated website. This is done to make sure that even if an image has been left over during the matching it is still accessible to the user.
This update resolves a test failure in the web_studio module caused by a dependency issue. The test incorrectly checked for models that weren't part of the installed modules, specifically due to the 'account_edi' module. The fix ensures the test accurately reflects the modules that are actually present, preventing false failures.
Original PR description
`RELATED_MODELS_TO_EXCLUDE` contains `account.edi.document`, which is installed by `account_edi`, which is neither in the `needed_modules` set nor a dependency of any of them. Therefore the test can fail because `account_edi` is not installed even though every module in the set is. Improve the test by checking that the models or fields we're checking for actually belong to the modules we've listed. Also add the missing module in the list. Forward-Port-Of: odoo/enterprise#105504 Forward-Port-Of: odoo/enterprise#104879
This update fixes an error in the SYSCOHADA Profit and Loss report where the gross margin calculation was incorrectly adding instead of subtracting account values. The change ensures the report accurately reflects the Ginea - SYSCOHADA fiscal localization requirements as defined in the official documentation, leading to more reliable financial reporting.
Original PR description
The SYSCOHADA gross margin is defined on page 330 - 331 of the document [Guide-d-application-du-SYSCOHADA.pdf](https://www.ohada.com/uploads/actualite/3504/Guide-d-application-du-SYSCOHADA.pdf). It…
The SYSCOHADA gross margin is defined on page 330 - 331 of the document [Guide-d-application-du-SYSCOHADA.pdf](https://www.ohada.com/uploads/actualite/3504/Guide-d-application-du-SYSCOHADA.pdf). It is TA (701) - RA (601) +/- RB (6031). TA and RA should always be positive and negative, respectively.
In the report "Profit and Loss (SYSCOHADA)", the line RA is negated. XA then subtracts this value from TA, adding the two values instead of subtracting them.
Steps to reproduce:
1. Create a new company on runbot.
2. In Accounting > Configuration > Settings, set their Fiscal Localization to Ginea - SYSCOHADA for Companies.
3. Make a MISC journal entry.
1. Set a credit of 110,000,000 on account 701100 and balance it with 411100.
5. Set a debit of 75,000,000 on account 601100 and balance it with 401100.
6. Set a credit of 5,000,000 on account 603100 and balance it with 411100.
7. Post the entry.
8. Navigate to Accounting > Reports > Profit and Loss.
9. Set the l10n version, Profit and Loss (SYSCOHADA).
10. Set the current date.
11. See XA = 110 million + 75 million + 5 million = 190 million; this does not match the example given on pg 357 of Guide-d-application-du-SYSCOHADA.pdf, where XA = 40 million.
[opw-5482300](https://www.odoo.com/odoo/project.task/project.task/5482300)
Forward-Port-Of: odoo/enterprise#104736
Forward-Port-Of: odoo/enterprise#104479This update removes potentially problematic 'bare except' clauses in several Odoo modules. These clauses could inadvertently suppress critical errors like system exits, leading to instability. The change ensures more robust error handling and prevents unexpected application behavior.
Original PR description
Using bare except clauses is dangerous. They will also catch `BaseException` exceptions and may therefore suppress exceptions such as `SystemExit`, `KeyboardInterrupt`, etc. It is therefore good practice to explicitly mention the type of exception we want to catch. It is possible to use `except BaseException` if necessary. task-5008738
This update clarifies how SCSS variables are defined, ensuring only one of the !global or !default flags can be used. This change improves the consistency and predictability of our stylesheets, reducing potential styling issues. The update aligns with a recent Sass documentation change.
Original PR description
Variables will only allow a single !global or !default flag. Duplicate flags never had any additional effect, this just ensures that stylesheets are more consistent. Reference: https://sass-lang.com/documentation/breaking-changes/duplicate-var-flags/
This update resolves an issue in Odoo's Web Studio where incorrectly configured related fields could cause errors and warnings. The change ensures that related fields are only created when linked to searchable fields, preventing these technical problems and improving stability for business users. This resolves a previous vulnerability.
Original PR description
Before this commit studio allowed to make a related field with a non-searchable field (ie standard computed fields) in the the chain. This triggered a warning at creation (at fields.py:resolve_depends) and errors when using in a business setting. After this commit, the filter to build the relational field is modified to take into account this. opw-5436158 Forward-Port-Of: odoo/enterprise#105668 Forward-Port-Of: odoo/enterprise#105607
This update resolves issues in the Romanian SAF-T export process that occurred when partner information (country or name) was incomplete. Specifically, it corrects errors related to invoice generation and ensures accurate SAF-T file creation, improving compliance for Romanian companies.
Original PR description
Fix SAF-T export errors when partners have no country or name. For Romanian companies, the RegistrationNumber should be generated as “04 + partner ID” for customers not subject to VAT and with unknown CNP, without including the country code. Steps to reproduce country issue: - Configure a Romanian company with l10n_ro_saft installed - Create a contact without a country - Create and validate an invoice for this contact - Export the SAF-T file from the General Ledger report You you will get a TypeError because you cant concatenate Bool and String. Steps to reproduce name issue: - Create a main contact - Add a child contact without a name - Change the child type to “Company” - Create and validate an invoice - Export the SAF-T file from the General Ledger report This prevents KeyError when printing the first 70 characters of the partner name in the report. opw-5499918 Forward-Port-Of: odoo/enterprise#105579 Forward-Port-Of: odoo/enterprise#105020
This update resolves a problem where the demo call tour wasn't functioning correctly with the standard demo data. The code was adjusted to ensure the correct contact and activity were selected during the tour, and the tour file was moved to the appropriate location for improved functionality. This ensures a smoother experience for users running the demo.
Original PR description
Make sure we select correct contact/activity when with demo data. Also move the tour to correct file. Forward-Port-Of: odoo/enterprise#105609
This update fixes an issue where applicant stage changes weren't correctly displayed in the recruitment reports demo data. The fix ensures that stage change messages appear with the correct 'Stage changed' label and uses the accurate 'Qualification' stage name, improving the clarity of applicant communication history.
Original PR description
…records in hr_recruitment_reports demo data Steps to reproduce: 1. Load demo data for hr_recruitment_reports module 2. Check applicant records in chatter 3. Observe that stage change messages don't…
…records in hr_recruitment_reports demo data Steps to reproduce: 1. Load demo data for hr_recruitment_reports module 2. Check applicant records in chatter 3. Observe that stage change messages don't show "Stage changed" label 4. Review mail.tracking.value records for applicant stage changes 5. Observe incorrect stage name "Initial Qualification" instead of "Qualification" Bug cause: mail.message records for applicant stage changes were missing the subtype_id field, which defaults to an incorrect subtype (mt_note instead of mt_applicant_stage_changed). This caused the messages to be treated as internal notes rather than stage change notifications. Additionally, mail.tracking.value records used "Initial Qualification" as the old_value_char or new_value_char, which doesn't match the actual stage name defined in hr_recruitment module. The correct stage name is simply "Qualification" (ref: hr_recruitment.stage_job1). Solution: - Add subtype_id field with reference to hr_recruitment.mt_applicant_stage_changed to all mail.message records that track applicant stage transitions - This ensures stage change events are properly identified and displayed in chatter with the correct "Stage changed" label - Update old_value_char and new_value_char fields in mail.tracking.value records to use the correct stage name "Qualification" instead of "Initial Qualification" - Ensures consistency with actual stage names and proper display in applicant chatter history Affected records: 20 mail.message records in hr_recruitment_reports_demo.xml Task Id:5454691 Forward-Port-Of: odoo/enterprise#105278
This update enhances the monitoring of our AI integrations by changing key log levels to 'info' for easier tracking by our team and database administrators. Additionally, the system now accurately reports token usage from LLM providers, addressing a previous underreporting issue. This provides better insights into AI costs and performance.
Original PR description
In this commit we change some important llm api usage logs from debug to info so they can be more easily monitored by us and database admins. We also change the usage reporting from a naive estimation (which greatly under-reported the token usage) to the actual token usage given to us by the LLM prodivers in the response. Forward-Port-Of: odoo/enterprise#105627 Forward-Port-Of: odoo/enterprise#105364
This update resolves a bug that prevented successful NFC-e refunds in Point of Sale (PoS). The fix corrects a logic error in how the system checks for existing invoices, ensuring that refund requests are processed correctly. This improves the reliability of NFC-e transactions.
Original PR description
**Steps to reproduce:**
- Setup a database that supports NFC-e
- Go to PoS, make a purchase, then refund it
- A traceback appears, saying we couldn't find the original invoice
**Why the fix:**
Before this commit the way we checked if there was already an invoice in the payload we give to the API was wrong, as it was always true. This happens because before the
*def _get_l10n_br_avatax_service_params(self):* call, we set res['invoice_refs'] as {}, then we were supposed to fill it. But if we check https://github.com/odoo/enterprise/blob/32b73b12f9f8f5600b820d9a938bfbb0cf10054d/l10n_br_edi_pos/models/account_move.py#L13 'invoice_refs' is found in res, even though it is empty, so we never entered the if statement.
We now check if there is a value in res['invoice_refs'] and if not we set it.
opw-5359407
Forward-Port-Of: odoo/enterprise#104987
Forward-Port-Of: odoo/enterprise#102770This update corrects a problem in the testing process for payroll documents. The original setup incorrectly assumed contract end dates were always false, leading to test failures. The fix ensures contract end dates are automatically set to two years from the contract start date, aligning with standard payroll practices.
Original PR description
### Cause: Apparently the contract ends automatically after a period if `contract_date_end == False` ### Solution: Set `contract_end_date` to ` Date.today() + relativedelta(years=2)` like in `hr_payroll/tests/common.py` runbot-237945 runbot-237894 Forward-Port-Of: odoo/enterprise#104627
This update fixes a problem that occurred when installing new chart of accounts. Previously, creating a new payroll database with a specific chart (ZA) would trigger an error. Now, the system correctly handles deleting and replacing old records during chart of account installations, ensuring smoother payroll database setup.
Original PR description
When installing a chart of account, previous records are deleted to be replaced by the one of the installed chart. Since odoo/odoo@4400130eb32, we need to explicitly check for force_delete flag. Before this commit, creating a new payroll database with the ZA chart of account was raising this constraint. opw-5879978 Forward-Port-Of: odoo/enterprise#105633
This update resolves an issue where contact information wasn't consistently displayed when receiving incoming calls. The team corrected a missing piece of code in the 'getOrCreateCall' function, ensuring that contact details are now correctly fetched and shown. This improves the user experience when managing calls.
Original PR description
In https://github.com/odoo/enterprise/pull/105036, some part of the code in getOrCreateCall was forgotten. Consequently, on an incoming call, contact info could sometimes not be displayed.
This update resolves an issue where outdated sign requests were incorrectly sending notifications to the wrong users due to missing email information. The fix ensures that sign requests are only sent to users with matching email addresses, improving the accuracy and reliability of the sign request process. This prevents unnecessary notifications and streamlines document signing.
Original PR description
This commits fix the problem where the `signer_email` field of old sign items don't have a value defined then showed up as "next documents to be signed" for other users, even when the email doesn't match. task-5487349 Forward-Port-Of: odoo/enterprise#104755
This update resolves an issue where sale orders with missing address information in Mexico prevented successful online payments. The fix automatically enables 'CFDI to Public' when the address is incomplete, ensuring transactions are validated and payments are recorded as required by Mexican regulations. This improves payment processing reliability for Mexican customers.
Original PR description
### Issue: On a Mexican sale order, it was possible to have an invalid partner address while `CFDI to Public` was not enabled In this situation, an online payment could be initiated, but a silent…
### Issue: On a Mexican sale order, it was possible to have an invalid partner address while `CFDI to Public` was not enabled In this situation, an online payment could be initiated, but a silent error occurred during move validation: the transaction was created, but the payment was never recorded, and no error appeared in the portal or the SO chatter ### Cause: The CFDI validation error is raised internally but never surfaced to the user https://github.com/odoo/enterprise/pull/91655 The PO (MIAL) recommended automatically enabling `CFDI to Public` when the partner address is incomplete, forcing the user to complete the data This also ensures that the payment can be confirmed properly ### Steps to reproduce: - Install `l10n_mx_edi_sale` and switch to the MX company - Configure a Payment Provider and Payment Method (e.g., demo) - Create a customer without ZIP or country - Create a Sale Order for that customer - In Other Info, set Online Payment to 100% - Send the quotation and open the link in a private window - Sign and Pay Before the fix: the transaction is created, but no payment is recorded, and no error is shown opw-5023724 Forward-Port-Of: odoo/enterprise#101881
This update resolves a technical issue that could cause errors when generating Peruvian VAT (PE) documents. The fix ensures that the system handles cases where a required text field is missing, preventing a traceback and improving the reliability of the l10n_pe_edi module. This ensures accurate VAT reporting for our Peruvian customers.
Original PR description
Forward-Port-Of: odoo/enterprise#105610 Forward-Port-Of: odoo/enterprise#105462
This update addresses a technical adjustment to the checksum associated with the EU IoT Scale certification module. The underlying code for the scale component was modified to resolve a bug, necessitating a corresponding update to the checksum to maintain data integrity. This ensures accurate reporting and compliance.
Original PR description
Checksum needs to be updated as the code of the scale changed for a bugfix Cummunity PR: https://github.com/odoo/odoo/pull/245048 Forward-Port-Of: odoo/enterprise#105328
This update resolves a technical issue preventing the correct generation of events related to timesheets. The problem stemmed from an outdated categorization method, which has now been corrected. This ensures accurate tracking and reporting of timesheet activity.
Original PR description
Fake events generation was broken since we categorized events by category instead of watcher in https://github.com/odoo/enterprise/pull/105263. Also something else that we shall not mention Forward-Port-Of: odoo/enterprise#105724
A small correction was made to the names of reports used in the Spanish tax reporting module (l10n_es_reports). This change was a result of a recent system update and ensures the reports function correctly. The updated names are now consistent and accurate.
Original PR description
Problem --------- During the FWP moving the dictionnary definition from in-class to standalone, the naming of the wizards was wrongly updated. Solution --------- Change the naming from `l10n_es_reports_2025` to `l10n_es_reports`. error-237536 Forward-Port-Of: odoo/enterprise#105537
This update ensures accurate payslip data by adding a necessary 'sudo' call to access employee records. Previously, users lacked the correct permissions to update their own payroll information, leading to errors. This change corrects a technical issue and improves data reliability.
Original PR description
From a previous PR (103147), the payslip update logic was moved to the write function which gets called when a field is changed. In doing so, a sudo call is necessary to avoid problems with users modifying their own record (and not having access rights to read slip_ids). This also applies to tests and solves the following runbot error: Runbot Error: 237743 Forward-Port-Of: odoo/enterprise#105287
This update corrects a bug where the website generation process wasn't correctly setting a key value. The fix ensures that the website creation process is always enabled, preventing issues with new website setups. This improves the reliability of the website generation feature.
Original PR description
Missing the 'import_website' value, and since /startwebsite always creates a website it should always be True. Forward-Port-Of: odoo/enterprise#104894
This update fixes a technical issue where Greek translations were incorrectly using the 'gr' language code instead of the correct 'el' code. This ensures that all Greek language content within the Odoo Enterprise system is accurately translated and displayed. The fix was part of a larger effort to improve the consistency of our internationalization efforts.
Original PR description
~~Modules added into stable without being properly added to .weblate.json file = never translatable.~~ Fix Greek translations using the wrong language code. `gr` => `el` Forward-Port-Of: odoo/enterprise#105578 Forward-Port-Of: odoo/enterprise#104890
This update resolves a bug that prevented the Gantt chart from correctly rescheduling tasks when using new Date fields instead of DateTime fields. The fix ensures that date-based rescheduling functions properly, improving the usability of the Gantt chart for project planning. This change was implemented after addressing a related issue in a previous pull request.
Original PR description
…atetime
Steps to reproduce
==================
- Install web_studio,project
- Open a project task
- Open studio
- Add a new Date field in the form view
- Switch to the gantt view
- Change the Start Date Field to the newly create Date field
- Exit studio
- Open a task
- Set a value for the date field
- Switch to the gantt view
- Drag the record
```
start_date_field_name in vals and datetime.strptime(vals[start_date_field_name], '%Y-%m-%d %H:%M:%S')
^^^^^^^^
ValueError: time data '2025-12-22' does not match format '%Y-%m-%d
```
Cause of the issue
==================
Since https://github.com/odoo/enterprise/pull/84820 , it only works for DateTime fields
opw-5345470
Forward-Port-Of: odoo/enterprise#104751
Forward-Port-Of: odoo/enterprise#103068A recent bug in the Point of Sale appointment tour was causing it to fail when tests were run close to midnight. This was due to the system scheduling appointments for the next day, which the POS frontend then filtered out. This fix ensures the tour functions correctly regardless of the time of day.
Original PR description
The `test_pos_restaurant_appointment_tour_basic` test was failing when run late in the day. The test creates an appointment 30 minutes in the future and expects a corresponding label to appear underneath the table in the POS floor plan. However, if the test is executed near midnight (e.g. 23:45 UTC), the appointment is scheduled for the following day. Since the Point of Sale frontend only displays appointments for the current day, it filters the booking out, causing the tour to timeout while waiting for the label. runbot-232601 Forward-Port-Of: odoo/enterprise#105738
Features or functions removed from Odoo
This update removes the 'New' button from the DIMONA Declaration List view in the odoo/enterprise module. This change simplifies the user interface and streamlines the process of creating DIMONA declarations, aligning with best practices for user experience. It addresses a minor UI inconsistency.
Original PR description
. Remove the New button on DIMONA Declaration List view task-5471873
This pull request removes a broken widget that was previously used for scanning product quantities during receiving. The recommended approach now utilizes the dedicated Barcode app, streamlining the process and eliminating a source of potential errors. This change improves efficiency and simplifies inventory management.
Original PR description
This widget has been broken for some time and can be removed. It was probably used when receiving products, allowing the operator to scan a product and its quantity, and to send a barcode command to move to the next line. In any case, the new recommended approach is to use the Barcode app.
Code cleanup and technical improvements
This update removes the use of 'Cache view of fields' within several Odoo reports. This change is part of a broader effort to streamline Odoo's codebase and improve performance. While the reports continue to function as before, this refactoring prepares for future updates and optimizations.
Original PR description
https://github.com/odoo/odoo/pull/246069
This update reorganizes the structure of portal chatter code to better align with how it's used across Odoo. The changes clarify which parts of the chatter system are for website-only functionality versus those shared with project sharing, improving code organization and maintainability. This ensures smoother performance and future updates.
Original PR description
When the portal chatter conversion began, code was split into `core` and `frontend` folders for chatter in portal. `core` was intended for shared logic between website and project sharing while `frontend` was reserved for website only usage. With this commit, the boot service which is responsible for lazy loading the portal chatter in frontend is now located in the `frontend` folder. Those that are `portal specific` or common between `portal` and `project sharing` are located in the `portal` and `portal_project` folders respectively. Accordingly, `web_portal` subfolder has been renamed to `web_portal_project` to reflect the actual usage. The folder tree structure will look like this: In portal: ``` src/ |-- chatter/ | |-- frontend/ | |-- portal/ | |-- portal_project/ ``` In mail: ``` src/ |-- chatter/ | |-- web/ | |-- web_portal_project/ ``` [Comunity PR](https://github.com/odoo/odoo/pull/206284)
7 changes
Resolved issues and error corrections
This update resolves an issue where sale orders with missing customer address information in Mexico prevented successful online payments. The fix automatically enables 'CFDI to Public' when the address is incomplete, ensuring proper payment confirmation and preventing silent transaction errors. This improves the reliability of Mexican sales transactions.
Original PR description
### Issue: On a Mexican sale order, it was possible to have an invalid partner address while `CFDI to Public` was not enabled In this situation, an online payment could be initiated, but a silent…
### Issue: On a Mexican sale order, it was possible to have an invalid partner address while `CFDI to Public` was not enabled In this situation, an online payment could be initiated, but a silent error occurred during move validation: the transaction was created, but the payment was never recorded, and no error appeared in the portal or the SO chatter ### Cause: The CFDI validation error is raised internally but never surfaced to the user https://github.com/odoo/enterprise/pull/91655 The PO (MIAL) recommended automatically enabling `CFDI to Public` when the partner address is incomplete, forcing the user to complete the data This also ensures that the payment can be confirmed properly ### Steps to reproduce: - Install `l10n_mx_edi_sale` and switch to the MX company - Configure a Payment Provider and Payment Method (e.g., demo) - Create a customer without ZIP or country - Create a Sale Order for that customer - In Other Info, set Online Payment to 100% - Send the quotation and open the link in a private window - Sign and Pay Before the fix: the transaction is created, but no payment is recorded, and no error is shown opw-5023724 Forward-Port-Of: odoo/enterprise#101881
This update fixes an issue where dialog windows were hidden behind chat windows, making them difficult to use. Now, the AI chat window remains prominently displayed above all other dialogs, ensuring users can easily interact with both. This improves the overall user experience for the Enterprise platform.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Dialogs were rendered behind chat windows, making them difficult to see and interact with. **Current behavior before PR:** --------------------------------- - The dialog appears behind the chat window **Desired behavior after PR is merged:** ----------------------------------------- - Dialogs are displayed above all chat windows except AI - The AI chat window remains intentionally above dialogs **Task:** 5367135 Forward-Port-Of: odoo/enterprise#103076
This update resolves an issue where signed documents were sometimes displayed incorrectly, showing fields that hadn't been filled in. The change ensures the document is refreshed after loading, guaranteeing a complete and accurate view of the signed document for users. This improves the user experience and prevents confusion.
Original PR description
Ensure sign items are refreshed after the PDF iframe is fully loaded to avoid displaying partially signed documents without fields when not in sign mode. task-5877678
This update corrects a technical issue preventing accurate payslip updates by ensuring the necessary permissions are granted during data access. Specifically, a sudo call is now used to read slip IDs, resolving a previous error and improving payroll processing reliability. This ensures employees' payroll information is correctly updated.
Original PR description
From a previous PR (103147), the payslip update logic was moved to the write function which gets called when a field is changed. In doing so, a sudo call is necessary to avoid problems with users modifying their own record (and not having access rights to read slip_ids). This also applies to tests and solves the following runbot error: Runbot Error: 237743 Forward-Port-Of: odoo/enterprise#105287
This update ensures that sign templates are automatically named with the correct document name, regardless of the user's language setting. Previously, templates created in non-English languages would default to 'New Template' due to a comparison issue. This fix guarantees accurate template naming for all users.
Original PR description
## Steps to reproduce: 1. Upload a new PDF document to be signed. 2. Select it in the Documents app to sign it. 3. Check the name of the sign template created. ## Issue: When creating signature templates in languages other than English, the template name would stay as "New Template" instead of updating to the actual document name. This happened because the code was comparing the template name against a translated version of "New Template", but the template was initially created with the English default value. Since "New Template" ≠ "Nueva Plantilla" (Spanish), the comparison failed and the name never got updated. The fix ensures we always compare against the original English default value, so the template name gets properly updated to match the document name regardless of the user's language. Related commit: 4254542 opw-4980747 Forward-Port-Of: odoo/enterprise#92682
This update fixes an issue where editing component quantities on the shop floor incorrectly displayed all internal locations instead of just the source location. The fix ensures that only the intended source location is considered when updating component quantities, improving accuracy in work order management. This resolves a previous bug impacting inventory tracking.
Original PR description
In the shop floor when you edit the quantity of components, all the components for the internal localization will appear instead of only the one from the source location
Steps to reproduce:
-------------------
- Active lot/serial number in settings
- Create component A tracked by lot, and add quantities in two location (WH/stock and WH/random)
- Create a product with a bom that use component A
- Create an operation for that bom
- Update the bom to consume the component during the operation
- Create a workorder for the product, confirm it and go to the shop floor
- Click on the operation
- Edit the quantity of components
-> all internal localisation appear (WH/{stock/random})
Observation:
-------------
The domain consider all localisation where the usage is internal: https://github.com/odoo/enterprise/blob/e99c20547528f6664d091cd230ce94cf76a08eb1/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L119
opw-5268989This update ensures salary configuration personal information is automatically populated using the employee's most recent version, regardless of whether it's a standard offer or a contract template. This eliminates inconsistencies and provides a more accurate and up-to-date salary setup process for all employees.
Original PR description
The personal informations in the salary config is prefilled using the version selected in the offer. When making a new offert for an already employed person, the default version is the last active version, the address and other personal info are already set on that version and the salary has the last up-to-date data. But when selecting a contract template in an offer, the version does not have the personal info from the employee (as it's a template). In this commit, we force to use the employee itself (from the active version of the employee, or the employee linked to the contract template copy - created during the offer creation). may it be an applicant or an existing employee, when an offer is generated, an employee is created (or re-used) and set on the contract template. So it works in every case. Taks-5162703 Forward-Port-Of: odoo/enterprise#99908
18 changes
Resolved issues and error corrections
This update resolves a visual bug where columns in mass emails weren't rendering correctly when sent. The issue stemmed from a conflict between the email's styling and the Odoo website's CSS. The fix ensures consistent column alignment in received emails by standardizing color formatting.
Original PR description
**Steps to reproduce:** - Install Mass Mailing and Website apps - Create a new mailing - Add Columns block with different content size - In "Vert. Alignment" field > Select the "Stretch to Equal Height" option - Columns are properly aligned in Odoo - Save the record and send test mail - The columns are not aligned anymore in the received mail **Issue:** Inline styling breaks in mail engines due to `website.scss` file. The `color-mix` css function is used and cast as a `color()` functional notation in the columns `border-color`. The inline styling is then removed by the mail engine (with all siblings attributes) as it is not compatible with this notation. (e.g. `border-color: color(srgb 0.129412 0.145098 0.160784 / 0.15);`) The color normalization step doesn't take this into account as it only checks for rgb patterns. **Fix:** Overwrite the css with the color notation by a default value for mailing. opw-5225248
This update resolves a regression that prevented new participant registrations within the PEPPOL system. The issue stemmed from an outdated configuration that required existing EDI proxy users, leading to failures for new registrations. This fix ensures smooth and successful participant onboarding.
Original PR description
Fix regression of participant fetch cron introduced in forward port odoo/odoo#245038 Indeed self might be a record set in lots of different cases, which leads to users at least 1 existing edi proxy user in their company, all future registrations will fail
This update resolves an issue preventing Odoo payments using Swedbank's Bankgiro accounts. Swedbank requires a specific 'RfdDocAmt' field in payment XMLs, which was missing in Odoo's generated batches. This fix adds this field, ensuring successful payment processing and avoiding bank rejections.
Original PR description
**PROBLEM** Swedbank requires the RfdDocAmt Element for Bankgiro account. [documentation](https://internetbank.swedbank.se/ConditionsEarchive/download?bankid=1111&id=WEBDOC-PRODE211415244). Payment batches generated by Odoo don't contains this fields, meaning they are refused by the bank. **REPRO STEPS** We can't reproduce the error the client have because it would require a valid bankgiro account. To generate the payment batch xml you have to: 1. Install l10n_se. 2. Create a vendor bank account of type bankgiro. 3. Create a vendor payment with this vendor bank account. 4. Create a batch payment and validate it. 5. There should be a xml in the chatter, you can look at it to see there is no RfdDocAmt element. opw-5427505
This update corrects a visual issue where the 'Sign and Pay' button remained enabled when the customer's name field was blank. The fix ensures the button is disabled when no name is entered, improving the user experience and preventing accidental order creation. This resolves a minor usability problem.
Original PR description
**Steps to produce:** - Install `sale_management` module. - `Create a SO > Click on Preview > Sign and Pay`. - Remove all text from the Full Name`. **Issue:** - The `Accept & Sign` button remains…
**Steps to produce:** - Install `sale_management` module. - `Create a SO > Click on Preview > Sign and Pay`. - Remove all text from the Full Name`. **Issue:** - The `Accept & Sign` button remains enabled even when the Full Name field is empty. **Root cause:** - At [1], When the `drawCurrentName` method is called, it retrieves text using `getCleanedName`. This method returns an empty string when no name is provided - Despite this, the code still generates an image and passes it to `printImage`, which keeps the button enabled. **Solution:** - If the cleaned name is empty or contains only spaces, do not generate image. - Instead, immediately clear the signature pad so the button remains disabled. [1]https://github.com/odoo/odoo/blob/9dedf75810bd6b7a92fe5bd279bf6bae98834750/addons/web/static/src/core/signature/name_and_signature.js#L103-L109 **Before:** <img width="400" height="400" alt="before" src="https://github.com/user-attachments/assets/5ebdf852-4cba-4e1d-9ae4-7373e4b8b91d" /> **After:** <img width="400" height="400" alt="after" src="https://github.com/user-attachments/assets/9280aa66-4f22-40d6-8a22-326cec24378d" /> **opw-5361890** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where auto-batching wasn't triggered for deliveries with partially assigned moves. The fix ensures that a batch transfer is automatically created when a delivery is ready, regardless of the initial stock levels, improving inventory management efficiency.
Original PR description
### Steps to reproduce: - In the settings enable: Batch, Wave & Cluster transfers - Inventory > Configuration > > Warehouse Management > Operation types - Enable Auto-batches, Batch grouping by…
### Steps to reproduce: - In the settings enable: Batch, Wave & Cluster transfers - Inventory > Configuration > > Warehouse Management > Operation types - Enable Auto-batches, Batch grouping by partner on Delivery orders - Create and confirm a delivery for 2 units of a storable product that you do not have in stock. - Change the quantity of the move to 1 unit #### > The delivery is not auto-batched ### Expected behavior: As the delivery becomes ready a batch transfer containing your delivery should be created. This is by the way what happens if you had at least 1 unit in stock when you confirm the deliver. ### Cause of the issue: The auto-batching is suppose to be applied on assigned pickings via the `_find_auto_batch` method: https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L194-L198 That being said a picking is only batchable if it is Ready hence his state is 'assigned'. Now, the issue is that the `_find_auto_batch` is only callable in two places in our workflow: First at confirmation: https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L138-L142 Which will fail in our case but wokrs in the use case where you have at least one unit in stock since the delivery is respectively not "assigned" or "assigned" at this point. And, else, wehn the sate of a move of the delivery is assigned: https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_move.py#L30-L38 Now, the only issue with this call is that the picking becomes assigned if a move is partially assigned: https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock/models/stock_picking.py#L841-L845 But since the move is not "assigned" but only "partially_vailable" this will not trigger a call of the `_find_auto_batch`. opw-5441718 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where subcontract quantities weren't being split correctly, leading to inaccurate production tracking. The fix ensures that the quantity of products produced under subcontracting is accurately reflected in the system, improving the reliability of production reports and inventory management. This update impacts the MRP and subcontracting modules.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where quantity calculations were incorrect for subcontracting processes within the MRP module. The fix ensures accurate tracking and reporting of materials used in subcontracted production, improving the reliability of production data and reducing potential errors in costing.
This update fixes an issue where event registration emails were incorrectly canceling invitations for contacts on an exclusion list. The change bypasses the filtering process for blacklisted emails, ensuring all registered attendees receive their invitations. This improves the reliability of event registration communications.
Original PR description
**Steps to reproduce:** - Install Events & Contacts apps - Open Contacts - Create a contact "BLACKLIST", email: `blacklist@example.com` - Create a contact "GOOD", email: `good@example.com` - Open Settings > Technical > Discuss > Email Blacklist - Create a record with email: `blacklist@example.com` - Open Events - Create an event - Go to the event attendees - Create attendees for both contacts - Open Settings > Technical > Email > Emails - Both email are listed but the blacklisted one is cancelled **Issue:** The composer created in `EventMailScheduler._send_mail` is using `_process_mail_values_state` to find the list of blacklisted records and applies it to filter the mail recipients, which prevents the event mailing from being processed correctly. **Fix:** `use_exclusion_list` is set to `false` on the composer to bypass its exclusion process. opw-5046491
This update resolves an issue where Odoo was incorrectly including a UETR tag in ISO 20022 payment files, causing rejection by strict banks. The change ensures compliance with SEPA regulations, preventing errors and guaranteeing successful payment processing. This improves compatibility with major banking systems.
Original PR description
In Odoo 18.0, when a user selects the pain.001.001.09 format (ISO 20022), Odoo systematically includes the <UETR> (Unique End-to-end Transaction Reference) tag for every transaction. While valid under the general ISO 20022 XML schema, the <UETR> tag is not authorized by the EPC (European Payments Council) within the standard SEPA Credit Transfer (SCT) Rulebook. Strict banks (e.g., UBS, German banks) reject the entire file with errors such as: "No child element is expected at this point" when an UETR is detected in a domestic or intra-SEPA flow. Task: 5871528
This update fixes an issue where the virtual keyboard would cover bottom sheets in the Point of Sale module, preventing users from seeing their input. The change ensures the bottom sheet correctly resizes with the viewport, resolving this visibility problem and improving the user experience.
Original PR description
Before this commit, when you clicked on an input that didn’t have focus inside a bottom sheet, the virtual keyboard popped up on top of the bottom sheet, hiding the input. As a result, you couldn’t…
Before this commit, when you clicked on an input that didn’t have focus inside a bottom sheet, the virtual keyboard popped up on top of the bottom sheet, hiding the input. As a result, you couldn’t see what you were typing. This happens because, in this case, the browser opens the virtual keyboard in overlay mode and does not resize the viewport. This seems to be a common behavior for inputs inside fixed or overlay-based layouts such as bottom sheets. Strangely, when you clicked on an input that was already the active element, the keyboard still popped up, but the viewport was resized and the bottom sheet remained visible. In this situation, the browser treats the keyboard appearance as a viewport change and recomputes the layout to keep the active element visible (safe mode?). To fix this inconsistency, we now explicitly control how the virtual keyboard affects the layout by forcing the bottom sheet to resize with the viewport. This is done by using `interactive-widget: resizes-content`, which ensures the viewport is resized when the keyboard appears and prevents the bottom sheet from being covered. Note that we should probably apply this change on the web as well, but it seems that we currently don’t have any inputs inside bottom sheets there. Since this is a fix, we prefer to apply it only where it is necessary for now. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/viewport#interactive-widget opw-5491343 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where negative procurement quantities were not being processed correctly, specifically within MTO product workflows. The change impacts the creation of purchase orders when a user reduces the quantity of an MTO product. This ensures accurate procurement quantities are generated.
Original PR description
Steps to reproduce ----- - Enable routes - Unarchive MTO - Create a MTO product with a vendor - Create a final product - Create a MO for final product - Confirm MO - Open catalog - Add 0.5 of the MTO…
Steps to reproduce ----- - Enable routes - Unarchive MTO - Create a MTO product with a vendor - Create a final product - Create a MO for final product - Confirm MO - Open catalog - Add 0.5 of the MTO product - Open the linked purchase > Quantity on the PO is 1 Cause ----- The catalog creates a move with a default quantity of 1 when the product is clicked. Then, when the user updates the quantity in the catalog, it triggers a `write` of the `product_uom_qty` (which triggers a procurement). Error comes from the code added in commit c0f00e4, which changed the `_run_procurement` of `stock.move` to avoid creating returns for done moves. https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L493-L497 In our case, all of the conditions are met: - the quantity update is negative - the move is MTO - `move_orig_ids` is empty, so the `all()` is also true This means the move gets skipped for procurement, although that was not the goal of the commit. Even if we were to fix this last condition, there is also a problem with https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L505-L507 that was also affected by the mentioned commit. Since `move_orig_ids` is empty, `possible_reduceable_qty` is 0. And because `procurement_qty` is negative, taking the max of the 2 will always mean `procurement_qty` is 0. This again does not match the goal of the original commit. ----- Ticket: opw-5440296
This update fixes an issue where certain records didn't display correctly by default. The change ensures that other views are enabled when opening records, providing a smoother and more consistent user experience. This resolves a technical glitch that impacted how records were initially presented.
Original PR description
Records of some models may not want to be shown in their form view by default. See related ENT PR for documents. We re-export to avoid patching order issues. In particular, this makes sure that if we are in the webclient, the chat window is opened before executing the "real" open. Task-5386466
This update prevents documents from automatically opening in their form view when accessed through various channels like direct URLs, systray notifications, or the Discuss app. This change improves the user experience by giving users more control over how they access documents, addressing a previously uncovered access pattern.
Original PR description
Users do not want to access the form view of the document by default. This PR solves three cases for accessing documents.document records that were not covered before: * From the basic path pattern `odoo/x/documents.document/<id>` * From a systray notification "Open Form View" * when we are not yet in Documents * when we already are in Documents * From the Discuss app, on the record's thread Tests for most of these are included. Additionally, make sure the document is selected on accessing from `_get_access_action`. Task-5386466
This update ensures accurate payroll slip transmission for Swiss users by adding a necessary security layer (sudo) when accessing payroll data. Previously, users lacked the correct permissions to read their own payroll information, leading to errors. This fix resolves a technical issue identified by automated testing.
Original PR description
From a previous PR (103147), the payslip update logic was moved to the write function which gets called when a field is changed. In doing so, a sudo call is necessary to avoid problems with users modifying their own record (and not having access rights to read slip_ids). This also applies to tests and solves the following runbot error: Runbot Error: 237743 Forward-Port-Of: odoo/enterprise#105287
A test within the sale_pdf_quote_builder module was failing due to how it handled PDF files. This update replaces the test's invalid PDF data with a real, encrypted PDF, resolving the warnings and ensuring the test now passes. This improves the stability of the nightly builds.
Original PR description
The `test_wrong_pdf` test fails on runbot in the `Nightly build` when executed under `Distro Builds > Testing distro PureTrixie without requirements for config Parallel testing`. **Steps to…
The `test_wrong_pdf` test fails on runbot in the `Nightly build` when executed under `Distro Builds > Testing distro PureTrixie without requirements for config Parallel testing`. **Steps to reproduce:** - Install `sale_pdf_quote_builder` module. - Run `test_wrong_pdf` (Make sure `PyPDF==5.4.0` is installed). - Observe `PyPDF` warnings in the logs. **Warnings:** ``` WARNING server pypdf._reader:435 invalid pdf header: b'test' WARNING server pypdf._reader:435 EOF marker not found WARNING server pypdf._reader:435 EOF marker not found ``` **Root cause:** Odoo officially supports the PyPDF version defined in requirements.txt [1]. The test passes with `PyPDF2`, but `PyPDF` is stricter and emits warnings when parsing arbitrary byte content. Because the test uses raw bytes instead of a structurally valid (but unsupported or encrypted) PDF, PyPDF logs warnings. **Fix:** This commit updates the test to use a real encrypted PDF instead of raw bytes, similar to [2]. This commit fixes test failures caused by [3]. **Note:** Refer to [4] for generating the encrypted file. [1]: https://github.com/odoo/odoo/blob/a6af7df429f9cd3bfb60347e9b30cc48fb5bfaff/requirements.txt#L63-L65 [2]: https://github.com/odoo/odoo/blob/0499dbd8944b4002883afab5d3ed76d8e55dab9c/addons/mail/tests/discuss/test_discuss_attachment_controller.py#L63-L75 [3]: https://github.com/odoo/odoo/pull/230712 [4]: https://colab.research.google.com/drive/1UfWSKDluObEkKxCg6eX-nHoe04_FGrEq#scrollTo=A5hO11Eh1qvV runbot-238399
This update fixes a security vulnerability where customer emails with shorthand background styles were being stripped, potentially leading to styling issues. The team implemented a solution using a specialized tool to correctly interpret and sanitize background styles in emails, ensuring consistent and secure email rendering.
Original PR description
Issue: When the customer sends an email with shorthand background it stripes the styling.
"background" isnt being striped into their longhand terms for xss.
Fix: I am using https://pypi.org/project/tinycss2/ to tokinize and identify the longhand terms inside the background shorthand and replace them with the longhand terms.
opw-5391098
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where refund calculations for Mexican VAT (l10n_mx_edi_pos) were inaccurate due to incorrect summing of line items. The change ensures that refunds are compared against the original order total correctly, preventing errors and ensuring proper processing of multi-line orders. This improves the reliability of refund transactions.
Original PR description
Before this commit, the some of individual line amounts were being summed to compare against the original order total when processing a refund. This could lead to incorrect comparisons due to rounding issues, resulting in errors when attempting to refund orders with multiple lines. <img width="626" height="288" alt="image" src="https://github.com/user-attachments/assets/e1bdc126-64d9-4b9a-bd16-2b97ac75e40c" /> opw-5433201
This update ensures that the employee's current location field is consistently included when views are generated, particularly in situations like creating many-to-many relationships in Studio. Previously, this data was sometimes missing, causing issues. This fix guarantees accurate location information is available across all views, improving data consistency and reporting.
Original PR description
Before this commit, the feature at commit odoo/odoo@b3be3af61cc08d0dea84969425d24957f215b26f worked by chance, because in most cases ALL fields where returned in the get views, since most of the time the search view is asked for as well, hence yielding all fields in the model There were issues when triggering get_views from another place, namely studio when creating a many2many. After this commit, we make sure the current day location field's description is sent opw-5484321 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245740
3 changes
Enhancements to existing features
This update optimizes the Excel export for the general ledger, reducing the file size and improving loading times. This change enhances the user experience by making large ledger reports faster to generate and download. The update focuses on streamlining data output without impacting the report's core functionality.
Resolved issues and error corrections
This update resolves a bug where the timer stopped appearing for survey participants after submitting their answers in live sessions. The fix ensures the timer correctly displays for the duration of the session, improving the participant experience and data accuracy. This change was made to align the survey logic with live session behavior.
Original PR description
Description of the issue/feature this PR addresses: Fixes timer not showing to participants of a live session after submitting an answer. Current behavior before PR: Steps to reproduce: Create a…
Description of the issue/feature this PR addresses: Fixes timer not showing to participants of a live session after submitting an answer. Current behavior before PR: Steps to reproduce: Create a Survey with two questions of any type. Set some Question Time Limit on both. Create Live Session for that Survey. Access Live Session as a participant. Start Survey as the host. The first question appears to the participant, with the timer on the top right. Answer the question as the participant and click Submit or press Enter. On the host side move to the next question. Bug: timer for the second question does not appear to the participant. Desired behavior after PR is merged: Fix: The logic to hide the timer is on `survey_form.js`. In the `_nextScreen` function. Specifically, when `options.isFinish` is set to `true`. It is set to `true` in the `_onSubmit` function. This function triggers when the participant submits an answer. The fix: only set that flag to `true` if there isn't a session in progress. This aligns with the other calls to `_nextScreen` for live sessions. That is, when a timer expires and the form is submitted: `'isFinish': !this.options.sessionInProgress` and when a notification is received for the session: `isFinish: nextPageEvent.type === 'end_session'` Meaning that for live sessions the only time `isFinish` should be set to `true`, is when the `end_session` notification is received. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a minor issue where payment links were incorrectly displayed for expired subscriptions. Specifically, the 'Pay Now' anchor was only added when the advance payment section was visible, even if products within the subscription had been archived. This ensures a cleaner and more accurate user experience for subscription payments.
Original PR description
When the subscription is expired and has to be paid, only use an anchor for `Pay Now` if the advance payment section is displayed (it could be hidden for ex. if any of the product has been archived)