Friday, September 12, 2025
69 changes · 19.0
Resolved issues and error corrections
This fix lets users with invoicing permissions update Argentine partner perception and withholding details on customer or vendor records. It helps billing staff prepare invoices correctly without needing full accounting administrator access.
Original PR description
Description of the issue/feature this PR addresses: This pull request adds `l10n_ar.partner.tax_billing` on the `l10n_ar_partner_tax` model, granting read, write, and create permissions (but not…
Description of the issue/feature this PR addresses: This pull request adds `l10n_ar.partner.tax_billing` on the `l10n_ar_partner_tax` model, granting read, write, and create permissions (but not unlink) to users in the `account.group_account_invoice` group. Current behavior before PR: Only users with administrator access rights on the Accounting module could modify the "Perceptions / Withholdings" Section on the "Accounting" tab of the partners. <img width="1236" height="673" alt="image" src="https://github.com/user-attachments/assets/92b42973-2b01-4019-8e23-5e3cbf5111a4" /> Desired behavior after PR is merged: Users with invoicing rights can modify the Accounting module could modify the "Perceptions / Withholdings" Section on the "Accounting" tab of the partners. This is needed to properly create the invoices with the perceptions / withholding that apply, for example in cases where by default all partners are set with perceptions, but some depending on their activity are not taxed. In that case, the user that created the partner needs to be able to modify the field by putting a 0% aliquot or deleting the perception line on the contact. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225180
Live chat agents now see recent website visit times in their own timezone instead of UTC. This makes the visitor history banner easier to understand and helps agents interpret customer activity accurately during conversations.
Original PR description
Before this PR, when browsing a website livechat in the discuss app, the banner containing the 3 last pages browsed by the user showed the utc time instead of the time in the timezone of the agent. Now, the livechat agent is seeing the visit timings in his timezone. To achieve this, we now construct the visit string in the frontend and receive the page and datetime (utc) info from the backend task-4937769 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225761 Forward-Port-Of: odoo/odoo#219113
Product pictures in the sales catalog now display without being stretched when they are not square. This improves the visual quality of quotations and helps users recognize products more easily.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have products with non-square images available for sale; 2. open a quotation; 3. open the product catalog. Issue ----- The product images appear stretched. Cause ----- Commit e8836b42200e3 replaced the `div.kanban_image` element with a `field` element using the `image` widget. It maintained the same size limit of 55x55 via the widget's options, but without additional input, this causes the widget to stretch the images to fill the area. Solution -------- Add the `object-fit-contain` as `img_class` to the options. This class contains the image to the area instead of stretching it. opw-5007629 Forward-Port-Of: odoo/odoo#225112
This fixes a small issue in the Mercado Pago payment form customization. It helps ensure the payment option behaves as intended during checkout, reducing the chance of customer payment friction.
This fix keeps spreadsheets in the light theme because the spreadsheet interface does not support dark mode yet. It prevents mixed dark and light styling, making the spreadsheet screen look consistent and easier to use.
Original PR description
Spreadsheet doesn't support dark theme. This fixes some style where dark and light themes are mixed. Task: 5082593 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 fixes a crash that could happen when two employees had time off on the same dates but their time off types handled public holidays differently. Updating a public holiday during those overlapping absences now works reliably, helping HR teams manage calendars without interruptions.
Original PR description
When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback. Steps to…
When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback. Steps to reproduce: ------------------- * Marc demo and Abigail Peterson using the same calendar * Create a "Paid time off" leave for marc demo: June 19 - June 20 * Create a "Extra time off" for abigail: same date * Update Time off type "Extra Time Off" to "Ignore Public Holidays" * Approve both leave request previously created * Create public holidays on June 19 --> traceback Observation: When both time off have the same dates it will overide the value in the dictonary https://github.com/odoo/odoo/commit/0d846ecd1ec7ff5149d580d3494b1a4bab1e68d2#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R464 and when it will try to call the employe_id it will trigger the traceback https://github.com/odoo/odoo/commit/f72ac3a14d76d4fb53ec3a092d08afafe4c35888#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R561 Why the fix: ------------ Added a new key on work_days_data to avoid the collision of two similar timeoffs. opw-4933820 Forward-Port-Of: odoo/odoo#225884 Forward-Port-Of: odoo/odoo#221942
A stock app test now sets up a default route so it can run correctly when only the Stock module is installed. This prevents automated validation from failing due to a missing button, improving confidence in Stock module quality checks.
Original PR description
Issue Before This Commit: ============================ The test_stock_route_diagram_report tour fails when only the stock module is installed. The tour breaks because the element `.btn[id="stock.view_diagram_button"]` is not found. Steps to Reproduce: ============================ - Install only the `stock` module. - Run the `test_stock_route_diagram_report` test. - The tour breaks because the element `.btn[id="stock.view_diagram_button"]` is not found. Cause of the Issue: =========================== The tour breaks due to a recent [PR](https://github.com/odoo/odoo/pull/223685) that hides the `view_diagram_button` when no routes are available for the product. With This Commit: ============================ Ensure the tour runs successfully by activating a default MTO route in the test setup, so the required element is present. runbot-232573
The chat window message composer now uses more consistent spacing at the bottom and sides. This small layout fix makes the chat area feel cleaner and allows slightly more conversation history to remain visible on screen.
Original PR description
This makes consistent spacing of bottom and horizontal, and also has the benefit to show more message list in viewport. Before <img width="1169" height="644" alt="Screenshot 2025-09-11 at 11 52 03" src="https://github.com/user-attachments/assets/7863dc04-d572-4c37-b182-6d519956a041" /> After <img width="1167" height="647" alt="Screenshot 2025-09-11 at 11 48 21" src="https://github.com/user-attachments/assets/8980a2a2-93fc-4016-8e76-5b5b3fa6899a" />
This fixes a visual issue where thumbnail images in website product snippets could repeat in the background. Product displays now look cleaner and more consistent for shoppers browsing the website.
Original PR description
This PR fixes a issue where the thumbnail image on the 'products' snippets would repeat itself. task-5076717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Embedded live chat users can now open meeting chats from the chat window as intended. This fixes a missing permission in the embedded experience, making meeting-related conversations accessible without changing broader live chat behavior.
Original PR description
The embed live chat has a subset of allowed thread actions. The meeting chat action was added but not added to the allowed thread actions. In the future, we will allow most of the thread actions, at least the ones allowed for guests. Environment should not impact feature availability. However for now, let's just enable the missing action.
This update corrects several user-facing issues across Odoo, including helpdesk tickets being assigned to the wrong team from timesheets, accounting report export and folding errors, payroll calculation fixes, and invoice validation improvements. It also hides an obsolete Sign setting and refreshes translations, reducing confusion and improving reliability in daily operations.
This fixes an issue where shop floor quality checks could crash or remain stuck in the wrong result after a worker reverted and repeated a check. Manufacturing operators can now retry quality checks and see the correct highlighted status, reducing blockers during production.
Original PR description
To reproduce: - Create a BoM for a product with an operation and a quality point for this operation - Create and confirm a MO for this BoM - Process it in Shop Floor, pass or fail the QC, revert it then pass/fail it again Current behaviour: traceback Expected behaviour: mark the quality check with primary highlight Introduced in: https://github.com/odoo/enterprise/pull/91986
Indian localization reports now calculate return statuses using the latest shared Odoo logic. This keeps these reports consistent with the rest of the system and helps avoid incorrect return states in Indian reporting workflows.
Original PR description
## Before this commit The state was computed using the `__get_state_field()` method. After the reference commit, the state computation logic was improved, but this updated logic was not applied in `l10n_in_reports`. Ref commit: https://github.com/odoo/enterprise/commit/a3083e9db2534d649bfc2d02dac79582ebb6397a ## After this commit: The computation of state in `l10n_in_reports` now follows the latest logic, keeping it consistent with the generic code.
Fixed an error that could prevent users from opening the rental availability view from a rental order. This helps rental teams check product availability reliably without being interrupted by a system traceback.
Original PR description
**Steps to reproduce:** 1. Go to Rental > Create a rental product and enable Sales. 2. Create a rental order with a customer and created product. 3. Click the availability icon and open the view rental. **Issue:** A traceback occurs: `Caused by: InvalidDomainError: Invalid domain representation: product_id,=` **Cause:** The rental availability check crashed due to improper domain construction: <img width="453" height="89" alt="image" src="https://github.com/user-attachments/assets/fd3ff556-fdab-40ab-9c1b-a539e5b164e8" /> **Solution:** Now the `product_id` is correctly retrieved from the record’s `id` property before building the domain, preventing crashes when opening the rental gantt view. opw - 5066061 Forward-Port-Of: odoo/enterprise#94288
This fix prevents Chilean electronic factoring document sending from crashing when the tax authority returns unexpected or invalid responses. It also refreshes invalid access tokens and adds test coverage, improving reliability when external tax services have intermittent issues.
Original PR description
There were some typos in this method. We add test coverage and we reset the token in situations where we receive invalid responses. It's apparently common for the SII to have some random errors that could result in invalid tokens being generated. Based on the work in https://github.com/odoo/enterprise/pull/92035. Forward-Port-Of: odoo/enterprise#94342 Forward-Port-Of: odoo/enterprise#94134
Batch payments now ignore payment term lines that have already been reconciled. This prevents errors when vendors are paid in multiple installments, allowing each installment to be matched to its bank statement normally.
Original PR description
**Steps to reproduce:** - Install accountant - Go to "Accounting / Configuration / Invoicing / Payment Terms" - Create a payment term having at least 2 installments (e.g. 20%-80%) - Create a bill: *…
**Steps to reproduce:** - Install accountant - Go to "Accounting / Configuration / Invoicing / Payment Terms" - Create a payment term having at least 2 installments (e.g. 20%-80%) - Create a bill: * Vendor: [any] * Payment terms: [the created payment term] * Amount: 1000 - Confirm the bill - Pay the first installment from the bill (i.e. 200) - Go to "Accounting / Vendors / Payments" - Select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -200 - Reconcile the statement with the batch payment - From the bill, pay the second installment (i.e. 800) - Go to "Accounting / Vendors / Payments" - Select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -800 - Reconcile the statement with the batch payment **Issue:** The following UserError is raised: "You are trying to reconcile some entries that are already reconciled." **Cause:** When reconciling a batch payment, all the payment term lines from the invoices/bills linked to the payment are used. However, in this case, when the first batch payment has been reconciled, the first payment term line of the bill (linked to the first installment) has been reconciled. It should not be reused when reconciling the second batch payment. **Solution:** Exclude reconciled payment term lines when reconciling a batch payment. opw-4830185 Forward-Port-Of: odoo/enterprise#92524 Forward-Port-Of: odoo/enterprise#91367
Deleting all items from a grouped list no longer causes an error screen. This keeps list views stable when users remove the last records in a group.
Original PR description
After this commit [1], deleting all entries of a grouped list may trigger the following traceback: ``` TypeError: value[currencyField].forEach is not a function ``` This happens because the `currency_id` of an empty group becomes `0`, so `forEach` is called on a non-iterable value. This fix ensures that `currency_id` is correctly handled to prevent such error. [1] odoo@98f7462
Fixed an issue where downloading files from the Send & Print wizard could fail for Uruguayan electronic invoices. The wizard now skips the CFE attachment that belongs to the e-invoicing document, while users can still access that file from the CFE document itself.
Original PR description
When downloading attachment via the send & print wizard, we get an error from the server. This is because we raise an assertion error if any attachment is not from 'account.move' model. But the CFE file is from 'l10n_uy_edi.document' model. With this commit, we extend the `_action_download` method to filter the CFE file from the attachments. It is not blocking for client as he can still download it from the form view of the CFE document. Steps: - Create an invoice - Set a 0% tax on the invoice line - In 'Other infos' tab, fill the 'Incoterm', 'Sales Modality' and 'Transportation Rules' fields - Confirm - Open S&P wizard, select 'Create CFE' and confirm - Reopen S&P wizard, select 'Download' and confirm (can be done along the previous step too) -> Error opw-5043902 Forward-Port-Of: odoo/enterprise#93830
This change fixes an issue in the SEPA Direct Debit payment form customization. It helps ensure the payment form behaves as expected when customers use SEPA Direct Debit, reducing the risk of checkout or payment setup problems.
The PAN entity list in the Indian localization no longer shows the same Type column twice. This removes visual clutter and makes the list easier for users to read without changing any underlying data or workflow.
Original PR description
Before: - The list view in `l10n_in_pan_entity_view_tree` included `type` field twice, causing redundancy. After: - The duplicate field has been removed
The Website Builder mobile preview button now uses green to better match the product's visual theme. This is a small visual consistency fix with low business impact.
Original PR description
- The mobile preview button color is changed to green to align with the overall theme. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where image descriptions could be accidentally erased after reopening and saving the website SEO dialog without making changes. It helps preserve accessibility and SEO metadata reliably for website content.
Original PR description
Steps to reproduce: 1. Open Optimize SEO. 2. Mark an image as decorative. 3. Give a description(ALT) to that image from editor. 4. Open Optimize SEO again and save without doing anything. Issue: The description(ALT) on the image being set is lost. Cause: When reopening the `Optimize SEO` dialog, `seoContext.updatedAlts` still contained entries from previous edits. As a result, saving without making any further change triggered an call to `/website/update_alt_images` which reset the `alt` attribute to empty, effectively discarding the description. This PR ensures `seoContext.updatedAlts` is reset when opening the dialog.
Odoo now ignores accounting localization templates from modules that are not currently installable. This prevents unnecessary error logs when a custom localization module is present but not yet ready to be installed.
Original PR description
* Problem: if having a custom module that add extra tax to current localization module, ex: l10n_x inherit l10n_vn module, but the l10n_x module is not installable because it hasn't upgraded yet, the _get_chart_template_mapping include it as well, there for will log error in https://github.com/odoo/odoo/blob/18.0/addons/account/models/chart_template.py#L1219 * Solution: only get available template code for module that installable 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#225821
The account reports return screen now shows only the relevant reset button, reducing confusion for users handling tax or EC sales list returns. This fixes a display issue caused by the system checking return type details in the wrong place.
Original PR description
Multiple reset buttons were visible on returns, which was confusing. This happened because `is_tax_return_type` and `is_ec_sales_list_return_type` were referenced via `type_id` in invisible, which does not work correctly. To fix this, two related fields (`is_tax_return_type` and `is_ec_sales_list_return_type`) were added directly on `account_return`, and these are now used in invisible. ref - https://github.com/odoo/enterprise/commit/a3083e9db2534d649bfc2d02dac79582ebb6397a
This fixes a checkout issue where the browser could incorrectly restore the billing-address checkbox state after a customer used the back button. The billing address section now stays consistent with the customer’s actual choice, reducing checkout confusion.
Original PR description
Steps to reproduce: 1) Add a product and go to checkout 2) Uncheck use_delivery_as_billing 3) Click to edit the main address for example 4) Return to the previous page via the browser button 'back' See that use_delivery_as_billing is unchecked but the billing address row is hidden, it happens due to the browser's autocomplete.
This update corrects several inventory replenishment planning issues so users see clearer warnings, graph labels, and ordering frequency information. It also improves deadline calculations across companies and locations, helping purchasing and stock teams get more accurate replenishment recommendations.
Original PR description
- make the invisible condition on the warning icon lighter to process - ensure the labels are shown on the Y axis of the graph no matter the value - show "Ordering Frequency: On demand" if the min and max qties are the same - compute the deadline_date one company at a time in case of different horizon_days - add a groupby location in _compute_deadline_date - do not add horizon_days to total_delay since it's not a lead time per se - removing a forgotten `visibility_days` task 5072870 & 19.0 inventory testing pad --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Theme modules can now include their customization settings without being incorrectly rejected during validation. This prevents automated checks from failing for valid theme updates and helps keep theme releases moving smoothly.
Original PR description
Follow-up of PR https://github.com/odoo/design-themes/pull/1137 that introduced `theme_customizations` in design theme manifests for eCommerce block customizations. For Error https://runbot.odoo.com/odoo/runbot.build.error/232249 : Issue: - `ManifestLinter.test_manifests` errors in multiple theme modules. - The error was caused by the `theme_customizations` key being unrecognized in manifests and flagged as unknown. Fix: - Added `theme_customizations` to the list of allowed manifest keys, so the linter accepts it in theme module manifests.
The website builder now avoids unnecessary background work when opening the theme settings tab. This reduces the waiting time for users customizing website themes, with an estimated performance improvement of about 20%.
Original PR description
The purpose of this commit is to reduce the rendering time of the theme tab. Currently, when we have a BuilderRow that contains a collapse slot, we always render it in order to know whether it contains content or not, so that we can display the collapse arrow. The collapse feature is widely used in the theme tab. This results in a lot of unnecessary calculations, because the only case that requires dynamic calculation of the collapse arrow is the BuilderOption for visibility. So we will therefore add the “observeCollapseContent” props to enable or disable the rendering of the slot in order to dynamically display the collapse arrow. This change saves approximately 20% of time. 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#223929
The Newsletter Benefits snippet now shows a "Popup" label in the website editor preview. This fixes a missing label so users can more easily identify the snippet behavior before adding it to a page.
Original PR description
This PR adds the "Popup" label to the "Newsletter Benefits" snippet in the preview in `AddSnippetDialog`. [*]: website_mass_mailing | Before (missing label) | After (introduced label) | |-----------------------------|---------------------------------| | <img width="433" height="214" alt="image" src="https://github.com/user-attachments/assets/22bd30c6-0085-4739-bcf5-d4c84b1353a0" />| <img width="435" height="226" alt="image" src="https://github.com/user-attachments/assets/e29c2707-fb85-4252-931a-8044ffb183f0" /> |
Account return cards now show the correct Reset button instead of displaying two at once. This avoids user confusion and makes the return workflow clearer in accounting and Intrastat reporting.
Original PR description
Two buttons "Reset" are shown in the card of an account return. This is due to the invisible attributes that wrongly computes the value. Indeed, it is not possible to write something like "type_id.is_intrastat_return_type" in an invisible condition, so we need to make a related field.
The quick reorder button now shows text that can be translated for different languages. Its help text also updates immediately when the button becomes disabled, so customers see accurate guidance without refreshing the page.
Original PR description
Before this fix: - The quick reorder button title was not translatable. - After the quick reorder sidebar became empty, the button was disabled but its title was not updated accordingly. A page reload was required to see the correct title. After this fix: - The button title is now translatable. - The title is refreshed immediately when the button state changes, without needing a page reload.
Repair orders that require quality checks can now be created and saved without an error. The fix ensures lot and serial number information is handled correctly, reducing interruptions for repair and quality teams.
Original PR description
Issue: ---------------------------------------- When creating a repair order that has a quality point (defined for all products or for a specific product), or when trying to create a new lot/serial…
Issue: ---------------------------------------- When creating a repair order that has a quality point (defined for all products or for a specific product), or when trying to create a new lot/serial number from the repair order, a traceback is triggered: `ValueError: Invalid field 'lot_id' in 'quality.check'` Steps to reproduce: ---------------------------------------- - Install the `quality_repair` module. - Create a Quality Point for Operation: Repair Orders and set Control per Product/Operation. - Create a Repair Order and add a product to repair. - Save the Repair Order. - Traceback is triggered. Cause: ---------------------------------------- In PR https://github.com/odoo/enterprise/pull/90930, the `lot_id` field was replaced by a many2many field `lot_ids`. Repair orders were still trying to assign `lot_id`, causing the error. Solution: ---------------------------------------- In this commit, we ensure that `lot_ids` is set properly, allowing repair orders with quality checks to work smoothly and enabling users to assign lots/serial numbers without triggering errors. Task ID:- 5067457
This fixes a visual issue in Discuss calls where participants without video could show two green speaking outlines at once. The speaking indicator now appears in the right place, making calls look cleaner and less confusing for users.
Original PR description
Before this commit, when in a discuss call, a participant that talks while sending no video stream (both camera and screen-sharing off) would display double "is talking" green outline. This happens…
Before this commit, when in a discuss call, a participant that talks while sending no video stream (both camera and screen-sharing off) would display double "is talking" green outline. This happens when the card is not minimized, such as when this is the active main card or another participant has camera or screen-sharing on. In that case, the "is talking" outline effect is shown twice: one around the card border like card with video stream, and one around the participant avatar. The outline around the card like video stream is intended, the one around image should only happen when not around the card. This commit fixes by setting the "is talking" around image only when the card is minimized. Before <img width="498" height="315" alt="Screenshot 2025-09-11 at 15 41 09" src="https://github.com/user-attachments/assets/52334553-8ef9-460c-9162-805f44db5980" /> After <img width="499" height="314" alt="Screenshot 2025-09-11 at 15 33 39" src="https://github.com/user-attachments/assets/119ea12f-d90c-4f9d-a131-8fd6b15ec858" />
The mobile checkout cart summary now uses less screen space by hiding an extra separator. Spacing around the back action was adjusted to reduce accidental taps on the confirm button, making checkout easier on smaller screens.
Original PR description
The sticky cart summary is taking a lot of screen estate. This commit hides the - or - on mobile to optimize spacing. Replace padding top for margin top to avoid misslick on the confirm button. task-5080440 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Scanning package type barcodes with GS1 barcode settings now works without triggering server errors. This prevents interruptions in warehouse barcode workflows and improves reliability for package handling.
Original PR description
Steps to Reproduce: - Set the barcode nomenclature to GS1 - Scan a package type barcode - Server logs an AttributeError(in Odoo 18) or KeyError(in Odoo 16 and 17) Issue: - The model class "stock.package.type" is missing an attribute "_barcode_field" Solution: - Add the attribute "_barcode_field" to the model class "stock.package.type" Task: [4888064](https://www.odoo.com/odoo/49/tasks/4888064) Forward-Port-Of: odoo/enterprise#94347 Forward-Port-Of: odoo/enterprise#93116
[This commit][1] introduced errors in the Dutch and German translation files. As a result this module can not be installed anymore when any of these languages is used. This commit fixes the errors. [1]: https://github.com/odoo/enterprise/commit/d3d5e667a2d543b55a40148cb536e54d2ac64300
Original PR description
[This commit][1] introduced errors in the Dutch and German translation files. As a result this module can not be installed anymore when any of these languages is used. This commit fixes the errors. [1]: https://github.com/odoo/enterprise/commit/d3d5e667a2d543b55a40148cb536e54d2ac64300
This change fixes an internal upgrade test so it works correctly when run from external add-on locations. It helps keep automated checks reliable and reduces false failures during development and validation.
Original PR description
This test fails when executed on an external addons path. (runbot)
Self-billing invoice sequences now use a padded partner ID instead of the partner name, making references clearer and less likely to be confused with dates. The numbering is also grouped by commercial partner, helping keep invoice sequences consistent across related contacts.
Original PR description
- We prefer to use the partner's ID (padded to 5 digits to avoid confusion with the year) rather than the partner name - We make sure the sequence is unique per commercial partner rather than per partner. task-none
Website editors now get more predictable link behavior when adding or editing links. Image links no longer show an unnecessary live preview while typing, and links with an emptied URL are kept with a safe placeholder instead of silently losing the edit.
Original PR description
### Description of the issue/feature this PR addresses: - onChange was triggered both while typing in the URL input and when selecting an autocomplete item, causing live preview even for image links. - When editing a link, removing URL and clicking outside discarded changes. ### Desired behavior after PR is merged: - Live preview is now applied only for normal text links, not for image links. - If the URL field is empty and the user clicks outside, the link now default its href to '#'. task-5028570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223887
The blog sidebar now shows the RSS subscription link again after it was accidentally removed in a previous update. This makes it easier for visitors to subscribe to blog updates while keeping social media links separate and focused on website-wide channels.
Original PR description
Commit [1] changed the "follow us" social media snippet in the blog sidebar to not be dynamic anymore (meaning, it uses the website related social media by default but they are not added/removed automatically based on if they are set or not)... but doing so it removed the custom "RSS" button by mistake. This commit restores it, placing it at the top right of the sidebar, instead of being a part of the "follow us" social media. This keeps everything as static as possible + it actually makes sense to have this dedicated button outside of the more general "follow us" which is more website related than blog related. [1]: https://github.com/odoo/odoo/commit/8b7e44c8c6a7b5c267da39f438e0dfc20699befd Forward-Port-Of: odoo/odoo#226625
Users can now save the document sorting wizard for finance folders even when pinned multi-actions include accounting record creation. The update prevents unsuitable AI actions from being selected automatically, while still allowing users to choose them manually when needed.
Original PR description
Bug === When trying to save the sort wizard for a folder having a pinned multi action, with a `documents_account_record_create` child action, then the constraint `_check_use_in_ai` was triggered, and it shouldn't. The reason is the way recursive compute work, we can not set `False` as the default, because it will allow the parent to be computed with that. Task-5077569
This fixes an error that occurred when users allocated a manufacturing order to a sales order or outgoing delivery. Users can now assign quantities in the manufacturing allocation report without being blocked by a crash.
Original PR description
Issue: ---------------------------------------- When creating a manufacturing order and trying to allocate it to the desired sale order or outgoing picking, a traceback is triggered: `AttributeError:…
Issue: ---------------------------------------- When creating a manufacturing order and trying to allocate it to the desired sale order or outgoing picking, a traceback is triggered: `AttributeError: 'stock.move' object has no attribute 'group_id'. Did you mean: 'grouped'?` Steps to Reproduce: ---------------------------------------- - Install the `mrp` module and enable `Allocation Report for Manufacturing Orders`. - Create a product with a BoM. - Create a Sale Order or outgoing picking for the product. - Create a Manufacturing Order and go to the allocation report. - Try to assign it to the picking. - Traceback is triggered. Cause: ---------------------------------------- In PR odoo#212679, the `group_id` field was replaced by a many2many field `reference_ids`. However, the `_action_assign` method still tried to set the value of `group_id` instead of `reference_ids`, causing the error. After this Commit: ---------------------------------------- In this commit, we ensure that `reference_ids` is used and set properly instead of `group_id`, allowing users to assign quantities to the desired picking smoothly without errors. Task ID: 5076863
Preparation tickets in Point of Sale now include customer notes added to individual order lines. This helps kitchen or preparation staff see special instructions at the right moment, reducing missed requests and order mistakes.
Original PR description
In this commit: ----------- Orderline-level customer notes are now printed on preparation tickets. Task-4879140 Related: https://github.com/odoo/enterprise/pull/90229 Forward-Port-Of: odoo/odoo#226382 Forward-Port-Of: odoo/odoo#215761
Printing an invoice now uses the same custom PDF report selection as sending an invoice. This ensures customers receive documents with the correct partner or journal-specific template, improving consistency and reducing manual workarounds.
Original PR description
Before: Clicking 'Print' on an invoice did not respect the custom PDF report template set on the partner profile or journal. The selection was only applied in the 'Send' flow, while 'Print' always fell back to the generic invoice report. After: 'Print' now uses `_get_default_pdf_report_id()` to determine the correct PDF report. This ensures the same priority order is applied as in 'Send'. Explanation: The method `_get_default_pdf_report_id()` encapsulates the logic for choosing the report template (user → invoice default in 18.0, extended with journal in later versions). By reusing this method, we avoid duplicating logic and ensure consistency between 'Send' and 'Print'. task-5072522 Forward-Port-Of: odoo/odoo#226082
Repair orders no longer fail when a kit product is added as a part. This prevents an unexpected error during repair order creation and lets users save repairs that include kit-based components.
Original PR description
When user tries to set the kit as product parts in repair order, A traceback will appear. Steps to reproduce the error: - Install ``mrp_repair`` module with demo data - Create a new repair order > In Parts, Add a line > Product: ``Table Kit`` > Save Traceback: ``AttributeError: 'stock.move' object has no attribute 'name'`` https://github.com/odoo/odoo/blob/83a8508b958ed88bbdbf80612039ec33817bc02c/addons/mrp_repair/models/repair.py#L84 The ``name`` field of ``stock.move`` was removed in the [commit](https://github.com/odoo/odoo/pull/211488/commits/f3fc7a5cfd6e77cbbcfff891383abeac930d41ac), but it is still being referenced here. So, It will lead to the above traceback. sentry-6870866512 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226420
New users can now connect Mercado Pago accounts using the existing access token setup while OAuth is not yet available. Odoo also sends the account country to Mercado Pago so the correct account is retrieved during onboarding.
Original PR description
Enable old account configuration for new users. Country code is passed to Mercado Pago proxy so correct account can be retrieved. OAuth was not configured yet on Odoo side, which means that new users couldn't connect their account. Access token is now visible and editable for all users.
Fixed an issue where adding a service line after a sales order was confirmed showed a zero cost instead of the product’s configured cost. This keeps margin information accurate for sales teams and financial reporting.
Original PR description
…O confirmation **Problem:** When a service is added on a SO after the confirmation the cost column (purchase_price) is 0 **Steps to reproduce:** - make sure that sale_timesheet_margin is installed - create a service with a positive cost - create a SO for 1 unit of this service - confirm - add a new line on the SO for the same service **Current behavior:** the cost is 0 **Expected behavior:** the cost should be the cost you set on the product form **Cause of the issue:** since this PR https://github.com/odoo/odoo/pull/207228 services that are "ordered_prepaid" on confirmed sale order are filtered out the purchase price computation https://github.com/odoo/odoo/blob/5f6d2afa8c09fe72c01d056ebef01214567a4a99/addons/sale_timesheet_margin/models/sale_order_line.py#L9-L15 opw-5016622 Forward-Port-Of: odoo/odoo#225704 Forward-Port-Of: odoo/odoo#225027
This fixes a visual issue in website price list and product catalog snippets where separator lines could render incorrectly after changing border settings in the editor. Business users can now customize these snippets without unexpected layout or styling problems on their website pages.
Original PR description
Prior to this commit, the separators in the `s_product_catalog` and `s_pricelist_*` snippets didn't render correctly when changing the border values in the web editor. Steps to reproduce: - Open the…
Prior to this commit, the separators in the `s_product_catalog` and `s_pricelist_*` snippets didn't render correctly when changing the border values in the web editor. Steps to reproduce: - Open the Web Editor. - Drag and drop a price list snippet (`s_product_catalog`, `s_pricelist_cafe`, or `s_pricelist_boxed`). - Click on the snippet. - Set the border value to `0`. task-5081626 | Before | After | |--------|--------| | <img width="1914" height="646" alt="Capture d’écran 2025-09-11 à 09 30 11" src="https://github.com/user-attachments/assets/f7dc319f-e151-4fc4-9349-df70719aec9f" /> | <img width="1912" height="643" alt="Capture d’écran 2025-09-11 à 09 31 02" src="https://github.com/user-attachments/assets/dbbaacff-9f20-4ec4-9fec-f4cc3770952a" /> | | <img width="1915" height="646" alt="Capture d’écran 2025-09-11 à 09 30 52" src="https://github.com/user-attachments/assets/f138bd04-60cd-4238-9338-2fa5921d7715" /> | <img width="1911" height="647" alt="Capture d’écran 2025-09-11 à 09 31 37" src="https://github.com/user-attachments/assets/c38e486a-2b23-4685-83f1-de363c15c881" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226439
Sales orders created from a customer record in the Contacts app now use the customer’s preferred delivery address, matching the behavior in the Sales app. This prevents orders from being sent to an older or less relevant address and reduces manual corrections.
Original PR description
## Versions 17.0+ ## Issue When creating a SO from the Contacts app, the first delivery address is used, ignoring the preferred one. In contrast, the Sales app correctly uses the preferred delivery…
## Versions
17.0+
## Issue
When creating a SO from the Contacts app, the first delivery address is used, ignoring the preferred one. In contrast, the Sales app correctly uses the preferred delivery address. This fix ensures consistent behavior across both.
## Steps to reproduce
*Ensure Contacts app is installed*
*Activate "Customer Addresses" in the settings*
- Go to the Contacts app:
- Create a new contact:
- Name: C1;
- Contacts & Addresses:
- Delivery Address (Add 2 new addresses):
- D1;
- D2.
- Click the "Sales" action button:
- Create a new SO for C1 (pre-filled):
- Invoice Address: C1, D2;
- Delivery Address: C1, D2;
- Add any product with:
- Quantity: 1;
- Delivered: 1.
- Create the invoice and confirm it.
- Go back to Contacts and look for C1:
- Click the the "Sales" action button:
- Create a new SO and see the Delivery Address set to "C1, D1".
- Go to Sales app:
- Create a new SO and select C1 as customer;
- Delivery Address retrieves "C1, D2" as it is the preferred address.
## Cause
Each time an invoice is validated, the corresponding address gets a higher score.
This score is then used in the SQL ordering of customers/suppliers:
https://github.com/odoo/odoo/blob/b523f5c6d8e235a6cedb029f701a0ebd89a5f74a/addons/account/models/partner.py#L347-L354
## Fix
Apply context search mode if first call. This mimics the base behavior: https://github.com/odoo/odoo/blob/b57bb1decd46dcbb1fe602bb72b6f8e5382e9b28/odoo/addons/base/views/res_partner_views.xml#L534
opw-4916381
Forward-Port-Of: odoo/odoo#225189This corrects a module dependency so the AI website live chat feature can be uninstalled and reinstalled reliably. It prevents setup failures caused by a missing website component that the live chat integration depends on.
Original PR description
odoo/enterprise#93271 changed the dependencies from `ai_website, im_livechat` to `website, ai_livechat`, but this change is incorrect: in `snippets.xml` the module hooks onto `t[@id='ai_livechat_hook']` which is installed by `ai_website`. As a result trying to uninstall `ai_website` when `ai_website_livechat` is installed breaks reinstallation since the snippets view becomes invalid.
This fixes cases where protected links in the HTML editor, such as important website builder links, could be accidentally removed when deleting images, editing locked content, or removing multiple links at once. The toolbar now better reflects when a link cannot be removed, helping prevent broken page layouts after saving.
Original PR description
### [FIX] html_editor: prevent removal of unremovable links with images The override that remove a link on `deleteImage` command did not check if the link was unremovable before removing it. ###…
### [FIX] html_editor: prevent removal of unremovable links with images The override that remove a link on `deleteImage` command did not check if the link was unremovable before removing it. ### [FIX] html_editor: prevent removal of links in contenteditable=false If a link was `contenteditable=true`, but inside a `contenteditable=false`, it could be removed ### [FIX] html_editor: prevent removal of unremovable links in batch removal If the selection covers several links, the "unlink" of the toolbar removes all the links selected. This included the links which were supposed to be unremovable. The procedure for removing the links is changed to avoid removing the unremovable nodes. The availability of the tool in the toolbar is also changed to better reflect whether there is links to remove. In case of unremovable links, the tool is shown as disabled Steps to reproduce: - Open website builder - In the toolbar, insert links just before and after the "Contact Us" - Select from the link inserted before, to the one after - In the toolbar, click "Remove Link" - Bug: the link on "Contact Us" is gone, but it was "unremovable" (Saving after these steps currently breaks the toolbar's rendering) Forward-Port-Of: odoo/odoo#223237
This fix prevents carousel slides from changing when translators use arrow keys while editing text in the website builder. It avoids a crash and makes translating carousel content behave as expected, so users can move the text cursor safely.
Original PR description
Since the initial [website builder refactor], when in translate mode in website builder, pressing an arrow key when the cursor is inside the text of a carousel moved to the next slide once, pressing…
Since the initial [website builder refactor], when in translate mode in website builder, pressing an arrow key when the cursor is inside the text of a carousel moved to the next slide once, pressing again caused a crash. Before the refactor, there was also the slide behavior but not the crash. The arrows triggers the slide because the contenteditable is inside the slide in translate mode. It does not trigger it in normal edit mode because the contenteditable is on an ancestor. This commit fixes it by changing the config pass to the bootstrap carousel in edit mode, so that the carousel does not slide on keyboard. Changing this config makes the event handlers to stop the keydown event on the other parts of the carousel redundant, so they are removed Steps to reproduce: - Open website bulider - Drop the snippet "Quotes Minimal" - Add a second language to the website - Edit the translation for the second language - Click on the text in the quote in the carousel - Press a left or right arrow key - Bug: the slide changed (instead of moving the cursor in side the text) - Click on the text of the slide that is now shown - Press again the arrow key - Bug: Crash [website builder refactor]: https://github.com/odoo-dev/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641 Forward-Port-Of: odoo/odoo#226273
Due to time constraints the translations were not added in the commit adding the modules (72ac059edfcc35ad44c5faa9daf971123377af24). This commit adds the translations / fills the `.po` files. The translations were created by LMAN based on the 18.0 po files. Veri*Factu task: task-3745982 Forward-Port-Of: odoo/odoo#226298 Forward-Port-Of: odoo/odoo#225173
Original PR description
Due to time constraints the translations were not added in the commit adding the modules (72ac059edfcc35ad44c5faa9daf971123377af24). This commit adds the translations / fills the `.po` files. The translations were created by LMAN based on the 18.0 po files. Veri*Factu task: task-3745982 Forward-Port-Of: odoo/odoo#226298 Forward-Port-Of: odoo/odoo#225173
The Planning app now handles views grouped by multiple fields more safely, even when resource is not the first grouping. This prevents an error screen and helps users keep working with grouped planning data without interruption.
Original PR description
Steps to reproduce: - Open planning and use multi groupby. - Dont use resource as first groupby. Issue: - Traceback Reason: - When we multi-groupby each row has a id, and we try to extract resource id, but we dont get it undefined/open rows. - Missed proper error handling. Fix: - Add better error handling to prevent further traceback using optional chaining. task-5065999
This fix corrects the display alignment of start and end date fields in Planning screens after users leave a date field. It keeps the planning form and send wizard visually consistent, reducing confusion when entering or reviewing schedule dates.
Original PR description
currently, `start_datetime` and `end_datetime` fields became misaligned when the date field lost focus, due to the datetime formatting changes introduced in PR https://github.com/odoo/odoo/pull/218387. This fix ensures the fields are properly aligned. task-5046364
This fix lets employee users complete screens that include selecting multiple employees, even when they do not have direct access to employee records. It prevents access errors in HR, time off, and point of sale workflows, making everyday employee actions smoother.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website builder now scrolls more smoothly in Chrome when using a laptop trackpad. This removes distracting visual stutter in the Edit and Theme panels, making page editing feel more polished and responsive.
Original PR description
__Current behavior before commit:__ On Chrome, some elements of the builder, like the options headers, move at different times when scrolling with the trackpad creating unpleasant jank visual effect. __Description of the fix:__ Use `will-change: scroll-position;` to tell the browser to optimize the scroll rendering. __Steps to reproduce the issue on runbot:__ 1. Open the website builder in Chrome 2. Scroll with the laptop trackpad in the *Edit* or *Theme* tab Forward-Port-Of: odoo/odoo#224598
This update prevents access errors for non-administrator users when employee-linked records are shown in appraisals, planning, manufacturing work orders, and the shop floor. It ensures regular authorized users can continue their daily HR and manufacturing workflows without needing administrator rights.
US accounting templates now classify all accounts starting with 7 or 8 as other expenses. This helps keep financial reporting categories consistent and avoids misclassified expense accounts.
Original PR description
task-5068369
This update corrects how a closed WebSocket connection is handled in Odoo's core test utilities. It prevents misleading internal errors and helps automated checks report the real connection issue more reliably.
Original PR description
Followup to 16.0-closed-in-stop-xmo: the condition in `stop` is a `hasattr`, so we need to delete `self.ws` not set it to `None`. Setting it to `None` means the condition passes then blows up as soon as we try to use it, which means we "just" converted all the old `WebSocketConnectionClosedException` to an `AttributeError`. https://runbot.odoo.com/odoo/error/231446 Forward-Port-Of: odoo/odoo#226267
The Import Template button is restored for accounting moves and timesheets after it disappeared due to missing context information. This helps users access the correct import templates and reduces friction when bringing data into Odoo.
Original PR description
The context was removed in a previous change (#222793), which caused the "Import Template" button to disappear in `account.move` and `hr.timesheet`. These models rely on context keys in `get_import_template` to display the correct label and link. This commit adds the `context` back and tests for both models.
The Belgian salary configurator now prevents employees from using fuel card inputs when they claim a private bike reimbursement above zero. This keeps salary package choices consistent and avoids conflicting mobility benefits.
Original PR description
The Belgian salary configurator allows employees to declare a private bike cost. When the "Private Bike" option is checked and its reimbursement value is greater than zero, the fuel card inputs must be reset to 0 and disabled. task-5062963 Forward-Port-Of: odoo/enterprise#94063 Forward-Port-Of: odoo/enterprise#93884
Customers could be incorrectly blocked from paying for an appointment when a resource allowed more than one capacity but capacity management was disabled. The fix ensures paid appointment bookings reserve only one booking slot in this setup, so valid bookings can proceed to payment as expected.
Original PR description
ISSUE ===== Introduced in odoo/enterprise@bce7e94650c337a9046958a7689c81db5b2a4c73 , we now allow configuring a number of max simulatenous appointments per resource / user per slot, when…
ISSUE ===== Introduced in odoo/enterprise@bce7e94650c337a9046958a7689c81db5b2a4c73 , we now allow configuring a number of max simulatenous appointments per resource / user per slot, when manage_capacity is False. However, this broke the booking flow when enabling a payment on the appointment type as well, for resources with capacity > 1. More specifically, as soon as the remaining capacity is lower than the resource's own capacity. STEPS TO REPRODUCE ================== 0. Install payment_demo, in order to be able to test the payment issue. Install website_appointment_sale to ease the testing too. 1. Create an appointment type for 'Resources', enable 'Up-front payment'. 2. Set a new resource with capacity = 2 on the appointment type. 3. Make sure manage_capacity is False, and number of simultaneous appointments (max_bookings) is set to 1. 4. Go to the front end and pick any slot. 5. Fill the form and 'proceed to payment' 6. Try to 'pay now' 7. You get a validation error message telling you that the slot is not available anymore. But it is not the case since it is a new type and new resource. FIX === For resources, created booking lines were setting capacity_used to the resource's capacity, unless shared. (meaning: the resource is completely used, even if the reserved quantity is smaller). It made sense before but not for this new feature. It should only use 1 capacity, as we count the number of different simulatenous appointments, and it is unrelated to the resource's own capacity. When creating the meeting at the end of the regular flow, the computed field on capacity_used on appointment.booking.line will set it to 1 when manage_capacity is False. Hence, no issue will happen there in practice as the meeting is always created in that case and capacity_used updated. However, when enabling a payment, we create a calendar.booking instead, with calendar.booking.lines. And based on those, we evaluate availability when checking the cart before going to payment. Those are simply created from values in the controller, and the model is much simpler. Therefore, we fix the issue by manually setting the capacity_used to 1 when creating the booking lines in the front-end booking flow, in the case of an appointment without capacity management. Task-4963012 Forward-Port-Of: odoo/enterprise#91700
This update makes Philippine tax report export tests more dependable by ensuring report lines are always ordered consistently. It reduces false test failures without changing the intended business data or user-facing reporting behavior.
Original PR description
Fixes an issue with tests that would fail when the order of the lines in the file where not consistent. We will be a bit more precise in the order by of the export queries, and for SAWT/QAP we will also sort the lines after grouping per schedules to ensure that the order is consistent there too. See runbot error 232581
Corrects rounding used for Mexican electronic payment documents when invoices and payments use different currencies. This prevents valid payments from being rejected by the tax authority due to tiny exchange-rate precision differences.
Original PR description
Steps to reproduce: - With an MX Company setup - Set USD rate to: - 0.049216958195 for day 1 - 0.053418803419 for day 2 - Create an invoice in USD as follows: - line 1: price_unit 91, quantity 64,…
Steps to reproduce:
- With an MX Company setup
- Set USD rate to:
- 0.049216958195 for day 1
- 0.053418803419 for day 2
- Create an invoice in USD as follows:
- line 1: price_unit 91, quantity 64, tax 16%
- Confirm and send CFDI
- Register full payment in MXN
- Send Payment CFDI
Issue: Payment validation will fail with error
Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de
los importes de las bases registrados en los documentos relacionados donde el
impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento
y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de
este elemento.
Message : Valor esperado: 109025.275956 valor reportado: 109025.275862
This occurs because the precision set in https://github.com/odoo/enterprise/commit/e642e4d6d35c79d02c799d12451f3e2d92ab96e9 is high and can lead to failed
verification due to rounding on our side, because we compute BaseP using
the full digits of EquivalenciaDR, but, according to the specs, we
send it rounded to 10 digits.
opw-4750981
Forward-Port-Of: odoo/enterprise#94465
Forward-Port-Of: odoo/enterprise#92768This fixes internal self-billing tests so they no longer depend on an optional Peppol feature being installed. It helps keep invoice data exchange checks reliable across more test environments, reducing false failures during development and release validation.
Original PR description
The self-billing tests in `account_edi_ubl_cii` write on the `res_company.peppol_activate_self_billing_sending` field, which exists only if `account_peppol` is installed. To enable those tests to be run even if `account_peppol` isn't installed, we instead patch `_get_move_constraints` to enable the UBL to be generated via the `account.move.send` wizard. runbot-231735
Website footer templates have been updated to display correctly with the new default color palette. This prevents small visual layout issues and helps newly created or edited website footers look consistent and polished.
Original PR description
After the introduction of the new default color palette in commit [1], small layout issues appeared in the new footer templates. This commit adapts these templates to ensure compatibility with the…
After the introduction of the new default color palette in commit [1], small layout issues appeared in the new footer templates. This commit adapts these templates to ensure compatibility with the new palette, and also fixes some general layout issues. [1]: https://github.com/odoo/odoo/commit/62cad846a5c8adf52fc0450bc3f5cfd0492d0622 task-5079349 | Before | After | |--------|--------| | <img width="1503" height="426" alt="Capture d’écran 2025-09-10 à 14 58 34" src="https://github.com/user-attachments/assets/5b893998-b2e2-4178-9204-d4bd96636000" /> | <img width="1500" height="424" alt="Capture d’écran 2025-09-10 à 14 58 48" src="https://github.com/user-attachments/assets/7b7eb6c0-b5fd-4c27-a477-667d84f692d8" /> | | <img width="1502" height="259" alt="Capture d’écran 2025-09-10 à 14 59 20" src="https://github.com/user-attachments/assets/b22bac13-9d02-4c6a-be30-daa26a6a8667" /> | <img width="1503" height="276" alt="Capture d’écran 2025-09-10 à 14 59 34" src="https://github.com/user-attachments/assets/13c3859f-6842-440a-a3d9-0b5cde9bbd95" /> | | <img width="1503" height="297" alt="Capture d’écran 2025-09-10 à 15 00 03" src="https://github.com/user-attachments/assets/55a7ad04-5f8b-45c5-80c3-88444734dc40" /> | <img width="1502" height="297" alt="Capture d’écran 2025-09-10 à 15 00 15" src="https://github.com/user-attachments/assets/7be90fb2-6a6f-4327-bc25-091defc02dff" /> | | <img width="1504" height="313" alt="Capture d’écran 2025-09-10 à 15 00 45" src="https://github.com/user-attachments/assets/896c7246-3fdd-425e-b354-3ef86a8d1cef" /> | <img width="1502" height="337" alt="Capture d’écran 2025-09-10 à 15 00 56" src="https://github.com/user-attachments/assets/ebc65e75-c555-4e1f-b2e2-bc41ea528513" /> | | <img width="1501" height="450" alt="Capture d’écran 2025-09-10 à 15 01 34" src="https://github.com/user-attachments/assets/d361548a-a62d-49ca-acd6-eeec432da9fe" /> | <img width="1500" height="447" alt="Capture d’écran 2025-09-10 à 15 01 47" src="https://github.com/user-attachments/assets/4222a3ed-37e6-439d-ac21-8ec6b7a142c0" /> | | <img width="1504" height="530" alt="Capture d’écran 2025-09-10 à 15 02 15" src="https://github.com/user-attachments/assets/324c0b45-83d8-4333-ae5e-de11f7abd4a3" /> | <img width="1499" height="529" alt="Capture d’écran 2025-09-10 à 15 02 28" src="https://github.com/user-attachments/assets/482e8534-3dc9-433f-8d2e-58a3a5e73e4f" /> | | <img width="1502" height="483" alt="Capture d’écran 2025-09-10 à 15 03 13" src="https://github.com/user-attachments/assets/42045375-ae70-4b3f-8a32-84d5c27ca151" /> | <img width="1500" height="485" alt="Capture d’écran 2025-09-10 à 15 03 26" src="https://github.com/user-attachments/assets/1f2b2eda-03c5-4434-82d7-58b37d4f7a6c" /> | | <img width="1497" height="588" alt="Capture d’écran 2025-09-10 à 15 03 54" src="https://github.com/user-attachments/assets/3a12c5c9-2f06-4819-8e7f-77e07e4567fe" /> | <img width="1499" height="592" alt="Capture d’écran 2025-09-10 à 15 04 14" src="https://github.com/user-attachments/assets/313d227c-225f-476c-90bc-64229a52b72c" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoices no longer overwrite a manually entered currency exchange rate when no invoice date has been set. This prevents Odoo from recalculating invoice lines unexpectedly and helps users keep the values they just entered.
Original PR description
in case the user would enter manually a different rate than the default one, but does not fill the invoice date; odoo was setting today as the invoice date, which was changing the rate and recomputing all the lines... Effectively losing everything the user just encoded. So now, we only recompute the rate and the lines if the user didn't change it. The title of the refresh_invoice_currency_rate button has also been improved to be more explicit on what it does. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue in Point of Sale restaurant orders where combo items could lose their connection to the main combo product after an order was synchronized. This helps staff see and manage combo meals correctly when returning to a table after customer or order updates.
Original PR description
When one of the combo line is marked as "Dirty", it would be synched but it would remove it's link to the combo parent. Steps to reproduce: ------------------- * Create a combo product * Open a PoS restaurant * Open a table, and add the combo product * Leave the table to synchronize the order with the backend * Go back on the table and select a partner * This will mark the combo line as "dirty" * Leave the table again to synchronize the order with the backend * Go back on the table > Observation: The combo now appears as a normal product, not linked to the combo parent. Why the fix: ------------ When marking a line as "dirty", we now make sure to also mark it's combo parent as "dirty" so that it will be synchronized correctly. And keep the link to the combo parent. opw-4950262 Forward-Port-Of: odoo/odoo#225573 Forward-Port-Of: odoo/odoo#220099