Daily updates from Odoo
Tuesday, March 10, 2026
283 changes
8 changes
Resolved issues and error corrections
This update enhances the payroll system's ability to find worker codes by incorporating DMFA and egov3 codes alongside the previous display name search. This change improves accuracy and efficiency in matching worker codes, streamlining payroll processing.
Original PR description
before when searching for worker code it only used display name now it uses dmfa, egov3 codes Task#6020172
This update resolves a bug that prevented users from deleting employee leave report records within the reporting module. The system was incorrectly attempting to delete a record that doesn't have a corresponding database table. This fix ensures that the delete function works as expected, preventing data inconsistencies.
Original PR description
When the user tries to perform delete operation on the ``hr.leave.employee.report`` model, a traceback appears. Steps to reproduce the error: - Install ``hr_holidays`` module with demo data - Go to > Time Off > Reporting > by Employee > Switch to Graph View - Click on any record > Select any record > Actions > Delete Traceback: ```py UndefinedTable: relation "hr_leave_employee_report" does not exist ``` ``hr.leave.employee.report`` model is ``_auto=False``, meaning that no database table is created for this model. When the user attempts to delete a record of that model, It will lead to the above traceback. sentry-7202115608 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247315
This update fixes a visual issue in the chart granularity select dropdown in Chrome, particularly in dark mode. The changes ensure the icon is clearly visible and horizontally aligned with the label, providing a better user experience. This improves the overall appearance and usability of the dashboard.
Original PR description
## Description of the issue/feature this PR addresses: Current behavior before PR: - In Chrome, the select dropdown showed label and picker icon stacked vertically. - In dark mode, the picker icon was not clearly visible due to a change in picker color. Desired behavior after PR is merged: - Use flex + align-items: center to align label and icon horizontally. - Use a fixed spreadsheet color for the icon to ensure visibility. - Add a transition for smooth picker icon rotation. Task: [5418157](https://www.odoo.com/odoo/project/2328/tasks/5418157) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251100
This update fixes an issue where credential errors were displayed in a confusing format. It also corrects how XML invoices are generated when an OIB (tax ID) isn't provided, ensuring accurate invoice creation. New tests have been added to validate these improvements.
Original PR description
- Credentials errors have a separate format in MER, they should now be displayed in a more user-fiendly manner - Correcting XML generation for partners with no explicit OIB provided - Adding tests for both changes task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252284 Forward-Port-Of: odoo/odoo#249448
This update prevents the appearance of the "...") button in the members panel for regular users. Previously, this button was visible even when users couldn't perform any actions on channel members, leading to an empty popover. This change improves the user experience by removing unnecessary options.
Original PR description
Partial backport of https://github.com/odoo/odoo/pull/246580 Before this commit, the button "..." on channel members was visible even for non-owner / admins. Normal members cannot make any action on members, so there's no point in showing this button: clicking on it shows an empty popover. This commit prevents the showing of this button when member has no actions. Before / After <img width="244" height="223" alt="Screenshot 2026-03-06 at 12 50 59" src="https://github.com/user-attachments/assets/2257e27a-33b3-4c33-94a7-0d81dff3e0a9" /> <img width="244" height="206" alt="Screenshot 2026-03-06 at 12 51 21" src="https://github.com/user-attachments/assets/6da655a3-30b4-430b-bdf6-7c2316674ebc" /> Forward-Port-Of: odoo/odoo#252439
This update fixes an issue preventing the IoT box's Wi-Fi access point from connecting. The problem was resolved by changing the Wi-Fi standard to 802.11a, which is compatible with modern Wi-Fi equipment. This ensures consistent connectivity for IoT box configurations.
Original PR description
Before this commit, the `hostapd` Wi-Fi access point that is started to allow configuring the Wi-Fi network on the IoT box could not be connected to when using the latest images. The exact cause is unknown, but the Odoo code has not changed so it seems to be due to an OS or driver update. After this commit, we set the Wi-Fi mode to 802.11a, which enables modern Wi-Fi standards on the AP, whereas before it defaulted to 802.11b which is the oldest Wi-Fi standard. This change makes the network visible and able to be connected to. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252404
This update allows administrators to view and revoke user sessions, enhancing security and control over access to the Odoo system. The change was implemented to centralize session management and provide administrators with the tools they need to manage user access effectively.
Original PR description
An administrator must be able to revoke other users' sessions. The revocation action has been moved to the `res.session` model. Add the view that allows admins to view user sessions and revoke them. Task-5941823 Forward-Port-Of: odoo/odoo#248813
This update resolves several issues impacting the AI chatbot functionality, specifically related to prompt management and voice transcription. The fixes ensure users can correctly define prompts for AI interactions and address errors preventing public users from accessing the AI chat, improving overall AI performance and reliability.
Original PR description
This PR fixes the following bugs: - After 2acc117, users have the ability to define prompts for ai.prompt.button records instead of using the name field as the prompt. However, the VoiceTranscription component wasn't updated to use the new prompt field. - The _render_prompt method should return the `name` of the `ai.prompt.button` if no `prompt` is defined or no `rendering_record` is passed to the method. However, this check didn't take into account that `prompt` may contain empty HTML, for example `Markup(<p></p>)`. - Accessing render_model field on `ai.prompt.button` records raises AccessError. - An error would occur if a public user (or portal) tried to chat with the AI using the live chat. - The composer retrieved by the `TranscriptionComponent` doesn't take the model of the current record into consideration.
37 changes
Enhancements to existing features
This update streamlines how the base_geolocalize module retrieves API keys, enhancing the system's stability and organization. By separating this process, the change improves the overall architecture and reduces potential issues related to API key handling. This change is considered an internal improvement.
Original PR description
Move the api key retrieval to another method. Forward-Port-Of: odoo/odoo#252342 Forward-Port-Of: odoo/odoo#243496
Resolved issues and error corrections
This update resolves an issue where users without project access rights would encounter errors when modifying work orders linked to private projects. The fix ensures that workers can successfully update these work orders by granting necessary read permissions to project data, preventing access errors.
Original PR description
When working on a MO that is linked to a project in private, it will trigger a access error if the worker is does not have project access right Steps to reproduce: ------------------- * Install Project, MRP, Accouting * Create a private project * Create a MO and link it to this project * confirm this MO with a user that has no project access right Observation: ------------- When modifying the MO, we will pass through the write that has been overwritten: https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/project_mrp_workorder_account/models/mrp_production.py#L6-L10 we will call _get_analytic_distribution on project.project and since _get_analytic_distribution will [read fields from self](https://github.com/odoo/odoo/blob/436921c24a531eba6bf57ffe3f7c3b4978139d83/addons/analytic/models/analytic_line.py#L59-L64) we need project.project read rights. opw-4919576 Forward-Port-Of: odoo/enterprise#108148
This update ensures that refunds created through the Odoo backend system now accurately reflect the positive price changes made when refunds are created through the user interface. Previously, refunds in the backend showed negative prices, which was inconsistent with the UI. This fix improves data accuracy and consistency for all refund transactions.
Original PR description
Before this commit, when creating a refund from backend, the refunded lines had negative price, which is not the case when creating a refund from the UI. This commit makes sure that the refunded lines have positive price. opw-5459378 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249548
This update corrects a display issue in the info side panel of demo livechat sessions. Previously, closed sessions were incorrectly shown as active, leading to inaccurate data. Now, demo sessions with feedback are properly marked as ended, ensuring the info panel accurately reflects the conversation outcome.
Original PR description
**Description of the issue this PR addresses:** ---------------------------------------------- Some livechat demo sessions included feedback/ratings but were still displayed as active conversations…
**Description of the issue this PR addresses:** ---------------------------------------------- Some livechat demo sessions included feedback/ratings but were still displayed as active conversations in the info side panel. This created inconsistent demo data where closed conversations appeared with options meant for ongoing chats (e.g., status shown instead of outcome). **Current behavior before PR:** ---------------------------------------------- - Certain demo livechat sessions had ratings applied but no explicit livechat_end_dt set. - As a result, the info side panel treated them as ongoing conversations. - This caused mismatched UI information for demo data. **Desired behavior after PR is merged:** ---------------------------------------------- - Demo livechat sessions that received feedback are explicitly marked as ended using livechat_end_dt. - The info side panel correctly reflects closed conversations with coherent outcome information. Task-5412081 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250001
This update removes unnecessary customizations related to Swiss payroll calculations within the payrun process. The core logic has been corrected, eliminating redundant and potentially conflicting rules. This ensures consistent and accurate payroll processing for Swiss users.
Original PR description
Not necessary anymore, standard logic has been fixed Forward-Port-Of: odoo/enterprise#108121
This update resolves an issue where early payment discounts weren't correctly processed when generating invoices in the Factur-X format. The change adds the necessary handling for Early Payment Discounts (EPD) within this format, ensuring accurate invoice generation and compliance. This improves the accuracy of financial reporting.
Original PR description
Added the handling of early payment discount in the factur-x format. opw-5265981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252098 Forward-Port-Of: odoo/odoo#244659
This update resolves an issue where extra drag-and-drop dropzones appeared when hidden popups were present in the website editor. By ensuring the popup's visibility state is consistently tracked, this fix prevents these unwanted dropzones and improves the overall user experience when working with popups.
Original PR description
## Description There was a desync issue with popup states between normal mode and edit mode. That caused: - Hidden popups contributed extra dropzones during drag-and-drop - Hidden popups lost…
## Description There was a desync issue with popup states between normal mode and edit mode. That caused: - Hidden popups contributed extra dropzones during drag-and-drop - Hidden popups lost `d-none` class after dropping unrelated snippets ## How to reproduce ### Bug 1: extra dropzones from hidden popup desync 1. Enter website edit mode. 2. Drop popup in the page 3. Drag another snippet as you were adding it to the page 4. An additional dropzone appears below the invisible popup snippet ### Bug 2: hidden popup loses `d-none` class 1. Enter edit mode. 2. Drop a popup. 3. Close it so `.s_popup` gets `d-none`. 4. Drop any other snippet on the page arbitrarily. 5. Popup loses `d-none` class. ## Expected behavior after fix - Popup hidden/shown state remains stable across editor refreshes and snippet drops. - Drag-and-drop no longer creates extra dropzones from hidden popups. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251517 Forward-Port-Of: odoo/odoo#250625
This update ensures that employees only receive timesheets for public holidays that are relevant to their company. Previously, timesheets were incorrectly generated for employees in companies without a linked public holiday, leading to inaccurate record-keeping. This change improves data accuracy and reporting.
Original PR description
**Steps to reproduce** - Have 2 companies A and B - Use a single working schedule (needs to have no company on it) for both companies and their employees - Create a public holiday with company A, while having company B in the selected companies - There's a timesheet for the public holiday created for employees of company B, even though the public holiday will not apply for them. **Change** Only generate the timesheets for employees belonging to the companies of the public holidays. opw-5498462 Forward-Port-Of: odoo/odoo#245743
This pull request reverses a recent change to the spreadsheet edition's styling, specifically related to borders. The change was reverted to restore the previous visual appearance. This ensures consistent and expected formatting within the spreadsheet functionality.
This update resolves an issue where temporarily disabled products weren't appearing correctly in the self-order POS configuration. The fix ensures that product snoozes are now accurately reflected in real-time, allowing cashiers to manage product availability effectively. This improves the user experience and operational accuracy of the self-order system.
Original PR description
The `pos_snooze_ids` was not included in the `load_pos_self_data_fields` so the field was not accessible in the config in self and it would not display the temporary disabled products. I added it now so that products will be disabled in real time based on updates from the cashier screen --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing users from applying the 'My Department' filter in the Time Off module. The fix addresses a permissions error related to accessing employee data, ensuring the filter functions correctly for all users. This improves usability and prevents data access problems.
Original PR description
Steps to reproduce: 1- Install Time off app with demo data 2- Log in as Marc Demo 3- Go to Time Off > Overview 4- Enable My Department filter Issue: An access error is raised because of not having enough rights to access the field version_id on hr.employee. task-5948520
This update fixes a test failure related to live chat operator access permissions. The system now correctly assigns operators to channels, and the test has been updated to verify access without relying on outdated membership assumptions. This ensures consistent and reliable testing of the live chat functionality.
Original PR description
this PR is resolving [runbot error](https://runbot.odoo.com/odoo/runbot.build.error/241727) due to **/get_session** now creates the assigned operator as a channel member, so the previous non-member assertion became invalid and could fail depending on operator assignment. The test now uses a distinct livechat operator added after session creation to keep validating description edit access without relying on outdated membership assumptions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent update caused errors in Odoo logs when using domains with computed fields in automation rules or record filters. This fix ensures that domains are properly validated, preventing unexpected behavior and improving data consistency. The change reverts a previous refactoring to correctly evaluate domain expressions.
Original PR description
An error is generated in the logs when a user opens a record after saving a computed field used in the domain, as demonstrated in the steps below. Step1: - install `crm` and `base_automation` -…
An error is generated in the logs when a user opens a record after saving a computed field used in the domain, as demonstrated in the steps below.
Step1:
- install `crm` and `base_automation`
- Create a new automation rule for the `Activity` module and set the `Apply On` domain as below: `[("res_model", "=", "crm.lead"), ("state","=","done")]`
- An error will occur in the log when you open this record.
Step 2:
- Install `mass_mailing`
- Go to Email Marketing and create a record as below data
- Recipients: `Contact`
- Set domain as `[("vat_label", "=", 'test')]`
- An error will occur in the log when user open this record.
This issue occurred because the recently refactored commit [1] used `validate` of Domain for the domain instead of `search_count`. The `validate` method only checks the structure of the domain and does not verify whether the domain is actually executed or not.
This commit fixes the issue by reverting commit [1], restoring the previous behavior where the domain is evaluated using `search_count`.
[1]: https://github.com/odoo/odoo/commit/a1434c32e9f4dd226d512677fd96e3051b908d8b
sentry-7004977102This update resolves an issue causing the floor screen to repeatedly refresh, impacting the user experience. The problem stemmed from a code change that incorrectly modified appointment start times, triggering an endless loop of re-renders. This fix ensures a stable and reliable booking process.
Original PR description
Infinite re-rendering in floor_screen.
Root cause: `getFirstAppointment` mutates reactive model state
(appointment.start) during rendering:
```
appointments.map((appointment) => {
if (appointment.start < startOfToday) {
appointment.start = startOfToday; // <= mutates reactive state!
}
});
```
And `startOfToday` is set by
`DateTime.now().set({ hours: 0, minutes: 0, seconds: 0 })`
Which doesn't zero milliseconds, so each render creates a new
`startOfToday` with a later millisecond value.
The comparison `appointment.start < startOfToday` keeps being true
triggers another write => another re-render => infinite loop.
Forward-Port-Of: odoo/enterprise#109915This update corrects a bug in the Point of Sale module that caused incorrect tip calculations when the decimal separator in Odoo settings was changed. The fix ensures the NumberBuffer service dynamically retrieves the correct decimal separator, resolving parsing issues and guaranteeing accurate tip math regardless of user-defined settings.
Original PR description
Steps to reproduce: 1. Open the Point of Sale. 2. In Odoo Settings, change the Decimal Separator (e.g., from '.' to ','). 3. Go back to the PoS and add a Tip. 4. Observe that the tip math is wrong. Cause: The 'NumberBuffer' service is a singleton initialized at PoS startup. During initial setup, it caches the decimal point from 'services.localization.decimalPoint' into 'this.defaultDecimalPoint'. Because the service is a singleton, this value remains stale if settings are changed without a server refresh. When the 'NumberPopup' is opened, it uses the cached stale separator, causing parsing issues in methods like 'addTip'. Solution: Modify the 'NumberBuffer' service to fetch the decimal separator directly from the 'localization' service during the '_setUp' process. opw-5895622 Forward-Port-Of: odoo/odoo#247769
This update fixes a bug that occurred when users attempted to set the inventory quantity of a product to zero without a defined inventory location. The issue caused an error, preventing accurate stock tracking. This change ensures the system handles this scenario correctly, improving data reliability.
Original PR description
When a user sets the inventory quantity to 0 on a quant while the product’s Inventory Location is unset, a traceback is raised. Steps to reproduce the error: - Install ``stock`` module with demo data…
When a user sets the inventory quantity to 0 on a quant while
the product’s Inventory Location is unset, a traceback is raised.
Steps to reproduce the error:
- Install ``stock`` module with demo data
- Open ``Cabinet with Doors`` product
- In Inventory tab, unset Inventory Location > Open forecast report > click the On Hand quantity
- Select the quant > Actions > Set to 0
Traceback:
```py
ValueError: NotNullViolation('null value in column "location_dest_id"
of relation "stock_move" violates not-null constraint
```
https://github.com/odoo/odoo/blob/bc790e13ddf3ceacead40cc6ff8d27f1a5f5364d/addons/stock/models/stock_quant.py#L1005-L1016
When property_stock_inventory is unset,
the ``_get_inventory_move_values`` method assigns a NULL value to ``location_dest_id`` in ``move_vals``.
As a result, creating the stock move with a NULL ``location_dest_id`` leads to the above traceback.
sentry-7117991902
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245245This update fixes an issue where a Purchase Order would lose its connection to the underlying Stock Movement after the PO was canceled. The fix ensures that the link remains intact, allowing for accurate tracking and reporting of stock movements related to purchase orders. This improves the reliability of our inventory management processes.
Original PR description
* Currently when a PO generated from MO, after that we cancel that PO, the MO statsbutton disappear, * Reason: because we remove move_dest_ids out of po line so the link is missing 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#250042
This update fixes a bug related to member removal confirmation messages and ensures that actions related to archived users are restricted. This improves the user experience and prevents unintended actions when users are no longer active.
Original PR description
*=im_livechat, test_discuss_full Purpose the commit: - To update the string the member removal confirmation dialog. - Restrict the actions usage for archived users. task-5944930 part of-5867464
This update resolves an issue where custom headers on invoices were not functioning correctly after a recent layout change. The fix corrects a targeting error in the document layout, ensuring that custom header configurations are now properly applied. This restores the ability for users to personalize their invoice documents.
Original PR description
The document layout was made more flexible [1], but in the process the custom_header feature broke. The xpath was targeting a `<tr>` instead of the `<div>` it was meant to replace. Change it to target the right `<div>` in a slightly more robust way. Also consistently add the same header classes to the replacement `<div>`s in all the themes. [1] https://github.com/odoo/odoo/pull/237109 task-5949275 Backport of https://github.com/odoo/odoo/pull/251341.
This update resolves an issue where calls within Discuss were failing due to race conditions with initial channel data fetching. The fix ensures that all necessary channel information is fully loaded before initiating calls, preventing outdated data from causing problems. This improves the stability and reliability of the Discuss call feature.
Original PR description
...in crosstab call test The "join/leave sounds are only played on main tab" test could race with the initial `channels_as_member` fetches triggered when opening Discuss in both tab Those fetches return full channel data, including `rtc_session_ids`. one of their responses could arive after the call had already progressed or ended and overwrite the state with stale RTC data Wait for `channels_as_member` to be fully processed after opening Discuss in each tab before starting the call. fix for: https://runbot.odoo.com/odoo/runbot.build.error/241061
This update fixes an issue where long preset names in Point of Sale (PoS) were causing the PoS button to become too large and obscure other buttons. The change ensures that preset names can be longer without disrupting the user interface, improving the overall PoS experience.
Original PR description
# How to reproduce - Enable Take out / Delivery / Members in PoS Configuration - Create a preset with a very long name and set it as default - Open the register # The problem The preset button takes too much space and hide the other buttons opw-5938578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250671
This update resolves an issue where large file uploads to forms would fail, resulting in error messages. The fix adjusts how the system handles request sizes, ensuring compatibility with our web server's limits. This prevents form saving failures and improves the user experience when uploading files.
Original PR description
# How to reproduce - A reverse proxy needs to be set up between the client and the backend (for localhost, you can use nginx) - This reverse proxy needs to have a request max body size set below…
# How to reproduce - A reverse proxy needs to be set up between the client and the backend (for localhost, you can use nginx) - This reverse proxy needs to have a request max body size set below 128mb (for nginx : client_max_body_size) - If the system parameter web.max_file_upload_size is set, delete it and refresh your page - Pick any form view and add a file field with studio - Upload a file larger than the limit set in the proxy, but smaller than 128mb - Save the form # The problem The form is not saved and depending on the version, a Traceback will be shown (18.X) or a Connection Lost notification will be shown for a short period of time (19.0+) # Why When the system parameter web.max_file_upload_size is not set, the check for file size uses the default 128mb. A binary field added to a form via studio will upload its file in the json of the post request. This is done by encoding the file in base64. Our nginx servers set a limit for the request body size (usually 64mb). So if you add a file between 64mb and 128mb, it will bypass the default front-end size check but be stopped by the nginx reverse proxy. The proxy will send back an HTTP response with error code 413 to the client. Theses http responses are not correctly handled by the framework and are interpreted as a Connection Lost error because the response content cannot be parsed to json. Additionally, since we use base64 for the encoding and then use gzip to compress the json request, it's not really feasible to synchronize the front-end limit with the nginx one. opw-5891662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252325 Forward-Port-Of: odoo/odoo#249025
This update removes a temporary disabling of longpolling after connection errors in the IoT system. We’ve shifted to a model where clients with properly configured networks should automatically recover from errors. This change enhances the overall stability and reliability of IoT connections.
Original PR description
We used to disable longpolling for 5 min after a failure, in order not to lose time while making requests to an unreachable device, and jump directly to WebSocket. As we now recommand using LNA, clients should have a correctly configured network: if an error occurs the next one should work correctly. We then removed the longpolling auto disable feature. Forward-Port-Of: odoo/enterprise#108335
This update resolves an issue where the Gantt view for service projects would produce an error when grouping by project. The fix adjusts how date comparisons are handled within the task domain, ensuring compatibility with dynamic date formats used in the system. This improves the stability and usability of the Gantt view.
Original PR description
### Issue: When in the Gantt view of service projects, grouping by project results in a traceback. ### Steps to reproduce: - Create another field service project - Create a task in the new project…
### Issue: When in the Gantt view of service projects, grouping by project results in a traceback. ### Steps to reproduce: - Create another field service project - Create a task in the new project and add start and end dates - Go to Field service > my tasks > gantt view > group by project - Error with traceback `time data 'today' does not match format '%Y-%m-%d %H:%M:%S'` ### Cause: This [commit](https://github.com/odoo/odoo/commit/d1ea43f6721116914762ea323d8a5987f043e87f) added the possibility to use dynamic dates in domains. Then all domains were changed in 42b1fca8e127926a06f503d79c8baeddf7d5ae82 But `_expand_domain_dates()` is trying to parse the dates as if they were written in ISO format: https://github.com/odoo/enterprise/blob/be853cc1ee544dda580960d94417cfdff2c8a7db/project_enterprise/models/project_task.py#L626 ### Solution: We use the method `parse_date()`, which was added with dynamic dates, to parse them. opw-5955317 Forward-Port-Of: odoo/enterprise#109236
This update corrects a technical issue that prevented German customers from correctly completing their addresses on Amazon. The system was sending building names as the primary address line, which caused delivery validation errors. By swapping the fields, we ensure accurate address formatting and successful deliveries for German customers.
Original PR description
When filling in a German address on Amazon, customers are presented with two fields: - Street, and - Building or company name. The street is sent as AddressLine2, while the building/company name is sent as AddressLine1. However, delivery providers validate address existence, which fails when address line 1 is not a street name. To resolve this, we swap these two fields for German addresses. opw-4668178 Forward-Port-Of: odoo/enterprise#109215
This update ensures that live chat channels are created only once, even when multiple messages are sent in quick succession. Previously, sending multiple messages could result in duplicate channels being created, which has now been resolved to improve channel management and user experience. This change ensures a cleaner and more reliable live chat setup.
Original PR description
Before this commit, sending multiple messages before the channel creation can result in multiple channels being created. It occurs because the post function is overriden to first persist the channel. When the persist call is still in progress, we shouldn't issue a new one. task-4756758 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#250806 Forward-Port-Of: odoo/odoo#250374
This update fixes an issue where new timesheets weren't correctly selecting the appropriate Service Order Line (SOL) when creating timesheets in a multi-company setup. Now, the system automatically links the user's billing rates to the correct SOL, ensuring accurate billing calculations regardless of the company being used.
Original PR description
****Behavior:**** **Current:** In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific…
****Behavior:**** **Current:** In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific task, creating a new timesheet for the project does not set the correct SOL. This only happens if the sale is happening from a company that does not have an employee linked to the user. **Expected:** The new timesheet should be able to connect the current user to the related employee in the billing rates to find the right SOL. In the situation in which multiple companies have created an employee for the same user, and more than one of these has been linked to a SOL in the billing rates (unlikely workflow): We choose the SOL linked to the employee record created for the currently activated company, otherwise, we default to the first employee in the list. **Steps to reproduce:** - Be in a multicompany environment: company A and B - Create User with access to both but only one employee record for company A - Switch to company B - Create 2 services product, both creating a task in the same project. - Activate Billable Rate Indicators in the settings - Create a quote with both services and confirm - Go to the related project, and in the Invoicing tab, link employee from company A to SOL2 - As the user, check both companies but set company B as current active - Go to timesheet and create a new timesheet, when setting the project from the quote, you should see SOL1 by default, however we would want SOL2 as it was configured. opw-5159195 Forward-Port-Of: odoo/odoo#234200
This update fixes an issue where instructions added to Work Orders weren't properly linked when creating Purchase Orders via the mobile app. The fix restores a key data field, allowing instructions from the Bill of Materials to be correctly associated with the Purchase Order. This ensures accurate order fulfillment on the shop floor.
Original PR description
# How to reproduce - Create a BOM for a product with a Work Order - Add instructions to the WO - Using mobile, create a new MO for the product # The problem The instructions are not linked to the MO. This can easily be seen via the shop floor application # Why This issue is identical to https://github.com/odoo/odoo/pull/197889. This commit https://github.com/odoo/odoo/commit/b1ceec4c616d8ad2fee5b0fa1ce76c85cacbb344 removed the operation_id field from the workorder kanban mobile view, which is used in the MO form on mobile. operation_id is then not passed to the server in vals_list when creating the MO but it is required to link the instructions from the BOM to the MO. opw-5950983 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250090
This update fixes an issue where meeting dates displayed in the CRM were incorrectly showing a day after the scheduled meeting. The fix aligns the displayed date with the user's timezone settings, ensuring accurate meeting information. This improves the user experience and prevents confusion regarding meeting times.
Original PR description
# How to reproduce - Use a browser extension to manage your browser's timezone - Set your browser's timezone to a timezone with quite a big delay (like "America/Grand_Turk" if you live in Europe) -…
# How to reproduce - Use a browser extension to manage your browser's timezone - Set your browser's timezone to a timezone with quite a big delay (like "America/Grand_Turk" if you live in Europe) - Go to the form view of an opportunity - Click on the smart button for meetings (Should be "No Meeting" if it is a new Opportunity) - In the calendar view, add a new meeting for very late in the day (Example : 2026-02-10 22:00:00 => 23:00:00) - Go back to the opportunity for view # The problem The date displayed is a day after the meeting that was just set up. Taking back our example, the date displayed would be 2026-02-11 # Why The calendar view uses the browser's timezone to manage the dates. The smart button does not. It is not possible to make the smart button use the browser's timezone, atleast in a clean way. That is because the smart button's data is managed by a python template, which does not have access to the browser's data. Trying to change the data displayed by the framework would be clunky as the html would need to be edited directly. The fix that I implemented follows what the hr_appraisal module does for it's smart button with a date: use the timezone set in the user's preferences. opw-5898520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251840 Forward-Port-Of: odoo/odoo#247984
This update resolves an issue where the 'Return' button was incorrectly visible on picking forms, even when the picking wasn't in the 'Done' state. This change was triggered by the installation of the 'stock_account' module, which was overriding the intended logic. Now, the 'Return' button only appears when a picking is in the 'Done' state or linked to a sales or purchase order.
Original PR description
_*= sale_stock, purchase_stock Steps to Reproduce: - Create a Helpdesk ticket. - Click Replace, and the picking form opens. - Add product lines to the picking to deliver to the customer. - Observe that the Return button is visible and shows a warning when clicked, even though the picking is not in Done state. Cause: - When `stock_account` is installed, the Return button visibility is overridden to always show (`invisible=0`), ignoring the original condition (`state != 'done'`). Solution: - Restore the Return button visibility to its original condition so it’s only shown when the picking is Done or when picking is linked to any PO or SO. task-5075584 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242473
This update resolves an issue where database upgrades from 19.0 to 19.1 were failing due to an incorrect version comparison. The fix removes a misleading prefix from version comparisons, ensuring upgrades work as expected and settings are correctly applied. This prevents users from encountering unexpected configuration changes after upgrading.
Original PR description
Before this commit, upgrade of local storage from 19.0 to 19.1 were not working. Steps to reproduce: - have DB in 19.0 with message sound "off" in Discuss Notifications settings - upgrade to 19.1 DB (or make a fresh 19.1 DB on same sub-domain) - log on this new DB => "message sound" settings is "on" when it should be "off". This happens because the server version is "saas~19.1" and the prefix `saas~` was not taken into account. As a result, the version `saas~19.1` was mistakenly considered as lower than `19.0`. This commit fixes the issue by omitting the prefix `saas~` in the utils function of version comparison, which is what is used by the local storage internal code to compare versions. Upgrade version has been bumped to `19.1.1` and upgrade scripts have their sub-version explicitly set to `19.1.0`, so that these scripts are run for versions equal or lower than `19.1.0`, meaning they re-run also for `19.1.0`. Task-6008166
This update removes a temporary workaround for renamed fields in older Odoo databases. Some users upgraded from previous versions and still rely on these older field names. This change ensures a smoother experience for these users until a full upgrade script is available.
Original PR description
This reverts commit d29c2ea2c32204302e5043f1b67e0905e7025bfc. There are databases that were upgraded from <19 and that still have badly renamed fields. So keep the bandaid, at least until we can have an upgrade script. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252698
This update fixes an issue where the number of valid time off allocations wasn't accurately displayed when allocations started in the previous year. The change ensures the smart button on the time off type page correctly reflects the total number of valid allocations, regardless of their start date, improving data consistency.
Original PR description
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee…
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee allocations on the time off type page. ## Reproduction Steps 1. Go to Time off > Configuration > Time off Types and click on any time off type. 2. A smart button Allocations should appear with a number in it. Note the number and click on the button. 3. If no allocation exists yet, create one. Otherwise, click on an already existing allocation. 4. Set the start date of the validity period to any date last year. Set the ending date so that the allocation is still valid as of now. 5. Go back to the Time off type page and look at the number on the Allocations smart button. ### Expected behavior As the allocation we set is still valid, the number shouldn't have changed. ### Unexpected behavior The allocation number has been decreased. However, when we click on the smart button, the same number of valid allocations will show. This creates an inconsistency between the smart button and the allocation page, as the smart button should show the number of valid allocations, and when landing on the allocation page, the results are automatically filtered by validity. ## Origin of the issue The domain of the allocations to take into account when computing the count of valid allocations is defined here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/models/hr_leave_type.py#L297-L304 This doesn't take into account valid allocations that started during the previous year. The inconsistency with the allocation page can be seen here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/views/hr_leave_allocation_views.xml#L40-L46 Where the filter is defined based on today, rather than on the whole year, unlike above. __ opw-5504272 Forward-Port-Of: odoo/odoo#250992 Forward-Port-Of: odoo/odoo#248482
This update resolves an issue where printing basic receipts would fail if the point-of-sale (POS) name exceeded a certain length. The fix prevents a software error caused by attempting to repeat a string an excessive number of times, ensuring receipts print correctly regardless of the POS name's length. This improves the reliability of the basic receipt printing functionality.
Original PR description
When printing a basic receipt, if the pos name is too long a traceback will occurs when printing the basic receipt. Steps to reproduce: * Create a pos with a name of 46 character or more * Setup the italian fiscal printer * Enable Basic Receipt printing * Open point of sale * Create an order and validate it * Try "Print Basic receipt" Traceback: RangeError: Invalid count value: -15 at String.repeat () If the data being printed is longer than the maximum number of character in a line (MAX_CHARS = 46), paddingLeft becomes negative which cause an error in repeat(). [Similar solution](https://github.com/odoo/enterprise/blob/18.0/l10n_it_pos/static/src/app/fiscal_printer/commands/print_rec_message/print_rec_message.js#L35) [opw-5270697](https://www.odoo.com/odoo/project/49/tasks/5270697) Forward-Port-Of: odoo/enterprise#109527
This update automatically deletes task assignment email notifications after they're sent. Previously, these emails were retained indefinitely, leading to a buildup of data in the system. This change optimizes performance and storage by removing unnecessary notifications.
Original PR description
Task assignment notification emails (sent via message_notify when a user is assigned to a project task) were configured with mail_auto_delete=False, causing them to accumulate in the mail.mail table indefinitely. These are transient notifications that don't need to be retained after sending. Forward-Port-Of: odoo/odoo#251853
Features or functions removed from Odoo
This update removes a technical restriction that previously limited sales reporting to only business-to-business transactions. The change was made because many companies within the Odoo system are now configured as individuals, broadening the scope of reporting. This ensures all sales data is accurately reflected.
Original PR description
Removing as the prod has a lot of companies that are configured as individuals. no-task Forward-Port-Of: odoo/enterprise#99807
Code cleanup and technical improvements
This pull request simplifies the management of our internationalization (I18n) files by re-exporting the base.pot file. Previously, accessing translations required navigating through multiple layers. This change streamlines the process, making it easier for developers to utilize and update our translation resources, ultimately improving the quality and speed of internationalization efforts.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248879
4 changes
Resolved issues and error corrections
This update resolves an issue where the 'Submit' button for Dutch account returns didn't actually trigger the necessary XBRL export to the tax authorities. Now, when an account return is submitted, the correct XBRL data is generated and transmitted, ensuring accurate reporting and compliance with Dutch regulations.
Original PR description
Commit 647699eeb4b8a1cc37ca074fa57844871c5086c1 introduced account returns to the Dutch localization. However, the "Submit" action only updated the internal record state without triggering the actual XBRL export to the Dutch tax authorities. This led to a mismatch where the UI displayed "Submitted" despite no data being transmitted. This commit fixes the flow by: - Overriding `action_submit` on the account return to launch the XBRL wizard when the return type is a Dutch tax return. - Ensuring the SBR tax report wizard calls `_proceed_with_submission` on the associated account return to correctly finalize the process (including locking the period and generating the closing entry). opw-5974711 Forward-Port-Of: odoo/enterprise#109691
This update fixes a server error that occurred when merging tables in the Point of Sale (POS) system, specifically when a table was empty. The fix ensures the system waits for order synchronization before merging, preventing errors and improving table management functionality. This enhances the reliability of the POS experience.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs while merging the tables Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related PR - https://github.com/odoo/odoo/pull/245162 Forward-Port-Of: odoo/enterprise#104577
This update fixes an issue where the 'Today' button in the Gantt view didn't function properly when navigating from yesterday. The fix ensures the view correctly returns to the current date, improving usability and preventing users from being stuck on incorrect dates.
Original PR description
**Version:** 18.0 **Steps to reproduce:** - Install Attendance modules. - Navigate to yesterday using the arrow button. - Then click on Today button. **Issue:** The view does not return to the current day when Today button is clicked. **Cause:** The condition to check this scenario fails for this case. **Fix:** Updated the condition to include the this scenario. task-5451384 Forward-Port-Of: odoo/enterprise#109245 Forward-Port-Of: odoo/enterprise#103139
This update resolves a bug where renewing a subscription while another process was closing it would incorrectly mark the subscription as churned. The fix ensures the renewal process doesn't interfere with the subscription expiration process, preventing data inconsistencies and ensuring accurate subscription status.
Original PR description
Steps to reproduce: - Have a subscription ready to expire/auto-close. - Trigger the `_cron_subscription_expiration` cron. - While the cron is processing earlier batches, manually renew the subscription. - The renewed subscription is incorrectly marked as closed/churned. Cause: The cron searches for all expired/unpaid subscriptions at the very beginning and processes them in batches of 30. If a subscription is renewed concurrently (Race condition), its ID is already in the `subscriptions_close` list, causing the cron to close it regardless of its new state. Solution: Inside the batch processing loop, consider only subscriptions that are strictly still in `SUBSCRIPTION_PROGRESS_STATE`. Task: 5929077 Forward-Port-Of: odoo/enterprise#107157
16 changes
Enhancements to existing features
This update simplifies the process of downloading attachments from account moves like invoices and vendor bills. Previously, users had to download each attachment individually. Now, all attachments are automatically bundled into a ZIP file, making it easier to manage and share important documents.
Original PR description
before: - In v17, account moves (invoices, vendor bills, etc.) did not provide any ZIP export. - Users wanting to download move attachments (e.g. for vendor bills) had to download each file individually. after: - Add an Action on account moves to export attachments as a ZIP archive. - The ZIP contains all attachments linked to the move (PDF, XML, and any other files present in the mail thread), not only the report PDF. - The action is available for all move types (customer invoices, vendor bills, journal entries, etc.) task-5232551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250269 Forward-Port-Of: odoo/odoo#241647
Resolved issues and error corrections
This update resolves an issue where users without sufficient permissions to view certain dashboard data would cause the dashboard to fail to load. The fix ensures that dashboards check data access correctly, allowing users to consistently access the dashboard regardless of their permissions. This improves the overall user experience.
Original PR description
## Description When opening a dashboard, `_dashboard_is_empty()` may call `search_count()` on one of the dashboard's main data models to decide whether sample data should be loaded. If the current user does not have read access to one of these models, `search_count()` raises an access error and the dashboard loading can fail, even though the user has access to the dashboard itself. To avoid this, only unreadable models are checked with `sudo()`, while readable models are still evaluated with the current user rights. This prevents the access error in `_dashboard_is_empty()` and allows the dashboard to open instead of failing early. Task: [5905166](https://www.odoo.com/odoo/project/2328/tasks/5905166) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249784
This update fixes an issue where the 'Today' button in the Gantt view wasn't functioning properly when navigating from yesterday. The fix ensures the Gantt view accurately returns to the current date when the 'Today' button is clicked, improving usability for scheduling and reporting.
Original PR description
**Version:** 18.0 **Steps to reproduce:** - Install Attendance modules. - Navigate to yesterday using the arrow button. - Then click on Today button. **Issue:** The view does not return to the current day when Today button is clicked. **Cause:** The condition to check this scenario fails for this case. **Fix:** Updated the condition to include the this scenario. task-5451384 Forward-Port-Of: odoo/enterprise#109245 Forward-Port-Of: odoo/enterprise#103139
This update fixes an error in how outstanding amounts are calculated when a down payment is reversed with a credit note. Previously, the system incorrectly produced negative amounts, leading to incorrect settlement calculations. This change ensures accurate outstanding balance reporting for sales orders.
Original PR description
When having a down payment that is reversed by a credit note, the amount unpaid is wrongly computed. This is because we take the sum of invoice lines price total, regardless they come from invoice or credit note. Therefore we end up with negative value. Steps: - Have a SO for 500 - Make a downpayment for 300, confirm - Make a credit note for the downpayment invoice, confirm -> SO's amount unpaid is -100, it should be 500. If you now settle the SO, the amount unpaid will be -300 instead of 0. opw-5175562 Forward-Port-Of: odoo/odoo#252343 Forward-Port-Of: odoo/odoo#233248
This update ensures that timesheet entries are correctly removed when a time off record is deleted, preventing data inconsistencies. Previously, timesheets remained even after time off was removed, leading to inaccurate tracking. This fix addresses a bug related to how the system handles the link between time off and timesheet records.
Original PR description
BUG 1: ----------- **Steps to reproduce:** 1. Install Time Off and Timesheets with demo data. 2. Create a time off for an employee and approve it. 3. Check the related timesheet entry for that…
BUG 1: ----------- **Steps to reproduce:** 1. Install Time Off and Timesheets with demo data. 2. Create a time off for an employee and approve it. 3. Check the related timesheet entry for that employee. 4. Delete the approved time off. 5. Check the timesheet entries again. **Issue:** The timesheet entry remains even after the related time off record is deleted. **Cause:** Following commit 944c11e, admins can delete [approved time off ](https://github.com/odoo/odoo/blob/f6cf0d067e5f30e2b22ea513071cd7c5e3d9f44c/addons/hr_holidays/models/hr_leave.py#L956-L959)records. The relationship between the leave and the analytic line (timesheet) did not have a deletion policy defined. When the leave was [unlinked](https://github.com/odoo/odoo/blob/f6cf0d067e5f30e2b22ea513071cd7c5e3d9f44c/addons/hr_holidays/models/hr_leave.py#L961-L964), the analytic line remained without its parent reference. **Solution:** Explicitly remove related timesheet entries before deleting the leave record. BUG 2: ----------- Currently, refusing/cancelling a time off record can lead to orphan timesheets/duplicated hours (16h instead of 8h) if a public holiday exists on the same day. **Root cause:** The issue comes from this write method: https://github.com/odoo/odoo/blob/79ff1d63caed2c1058aa338947b9af90ebb6cd20/addons/project_timesheet_holidays/models/hr_leave.py#L128-L130 The method first unlinks the holiday_id from the timesheets and then attempts to delete them. However, once the holiday_id is set to False, the timesheets are no longer linked to the leave. As a result, leave.timesheet_ids becomes empty, and nothing is deleted. This leads to orphan timesheet records. When the leave is later refused or cancelled, a new public holiday timesheet entry is generated (if applicable), resulting in duplicated timesheet entries for the same day. **Steps to reproduce:** 1. Create a time off for one day and validate it (8h timesheet generated). 2. Create a public holiday for the same day. 3. Observe that leave duration becomes 0, but the timesheet remains. 4. Refuse or cancel the time off. 5. Observe two timesheet entries for the same day (16h total). opw-5384428 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical problem where the spreadsheet edition occasionally crashed when trying to save a thumbnail. The issue stemmed from a race condition during thumbnail creation, which could cause the spreadsheet to be unexpectedly closed. This fix ensures thumbnails are reliably saved, improving the user experience.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update resolves a problem where Razorpay payments failed due to customer names containing commas or exceeding 50 characters. The fix ensures Razorpay receives only clean names (without commas) and limits them to 50 characters, preventing payment errors and improving the reliability of Razorpay transactions.
Original PR description
Steps: - Install and set up Razropay. - Create order and set customer with long name or name with comma. - Try to pay with Razorpay. Issue: - Error name is invalid. Cause: - Razorpay only take name without comma and upto 50 character, so having longer name or name with comma would cause an issue. Fix: - Replace comma with empty space and only take first 50 character of name while creating customer in Razorpay. Forward-Port-Of: odoo/odoo#252444
This update fixes an issue where currency exchange differences weren't correctly displayed in DATEV exports. The fix adjusts how the export generates amounts for exchange difference entries, ensuring accurate reporting of financial transactions. This improves the reliability of data sent to DATEV for accounting.
Original PR description
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has…
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank] 5. Create USD invoice for XX/02/26 and confirm it 6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment) 7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data **Description of issue: The currency exchange rate difference entries in the exported file are shown as 0 **Expected behavior: The actual currency exchange difference values should be displayed **Why this happens? The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export. **The fix: Updated the logic to use the line balance when the entry is identified as a currency exchange difference. opw-5358954 Forward-Port-Of: odoo/enterprise#109655 Forward-Port-Of: odoo/enterprise#107268
This update corrects a display issue on Arabic POS receipts where phone numbers were printed right-to-left. The fix ensures phone numbers are correctly formatted left-to-right in Arabic, improving the user experience for Arabic-speaking customers. The change involves adjusting the receipt header XML to explicitly set the direction for the phone number.
Original PR description
# Steps to reproduce: - Open the company, change the language to Arabic - Go to POS, open the shop - Buy anything and click on receipt # Problem: When clicking on the receipt, you would find the…
# Steps to reproduce:
- Open the company, change the language to Arabic
- Go to POS, open the shop
- Buy anything and click on receipt
# Problem:
When clicking on the receipt, you would find the phone number is written right to left, although it should be printed left to right.
# Cause:
Normally when another language is selected, this line will adapt to it, and translate the whole block "Tel: `props.data.company.phone`" to arabic (right to left)
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L12
# Fix:
We need to specify the direction of the phone number to be Left to right.
```
<div>Tel:<span dir="ltr"><t t-esc="props.data.company.phone" /></span></div>
```
**Result:**
<img width="167" height="86" alt="HATEF" src="https://github.com/user-attachments/assets/4fe0bdd0-fe77-430f-9136-cd7086c4d5d9" />
There is also alternative fixes:
# First alternative fix:
Replace the '+' with '00' (there is no difference when trying to copy), and make a function in js that preserve the whole thing in a string variable.
```
get phoneText() {
return _t("Tel:") + " " + this.props.data.company.phone.replace("+", "00");
}
```
**Result:**
<img width="215" height="148" alt="hatef2" src="https://github.com/user-attachments/assets/e9cb4415-baad-4d66-a04b-ecdb308e3e72" />
**Drawback:**
- The inconsistency between how the number is stored and how we view it.
# Second alternative fix:
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.js`
```diff
import { _t } from "@web/core/l10n/translation";
import { Component } from "@odoo/owl";
+ import { localization } from "@web/core/l10n/localization";
```
```diff
+ get direction() {
+ return localization.direction;
+ }
```
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml`
```diff
<t t-if="props.data.company.phone">
- <div>Tel:<t t-esc="props.data.company.phone" /></div>
+ <t t-if="direction == 'ltr'">
+ <div>Tel:<t t-esc="props.data.company.phone" /></div>
+ </t>
+ <t t-elif="direction == 'rtl'">
+ <div><t t-esc="props.data.company.phone" />Tel:</div>
</t>
</t>
```
**Drawback:**
- Too much code for a small issue that probably won't bother the client.
- The need to change in multiple translation files for all RTL languages in odoo.
- Readability
opw-5881503
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251975
Forward-Port-Of: odoo/odoo#249060This update resolves a technical issue preventing the Quote Builder from generating PDF quotes, which was causing a traceback. The fix addresses a change in the PDF library dependency, requiring a specific version (5.4.0) to ensure proper PDF form creation.
Original PR description
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall…
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0) 2- Enable Quote Builder. 3- Create a SO and in quite builder tab, select a document. 4- Print -> PDF Quote. This will lead to traceback. Cause: --- There is a requirement change on https://github.com/odoo/odoo/pull/233600, as pypdf2 will not be supported in future. Instead we use pypdf==5.4.0. In pypdf 5.4.0 it is required to have `Fields` present in `Acro Form` (introduced in [1] v3.13.0): https://github.com/py-pdf/pypdf/blame/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L1060-L1061 FIX: --- We could add an empty `fields` dictionary when it's not present. The entry should be `/Fields`: https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/constants.py#L362-L370 Note: --- In this fix, we replace `is_upper_version_pypdf2` with specific version comparison. To be precise `getNumPages` is depreciated in version 1.28.0 [2]. References: --- [1]- https://github.com/py-pdf/pypdf/commit/dcf997a028e993b215457c5629cb4e78186e11c0 [2]- https://github.com/py-pdf/pypdf/blob/3ab1581a51f446f86dd445662005f8747941c2b6/pypdf/_writer.py#L507-L514 opw-5784464 Forward-Port-Of: odoo/odoo#250329
A previous shortcut conflict in the asset management module caused users to incorrectly navigate to the Posted Entries view instead of the previous asset. This update resolves this issue by changing the shortcut from ALT+P to ALT+SHIFT+P, ensuring consistent and correct navigation within the asset form.
Original PR description
# How to reproduce - Have atleast two assets - Go to the last asset - Type ALT + P on your keyboard # The problem We enter the Posted Entries view instead of going to the previous asset # Why This PR (https://github.com/odoo/enterprise/pull/67840) added shortcuts to the asset form view, but used ALT + P for the Posted Entries. This shortcut is already used on all form views for the "previous page" button. After consulting with the developer of the original PR, we decided to move the Posted Entries shortcut to ALT + SHIFT + P opw-5948523 Forward-Port-Of: odoo/enterprise#109022
This update resolves a bug where the barcode scanning app incorrectly identified products when using barcodes that include product prices (starting with '23'). The fix mirrors the functionality in the Point of Sale app, ensuring accurate product recognition for these common barcode formats. This improves the reliability of product scanning and reduces potential order errors.
Original PR description
Issue ----- Barcode app doesn't match products when using price-embedded barcodes. Steps to reproduce ----- - Use default nomenclature (so price embedded barcodes are 23...) - Create a product with barcode 2355555000004 - Go to barcode and scan 2355555009502 > The product isn't recognised Cause ----- There is no logic in place to handle such barcodes, but it can be added to mimic how it works in POS. https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.js#L212 ----- Ticket: opw-5901412 Forward-Port-Of: odoo/enterprise#109815 Forward-Port-Of: odoo/enterprise#109627
This update resolves an issue where renewing a subscription while another renewal process was running would incorrectly mark the subscription as churned. The fix ensures that subscriptions are only processed when their status is actively in progress, preventing this race condition and maintaining accurate subscription management.
Original PR description
Steps to reproduce: - Have a subscription ready to expire/auto-close. - Trigger the `_cron_subscription_expiration` cron. - While the cron is processing earlier batches, manually renew the subscription. - The renewed subscription is incorrectly marked as closed/churned. Cause: The cron searches for all expired/unpaid subscriptions at the very beginning and processes them in batches of 30. If a subscription is renewed concurrently (Race condition), its ID is already in the `subscriptions_close` list, causing the cron to close it regardless of its new state. Solution: Inside the batch processing loop, consider only subscriptions that are strictly still in `SUBSCRIPTION_PROGRESS_STATE`. Task: 5929077 Forward-Port-Of: odoo/enterprise#107157
This update corrects a bug where the 'Documents' button for employees was displaying documents from other users, even when 'Human Resources' file centralization was disabled. The fix ensures that users only see documents associated with their own employee records, restoring the intended functionality. This resolves a usability issue for employees accessing their personal documents.
Original PR description
Steps: - uncheck the "Human Resources" file centralization option - go to an employee, click the documents smart button -> You see every documents, not only the ones from the employee PR https://github.com/odoo/enterprise/pull/93782 aimed at restoring the previous behaviour of the employee documents button and accesses for companies without the hr documents settings enabled, but forgot the domain on the employee smartbutton action. opw-5857914
This update ensures the Odoo spreadsheet functionality is running on the latest version of the library. This resolves a potential compatibility issue and improves the overall stability of the spreadsheet feature. The update was made by a team of developers to maintain optimal performance.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/05cefeb33a [REL] 18.3.38 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/0bb9142855 [FIX] Model: reject data that postdate the library version [Task: 5895572](https://www.odoo.com/odoo/2328/tasks/5895572) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves an issue where the HTML editor toolbar would incorrectly appear on elements that shouldn't have formatting options. Now, the toolbar only displays for editable content, ensuring a more stable and predictable user experience within the HTML editor. This prevents unexpected formatting changes and improves overall editor functionality.
Original PR description
Current behavior before PR: - Removing formatting on a contenteditable false element infinite loop when removing format. - The toolbar could appear even when the target element had contenteditable false Desired behavior after PR is merged: - Now,the toolbar no longer opens when the selected element is contenteditable false - The toolbar is now only shown for elements with contenteditable true, except for QWeb and icon elements, where it remains accessible. task-5265416 Forward-Port-Of: odoo/odoo#248364 Forward-Port-Of: odoo/odoo#231613
2 changes
Resolved issues and error corrections
This update resolves a problem where Odoo Enterprise spreadsheets could crash when taking screenshots to save thumbnails. The fix prevents the spreadsheet from being unexpectedly closed during the screenshot process, ensuring thumbnails are consistently saved and preventing errors. This improves the reliability of spreadsheet functionality.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update resolves a bug where pressing ALT+P in the asset module incorrectly navigated to the Posted Entries view instead of the previous asset. The shortcut was unintentionally duplicated with another feature, and it’s now corrected to ALT+SHIFT+P for accurate navigation. This ensures a smoother user experience when managing assets.
Original PR description
# How to reproduce - Have atleast two assets - Go to the last asset - Type ALT + P on your keyboard # The problem We enter the Posted Entries view instead of going to the previous asset # Why This PR (https://github.com/odoo/enterprise/pull/67840) added shortcuts to the asset form view, but used ALT + P for the Posted Entries. This shortcut is already used on all form views for the "previous page" button. After consulting with the developer of the original PR, we decided to move the Posted Entries shortcut to ALT + SHIFT + P opw-5948523 Forward-Port-Of: odoo/enterprise#109022
11 changes
Enhancements to existing features
This update adjusts the timing of changes to marital status for withholding tax calculations. Switching from an isolated status (single, divorced, widow) now takes effect at the start of the next calendar year, while becoming isolated (e.g., adding a spouse) is immediate. This aligns with Belgian tax regulations.
Original PR description
For withholding taxes: ----------------------- Switching from an isolated status (single, divorced, widow) to a non isolated will take effect the start of the next calendar year. But the other way around (becoming isolated) takes effect immediately. Task-5449907
Resolved issues and error corrections
This update fixes a potential issue where changes to knowledge articles (sharing, favorites, editing) weren't reliably applied. The update ensures the correct article is loaded before any modifications are made, enhancing the user experience and data consistency. This improves the reliability of the knowledge base.
Original PR description
With this commit, We ensure we're in the correct article before making any changes (share, add to favorites, edit) using `waitUntil`. We've added a `checkArticle` function to ensure the article is in the correct place in the menu. runbot-error-id~234645
This update optimizes how Odoo calculates planning fields for sales orders. Previously, all sales order lines were processed, even those not directly involved in planning. Now, calculations are focused only on sales order lines linked to products with planning enabled or those included in a planning slot, improving efficiency and accuracy.
Original PR description
Before this commit, the compute of planning_hours_to_plan and planning_hours_planned fields computes for all SOLs even the ones which are not related to planning. This commit makes sure the both computes calcules the planning field for the SOLs which are related to planning, that is: - SOL is linked to a product with planning_enabled set to True - or at least one planning slot has the SOL set. Issue detected during a fix of migration script of task-5258989 Forward-Port-Of: odoo/enterprise#109715
This update resolves several issues impacting the AI chatbot functionality, specifically related to prompt definitions and voice transcription. The fixes ensure correct prompt usage, prevent errors during rendering, and resolve issues impacting public users attempting to interact with the AI.
Original PR description
This PR fixes the following bugs: - After 2acc117, users have the ability to define prompts for ai.prompt.button records instead of using the name field as the prompt. However, the VoiceTranscription component wasn't updated to use the new prompt field. - The _render_prompt method should return the `name` of the `ai.prompt.button` if no `prompt` is defined or no `rendering_record` is passed to the method. However, this check didn't take into account that `prompt` may contain empty HTML, for example `Markup(<p></p>)`. - Accessing render_model field on `ai.prompt.button` records raises AccessError. - An error would occur if a public user (or portal) tried to chat with the AI using the live chat. - The composer retrieved by the `TranscriptionComponent` doesn't take the model of the current record into consideration. Forward-Port-Of: odoo/enterprise#108115
This update fixes a potential issue where changes to knowledge articles (sharing, favorites, editing) weren't reliably applied. The update ensures the correct article is loaded before any modifications are made, enhancing the user experience and data consistency. This improves the reliability of the knowledge base.
Original PR description
With this commit, We ensure we're in the correct article before making any changes (share, add to favorites, edit) using `waitUntil`. We've added a `checkArticle` function to ensure the article is in the correct place in the menu. runbot-error-id~234645
Code cleanup and technical improvements
This update modifies Odoo's template code to align with upcoming OWL3 requirements. Specifically, it adds `.this` to template variables that reference components, ensuring compatibility with the new OWL3 rendering context. This prepares the system for a smoother transition and avoids potential issues with future template development.
Original PR description
In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targetting the component. Script PR: https://github.com/odoo/odoo/pull/247965 THIS_TARGETS = [sign, sms, snailmail] task: OWL3 prep - add this. to template variables
This update prepares our Odoo Enterprise system for OWL3, a new rendering engine. It adds the necessary `.this` syntax to template variables that reference components, ensuring compatibility with the upcoming changes. This ensures a smooth transition and avoids potential issues with future functionality.
Original PR description
In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targeting the component. Script PR: odoo/odoo#247965 targets: ["product"] impacts: ["planning_field_service_sale_stock", "sale_subscription"] task: OWL3 prep - add this. to template variables
This update prepares our Odoo Enterprise system for OWL3, a new version of our template engine. We've updated template variables to include `.this`, which is now required to correctly reference component variables. This ensures continued compatibility and functionality with the upcoming OWL3 release.
Original PR description
In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targetting the component. Script PR: odoo/odoo#247965 task: OWL3 prep - add this. to template variables
This update prepares Odoo for OWL3, a new rendering system. It adds the `.this` syntax to template variables, which is now required to correctly reference component elements. This ensures compatibility with the upcoming OWL3 changes and avoids potential issues with future template development.
Original PR description
In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targetting the component. Script PR: odoo/odoo#247965 task: OWL3 prep - add this. to template variables
This update prepares the Web Studio module for the upcoming OWL3 release. It adds the `.this` syntax to template variables, which is now required to correctly target component variables within the rendering context. This ensures the Web Studio functionality continues to work seamlessly with the new OWL3 framework.
Original PR description
In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targetting the component. Script PR: #247965 task: OWL3 prep - add this. to template variables
This update prepares Odoo Enterprise for OWL3 by automatically adding '.this' to template variables that reference components. This change is necessary because OWL3 requires this syntax for correctly targeting component variables within templates, ensuring compatibility with the new rendering engine.
Original PR description
*project_enterprise In preparation for OWL3, where template variables will need to use .this to target component variables, we add .this to template variables that are targetting the component. Script PR: #247965 task: OWL3 prep - add this. to template variables
10 changes
Resolved issues and error corrections
This update fixes an issue preventing UK users from accessing Stripe funding instructions and adds support for UK account creation. The changes improve the user experience for UK employees by ensuring they receive the correct funding instructions based on their Stripe currency setting (Euro or GBP).
Original PR description
### [IMP] hr_expense_stripe: Rework tests for UK Rework the test framework to handle the United Kingdom specific tests ### [FIX] hr_expense_stripe: Fix UK account creation Add UK account creation funding instructions as it was made available to us by Stripe ### [FIX] hr_expense_stripe: Fix funding instruction EU Before this commit: The funding instructions were using the country group Europe as a reference to see if the country should use the EU funding instructions The issue comes from the fact that a lot of people remove their country from that country group, locking themselves out of stripe issuing EU. This adds second way of telling the user is in the EU flow if their stripe currency is set to Euros.
This update resolves latency issues experienced by users on iOS devices when interacting with the Point of Sale and related screens. The fix addresses differences in how iOS and Android devices respond to user input, improving the overall user experience. Pinch zoom functionality has also been disabled to ensure consistent performance.
Original PR description
On IOS devices, there was a latency issue when hitting different elements in the POS and self. Actually, the issue is because IOS devices don't react in the same way as Android devices. IOS adds a delay of +/-300ms when the element is not considered as a button. Instead of replacing a lot of elements with a button element we can add the parameter role="button". I also disabled the pinch zoom in the POS, self and preparation display. It's mandatory to add the parameter touch-action: pan-x pan-y to the * selector. task: 5976364 community pr : https://github.com/odoo/odoo/pull/251198
This update fixes a server error that occurred when merging tables with empty orders in the Point of Sale (POS) system. The fix ensures the system waits for order synchronization before merging, preventing the error and improving table management functionality. This enhances the reliability of the POS experience for restaurant operations.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs while merging the tables Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related PR - https://github.com/odoo/odoo/pull/245162 Forward-Port-Of: odoo/enterprise#104577
This update ensures that the total unsettled amount for POS orders is accurately recalculated when an order is cancelled. Previously, cancelled payments were incorrectly included, leading to inaccurate reporting. This change prevents double-counting payments and provides more reliable financial data.
Original PR description
Add `pos_order_line_ids.order_id.state` to the depends of `_compute_pos_amount_unsettled` so that cancelling a POS order triggers a recompute. Also exclude cancelled order lines from `total_pos_paid` to avoid counting payments that were rolled back. opw-5997872
This update fixes an issue where the 'Today' button in the Gantt view didn't reliably return to the current date after navigating from yesterday. The fix ensures the button functions as expected, providing a consistent user experience when viewing schedules.
Original PR description
**Version:** 18.0 **Steps to reproduce:** - Install Attendance modules. - Navigate to yesterday using the arrow button. - Then click on Today button. **Issue:** The view does not return to the current day when Today button is clicked. **Cause:** The condition to check this scenario fails for this case. **Fix:** Updated the condition to include the this scenario. task-5451384 Forward-Port-Of: odoo/enterprise#109245 Forward-Port-Of: odoo/enterprise#103139
This update resolves an issue where the Odoo Report Editor was unintentionally influenced by default theme colors, leading to potential styling inconsistencies. By preventing the report editor from using these theme colors, we've improved the stability and predictability of report designs. This change ensures reports consistently render as intended.
Original PR description
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer) Those colors are a bit special (see full…
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer)
Those colors are a bit special (see full discussion on the opw)
Their existence is described in module web
Their CSS definition is implemented in module html_editor
Reports don't use them at all We probably don't want reports' style to be influenced by the presence or lack thereof of the html_editor module, which was originally made to customize the interface.
Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.
This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.
After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.
see odoo/odoo#251446
opw-5892573This update fixes an issue where subscription products weren't displaying prices with tax, even when the website setting was enabled to show tax-inclusive prices. The fix ensures that the correct tax calculation is applied based on the product's company and the website's configuration, resulting in accurate subscription pricing for customers.
Original PR description
subscriptions Despite enabling the website setting to display tax-inclusive prices, subscription products show prices without tax when a recurring pricelist is configured. In `_get_sales_prices`, the product’s company ID is compared to the website’s company, but products visible to all have a false company ID, and products assigned to a parent company retain the parent’s company ID. As a result, when the product’s company ID does not match the website’s company ID, no taxes are applied.Instead, _filter_taxes_by_company should be used to determine whether the company can access the product’s tax_id. opw-5222411 Forward-Port-Of: odoo/enterprise#100662
This update ensures that taxes are automatically calculated for charge and discount lines in UrbanPiper orders, even when tax data isn't initially provided by the UrbanPiper system. Previously, taxes weren't applied if UrbanPiper didn't send tax information, and it was limited to India. Now, taxes are calculated using standard product tax rules, ensuring accurate pricing for all UrbanPiper transactions.
Original PR description
Before this commit: --- - If UrbanPiper did not send tax data for charge and discount lines, taxes were not applied. - Tax data was only provided by UrbanPiper for the India region. After this commit: --- - When the payload does not include tax data, compute taxes for charge and discount lines using the product tax, the same way as for normal order lines. task-5895987 Forward-Port-Of: odoo/enterprise#108821 Forward-Port-Of: odoo/enterprise#106686
A previous shortcut in the asset management module was causing users to navigate to the wrong view instead of the previous asset. This update corrects this behavior by changing the shortcut to ALT + SHIFT + P, aligning it with other similar shortcuts within Odoo.
Original PR description
# How to reproduce - Have atleast two assets - Go to the last asset - Type ALT + P on your keyboard # The problem We enter the Posted Entries view instead of going to the previous asset # Why This PR (https://github.com/odoo/enterprise/pull/67840) added shortcuts to the asset form view, but used ALT + P for the Posted Entries. This shortcut is already used on all form views for the "previous page" button. After consulting with the developer of the original PR, we decided to move the Posted Entries shortcut to ALT + SHIFT + P opw-5948523 Forward-Port-Of: odoo/enterprise#109022
This update resolves an issue where the 'Submit' button for Dutch account returns didn't actually trigger the necessary XBRL export to the tax authorities. The fix ensures that the correct XBRL wizard is launched and the submission process is fully finalized, accurately reflecting the 'Submitted' status in the system.
Original PR description
Commit 647699eeb4b8a1cc37ca074fa57844871c5086c1 introduced account returns to the Dutch localization. However, the "Submit" action only updated the internal record state without triggering the actual XBRL export to the Dutch tax authorities. This led to a mismatch where the UI displayed "Submitted" despite no data being transmitted. This commit fixes the flow by: - Overriding `action_submit` on the account return to launch the XBRL wizard when the return type is a Dutch tax return. - Ensuring the SBR tax report wizard calls `_proceed_with_submission` on the associated account return to correctly finalize the process (including locking the period and generating the closing entry). opw-5974711 Forward-Port-Of: odoo/enterprise#109691
10 changes
Enhancements to existing features
This update adds a convenient ZIP export feature for account moves like invoices and vendor bills. Previously, users had to download attachments individually. Now, all related attachments – including PDFs, XML files, and mail thread documents – are bundled into a single ZIP file for easy download and sharing.
Original PR description
before: - In v17, account moves (invoices, vendor bills, etc.) did not provide any ZIP export. - Users wanting to download move attachments (e.g. for vendor bills) had to download each file individually. after: - Add an Action on account moves to export attachments as a ZIP archive. - The ZIP contains all attachments linked to the move (PDF, XML, and any other files present in the mail thread), not only the report PDF. - The action is available for all move types (customer invoices, vendor bills, journal entries, etc.) task-5232551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241647
Resolved issues and error corrections
This update resolves an issue where changing the 'Kitchen Note' on a POS order after a quantity update would cause an error. The fix ensures that the note is correctly updated in subsequent order changes, improving the reliability of the POS system for restaurant operations. This prevents order discrepancies and ensures accurate customer notes are recorded.
Original PR description
**Steps to Reproduce:** - Install `pos_restaurant_preparation_display`. - Open Register for POS "**Restaurant**" Shop. - Choose table > select food-item > send the order. - Update food-item quantity > send the updated order. - Update food-item '**Kitchen Note**' > send the note. **Error:** `TypeError - 'NoneType' object is not subscriptable` **Cause:** When the food quantity is updated, a new preparation entry is created for the increased quantity. During the first iteration, the display and order quantities are already merged correctly. However, in a subsequent iteration, the original key no longer exists in `quantity_data`. As a result, accessing a None value leads to a traceback. **Fix:** This commit skips the merge step when the original quantity entry has already been merged. sentry-7197024946
This update resolves an issue where product availability emails were sending large, full-size images, leading to slow email loading times. The fix ensures images are appropriately sized for email delivery, improving email performance and user experience. This change was triggered by a bug in how product availability notifications were generated.
Original PR description
Steps to reproduce in local: 1. Install `website_sale_stock` 2. Make a product variant with an image 3. To make it easy set field `Back in stock Notifications`'s value on this product with the help…
Steps to reproduce in local:
1. Install `website_sale_stock`
2. Make a product variant with an image
3. To make it easy set field `Back in stock Notifications`'s value on this product with the help of the studio
4. Add a person to receive notification in this field
5. Don't set Outgoing email server
6. Run cron `Product: send email regarding products availability` manually
7. To Check sent email go to `Setting > Technical > Email > Emails`
Issue:
- The image is a full-size image
<table>
<tr>
<th style="text-align: center;">Before</th>
<th style="text-align: center;">After</th>
</tr>
<tr>
<td style="text-align: center;">
<img width="1395" height="728" alt="Before"
src="https://github.com/user-attachments/assets/a3fe3b38-c4a5-4a78-a63a-552c96cfdf84" />
</td>
<td style="text-align: center;">
<img width="1383" height="662" alt="After"
src="https://github.com/user-attachments/assets/8c346302-4295-44f2-8172-6a01072b23c7" />
</td>
</tr>
</table>
opw-5915587This update fixes an issue where customers could set the subscription start date to 'False', leading to incorrect invoicing. The change prevents this removal, ensuring subscriptions are properly billed and accurately reflect the subscription's terms. This maintains accurate subscription tracking and billing.
Original PR description
**Issue** Some customers were removing the `start_date` of subscriptions, leading to the subscription being considered free on the next invoicing. While there are legitimate use cases to edit the `start_date` of a running subscription, it should probably not be removed. opw-5325303
This update resolves a technical issue where saving thumbnails for spreadsheets could sometimes fail due to a brief disconnect during the process. The fix ensures that thumbnails are reliably saved, improving spreadsheet functionality and preventing potential data loss or errors. This was a minor stability improvement.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update corrects a problem with Razorpay payments caused by customer names containing commas or exceeding 50 characters. The fix ensures Razorpay correctly processes payments by trimming commas and limiting customer names to 50 characters, preventing errors.
Original PR description
Steps: - Install and set up Razropay. - Create order and set customer with long name or name with comma. - Try to pay with Razorpay. Issue: - Error name is invalid. Cause: - Razorpay only take name without comma and upto 50 character, so having longer name or name with comma would cause an issue. Fix: - Replace comma with empty space and only take first 50 character of name while creating customer in Razorpay. Forward-Port-Of: odoo/odoo#252444
This update streamlines the process of opening cashboxes for IoT devices. Previously, a redundant network check was performed, which has now been removed. This change improves efficiency and reliability by leveraging the existing websocket connection for communication.
Original PR description
Stable IoT Boxes can be reached using websocket, so it doesn't make sense to check the connectivity on local network before sending the "open cashbox" action. We then removed this check.
This change corrects a typo in an XML field related to Italian debit notes sent to the SDI. Previously, the system was rejecting these notes due to an incorrect naming convention. This fix ensures accurate data transmission and compliance with Italian tax regulations, preventing rejection errors.
Original PR description
# Problem:
When sending debit notes to the SDI, they are rejected with the following error:
`File non conforme al formato : Invalid content was found starting with element 'Datifatturecollegate'. One of '{DatiOrdineAcquisto, DatiContratto, DatiConvenzione, DatiRicezione, DatiFattureCollegate, DatiSAL, DatiDDT, DatiTrasporto, FatturaPrincipale}' is expected.`
# Cause:
In the `account_invoice_it_FatturaPA_export_debit_note` there's a typo in 'Datifatturecollegate' as it should be 'DatiFattureCollegate'
https://github.com/odoo/odoo/blob/bc1c264b6232c78c33a96169110b37d9d4430243/addons/l10n_it_edi_ndd_account_dn/data/invoice_it_template.xml#L5-L8
opw-5930596
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#249284This update resolves an issue where changes to view settings (like Interval/Scale/Mode) in Odoo Studio weren't being saved properly. The fix ensures that these settings are persistently stored using local storage, providing a more reliable user experience for editing and customizing views.
Original PR description
Example of steps: - Open any Cohort/Gantt/Calendar view - Open studio - Try to change the default Interval/Scale/Mode - Save - Nothing has changed Theses three view uses `localStorage` to persist theses settings, studio needs to update them directly via `localStorage.setItem` to do it properly. WIP opw-5951702
This update resolves an issue where the HTML editor wasn't accurately reflecting changes made by users. Previously, multiple edits within the same field could lead to incorrect 'dirty' status indicators. Now, the system reliably tracks changes within the HTML editor, ensuring users receive accurate feedback on modifications.
Original PR description
Prior to this commit, it was possible to: - make change A inside a html_field - save/commitChanges - make change B inside the html_field, before the end of the save/commitChanges - the field ends up incorrectly marked as "not dirty" (user can't use the FormStatusIndicator) even though change B was not committed yet. Solution: Give an id to the dirtiness, and associate that id with an extracted value from the editor. When the record update is done, mark the field as not dirty ONLY IF the current dirty id is the same as the id previously associated with the extracted value, else the field stays dirty. task-5976348
2 changes
Resolved issues and error corrections
This update resolves a technical issue that caused a traceback when using the pivot table autofill feature. The fix corrects a misnamed function call, ensuring consistent behavior with vertical autofills. While the core functionality remains unchanged, this resolves a potential error and improves stability.
Original PR description
When autofilling a positional pivot row header horizontally, we would get a traceback because we were calling `_autofillPivotColHeader` instead of `_autofillPivotRowHeader`. Note that this fix only fixes the traceback, the result is not correct, but is consistent with autofilling a positional col header vertically. Task: [5909266](https://www.odoo.com/odoo/2328/tasks/5909266)
This update fixes an issue where upsell orders within subscription plans weren't correctly reflecting the invoiced quantity. The fix ensures that the quantity invoiced on upsell orders matches the quantity on the associated invoice, resolving a discrepancy that prevented accurate billing. This impacts subscription revenue reporting.
Original PR description
_ ## Short functional explanation of the error When creating a subscription for the previous and current month, and creating an upsell order for a day in between the start of the previous and current…
_ ## Short functional explanation of the error When creating a subscription for the previous and current month, and creating an upsell order for a day in between the start of the previous and current period, when we invoice that upsell order, the quantities invoiced shown on the upsell order are incorrect. ## Reproduction Steps 1. Create a subscription starting the first day of last month. Set the recurring plan as Monthly and add a product. Click on Confirm. 2. Create a first invoice for which the Invoice Date is the first day of last month. Click on confirm. 3. In the breadcrumb, click on the Sales order and create a second invoice, this time with the date of today. 4. Click on the Sales order in the breadcrumb and click on Upsell. Set the quantity to 5, the quotation date to the 15th of last month and in the Other info tab, set the Start date to the same date. 5. Create an invoice and confirm. 6. Go back to the Sales order of the Upsell and check the Invoiced field in the Order Lines tab. ### Expected behavior The field Invoiced should be equal to 5, which is the quantity we have on the invoice. ### Unexpected behavior The field Invoiced is left at 0. ## Origin of the issue When getting the quantity invoiced for a specific Sales order, we retrieve the related invoice lines of that order using the code: https://github.com/odoo/enterprise/blob/13ca7fbc46e7c915423d80a152ecd3cfd0ac8468/sale_subscription/models/sale_order_line.py#L186-L190 The issue comes from `start_date <= l.deferred_start_date <= day_before_end_date`, as the invoices that have a deferred_start_date prior to the start_date won't be found. Only involves 17.0 __ opw-5238326