Daily updates from Odoo
Wednesday, March 4, 2026
143 changes
38 changes
Resolved issues and error corrections
This update corrects a technical issue where incoming VoIP calls weren't properly recording their creation date in the database. The fix ensures accurate tracking of all calls, improving reporting and operational efficiency. This change was implemented as a bug fix.
Original PR description
For incoming calls in VoIP, they didn't have create date written in the database becasue we were using `self.env.cr._now`. The orm `create` method uses `self.env.cr.now()`, a method, and it's working fine for outgoing calls. This commit fixes it for incoming calls and changes `_now` to `now()`. Task-5979968
This update resolves an issue where refreshing pivot tables caused unexpected behavior in related dynamic tables. The fix ensures that all dependent tables are properly invalidated during a pivot refresh, improving overall performance and stability. This change addresses a technical detail that enhances the user experience.
Original PR description
Refreshing the pivot will invalidate the datasource,which means that t dynamic table related to a pivot also needs to be invalidated. This usually occurs when we insert a new table but since [1], we create dynamic tables out of thin air. Pretty much every command that will invalidate the pivots will now need to invalidate the tables as well. [1]: https://www.odoo.com/odoo/2328/tasks/4552232 Counter-part of https://github.com/odoo/odoo/pull/250909 Task-5976773
This update resolves an issue where sample data continued to appear after creating new records in list views. The fix ensures that sample data is properly disabled when views are reloaded, providing a cleaner and more accurate display of data in the control panel. This improves the user experience by removing visual clutter.
Original PR description
Have a view (e.g. list) with no real records but sample data. In the control panel, have a button that, when clicked, creates new records which match the current filter, i.e. which are displayed…
Have a view (e.g. list) with no real records but sample data. In the control panel, have a button that, when clicked, creates new records which match the current filter, i.e. which are displayed directly in the UI. Before this commit, the new records were correctly displayed, but the sample data overlay (opacity) was still there. The problem came from the fact that the sample data are automatically disabled when the view is reloaded **from above** (typically from the WithSearch component, when the user interacts with the search view). However, in the faulty scenario, the `load` function of the model is called directly by the view itself, so we don't go through WithSearch, and the code of model.js that ensures that we leave the sample mode. We already faced that issue in pivot and graph, and we solved it locally. This commit fixes it globally, by creating a small override of model.load which leaves the sample mode. task~5980226 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines the HTML editor's paste functionality by removing redundant code. Previously, the process of moving table headers (thead) into table bodies (tbody) was duplicated. This change, implemented through a refactoring, ensures a more efficient and reliable paste experience.
Original PR description
Description of the issue/feature this PR addresses: This PR removes duplicated logic in `cleanForPaste` that moves `thead` content into `tbody`. That behavior is already handled in insert (via `before_insert_processors`), so keeping it in `cleanForPaste` was redundant. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the Odoo search bar on iOS devices (specifically with Korean keyboards) would incorrectly clear the input field during IME composition. The fix introduces a brief delay to account for iOS's temporary Backspace events triggered by the IME, ensuring the autocomplete remains open while Korean characters are typed.
Original PR description
Safari does not reliably set `KeyboardEvent.isComposing` during IME composition (e.g. Korean). As a result, the search value was processed too early and got cleared while composition was still in…
Safari does not reliably set `KeyboardEvent.isComposing` during IME composition (e.g. Korean). As a result, the search value was processed too early and got cleared while composition was still in progress. Interestingly, the issue could not be reproduced with the Japanese keyboard, which appeared to behave correctly. See [1]. This commit introduces a short delay before closing the autocomplete. On iOS, the IME temporarily triggers a Backspace event to remove the previously composed character before inserting the updated one. This Backspace incorrectly causes the autocomplete to close. With this change, we wait briefly (10ms) before closing it. If a new input event is received during that delay (corresponding to the newly composed character generated by the IME), the close action is cancelled. This ensures that the autocomplete remains open while the IME composition process completes. Steps to reproduce: - Configure a Korean keyboard on an iPhone - Open a Sale Order - Focus the search bar - Type a character, then type a second one to combine them - The search input value gets reset [1] #222151 opw-5448385 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#251141
This update resolves an issue where the admin user wasn't automatically creating an employee profile since version 19.1. The change streamlines the process when using workorder functions, directly creating an employee profile without a prior search, ensuring consistent functionality.
Original PR description
Since 19.1, the admin user doesn't have an employee profile automatically created. So we added a way to create one rapidly when using workorder functions. For that, we want to make direct use of the employee created by action_create_employee without needing to do a search. see https://github.com/odoo/enterprise/pull/107439 task 5932500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines the process of adding employees to work orders. Previously, the automatic creation of employee profiles was removed, causing issues for administrators. Now, a popup allows quick employee creation with the current user's ID pre-filled, and automatically creates an employee if none exist when editing shopfloor operators.
Original PR description
In 19.1, the automatic creation of an employee profile for the admin user has been removed. This causes issues when the admin wants to start a workorder or mark it as done, so we added a popup to create a new employee profile with the user_id already filled with the id of the current user. Also, if no employee exist when editing operators in the shopfloor, the popup proposes to directly create a new employee linked to the current user if they have HR access. This new employee will be directly logged in the shopfloor operators. see https://github.com/odoo/odoo/pull/250607 to make `action_create_employee` return an employee record. task 5932500
This update addresses a potential issue in the Swiss payroll reporting process. Specifically, it now displays a warning instead of an error when the 'AVS' (Authorized Value System) is negative, providing clearer guidance to users. This ensures accurate reporting and avoids potential disruptions to payroll calculations.
Original PR description
Forward-Port-Of: odoo/enterprise#109046
This update resolves a test failure caused by demo data interfering with the lot search functionality. We've implemented changes to ensure the test environment is clean, creating new data and avoiding conflicts with existing demo data. This ensures the test consistently passes and the lot search feature continues to function correctly.
Original PR description
The `test_lot_search_partner_ids` expects a specific number of lots/SNs to exist in the database in order to ensure its custom `partner_ids` search works correctly. Because of this, the test fails if any lot demo data is installed. Therefore we create all new locations, products, lots and add extra search domain fields to avoid loading any of these demo data. Also add in extra long partner name to avoid conflicts with overlapping demo/test partner names. runbot error: 162921 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250783 Forward-Port-Of: odoo/odoo#220777
This update corrects a technical issue where salary inputs weren't properly duplicated when creating copies of selections. Previously, this prevented accurate payslip generation. The change ensures that salary input selections are correctly copied, resolving a potential data discrepancy and improving payroll accuracy.
Original PR description
When having a salary input avaiblable for employee and payslip, and using it in an employee made it unavailable in payslips. This is unwanted behaviour and is due to the domain restricting existing_ids in employees. This was extracted from the action and is set in each separate model according to the needs. task-5909636 Forward-Port-Of: odoo/enterprise#106488
This update corrects a technical issue that could cause inconsistencies in payroll payslip data. The change ensures that all related data is synchronized correctly, preventing potential errors in payroll calculations and reporting. This improves the reliability of our payroll system.
Original PR description
Forward-Port-Of: odoo/enterprise#109112 Forward-Port-Of: odoo/enterprise#108729
This update fixes a minor inconsistency in the Documents app by ensuring that action names (like 'Vendor Bills') are dynamically set based on the type of account move being created. Previously, the action title was fixed to 'Invoices,' which wasn't always accurate. This change improves clarity and usability within the Documents app.
Original PR description
Previously, creating account moves from the Documents app opened the account.move list view with a static `Invoices` title, which was not explicit for all move types. Steps to reproduce: 1. Select suitable PDFs in Document App. 2. Click on `Vendor Bill`. 3. See the name of action (below Breadcrumbs) should be `Vendor Bills` instead of `Invoices` This fix adds and uses a mapping based on move_type to set the correct action name (e.g., Vendor Bills) after record creation. task-5983372 Forward-Port-Of: odoo/enterprise#109307 Forward-Port-Of: odoo/enterprise#109180
This update allows managers to automatically launch appraisal campaigns for all their team members, even if they don't select individuals from a list. This simplifies the process for managers and ensures all employees are included in the appraisal cycle. The change includes new tests to verify the functionality.
Original PR description
. Allow the Leader to launch an appraisal campaign for all their employees by default when no specific employees are selected in the list. task-5347755 Forward-Port-Of: odoo/enterprise#100214
This update simplifies the salary simulator by hiding temporary offers from the user interface. These offers are automatically removed after a month by a scheduled task, so this change only improves clarity and prevents user confusion. It ensures a smoother experience when using the salary configuration tool.
Original PR description
The salary simulator creates temporary offers to compute salary configurations. These offers must still exist for backend computations, as the configurator relies on them when updating results. Simulation offers are already cleaned up by a cron job after one month, so this change simply hides them from the list view to avoid user confusion. task: 5498873 Forward-Port-Of: odoo/enterprise#109241 Forward-Port-Of: odoo/enterprise#107340
This update fixes an issue where custom messages in website shop pages were being lost after saving. The change removes a cleanup process that incorrectly removed these messages during the website page save. Now, custom dropzone messages are correctly preserved after saving website pages.
Original PR description
Steps to reproduce: - Open the website shop page in edit mode. - Drag and drop a block in the shop header dropzone. - Save the page and re-enter edit mode. - Check the shop header dropzone message.…
Steps to reproduce: - Open the website shop page in edit mode. - Drag and drop a block in the shop header dropzone. - Save the page and re-enter edit mode. - Check the shop header dropzone message. => The custom message is replaced by the default one. Before this commit, `SetupEditorPlugin.cleanForSave()` removed `data-editor-message` and `data-editor-message-default` on the saved HTML clone, including custom messages defined in website templates. This cleanup was originally introduced in `web_editor` in [1]. Since the builder refactor in [2], website page saves now use the shared `html_builder` save cleanup flow and wrongly inherited that behavior, which introduced this regression in website. This commit removes that cleanup from `html_builder`, as it does not provide useful value in this save flow and drops custom dropzone messages. After this commit, custom dropzone messages are preserved after saving website pages. [1]: bab673488e185ddd7792aedecc3870663290fed3 [2]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5921283 Forward-Port-Of: odoo/odoo#251579 Forward-Port-Of: odoo/odoo#250874
This update fixes a data issue in the Danish (DK) demo company data within Odoo. Specifically, the street number was missing, which was preventing proper functionality with Nemhandel (the Danish e-commerce payment system). This ensures accurate data for testing and demonstration purposes.
Original PR description
This commit adds the street number to the DK demo company, because we need it for nemhandel. no-task Forward-Port-Of: odoo/odoo#250970
This update fixes an issue where tip and discount amounts in the Point of Sale system were not correctly formatted when using a different decimal separator. This ensures users see accurate tip and discount calculations, reducing potential confusion and improving the user experience. The change was made to align with standard decimal formatting practices.
Original PR description
Before this commit, when the decimal separator was not a dot, the amount in the tip and the discount number popup was not correctly formatted, which could lead to confusion for the user. opw-5921256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248232
This update fixes inaccuracies in the Bulgarian tax settings within the Odoo accounting system. Specifically, it corrects incorrect tax names and changes the default purchase tax rate to 20% FTC, aligning with current Bulgarian regulations. This ensures accurate tax calculations and reporting for Bulgarian businesses using the Odoo system.
Original PR description
Fixing incorrect tax names and changing the default purchase tax to 20% FTC instead of 20% PTC. task-5935754 Forward-Port-Of: odoo/odoo#251593 Forward-Port-Of: odoo/odoo#249269
This update resolves an issue where related fields within many2one chains were incorrectly displaying the wrong related model. Specifically, when two fields with the same name were used in a chain, the popover would show incorrect field options. This change ensures accurate field selection during related field creation.
Original PR description
You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if…
You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if the related model you are trying to show has a many2one with the same name as the field that was selected. Steps to reproduce 1. Create two many2one fields with studio that have the same name, one of the fields must link to the model the other field is on. i.e. `model_a.x_studio_test(relation=model_b), model_b.x_studio_test(relation=other_model)`. 2. Create a related field on model_a and click the related icon for the test field. 3. The popover will now be displaying the fields for other_model instead of model_b. Cause: This behavior was introduced by adding support for properties in this [pr](https://github.com/odoo/odoo/pull/189841). Solution: Check if `fieldDef` is a property or not in order to decide what to pass to `loadPath`. opw-ticket 5459944 Forward-Port-Of: odoo/odoo#249185
This update corrects a visual inconsistency in Odoo forms. Previously, the favorite star icon didn't match the heading font size, appearing at a smaller size. This change ensures all icons, including the favorite star, consistently align with the heading styles for a more polished and professional user experience.
Original PR description
Steps to reproduce:
Open a form with a favorite star in .oe_title (e.g. Product form). The star icon appears at body size (1rem) instead of matching the heading font size.
The <a> -> <button class="btn btn-link btn-link-inline"> refactor broke the size: .btn-link-inline sets --bs-btn-font-size to body size, so the existing .o_favorite i.fa { font-size: inherit } rule inherited 1rem from the button instead of the heading size.
Solution:
Add .o_favorite .btn to the font-size: inherit rule so the heading size cascades through the button to the icon.
opw-5998155This update corrects a bug that prevented users with RTL languages (like Arabic) from dragging and dropping content outside of designated dropzones. The fix adjusts the detection logic to account for the left-aligned sidebar in RTL layouts, ensuring proper functionality. This improves usability for a wider range of users.
Original PR description
When dropping outside a dropzone but still on the page, the code checks if the drop happened well outside of the sidebar (so on its left). However, in RTL languages, the sidebar is positioned on the left, so we need to check if the drop is on the right side of it instead. The fix checks if the sidebar is at the left edge (the body of the document should have the `o_rtl` class) and verifies the drop position is on the right of the sidebar. Steps to reproduce: - Set your profile to Arabic - Drag and drop a snippet outside of a dropzone => It's not dropped, but it should, as it would with an LTR language. task-5484936 Forward-Port-Of: odoo/odoo#251041 Forward-Port-Of: odoo/odoo#247759
This update resolves a technical issue that was causing errors in the mail composer and report generation when exporting invoices in certain UBL transactions. The fix ensures that the system doesn't attempt to access invoice date information when an invoice isn't present, preventing crashes and maintaining normal functionality.
Original PR description
### Description of the issue/feature this PR addresses: A regression in account_edi_xml_ubl_bis (_ubl_get_delivery_node_from_delivery_address) references invoice.invoice_date in the intracom delivery…
### Description of the issue/feature this PR addresses:
A regression in account_edi_xml_ubl_bis (_ubl_get_delivery_node_from_delivery_address) references invoice.invoice_date in the intracom delivery branch even when invoice is not set.
This method is also used in sale-order UBL export flows (for example during quotation PDF generation from mail.compose.message), where vals.get('invoice') can be None.
Blame points to regression introduction in commit 0bf8df7d0a096cf8fe984c42d331404d473eeb71 (FP from f6c5aed52e00e807c4879e4139b116f1bea8282e).
### Current behavior before PR:
When the flow reaches sale-order BIS3 export without an invoice in vals, Odoo crashes with:
AttributeError: 'NoneType' object has no attribute 'invoice_date'
This raises an RPC_ERROR and breaks the mail composer / send flow
### Desired behavior after PR is merged:
The intracom delivery-date override is only applied when invoice exists and has invoice_date.
If invoice is missing (sale-order export context), no crash occurs, the delivery node is still generated safely, and mail composer/report generation completes normally.
Invoice export behavior remains unchanged for valid invoice contexts.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250167This update resolves a problem where tests were failing due to incorrectly triggered event handlers. The fix ensures that test environments are properly cleaned up, preventing potential issues with resource usage and improving the stability of our core system. This change focuses on internal testing improvements.
Original PR description
Adapt tests failing due to keydown events being applied to the current active element. Community: https://github.com/odoo/odoo/pull/247137 Forward-Port-Of: odoo/enterprise#109316 Forward-Port-Of: odoo/enterprise#107286
This update resolves a technical issue within the Odoo Enterprise HR payroll module that prevented users from editing date inputs in a tour. The fix ensures the popover is displayed before the input field is cleared, restoring full functionality. This improves the user experience for payroll configuration.
Original PR description
With this additionnal step in tour, we ensure the popover is opened before clear the input. If we not wait for this, the input can be no longer editable. runbot-error-id~234440 Forward-Port-Of: odoo/enterprise#109346
This update resolves an issue where certain WebSocket routes were unintentionally causing user sessions to expire. By preventing session rotation for these specific routes, we ensure a smoother and more reliable experience for users. This improves stability and reduces potential disruptions.
Original PR description
Before this commit, calling `/websocket/peek_notifications` or `/websocket/update_bus_presence` could rotate the session. Since those routes are not called by the client, the cookie is unchanged on the client side, leading to expire sessions error later on. This commit ensure we won't rotate the sessions for those routes. opw-5445323 Forward-Port-Of: odoo/odoo#251496 Forward-Port-Of: odoo/odoo#250826
This update resolves an issue where the cash drawer wasn't opening when the cash details popup was accessed in the Italian Point of Sale (POS) system. The fix ensures that the cash drawer opens consistently, regardless of the printer type, improving the user experience for Italian POS operations. This was a simple missing function call.
Original PR description
When opening the cash details popup the cash drawer should be opened. It was not the case for the Italian fiscal printer. Steps to reproduce: ------------------- * Setup a Italian fiscal printer with cash drawer support * Open PoS * Open the cash details popup > Observation: The cash drawer does not open * Try to close the PoS session * Open the cash details popup > Observation: The cash drawer opens Why the fix: ------------ The cash drawer opening function was simply not called opw-5391094 Forward-Port-Of: odoo/enterprise#109155 Forward-Port-Of: odoo/enterprise#107987
This update fixes an issue where time formatting in reports and lists was inaccurate, consistently flooring the time value. The changes ensure time is rounded correctly based on its precision and allows for more flexible formatting options, including controlling the display of seconds.
Original PR description
The rounding of time was not correct. I was always flooring, but before the new duration the rounding was depending of the precision of the duration. The rounding has been restored as before and put…
The rounding of time was not correct. I was always flooring, but before the new duration the rounding was depending of the precision of the duration. The rounding has been restored as before and put in formatDuration. formatFloatTime has been modified to use formatDuration and now take the same options (specify the unit of time of the value). The graph view and list view didn't extract the otpions from the fields with widget. Now, they get the options and give them to the formatter. The widget was showing the seconds by default, but it doesn't match with the behavior of the DateTime widget. It has been changed and now the seconds are shown only if the options 'showSeconds' is true and it's false by default. The impacted views has been restored as before the original commit. The options of float_time widget couldn't take falsy values, now it can. an improvment has also been done: the popover on the float_time widget doesn't show up if the input value and the formattedValue are the same. followup of TASK-5347051 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug that prevented users from creating new resources within appointment bookings. The issue stemmed from an incorrect default value being set for the resource timezone, triggering a validation error. The fix ensures a proper timezone is assigned, preventing this error and improving the appointment booking process.
Original PR description
Steps to reproduce =============== 1. Open appointment of resource type 2. Create a new resource from resource tags. 3. Give the resource a name and save. ----> ValidationError will be shown. Issue…
Steps to reproduce =============== 1. Open appointment of resource type 2. Create a new resource from resource tags. 3. Give the resource a name and save. ----> ValidationError will be shown. Issue ===== When creating the new resource from the appointment form view, the value for the `tz` of the `appointment.resource` is `False`. Also, `tz` field is inherited from `resource.mixin` and is a related field as `resource_id.tz`. Therefore, when creating the `appointment.resource` with `tz` as `False` writes the related `resource.resource`'s `tz` field. As `tz` field is required field for the `resource.resource` table, the `ValidationError` is raised. Solution ======= After this commit, we give the default value to the timezone with fallback to current user's timezone or UTC which matches to the default value of `resource.resource`'s timezone field but with a side-effect of overwriting resource's timezone if somehow `default_resource_id` is provided. We also fix in parallel by making the timezone field `readonly` when invisible to avoid "saving" the `False` value for the tz. Task-5712786
This update resolves a technical issue preventing users from correctly selecting a cashier when opening the Point of Sale (POS) system. The problem stemmed from a renaming of a variable without corresponding updates, causing an error. This fix restores the original variable name, ensuring proper POS functionality.
Original PR description
Since this commit: https://github.com/odoo/enterprise/commit/52e2f216528bcb0e67844ac2164f647fee4a2a95 The clockState variable was renamed without modifying the other references. This causes a traceback when trying to select a cashier while opening the POS. This has now been fixed by restoring the previous variable name. Forward-Port-Of: odoo/enterprise#108665
This update fixes an issue where the 'Request Signature' option wasn't consistently appearing on form views, specifically within Timesheets and Projects. The change ensures the menu item only shows when a chatter is present, improving the user experience and ensuring all users can access this important feature.
Original PR description
****Behavior:**** **Current:** When selecting the cog menu on certain forms, the request signature item doesn't always show even though it should. The expected behavior of this menu item is to appear only on form views with a chatter, but the way the chatter's presence was verified is inconsistent. **Solution:** On form views with a chatter, we can check its presence directly from the viewArch using the selector from the compiler registry. **Steps to reproduce:** From Timesheets: - Go to Timesheets - Open a task - The cog menu will not contain "Request Signature" From Project: - Go to Project - Select a project and open a task - The cog menu will contain "Request Signature" opw-4817423 Forward-Port-Of: odoo/enterprise#109274 Forward-Port-Of: odoo/enterprise#97401
This update ensures that disabled user records are no longer incorrectly flagged as blacklisted when checking email communication. This prevents potential issues with email delivery for users who have been deactivated in the system. The change was made to address a previous bug and includes new tests for verification.
Original PR description
Same as https://github.com/odoo/odoo/pull/249466, but for v17 and with tests. > When computing wether the user is blacklisted, disabled records must be ignored. > > https://www.loom.com/share/41ea437477f8416f8b50f9ef979d82bf > > > --- > I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr > > @moduon MT-13153 OPW-5952301 Forward-Port-Of: odoo/odoo#250361
This update corrects a bug where internal users receiving ‘Signed Document’ emails were incorrectly directed to the public portal. Now, internal users automatically see the document preview, while the existing portal redirection for public users remains unchanged. This ensures a consistent and correct experience for all users.
Original PR description
Internal users opening the “Signed Document” email link were redirected to the portal instead of the document preview. Now they are redirected to the internal preview, while public users remain unchanged. task-5486043 Forward-Port-Of: odoo/enterprise#107079
This change corrects a display issue where upsell sale orders created from subscriptions incorrectly showed as "Quotation" in the preview. The fix ensures that upsell orders now display as standard sales orders, aligning with the presentation of the initial subscription. This improves clarity and consistency for users.
Original PR description
## Issue When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate. <img width="1330" height="296" alt="5489970"…
## Issue
When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate.
<img width="1330" height="296" alt="5489970" src="https://github.com/user-attachments/assets/cfff4c7a-fff7-4859-861b-c190dab9097d" />
## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a Subscription S00001
- Any Customer
- Any Recurring Plan
- Any Product
3. Create and confirm the invoice for the subscription S00001
4. On the subscription S, click Upsell and confirm the resulting Sale Order S00002
5. On the Sale Order S00002, click Preview
6. **The title of the Sale Order is "Quotation - S000002". In the sale.order list view, the Sale Order is shown as a Sales order, just like the initial Subscription.**
## Cause
The title shown in the preview is defined here:
https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/sale_subscription/views/sale_subscription_portal_templates.xml#L187-L195
The initial subscription falls into the `if` condition, which only shows the name of the SO. The upsell sale order is not considered as a subscription, as explained and showed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
The word *"Quotation"* shown in the preview is the `sale_order.type_name`", computed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L227-L237
The term "Quotation" was chosen in https://github.com/odoo/enterprise/commit/14e5cff65affa888f33d4008d10a32e6992d3a39.
## Fix
Before this commit, an upsell would always be named *"Quotation"*. With this commit, upsells are now added to the `other_orders` variable in `_compute_type_name` and follow the same logic as other SO:
https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/sale/models/sale_order.py#L797-L803
<img width="1316" height="308" alt="5479900_2" src="https://github.com/user-attachments/assets/7cfeb578-2870-43a6-a48b-ba0898718641" />
## Alternative
An alternative to this fix would be to update the condition used to display the name of the subscription in the preview (cf. first code snippet). This would probably result in removing the `sale_order.is_subscription` from the condition, as it is the part of the condition that upsell SOs do not meet.
opw-5489970
Forward-Port-Of: odoo/enterprise#109268
Forward-Port-Of: odoo/enterprise#106767This update resolves an issue where stock users with 'Own Documents Only' sales access were unable to open delivery orders. The fix avoids unnecessary access restrictions by computing the delivery description directly, rather than relying on complex rule configurations. This ensures stock users can perform their tasks without encountering access errors.
Original PR description
### Steps to reproduce: - Create a Stock User with access rights: - Sales: User: Own Documents Only - Inventory: User - With your admin: Create and confirm a sale order for 1 x a consumable. - With…
### Steps to reproduce:
- Create a Stock User with access rights:
- Sales: User: Own Documents Only
- Inventory: User
- With your admin: Create and confirm a sale order for 1 x a consumable.
- With the Stock User open try to open the delivery
#### > Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.
### Cause of the issue:
Sale users `Own Documents Only` are granted read access to the `sale.order` model which is restricted to the `sale.order`'s to which they are the designated sale person or no-one is due to this `ir.rule`: https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale/security/ir_rules.xml#L44-L49 However, the read access of the sale order related to a stock move is required in order to compute its desciption:
https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale_stock/models/stock.py#L26-L31 While this access is suppose to be provided:
https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale_stock/security/ir.model.access.csv#L5 It is overriden by the `ir.rule`.
### Fix:
Since the `_compute_description` overrides rely on numerous independant models such as the `sale.order`, `purchase.order.line`, `product.supplierinfo`, `mrp.bom`, since the `picking_description` does not really carries sensitive informations and since parts of the computes already required to be put in `sudo` for similar reasons see 80c80505fabc4544e41f270169737218e47cad5a, it is preferable to compute the field in sudo rather than adding an `ir.rule` with true leaf on the `sale.order` model for the `stock.group_stock_user`.
opw-5929485
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251471This update fixes an issue where users would need to refresh the application after installing a new language. The change clears all application caches when a language is installed, ensuring the new language is immediately available in the user preference settings. This provides a smoother and more intuitive experience for users.
Original PR description
Before this commit, after installing a new language, that language wasn't directly available in the selection field of the user preference form view. An extra reload was necessary to see the new language, which could confuse the user. This was due to the cache. As installing a language isn't a frequent operation, we simply clear all caches when this happens. task~5895416 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#251729
This update fixes an issue where long email addresses in the Point of Sale partner list were difficult to read due to awkward wrapping and inconsistent alignment. The changes include truncating long emails and adding a hover-over feature to display the full email address, ensuring a cleaner and more user-friendly experience.
Original PR description
Before this commit, long email addresses in the POS partner list would wrap awkwardly or expand the row height excessively, making the list difficult to read. Additionally, the vertical alignment between the text and the action buttons was inconsistent. This commit improves the Partner List UI by: - Truncating long email addresses - Adding a `title` attribute so the full email is visible on hover - Vertically centering all cell content to match the buttons. opw-5919153 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247964
This update resolves an issue preventing users from modifying rounded corner settings in the website editor when using themes with unitless '0' values for border-radius. The fix ensures the editor correctly handles these values, allowing for seamless customization of rounded corners across different themes. This improves the user experience and flexibility of theme customization.
Original PR description
**Problem:** When using themes that define border-radius as unitless `0` (e.g., Anelusia theme) and attempting to modify the "Rounded Corners" value of any element through the website editor, the…
**Problem:**
When using themes that define border-radius as unitless `0` (e.g., Anelusia theme) and attempting to modify the "Rounded Corners" value of any element through the website editor, the following error occurs: "Cannot convert 'px' units into '' units !"
**Steps to reproduce:**
1. Install and activate the Anelusia theme (or any theme with unitless border-radius: 0)
2. Open the website editor
3. Select any element (e.g., a table in the footer)
4. Try to change the "Rounded Corners" field to any non-zero value
5. Observe the error: "Uncaught Promise > Cannot convert 'px' units into '' units !"
**Current behavior:**
The website editor throws a JavaScript error and prevents changing rounded corners.
**Expected behavior:**
Users should be able to modify rounded corners values without errors, regardless of whether the theme uses unitless or unit-based zero values.
**Cause of the issue:**
Some themes define border-radius variables as unitless `0` (e.g., `$border-radius: 0`). When the website editor's areCssValuesEqual() function in utils_css.js compares the new value (e.g., "10px") with the existing computed value ("0" - unitless), it attempts to convert between units. The getNumericAndUnit() function extracts the unit from "0" as an empty string "", then convertValueToUnit() tries to convert "10px" to "" unit. Since there's no conversion defined for "px" to "" (empty unit), convertNumericToUnit() throws the error.
**Fix:**
Add a special case in areCssValuesEqual() to handle unitless zero values before attempting unit conversion. When the first value is unitless "0", we compare the numeric values directly using Number.EPSILON, avoiding the unit conversion entirely. This allows proper comparison between unitless "0" and values like "10px" or "0px" without errors, while maintaining correct equality checks (0 equals 0px, but 0 does not equal 10px).
opw-5412414
Forward-Port-Of: odoo/odoo#246335This update resolves an issue where the Sendcloud shipping API required a minimum product weight of 0.00099. This commit ensures that product weights are always at least 0.001, preventing errors and ensuring accurate shipping calculations through the Sendcloud integration. It's a necessary adjustment to maintain reliable delivery processing.
Original PR description
The Sendcloud API do not allow parcel details to have a weight value less than 0.00099 . This commit makes sure the products weights are at least 0.001. ref: <img width="1850" height="689" alt="image" src="https://github.com/user-attachments/assets/10242315-3c4d-4670-b77d-8cb429e00891" /> Forward-Port-Of: odoo/enterprise#107676
16 changes
Resolved issues and error corrections
This update corrects a minor issue in the Documents app where the action title wasn't consistently accurate for different types of account moves. Now, when creating account moves from the Documents app, the action name (like 'Vendor Bills') correctly reflects the move type, improving clarity and usability for users.
Original PR description
Previously, creating account moves from the Documents app opened the account.move list view with a static `Invoices` title, which was not explicit for all move types. Steps to reproduce: 1. Select suitable PDFs in Document App. 2. Click on `Vendor Bill`. 3. See the name of action (below Breadcrumbs) should be `Vendor Bills` instead of `Invoices` This fix adds and uses a mapping based on move_type to set the correct action name (e.g., Vendor Bills) after record creation. task-5983372 Forward-Port-Of: odoo/enterprise#109307 Forward-Port-Of: odoo/enterprise#109180
This update allows managers to automatically launch appraisal campaigns for all their team members, even if they don't select individuals from a list. This simplifies the process for managers and ensures all employees are included in the appraisal cycle. The change includes new tests to verify the functionality.
Original PR description
. Allow the Leader to launch an appraisal campaign for all their employees by default when no specific employees are selected in the list. task-5347755 Forward-Port-Of: odoo/enterprise#100214
This update fixes an issue where flexible resources were incorrectly displaying a total of 40 hours per week. The fix ensures that the system now accurately reflects the employee's scheduled hours (38 hours) when calculating available time. This improves the accuracy of scheduling and resource allocation.
Original PR description
### Steps to reproduce: - Download Planning app - From the employees app, create an employee - Assign that employee a new schedule that is 'Flexible', has 07:36 hours/day 'Avg', and has 'Total' 38 hours/week - Search for that employee in the planning app and hover over their name ### Cause of Issue: The total available hours for that employee show as 40h. This is because when calculating the hours per week for the resource, the resource's schedule is not taken into account but the company's. ### Fix: Add the hours per week for the resource's calendar (if available) in the calculation opw-5954982 Forward-Port-Of: odoo/odoo#250185
This update fixes an issue where resource scheduling wasn't accurately calculating working hours when using full-day periods. The system now calculates the midpoint between start and end times, ensuring correct representation of half-day schedules. This improves the accuracy of resource availability and time tracking.
Original PR description
### Steps to reproduce: - Go to any working schedule of an employee. - Add a working hour line for any day and choose day period as full day. - Change work from 10:00, and work to 18:00. ### Issue: - Resource was explicitly setting 12 if any hour_from/hour_to was missing. - Resource always consider that the working time is 8AM-5PM. ### Fix: - We will calculate the avg of working hours( hour_from + hour_to)/2 - Doing this we will always get the middle of day. task: 5912748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247756
This update fixes a data issue in the Danish (DK) demo company data within Odoo. Specifically, the street number was missing, which was required for proper integration with Nemhandel (the Danish e-commerce platform). This ensures accurate reporting and functionality for users working with the DK demo environment.
Original PR description
This commit adds the street number to the DK demo company, because we need it for nemhandel. no-task Forward-Port-Of: odoo/odoo#250970
This update fixes inaccuracies in the Bulgarian tax settings within the Odoo accounting system. Specifically, it corrects incorrect tax names and changes the default purchase tax rate to 20% FTC, aligning with current Bulgarian regulations. This ensures accurate tax calculations and compliance for Bulgarian businesses using Odoo.
Original PR description
Fixing incorrect tax names and changing the default purchase tax to 20% FTC instead of 20% PTC. task-5935754 Forward-Port-Of: odoo/odoo#251593 Forward-Port-Of: odoo/odoo#249269
This update corrects a bug where related fields within many2one chains were displaying the wrong model data. Specifically, when creating a chain with duplicate field names, the popover would incorrectly show fields from a different model. This issue was caused by a recent update to support properties in field definitions.
Original PR description
You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if…
You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if the related model you are trying to show has a many2one with the same name as the field that was selected. Steps to reproduce 1. Create two many2one fields with studio that have the same name, one of the fields must link to the model the other field is on. i.e. `model_a.x_studio_test(relation=model_b), model_b.x_studio_test(relation=other_model)`. 2. Create a related field on model_a and click the related icon for the test field. 3. The popover will now be displaying the fields for other_model instead of model_b. Cause: This behavior was introduced by adding support for properties in this [pr](https://github.com/odoo/odoo/pull/189841). Solution: Check if `fieldDef` is a property or not in order to decide what to pass to `loadPath`. opw-ticket 5459944 Forward-Port-Of: odoo/odoo#249185
This update resolves a minor visual issue with the select menu in Odoo, specifically addressing styling inconsistencies when scrolling. The fix ensures a consistent and polished appearance for the select menu across the base and base_import modules. This improves the overall user experience.
Original PR description
Before this commit, the select menu with its dropdown opened had a little style issue when scrolling base_import's select menu had also a style which was a bit off. After this commit, those are fixed part-of-task-5935511 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a minor display issue in the accounting dashboard where the 'Reconnect Bank' button incorrectly appeared for accounts without an expiration date. The fix ensures the button only shows when a valid numerical expiration date is present, improving the user experience.
Original PR description
The aim of this commit is fixing the behavior of Reconnect bank button in accounting dashboard. Before this commit, a synchronization without any expiring date will always show the Reconnect bank button in the accounting dashboard because the expiring due days (in the JS widget) is null and not undefined. This condition led to check the second part of the condition where null <= 0. Which is true in javascript. Now, we are checking the type of expiring due days as first condition, if it's not a number, we don't check the second part of the condition, and then we don't display the Reconnect Bank button. no task id
This update corrects a test case in the quality control module to reflect a recent change in how Odoo handles merging stock transfers. Specifically, transfers now only merge into existing ones when a 'stock reference' is defined. This ensures the test case accurately reflects the current system behavior and avoids potential issues.
Original PR description
Fix the test case to align with the updated picking move merge behavior, where the next transfer merges into an existing one only when a stock reference is set TaskID-5242340 Forward-Port-Of: odoo/enterprise#108520 Forward-Port-Of: odoo/enterprise#99342
This update corrects a bug that prevented drag-and-drop functionality when using Arabic or other RTL languages. The fix adjusts the detection logic to properly identify drops outside of the sidebar, ensuring a consistent user experience regardless of language settings. This improves usability for a wider range of users.
Original PR description
When dropping outside a dropzone but still on the page, the code checks if the drop happened well outside of the sidebar (so on its left). However, in RTL languages, the sidebar is positioned on the left, so we need to check if the drop is on the right side of it instead. The fix checks if the sidebar is at the left edge (the body of the document should have the `o_rtl` class) and verifies the drop position is on the right of the sidebar. Steps to reproduce: - Set your profile to Arabic - Drag and drop a snippet outside of a dropzone => It's not dropped, but it should, as it would with an LTR language. task-5484936 Forward-Port-Of: odoo/odoo#251041 Forward-Port-Of: odoo/odoo#247759
This update resolves an issue where US-specific reports were incorrectly appearing in Odoo databases configured for India. The fix ensures that the necessary US Payroll module is automatically installed when the l10n_in_hr_payroll module is installed, preventing this unintended report visibility.
Original PR description
**Version:** saas-19.1 **Steps to reproduce:** - Create a new database with India as country. - Install l10n_in_hr_payroll. - US company based reports are visible. **Issue:** Reports specific to us payroll localisation are visible for base hr_payroll module **Cause:** The l10n_us module was missing as the auto_install dependency. **Solution:** Added l10n_us as the auto_install dependency in the manifest file. **task-5948747**
This update resolves a technical error that prevented users from hearing incoming ringtones during VoIP calls. The fix ensures the necessary service is correctly initialized, allowing ringtones to play as expected. This improves the user experience for VoIP calls.
Original PR description
requestIncomingRingtone() was calling this.ringtoneService.incoming.play(), but ringtoneService is not defined on UserAgent, leading to: ``` TypeError: Cannot read properties of undefined (reading 'incoming') when handling VOIP:PLAY_INCOMING. ```
This update resolves an issue preventing multiple tax lines on Italian invoices processed through the l10n_it_edi_doi module. Previously, only the DOI tax could be applied. Now, other taxes like Enasarco and RIT can be added to the same line, aligning with Italian tax regulations. This ensures accurate invoice processing for Italian businesses.
Original PR description
We should be able to add more taxes with the 0% on the same line, like the Enasarco and 23% RIT. Indeed in italy it is possible to have invoices with Dichiarazione d'intento togheter with a withholding and Enasarco taxes. See also: odoo/odoo#236251 Ticket [link](https://www.odoo.com/odoo/project.task/5933699) opw-5933699 Forward-Port-Of: odoo/odoo#248586
This update resolves a technical issue within the Odoo Enterprise HR payroll module that prevented users from editing date inputs in a specific form view. The fix ensures the popover is displayed before the input is cleared, restoring full editability. This improves the user experience for payroll processing.
Original PR description
With this additionnal step in tour, we ensure the popover is opened before clear the input. If we not wait for this, the input can be no longer editable. runbot-error-id~234440 Forward-Port-Of: odoo/enterprise#109346
This update resolves an issue where vendor bills from foreign VAT companies were not correctly identifying their country of origin. The fix adds the necessary country code to the beginning of the invoice data, ensuring accurate reporting for JPK (Polish VAT reporting).
Original PR description
PR #81359 fixed the country code for foreign VAT companies by adding the country code to the start. However, this was only fixed for invoices going out, not vendor bills coming in. [opw-5917264](https://www.odoo.com/odoo/project.task/5917264) Forward-Port-Of: odoo/enterprise#109080
4 changes
Resolved issues and error corrections
This update ensures self-order transactions in the Odoo Enterprise system now adhere to the same data validation rules as standard point-of-sale orders. This enhances data accuracy and reliability, reducing potential errors and improving the overall transaction process. It addresses a previous issue related to inconsistent validation.
Original PR description
This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order. Forward-Port-Of: odoo/enterprise#109167 Forward-Port-Of: odoo/enterprise#108538
This update resolves a problem with the generation of CSV reports for Peru-specific accounting modules. The issue stemmed from incompatible CSV formatting settings within the Odoo system, specifically related to Python 3.13. The fix ensures reports are generated correctly and efficiently.
Original PR description
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises ValueError: bad delimiter or lineterminator value This is due to…
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises
ValueError: bad delimiter or lineterminator value
This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:
> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.
so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.
Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.
https://runbot.odoo.com/odoo/error/240950
Forward-Port-Of: odoo/enterprise#109081This update resolves an issue preventing power buttons from appearing in Odoo Studio reports. The fix defines a key configuration element within Studio's interface, ensuring proper functionality and report customization. It also addresses a previous issue with table menu positioning within Studio.
Original PR description
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu position calculation when the table cell is inside an iframe. Also Before localOverlayContainers was not defined in studio, so power buttons did not appear in studio reports. Now that localOverlayContainers is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250503 Forward-Port-Of: https://github.com/odoo/enterprise/pull/108724
This update ensures that Website Studio's translation features only apply to views within the Website module, preventing incorrect translations from other websites. The change corrects a bug where the default language of the first website was being used, improving the accuracy of translations within the Studio interface. This ensures a more reliable and consistent experience for users working with Website content.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/enterprise#108199 Forward-Port-Of: odoo/enterprise#107459
12 changes
Resolved issues and error corrections
This update fixes a minor issue where a warning about leaving a chatbot conversation was displayed even after the conversation had already ended. Now, the warning only appears when a chatbot conversation is actively in progress, creating a smoother and less disruptive user experience for customers interacting with the chatbot.
Original PR description
Before this commit: When a user finishes a chatbot script and the conversation is already ended, clicking on close / continue still triggers the leave conversation warning. After this commit: The leave conversation warning is no longer shown when the chatbot conversation is already closed or ended. The warning is only shown for active conversations. [Task-5882084](https://www.odoo.com/odoo/project/1519/tasks/5882084) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251335 Forward-Port-Of: odoo/odoo#247918
This update fixes a minor issue where the dynamic snippet carousel wasn't displaying correctly when showing a small number of items. The fix ensures a smoother, more consistent scrolling experience, especially with limited product data. It optimizes how the carousel handles data presentation for better performance.
Original PR description
Steps to reproduce: 1. Add a Dynamic Snippet Carousel(Products). 2. Set the number of records to 4. 3. Enable Single Scroll mode. Issue: When a dynamic snippet carousel is in single scroll mode (`o_carousel_multi_items`) and the number of fetched items is less than or equal to the visible slots per slide (`chunkSize`, typically 4 on desktop), the carousel still slides one item at a time. Cause: When `scrollMode` is single, the QWeb template generates each data item in its own `carousel-item` div. So with 3 products and 4 visible slots, we got 3 separate slides(this is the usual behavior of single scroll mode). But due to this bootstrap would slide between them one by one. Fix: If the number of fetched records is less than or equal to the number of elements per slide (chunkSize), use "all" scroll mode so that all items are grouped in a single slide instead of being split into individual carousel-items (which would cause unwanted sliding).
This update fixes a potential issue where VIES validation errors caused errors in Odoo, specifically impacting OCR invoice processing. By catching a broader range of exceptions from the VIES service, the system is now more resilient to invalid XML responses and prevents errors from propagating.
Original PR description
Catch all `zeep` exceptions instead of only `zeep.Fault`. On 14th of February 2026, the VIES service wasn't working properly, they were returning invalid XML in their response. This caused the `check_vies` call to raise a `zeep.XMLSyntaxError` which wasn't caught, causing a traceback every time VIES was used to validate a VAT number. opw-5938723 (OCR couldn't be refreshed on an invoice because it tried to create a partner from its VAT number and it couldn't be checked with VIES). Forward-Port-Of: odoo/odoo#249853
This update expands the color field options within the Odoo Gantt editor, allowing users to select all integer fields for color customization. Previously, the color field was limited to fields already present in the view. This change provides greater flexibility for visualizing project timelines and tasks.
Original PR description
Before this commit, only fields already present in the view were selectable for the color field in the gantt editor. After this commit, all int fields of the model are available task-5981029
This update adds the street number to the demo company data for Denmark (l10n_dk). This is necessary to ensure accurate reporting and integration with nemhandel, a key payment processing system, improving the demo data's realism and usefulness for testing and demonstration.
Original PR description
This commit adds the street number to the DK demo company, because we need it for nemhandel. no-task Forward-Port-Of: odoo/odoo#250970
This update fixes an issue where credit notes incorrectly rounded prices, leading to discrepancies in accounting. The change ensures that credit notes accurately reflect the original purchase price, regardless of rounding settings. This improves financial accuracy and reduces potential errors.
Original PR description
**Steps to reproduce:** - Setup a rounding of 0.05 - Add it to the PoS settings, turn on the only for cash setting - Make a purchase for 13.01, pay by card - Go to the backend, we have the correct price of 13.01 - Revert the invoice by making a credit note - The price is only 13.00 and we have a rounding of -0.01 **Why the fix:** When making a credit note, we round the price if we find a rounding method, not taking the **only_round_cash_method** setting into account. After this commit, we now check if the reversed entry (the invoice) has a rounding line. If it does not, we skip the rounding. If a rounding is found on the reversed entry, we still round the current account move. opw-5871514 Forward-Port-Of: odoo/odoo#249894 Forward-Port-Of: odoo/odoo#247617
This update resolves an issue preventing multiple tax lines (like Enasarco and RIT) from being added to Italian invoices within the Odoo system. Previously, only the DOI tax could be listed on a single line. This change aligns with Italian tax regulations, allowing for more accurate invoice processing and reporting.
Original PR description
We should be able to add more taxes with the 0% on the same line, like the Enasarco and 23% RIT. Indeed in italy it is possible to have invoices with Dichiarazione d'intento togheter with a withholding and Enasarco taxes. See also: odoo/odoo#236251 Ticket [link](https://www.odoo.com/odoo/project.task/5933699) opw-5933699 Forward-Port-Of: odoo/odoo#248586
A test failure related to invoice data formatting was resolved. The update ensures the correct data structure is used when generating electronic invoices, preventing potential errors and improving the reliability of the export process. This fix addresses a technical issue that could have impacted invoice generation.
Original PR description
In the `test_which_service_to_call` test, we are calling `_call_web_service_before_invoice_pdf_render` with invoice_data. But invoice_data is just a dict with `invoice.read()` and the extra key extra_edis. Instead of manually building invoice_data, we should call `_get_default_sending_settings`, which is meant to be used in the base `account.move.send` flow. Why this fix? Because by not calling `_get_default_sending_settings`, we risk changing the expected invoice_data format used in `_call_web_service_before_invoice_pdf_render`, which could lead to KeyErrors. Spotted while developing https://github.com/odoo/enterprise/pull/80590, the test failed, raising the ['invoice_edi_format'] key error. no-task Forward-Port-Of: odoo/odoo#232105
This change ensures that the Website Studio XML editor only uses translated views for websites, preventing incorrect translations from being displayed. The update modifies how the Studio editor retrieves related views, specifically targeting the Website module to improve the user experience and avoid unintended translation behavior.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. This is done here by adding a context flag, as to not interfere with customizations made in stable versions. This will be changed for master. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/odoo#249938 Forward-Port-Of: odoo/odoo#237000
This update ensures that the Website Studio XML editor correctly uses translations only for the specific website being edited. Previously, it incorrectly defaulted to translations for the first website in the database, leading to potential inconsistencies. This fix improves the accuracy of translations within the Studio environment.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/enterprise#108199 Forward-Port-Of: odoo/enterprise#107459
This update ensures that disabled user accounts are no longer incorrectly flagged as blacklisted when checking email restrictions. This change improves the accuracy of email delivery and prevents potential issues for users who have been deactivated. The fix was originally reported and addressed in a previous pull request.
Original PR description
Same as https://github.com/odoo/odoo/pull/249466, but for v17 and with tests. > When computing wether the user is blacklisted, disabled records must be ignored. > > https://www.loom.com/share/41ea437477f8416f8b50f9ef979d82bf > > > --- > I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr > > @moduon MT-13153 OPW-5952301 Forward-Port-Of: odoo/odoo#250361
This update corrects a display issue where upsell sale orders created from subscriptions were incorrectly labeled as "Quotation". The fix ensures that upsell orders now display as standard sales orders, aligning with the naming convention for initial subscriptions. This improves clarity and consistency for users.
Original PR description
## Issue When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate. <img width="1330" height="296" alt="5489970"…
## Issue
When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate.
<img width="1330" height="296" alt="5489970" src="https://github.com/user-attachments/assets/cfff4c7a-fff7-4859-861b-c190dab9097d" />
## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a Subscription S00001
- Any Customer
- Any Recurring Plan
- Any Product
3. Create and confirm the invoice for the subscription S00001
4. On the subscription S, click Upsell and confirm the resulting Sale Order S00002
5. On the Sale Order S00002, click Preview
6. **The title of the Sale Order is "Quotation - S000002". In the sale.order list view, the Sale Order is shown as a Sales order, just like the initial Subscription.**
## Cause
The title shown in the preview is defined here:
https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/sale_subscription/views/sale_subscription_portal_templates.xml#L187-L195
The initial subscription falls into the `if` condition, which only shows the name of the SO. The upsell sale order is not considered as a subscription, as explained and showed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
The word *"Quotation"* shown in the preview is the `sale_order.type_name`", computed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L227-L237
The term "Quotation" was chosen in https://github.com/odoo/enterprise/commit/14e5cff65affa888f33d4008d10a32e6992d3a39.
## Fix
Before this commit, an upsell would always be named *"Quotation"*. With this commit, upsells are now added to the `other_orders` variable in `_compute_type_name` and follow the same logic as other SO:
https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/sale/models/sale_order.py#L797-L803
<img width="1316" height="308" alt="5479900_2" src="https://github.com/user-attachments/assets/7cfeb578-2870-43a6-a48b-ba0898718641" />
## Alternative
An alternative to this fix would be to update the condition used to display the name of the subscription in the preview (cf. first code snippet). This would probably result in removing the `sale_order.is_subscription` from the condition, as it is the part of the condition that upsell SOs do not meet.
opw-5489970
Forward-Port-Of: odoo/enterprise#109268
Forward-Port-Of: odoo/enterprise#1067673 changes
Resolved issues and error corrections
This update corrects a problem with how Odoo generates CSV reports for Peruvian accounting modules. The fix addresses an incompatibility with a recent Python update, ensuring reports are created correctly. Removing redundant configuration steps improves efficiency and stability.
Original PR description
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises ValueError: bad delimiter or lineterminator value This is due to…
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises
ValueError: bad delimiter or lineterminator value
This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:
> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.
so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.
Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.
https://runbot.odoo.com/odoo/error/240950
Forward-Port-Of: odoo/enterprise#109081This update fixes an issue where tax reports were generating negative values for carried over tax lines (-81, -82, etc.). This ensures accurate tax reporting and avoids potential discrepancies in financial data. The change was triggered by a bug report and related internal tracking.
Original PR description
When generating the xml for tax report, negative values should not be present in the xml for carried over lines (81, 82, 83, 86, 87, and 88) Steps: - Create a RBILL for today - 1 month, add an invoice line with tax using one of the following tags: -81, -82, -83, -86, -87 or -88 in its base refund repartition line - Open the tax report on the month of the RBILL - Generate the xml, either by the dedicated button, or by creating and posting the closing entry -> there is line(s) for negative amounts opw-5955323 opw-5428395 Forward-Port-Of: odoo/enterprise#109229 Forward-Port-Of: odoo/enterprise#108916
This update resolves an issue where documents couldn't be opened after their names were changed. The fix corrects a technical error in the document management system, ensuring documents can now be reliably opened even after being renamed. This improves the overall usability of the documents feature.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Open a document in full screen and click on info icon on top right 3. Edit the name and close full screen document and chatter 4. Try to open the same document Issue: - Traceback occures `TypeError: Cannot read properties of undefined (reading 'insert')` Cause: - In file document_service `this.store.Attachment` was used instead of `this.store["ir.attachment"]` After this commit https://github.com/odoo/odoo/commit/70153559c34ffd18c67b83c39ee397ecb0a90b4a we renamed the Attachment model opw-5483625
10 changes
Resolved issues and error corrections
This update corrects a minor issue in the Documents app where action names weren't consistently reflecting the type of account move being created. Specifically, 'Invoices' was used regardless of the document type. The fix now uses the account move type to display the correct action name (e.g., 'Vendor Bills'), improving clarity and usability.
Original PR description
Previously, creating account moves from the Documents app opened the account.move list view with a static `Invoices` title, which was not explicit for all move types. Steps to reproduce: 1. Select suitable PDFs in Document App. 2. Click on `Vendor Bill`. 3. See the name of action (below Breadcrumbs) should be `Vendor Bills` instead of `Invoices` This fix adds and uses a mapping based on move_type to set the correct action name (e.g., Vendor Bills) after record creation. task-5983372 Forward-Port-Of: odoo/enterprise#109307 Forward-Port-Of: odoo/enterprise#109180
This update corrects a technical issue where incoming VoIP calls weren't properly recording their creation date in the database. The fix ensures accurate tracking of call start times, improving reporting and analysis of VoIP activity. This change impacts the VoIP module.
Original PR description
For incoming calls in VoIP, they didn't have create date written in the database becasue we were using `self.env.cr._now`. The orm `create` method uses `self.env.cr.now()`, a method, and it's working fine for outgoing calls. This commit fixes it for incoming calls and changes `_now` to `now()`. Task-5979968 Forward-Port-Of: odoo/enterprise#109041
This update simplifies the salary simulator by hiding temporary offers from the user interface. These offers are automatically deleted after a month by a scheduled process, so this change prevents confusion for users while ensuring the underlying salary calculations remain accurate.
Original PR description
The salary simulator creates temporary offers to compute salary configurations. These offers must still exist for backend computations, as the configurator relies on them when updating results. Simulation offers are already cleaned up by a cron job after one month, so this change simply hides them from the list view to avoid user confusion. task: 5498873 Forward-Port-Of: odoo/enterprise#109329 Forward-Port-Of: odoo/enterprise#107340
This update corrects a minor issue preventing users from editing date input fields within the HR payroll module. The change ensures the relevant popover is displayed before the input field is cleared, restoring full functionality. This resolves a temporary disruption to payroll processing.
Original PR description
With this additionnal step in tour, we ensure the popover is opened before clear the input. If we not wait for this, the input can be no longer editable. runbot-error-id~234440 Forward-Port-Of: odoo/enterprise#109346
This update corrects a technical issue within the Odoo Enterprise payroll module that could cause inconsistencies between payslip data. The fix ensures that all payroll line codes are synchronized, preventing potential errors in payroll calculations and reporting. This improves the accuracy and reliability of payroll processing.
Original PR description
Forward-Port-Of: odoo/enterprise#109280 Forward-Port-Of: odoo/enterprise#108729
This update fixes a minor issue in the Gantt chart's date selection tool. Previously, date labels didn't update immediately when a new range was chosen. Now, the UI provides instant visual feedback as you select dates, leading to a smoother and more responsive user experience. This ensures accurate date selection and reduces potential confusion.
Original PR description
This PR improves the user experience of the Gantt Scale Selector when using a **Custom** range. Previously, the "Start" and "Stop" date labels in the UI remained static until the "Apply" button was clicked, as they were bound directly to `props.scales`. This commit switches those labels to use the component's internal reactive state (`this.pickerValues`). **Changes:** * Bind `t-out` directives to `this.pickerValues` instead of `props.scales`. * Pass reactive Luxon objects through `getFormattedDate` for immediate localized rendering. **Task-5926713**
This update enhances the user experience within Odoo's web_studio by changing the names of report customizations from technical keys to more descriptive, human-readable labels. This makes it easier for users to understand and manage their report customizations, improving overall usability. The change was a simple refinement to improve clarity.
Original PR description
Before this commit the name of a view customization for a report was basically its key. After this commit, the name is more human readable task-5945040
This update corrects a display issue on payslips. The "Error" status, previously shown, has been changed to "Blocked" to provide a clearer indication of payroll processing problems. This ensures accurate reporting and easier troubleshooting for HR and finance teams.
Original PR description
[IMP] hr_payroll: renaming status name
Shown status in payslip ("Error") is needed to be changed to Blocked.
task - 5969322This update resolves an issue where refreshing pivot tables caused unexpected delays. The fix ensures that related dynamic tables are also updated, improving the overall performance and stability of the pivot functionality. This change addresses a technical problem that impacts how users interact with data visualizations.
Original PR description
Refreshing the pivot will invalidate the datasource,which means that t dynamic table related to a pivot also needs to be invalidated. This usually occurs when we insert a new table but since [1], we create dynamic tables out of thin air. Pretty much every command that will invalidate the pivots will now need to invalidate the tables as well. [1]: https://www.odoo.com/odoo/2328/tasks/4552232 Counter-part of https://github.com/odoo/odoo/pull/250909 Task-5976773 Forward-Port-Of: odoo/enterprise#109325
This update corrects a display issue where upsell sale orders created from subscriptions incorrectly showed as "Quotation". The fix ensures that upsell orders now display as standard sales orders, aligning with the naming convention for initial subscriptions. This improves clarity and consistency for users.
Original PR description
## Issue When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate. <img width="1330" height="296" alt="5489970"…
## Issue
When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate.
<img width="1330" height="296" alt="5489970" src="https://github.com/user-attachments/assets/cfff4c7a-fff7-4859-861b-c190dab9097d" />
## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a Subscription S00001
- Any Customer
- Any Recurring Plan
- Any Product
3. Create and confirm the invoice for the subscription S00001
4. On the subscription S, click Upsell and confirm the resulting Sale Order S00002
5. On the Sale Order S00002, click Preview
6. **The title of the Sale Order is "Quotation - S000002". In the sale.order list view, the Sale Order is shown as a Sales order, just like the initial Subscription.**
## Cause
The title shown in the preview is defined here:
https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/sale_subscription/views/sale_subscription_portal_templates.xml#L187-L195
The initial subscription falls into the `if` condition, which only shows the name of the SO. The upsell sale order is not considered as a subscription, as explained and showed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
The word *"Quotation"* shown in the preview is the `sale_order.type_name`", computed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L227-L237
The term "Quotation" was chosen in https://github.com/odoo/enterprise/commit/14e5cff65affa888f33d4008d10a32e6992d3a39.
## Fix
Before this commit, an upsell would always be named *"Quotation"*. With this commit, upsells are now added to the `other_orders` variable in `_compute_type_name` and follow the same logic as other SO:
https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/sale/models/sale_order.py#L797-L803
<img width="1316" height="308" alt="5479900_2" src="https://github.com/user-attachments/assets/7cfeb578-2870-43a6-a48b-ba0898718641" />
## Alternative
An alternative to this fix would be to update the condition used to display the name of the subscription in the preview (cf. first code snippet). This would probably result in removing the `sale_order.is_subscription` from the condition, as it is the part of the condition that upsell SOs do not meet.
opw-5489970
Forward-Port-Of: odoo/enterprise#109268
Forward-Port-Of: odoo/enterprise#1067676 changes
Resolved issues and error corrections
This update resolves a test failure related to holiday attestations in the Belgian payroll module. Adding a 'freeze_time' setting to the test ensures accurate calculations and prevents errors during automated testing. This ensures the correct processing of holiday pay calculations.
Original PR description
Addind freeze_time to Fix holiday attest test that failed on the runbot
This update resolves an issue where approval rules for account moves incorrectly linked actions to the list view. The change ensures that when an approval rule is applied, the associated list view action is automatically deactivated, streamlining the approval process and preventing unintended actions. This improves the reliability and usability of the approval workflow.
Original PR description
Following commit odoo/odoo@c442f72479b50855f40ba079800ee9e5a5690753 When putting an approval rule action_post (account.move) the action bound to the list view must be deactivated. opw-5921128
This update fixes an issue where payslips weren't being generated correctly for employees with flexible working hours. The system now automatically creates work entries for these employees when a payslip is created, ensuring accurate payroll calculations. This improves the reliability of payroll processing for a wider range of employee types.
Original PR description
**Version:** - 19.0 **Steps to reproduce:** - Create an employee. - Leave the Working Hours field empty. - Set the contract dates and a wage. - Create a payslip using the smart button. **Issue:** - Worked day lines are empty for flexible employees when the payslip is created from the smart button. **Cause:** - Flexible employees were being skipped because their working hours were empty, which results in work entries not being generated. **Solution:** - Updated the condition to also generate work entries for flexible employees. Task-5431870
This update corrects an issue where shift durations weren't accurately displayed in the Planning app when shifts spanned across multiple days. The fix removes outdated logic that previously truncated pill names based on hour spans, ensuring correct duration information is shown regardless of the shift's length. This improves the accuracy of shift scheduling and reporting.
Original PR description
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an…
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an employee from 3pm to 2am (over two days) - The hours of the shift are displayed - Modify the shift end to 3am - The hours of the shift aren't displayed ### Cause: Before the refactor adapting the gantt view to OWL, when a shift spanned over two days less than three hours, then the gantt view truncated the pill to display it in only one day. (see [`_snapToGrid()`](https://github.com/odoo/enterprise/blame/a16b2ef569903c0ae5803c169dbd68acd0141fe1/web_gantt/static/src/js/gantt_row.js#L1044-L1072)) The same logic was done for the computation of the pill's name in [this commit](https://github.com/odoo/enterprise/commit/98a86cbacf484646f486e4648788cfa53cc9648c). But as the pills are no longer truncated since 17.0, the computation of pill names is faulty. ### Solution: We remove the checks of the 3-hour margin. This also makes the variable `spanMoreThanOneDay` useless, so we delete it. opw-5881532 Forward-Port-Of: odoo/enterprise#109314 Forward-Port-Of: odoo/enterprise#107233
This update resolves a problem preventing the correct generation of CSV reports for Peru-specific financial reports. The issue stemmed from incompatible CSV formatting settings within the Odoo system, specifically related to Python 3.13. The fix ensures reports are generated correctly, maintaining data accuracy for Peruvian accounting.
Original PR description
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises ValueError: bad delimiter or lineterminator value This is due to…
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises
ValueError: bad delimiter or lineterminator value
This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:
> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.
so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.
Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.
https://runbot.odoo.com/odoo/error/240950
Forward-Port-Of: odoo/enterprise#109081This update fixes a restriction preventing all managers from viewing their subordinates' voip call records. The change updates a security rule to grant access through the standard 'group_user' group, ensuring consistent access for all managers. This simplifies access management and improves usability.
Original PR description
voip_hr defines a record rule that gives managers access to their subordinates' voip.call records. However, this rule is linked to the group 'hr.group_hr_user', which is not granted to all managers. This commit links the rule to the base.group_user group instead, so that all managers can access their subordinates' records without the need for an additional group. [Task-5363640](https://www.odoo.com/odoo/project/5778/tasks/5363640).
8 changes
Resolved issues and error corrections
This update prevents mail templates from automatically deleting attachments when they are removed from the mail composer. Previously, deleting an attachment in the composer also removed it from the template, causing confusion. The fix simplifies the process by only removing attachments from the template when explicitly deleted in the composer.
Original PR description
Removing an attachment (coming from a mail template) in the mail composer wrongly removes it from the template. - Edit the "Sales: Send Quotation" mail template, add it an attachment - Go to a draft…
Removing an attachment (coming from a mail template) in the mail composer wrongly removes it from the template. - Edit the "Sales: Send Quotation" mail template, add it an attachment - Go to a draft quotation - Click on "Send", it will open the mail composer which will use the template. You should see the file you added on the template. - Now, remove that file from the composer. For instance, for this client you don't want to send it, or you want to replace it or whatever. - The mail attachment has also been deleted from the template, not only from the current mail. - Note that you don't need to send it, just deleting it in the composer is enough to have it removed on the template. Many refactoring were made in `mail` between Odoo 17 and 18, breaking this flow. Another solution would be to change that in JS side, somehow managing to call `delete()` and not `remove()` in `/mail/[..]/attachment_model.js`. The caller is in `unlink()` in `/mail/[..]/attachment_upload_service.js` which is itself called by `onFileRemove()` from `/mail/[..]/mail_composer_attachment_list.js`. That would've kept using the same attachment record as the one in the template without removing it from the template when it's removed from the composer. The python solution seems more straightforward and since it's creating new attachment no other bugs should arise. Finally, note that "ghost" attachment are garbage collected through the `_gc_lost_attachments()` autovacuum method, looking for attachment having `res_id=0` and `mail.compose.message` as model. task-4748058
This update resolves a problem where CSV reports generated by the l10n_pe_reports module were failing due to incompatible CSV formatting settings. The fix ensures the reports generate correctly with Python 3.13 and removes unnecessary configuration steps, improving stability and efficiency. This prevents errors during report generation, particularly on automated builds.
Original PR description
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises ValueError: bad delimiter or lineterminator value This is due to…
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises
ValueError: bad delimiter or lineterminator value
This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:
> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.
so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.
Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.
https://runbot.odoo.com/odoo/error/240950
Forward-Port-Of: odoo/enterprise#109081A bug was causing a validation error when simultaneously updating the fiscal year's last month and last day for a company and its branches. This fix ensures that all changes are applied before the system checks for constraints, preventing the error and allowing users to correctly configure fiscal year settings. This improves the reliability of accounting configurations.
Original PR description
Having a parent company and a chid company selected, and changing both the last day and the last month of the fiscal year as the same time raises a ValidationError. This is because in this case, in the write we successively modify each changed delegated fields from root company to the branches. Then, when checking the constrains we loop through all delegated fields and check if the value of the branches are the same as the root company. This check triggers the error as all values are not set yet. By using a write on branches for all changed delegated fields instead of a simple assignation, the constrains check occurs once all the value have been updated. Steps: - Have a root company and a branch - Select both in company selector - Go to Accounting configuration - Change fiscalyear last month AND ast day at the same time - Save -> ValidationError in `_check_root_delegated_fields` opw-5431145
This update resolves a runtime error that occurred when generating the stock forecast report. Specifically, the report was failing due to an issue with how stock movements were being processed during delivery transfers. This change ensures the report generates correctly, preventing data inaccuracies.
Original PR description
This reverts commit 2b2d73df420baee4fec1c51c28250666d80b48b8. ## How to reproduce (in runbot): - Create Product P - Create Delivery transfer from 'WH/Stock/Shelf 1' - Open Forecast report: =>…
This reverts commit 2b2d73df420baee4fec1c51c28250666d80b48b8.
## How to reproduce (in runbot):
- Create Product P
- Create Delivery transfer from 'WH/Stock/Shelf 1'
- Open Forecast report:
=> RuntimeError: dictionary changed size during iteration
The original fix will be redone in another commit.
---
## Traceback:
```
File "/data/build/odoo/addons/stock/report/stock_forecasted.py", line 21, in get_report_values
'docs': self._get_report_data(product_ids=docids),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/stock/report/stock_forecasted.py", line 128, in _get_report_data
res['lines'] = self._get_report_lines(product_template_ids, product_ids, wh_location_ids, wh_stock_location)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/stock/report/stock_forecasted.py", line 359, in _get_report_lines
for product_id, location_id in currents:
RuntimeError: dictionary changed size during iteration
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251768This update resolves a problem with the HTML Editor's automated tests. The tests were unreliable due to the toolbar being a popover, making it difficult to wait for the display to fully load. The team has increased timeouts and addressed timing issues to ensure test stability and consistent results.
This update corrects a discrepancy in the Spanish version of the abbreviated balance sheet report. It adds account code 189, required by recent Spanish accounting regulations (PGCE) to ensure accurate reporting and compliance. This ensures the financial reports generated for Spanish businesses align with current legal requirements.
Original PR description
According to last updated of PGCE https://www.boe.es/buscar/act.php?id=BOE-A-2011-18458 <img width="790" height="342" alt="image" src="https://github.com/user-attachments/assets/d5875946-d3b0-480b-bea1-8a7f4202aef7" /> @moduon MT-14017
This update fixes a restriction in the Italian tax processing (l10n_it_edi_doi) module, allowing multiple tax lines to be added to invoices, including those with 0% taxes like Enasarco and RIT. This change aligns with Italian tax regulations that permit combining Dichiarazione d'intento with other tax withholdings on the same invoice.
Original PR description
We should be able to add more taxes with the 0% on the same line, like the Enasarco and 23% RIT. Indeed in italy it is possible to have invoices with Dichiarazione d'intento togheter with a withholding and Enasarco taxes. See also: odoo/odoo#236251 Ticket [link](https://www.odoo.com/odoo/project.task/5933699) opw-5933699 Forward-Port-Of: odoo/odoo#248586
This update resolves a minor technical issue that was preventing the correct processing of account EDI invoices, specifically related to handling country codes. The change ensures the system correctly identifies supported countries, improving the reliability of invoice generation and transmission. This fix was made as part of our ongoing commitment to stability and accuracy.
Original PR description
`('FR, DE')` was a single string instead of a tuple, causing a TypeError when `country_code` is not a string (e.g. falsy value on empty recordset). Changed to `('FR', 'DE')` so membership test is used instead of substring search.
opw-6004910
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr3 changes
Resolved issues and error corrections
This update prevents installable snippets from being dragged within website page editors. The previous system incorrectly allowed dragging of installable modules, which has now been corrected. This ensures a smoother and more reliable editing experience for users.
Original PR description
In [commit 1], jQueryUI was replaced by in house drag and drop and while doing so, replaced a jQuery array of snippets as the draggable elements by a selector `oe_snippet` on the `SnippetsMenu` HTML element. This lead to installable snippets being draggable even though they should not. More so, it seems like the "cancel" option of jQueryUI was not adapted to "ignore" of the new API. This commit fixes both and uses ignore to ignore installable snippets. Steps to reproduce: - Have a DB with installable modules - Start a website page edition - Drag an installable Snippet => It should not be draggable [commit 1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76 task-3600773
This pull request reverts a recent change that introduced a proforma bill report on the customer portal. This change was causing confusion and unnecessary complexity for users. The reversion restores the previous functionality, ensuring a simpler and more straightforward experience for customers.
Original PR description
This reverts commit e4e3bf63d413a6e41e28eab37c4ef51a94f9fc1e.
This update resolves a problem where the system was incorrectly returning multiple bank accounts for companies with shared account numbers, particularly when dealing with child contacts. The fix ensures that only one bank account is created, streamlining bank management and preventing data inconsistencies.
Original PR description
The function `_find_or_create_bank_account` is expected to return one or no record at all. In the case of child contacts, it is possible that the same account number was set on multiple records, leading the function to return multiple banks.