Daily updates from Odoo
Wednesday, August 20, 2025
73 changes
32 changes
Resolved issues and error corrections
The accounting dashboard now shows amounts needing review with the correct currency context for foreign-currency journals. This avoids confusion where a company-currency balance was displayed with the journal currency symbol, helping users interpret review amounts accurately.
Original PR description
Steps to reproduce: - create a new journal with foreign currency - create an invoice (amount:100) with this journal and set it "to check" - Go to dashboard Issue: check balance is in company currency…
Steps to reproduce: - create a new journal with foreign currency - create an invoice (amount:100) with this journal and set it "to check" - Go to dashboard Issue: check balance is in company currency amount but the symbol is the one from the currency of the journal Solution: ~~Chkl: Misc and Sales/Purchase Journals should display all amounts in company currency≃~ Eventually, we decided that it would be better for the stable versions to keep the currency displayed as the one from the journals. We therefore use the same logic as for the bill/invoices Note: As of 18.0 the logic has been inversed. The field is now `checked` and is unticked only if there are missing information. therefore, documents to_check -> checked=False As of 18.4, the checked is onaly available for bookeeper and accounting-admin. If you are one of these, the invoice will be considered as checked whenever it is posted. If you have only have the invoicing rights, when posting, the checked will not be set on True and will considered as to be reviewed by bookeeper and accounting admin. This does not change the validity of the test opw-4349684
This update corrects how Point of Sale and restaurant order actions communicate internally after a recent change. It helps prevent issues in payment, product, and restaurant workflows caused by mismatched call formats.
Original PR description
In a previous commit, some method signatures were changed to use an options object instead of multiple parameters. This commit updates the affected method calls to use the new options object format. Forward-Port-Of: odoo/odoo#222893 Forward-Port-Of: odoo/odoo#222473
The website builder now falls back to the default value when previewing progress bar settings, preventing invalid values from appearing. The progress bar color picker also shows only the relevant choices, making editing clearer for users.
Original PR description
This commit add a fallback to default value during option preview, as it was already the case in the commit. Steps to reproduce: - Drop `s_progress_bar` snippet - Click on it - Empty "Value" field - NaN appears on progress bar during the preview - Default value of BuilderNumberInput is not used Additionally, progress bar color picker was showing theme and gradient tabs.
This fixes an error that could occur when a user removed a product from the parts section of a repair order and then changed the customer. Repair teams can now update these orders without hitting a blocking crash, improving reliability in everyday repair workflows.
Original PR description
When User removes the product from parts in repair order and tries to change the partner, A traceback will appear. Steps to reproduce the error: - Install ``repair`` module - Create new repair order > Add a line > Add a product in parts > Save - Remove product from parts > change customer > Save Traceback: ``` AssertionError: precision_rounding must be positive, got 0.0 ``` https://github.com/odoo/odoo/blob/122dece7eeedbf670254aebd2a2d69642b381547/addons/repair/models/repair.py#L319 When user removes the product from parts, ``precision_rounding`` becomes 0.0 Which results in the above traceback. sentry-6650889934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223483 Forward-Port-Of: odoo/odoo#212577
Website editors can now add, remove, and re-add carousel slides quickly without triggering an error. This makes page editing more reliable and prevents interruptions when working with carousel content.
Original PR description
Before this commit, rapidly adding and removing slides in the Carousel snippet, a traceback occurred under certain conditions. Step to reproduce: 1. Drop a Carousel Snippet on the page. 2. Rapidly `add -> remove -> add` slides with button in editor. 3. Traceback occurs. Cause: - The issue occurred in the `addSlide` function of the `CarouselItemHeaderMiddleButtons` component. When invoking `callOperation`, the `getEditingElement()` function was returning an orphaned child element that was no longer associated with a valid `.carousel` container due to race condition. Solution: - We now resolve the editing element against its closest `.carousel` parent to avoid orphan elements and ensure stable behavior. task-4270369
This fixes an issue where editing a website page could accidentally remove a hidden search setting and cause an error when saving. The search form now keeps the selected sorting information intact, improving reliability for website editors.
Original PR description
Problem: In Website, the `order_by` hidden input stores the selected sort order for search. This input can currently be deleted via `oDeleteBackward`, which may break the form behavior. Solution: Make `order_by` input unremovable to ensure form integrity. Steps to reproduce: - Add a "Title" text block - Insert a search element before the text - Delete all the text - Use backspace to delete the header block - Save - > A traceback occurs because the `order_by` input was deleted opw-4863089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220107
This update corrects how rounded corners are calculated for inner visual layers in the website editor. It prevents a styling issue caused by an invalid CSS value, helping edited pages display consistently.
Original PR description
Follow-up of [1], introduced a mistake just before the merge. CSS calc does not support `0` without a unit. [1]: https://github.com/odoo/odoo/commit/d0daf3990079477ef7552d769b944b55d9be4366
This fixes the website editor so the Color Filter setting appears below the Video option when editing snippets with background videos. It helps users find and use the relevant design controls in the expected order.
Original PR description
[FIX] website: correctly placed the color filter option Steps to reproduce: - Add a "Text-Image" snippet. - Add a background video. -> The "Color Filter" option is misplaced. Since the [website refactoring], the "Color Filter" option is placed over the "Video" option while it should be under it. This commit fixes this problem. Related to task-4367641 [website refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
This update prevents a point of sale test from removing protected products that are needed elsewhere in the system. By archiving products instead of deleting them during the test, automated checks can run more reliably without triggering avoidable errors.
Original PR description
### Before this commit: - The `test_load_pos_demo_data` test case was deleting all products, including special ones like `Gift card`, `default_booking_product`, leading to errors due to constraints on deleting such records. ### After this commit: - The test case now archives existing products instead of deleting them, avoiding these errors. Runbot Errors: 229904 & 229903 Task: 4974081 Forward-Port-Of: odoo/odoo#223364 Forward-Port-Of: odoo/odoo#221317
This fix prevents images from appearing larger than intended when editing website pages. Image height and width settings are now preserved correctly, improving visual consistency for content editors.
Original PR description
In `initElementForEdition()`, the `height` and `width` attributes of an image were being converted to CSS properties without specifying units, leading to incorrect rendering. This fix ensures the values are suffixed with 'px' when converting, preserving the intended dimensions. Steps to reproduce: 1. In Website, navigate to `/slides` via the Courses tab. 2. Enter edit mode. 3. Notice that the "current rank" image (number 2) appears enlarged due to missing units in the applied styles.
This fixes invoice list sorting so users can order customer invoices by the Status and Sent columns. It makes it easier for accounting teams to review invoices by payment progress or whether they have been sent to customers.
Original PR description
**Issue** Users were unable to sort invoices by the "Status" and "Sent" columns in the customer invoices list view. **Steps to Reproduce** 1. Go to Accounting > Customers > Invoices 2. Try sorting by the "Status" or "Sent" columns 3. Observe that sorting is not functional for these fields **Root Cause** Both `status_in_payment` and `move_sent_values` are computed (non-stored) fields. Odoo cannot sort by non-stored fields unless a SQL representation is provided using the `_field_to_sql` method. Opw-4976838 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222357
This fix stops the online store page editor from reloading unexpectedly when replacing a product's main image. It makes product page customization smoother and helps avoid interruptions while merchandising products.
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
Purchase orders now recalculate the company total when the order currency is changed. This helps keep purchasing amounts accurate in the company's currency and avoids stale totals after exchange-rate related edits.
Original PR description
**Steps to reproduce:** 1. Create a Purchase Order (PO) with a non-company currency (e.g., EUR if the main currency is USD). 2. Add at least one order line so the "Amount Total" is greater than zero. 3. Change the currency of the PO to a different one and save the record. **Expected behavior:** The `Company Total` field is recomputed using the new currency's exchange rate. **Actual behavior:** The `Company Total` remains unchanged, still showing the value in the original currency. **Fix:** Add `currency_id` to the `@api.depends` decorator of the `_amount_all` compute method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220501
When sending an SMS from a selected phone field, Odoo now keeps that field as the source even if its value is invalid, instead of silently switching to the contact's main phone number. This helps users notice and correct the specific phone value they chose, reducing the chance of messages being sent to an unintended number.
Original PR description
If a user picks a specific field to open the composer with and that field is invalid we currently attempt to pick the number from the partner of the record as a fall back. Instead if the user picked a specific field and it happens to be invalid for some reason, they will want to correct it in-situ rather than have it be something completely different. Some similar tests are regrouped. task-4900210 Forward-Port-Of: odoo/odoo#216242
This fix prevents hidden conditionally visible website sections from being accidentally restored when users undo unrelated edits. It keeps the website builder history focused on real content changes, making editing behavior more predictable.
Original PR description
With the initial [website builder refactor], the class `o_conditional_invisible` was tracked in the history. This class is added/moved when the user toggles the visibility in the "Invisible Elements" panel of a conditionnaly visible element. Just toggling the visibility does not add a step, so that mutation was added on the next added step (and undone with it). This commit lists `o_conditional_invisible` in the `system_class` so it is not tracked by the history (like `o_snippet_override_invisible`) Steps to reproduce: - Open website builder - Drop a section - On the section, set "Visibility" to "Conditionally" - In the "Invisible Elements", hide the section - Somewhere else, do a change - Undo the change - Bug: the section is shown again (and redo hide it again) [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
A small internal dependency issue was fixed for an electronic invoicing field that had been renamed previously. This reduces the risk of errors for customers who expose or customize the field through Studio, with no expected impact on standard screens.
Original PR description
In previous PR [1], we renamed field `ubl_xml_id` to `ubl_cii_xml_id`, but failed the compute dependencies. It has next to no impact since this field it not in views, but could lead to problems if people add it through Studio. [1]: https://github.com/odoo/odoo/pull/115627/files#diff-5f7f5f6e9c54527b31f7579db7ef63b5b910794e462cd3346e32387900c13efdR12 task-none Forward-Port-Of: odoo/odoo#223259
This fix makes a Mail test target the correct uploaded attachment, preventing a timing issue that caused intermittent failures. It also improves logging and validation robustness so similar issues are easier to diagnose and less likely to disrupt testing.
Original PR description
The `:not(.o-isUploading)` selector was not targetting the correct attachment, it matched the first one rather than the second one. Also improve logs and robustness of model checking to prevent other potential issues. https://runbot.odoo.com/odoo/error/223165
This fix ensures a payment-related test only uses the demo payment provider when the required demo payment module is installed. It prevents false test failures in setups that install only website sales, improving release reliability without changing customer-facing behavior.
Original PR description
Add module installation check before using "demo" as payment provider to generate payment token for payment register test case. Steps to reproduce: 1. Install single module (website_sale). 2. Run test case `TestAccountPaymentRegister.test_register_payment_doesnt_send_email`. You will get ValueError: Invalid field 'demo_simulated_state' on model 'payment.token' build_error-230731 Forward-Port-Of: odoo/odoo#222330
When an automatically detected absence is edited into a normal attendance, it will now be shown as a regular attendance instead of remaining highlighted as an absence. This prevents corrected attendance records from appearing incorrectly flagged, improving clarity for HR users.
Original PR description
### Steps to reproduce: - Run Absence detection cron - Navigate to the attendances got created in list view - Notice all of them are in red color - Modify the check in and check out dates to correct them as normal attendance - Notice the color didn't change in the view and it is still shows as red ### Cause: This is happening because color of the record is dependant on the check out mode, so if it is technical it means it is absence so we give it red color. https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/hr_attendance/models/hr_attendance.py#L84-L89 Also, the check out mode cannot be changed in any way. ### Fix: When updating the check out and check in time we check if the mode is technical we change it to manual. opw-4865524 Forward-Port-Of: odoo/odoo#218177
This update improves the responsiveness of the website builder by avoiding repeated size checks when row labels are redrawn. Users should experience smoother editing with no change to visible behavior.
Original PR description
The goal of this commit is to speed up the rerendering of the BuilderRow component. In BuilderRow, we need to calculate whether a row's label is too long or not. If so, we display a tooltip. To do this, we use the clientWidth function to determine the size required for the label. This function is considered computationally expensive. We will therefore avoid calling it at each onPatch, since the length of the label and the right-hand side do not change in size. 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
When scheduling existing shifts from the Planning Gantt view, the pop-up list no longer shows date and resource columns that are not needed in this flow. This keeps the scheduling experience cleaner and avoids confusing duplicate information for users.
Original PR description
Steps to reproduce: - 1. Go to the Planning module. 2. Open the Gantt view. 3. Click on a cell to schedule an existing shift. 4. The date and resource columns are visible in the pop-up list view. Issue: - When scheduling existing shifts from the Gantt view, the date and resource columns were still visible in the pop-up list view. Cause: - The `planning_slots_to_schedule` context flag was removed in commit c3c4f02, this was used to hide the columns. Fix: - Restore the `planning_slots_to_schedule: true` context in the Gantt renderer to ensure the columns are correctly hidden in the list view. task-4922511
This update fixes internal call formats used by Point of Sale restaurant and Urban Piper features after a recent technical change. It helps keep related restaurant preparation and ordering flows working reliably without changing the user experience.
Original PR description
In a previous commit, some method signatures were changed to use an options object instead of multiple parameters. This commit updates the affected method calls to use the new options object format. Forward-Port-Of: odoo/enterprise#92332 Forward-Port-Of: odoo/enterprise#92091
The commission plan can no longer be changed on upsell orders when the original subscription order has Freeze Plan enabled. This avoids misleading sales users and keeps displayed commission settings aligned with how commissions are actually calculated.
Original PR description
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the…
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the Subscriptions and partner_commission modules. 2) Create a subscription SO with a referrer_id and set a recurrence. 3) Enable the Freeze Plan option and create a commission plan from the view 4) Add a rate of 50 and product category as service in the commission rules. 5) In SOL add a subscription product contains recurrence with unit price of 100 6) Confirm the SO → Create Invoice → Confirm → Pay. 7) Go back to the SO and create an upsell for it. 8) Change the commission plan rate to 30 by creating a new plan. 9)Repeat step 4. **Issue:** When you navigate to the referrer record from the SO and open the Purchase Order via the smart button, you will see two Purchase Order lines both showing a value of 50, even though the upsell order had a new commission plan with a rate of 30. **Cause:** When the invoice is marked as paid, a Purchase Order with POL is created using values from the commission plan. For subscription orders, the system intentionally uses the subscription’s original commission plan instead of the updated one. https://github.com/odoo/enterprise/blob/03a5efc04538fce380ec3ea993e7586047fe117e/partner_commission/models/account_move.py#L197-L203 However, the problem is that the commission plan field remains editable in upsell SOs even when the parent SO has Freeze Plan enabled, misleading users into thinking the new commission plan will be applied. **Solution:** Make the commission plan field read-only for upsell SOs when the parent SO has Freeze Plan enabled. opw-4954307 Forward-Port-Of: odoo/enterprise#92217 Forward-Port-Of: odoo/enterprise#92157
The Planning app no longer shows the auto-plan option for shifts that do not yet have a start or end date. This prevents users from triggering an error when working with unscheduled shifts from sales planning.
Original PR description
**Step to reproduce:** 1. Install sale_planning module 2. Create a product (Sales -> Products): - Set Product Type to Service - Enable Plan Services - Assign both a Planning Role and resources. 3.…
**Step to reproduce:**
1. Install sale_planning module
2. Create a product (Sales -> Products):
- Set Product Type to Service
- Enable Plan Services
- Assign both a Planning Role and resources.
3. Create a sales order for this product.
4. Confirm the Sales Order.
5. Click the "To Plan" button.
6. Switch to List View.
7. Open the Unscheduled Shifts (None) section.
8. Try to generate an Auto Plan.
**Issue:**
A traceback is raised during auto-planning when the start_datetime or end_datetime on the planning slot is missing.
`AttributeError: 'bool' object has no attribute 'astimezone'`
**Cause:**
The `auto_plan_ids()` method assumes that shifts have valid start_datetime and end_datetime.
However, for unscheduled shifts, these fields can be empty (i.e., False), causing the error.
https://github.com/odoo/enterprise/blob/42d829ea6e6a98f251cfffc8fb67b5320a5ada12/planning/models/planning.py#L1076-L1077
**Solution:**
we hide the auto-plan button, in case we do not have startdate or enddate
opw-4812509
co-authored by: Ajit Singh (aksi@odoo.com)
Forward-Port-Of: odoo/enterprise#89383The AI fields interface now treats false boolean values as valid, so users no longer see an unnecessary warning. It also hides an internal separator when inserting properties into AI prompts, making prompt setup cleaner and less confusing.
Original PR description
Bug === The `False` value is a valid value for boolean type, and the warning should not be displayed for that type. When inserting properties in an AI prompt, the property separator should not be visible. Task-4896271 Forward-Port-Of: odoo/enterprise#88483
An accounting test was updated so it no longer depends on a fixed year in generated payment references. This prevents avoidable test failures when the test date changes, helping keep validation and release checks stable.
Original PR description
In `test_matching_rules_with_empty_aml_move_name`, the payment `move_id.name` was hard-coded to use the year "25" in the sequence prefix (e.g. MOVE25/00004). This caused ValidationErrors when the mocked posting date in the test environment belonged to a different year, as the sequence mixin enforces alignment between the move date and sequence year. The test now derives the year suffix dynamically from the actual `move_id.date` to ensure it always matches the posting date used in the test context. This makes the test stable regardless of the current (or mocked) date, removing the need for manual adjustments when fiscal years or test setup dates change. build_error-230659 Forward-Port-Of: odoo/enterprise#92080
The Journal Audit report now handles cases where the underlying Journal Report has had all its lines removed. Instead of showing an error, the report safely stops processing, avoiding disruption for accounting users.
Original PR description
Currently, error occurs when user try to open Journal Audit with no lines. Steps to replicate: - Install `accountant`. - Navigate to `Accountant > Configuration > Accounting reports`, search for `Journal Report` and open it. - Under the Lines tab, delete all the records and save. - Open the `Journal Audit` report, and the error will appear. Error: `IndexError: list index out of range` Cause: - An error occurred because the user deleted all the lines from the report, and the code tried to access the first element [1] of those lines (`lines[0]`) which caused the error. Solution: - Added a check if lines are present, if not then returned from the function. [1]: https://github.com/odoo/enterprise/blob/5670a73ef63d313f6c3df2b1ceeec7f7d6cd6a1b/account_reports/models/account_journal_report.py#L167 sentry-6795898305 Forward-Port-Of: odoo/enterprise#91979
The Sign button now disappears once a document has been fully signed from the chatter. This avoids confusion by showing users the correct document status and preventing unnecessary signing attempts.
Original PR description
Before this fix, even after a user signed a document from the chatter and The document was fully signed, and the Sign button was still visible. In this PR, the button is hidden once the document is fully signed.
WhatsApp template previews now avoid treating underscores inside links or words as italic formatting. This keeps portal links and other URLs displayed correctly while preserving intended italic formatting when underscores are separated by spaces.
Original PR description
Steps to reproduce: 1. Go to a WhatsApp template, for e.g. Sale Order. 2. Update the sample value for the Portal Link variable to include an underscore. 3. Click on Preview Issue: Due to the current…
Steps to reproduce: 1. Go to a WhatsApp template, for e.g. Sale Order. 2. Update the sample value for the Portal Link variable to include an underscore. 3. Click on Preview Issue: Due to the current regex, we will apply italic to any underscore we find which is not ideal, mostly when we work with URLs that can contain underscores like "acces_token" which we will try to apply italic to it too. Solution: Following the most common logic for italic formatting, we will only apply italic formatting when the underscore is surrounded by whitespace. This is the same way it already behaves in Whatsapp. If we write it like_this_for example, it will not apply italic formatting, but if we write it like this _this_ it will apply italic formatting. So this for example: **"If we write it like_this_for example"** Will be like - before the fix: **"If we write it like<i>this</i>for example"** Will be like - after the fix: **"If we write it like_this_for example"** opw-4720017 Forward-Port-Of: odoo/enterprise#91217
The Swiss payroll wage type form no longer shows a message panel that was left behind after related messaging support was removed. This prevents users from seeing a non-working area in the payroll setup screen and keeps the form clearer.
Original PR description
After mail thread was removed from the model, the chatter is still present in the view and should be removed
The Planning app now handles invalid shift template hours more gracefully. If a user enters an end or start hour outside the allowed range, they receive a validation message instead of triggering a system error.
Original PR description
Currently, an error occurs when entering an invalid end hour in the shift template. Steps to Reproduce: - Install the `planning` module. - Go to `Shift Templates`. - Create a new `shift template` and…
Currently, an error occurs when entering an invalid end hour in the shift template. Steps to Reproduce: - Install the `planning` module. - Go to `Shift Templates`. - Create a new `shift template` and enter an `invalid end hour (greater than or equal to 24)` > `save`. `ValueError: hour must be in 0..23` This error occurs after [this commit](https://github.com/odoo/enterprise/commit/a0bb61f5871fe02a0a32691f33dabfb06c9d2ce2), which added the _get_name method to generate the display name without validating the data.when a user enter invalid value in the end hour while creating or editing shift template. The compute method is then triggered, which attempts to generate the display name [1] based on the formatted time. During the formatting of the end time, the hour value is invalid for the time function,and raise the error [2]. This commit ensures that if the start hour or end hour is invalid, it raises a validation error, similar to [this commit](https://github.com/odoo/enterprise/pull/67580/commits/fa566f9de1b8f75510cbc01837fb3ff4764eccdf). [1]- https://github.com/odoo/enterprise/blob/3009d64c72ef3f4e6bae64ddb9e24f48a4f778a5/planning/models/planning_template.py#L54 [2]- https://github.com/odoo/enterprise/blob/3009d64c72ef3f4e6bae64ddb9e24f48a4f778a5/planning/models/planning_template.py#L74-L78 sentry-6792658060
Batch payment validation now avoids posting an incorrect message saying a payment was removed when it actually remains in the batch. This keeps payment history clearer and helps users trust the audit trail during payment processing.
Original PR description
When validating a batch that includes payments in process (e.g., without journal entries), Odoo incorrectly logs that the payment was removed from the batch, even though it remains. This commit fixes the chatter message by not possessing the write method of the account_payment if batch_payment_id not in vals. task-5011672 Forward-Port-Of: odoo/enterprise#92197
15 changes
Resolved issues and error corrections
This fixes the Australian localization so the GST-only import tax is treated as fully included for customs purposes again. It restores the expected tax setup that had been unintentionally removed, helping businesses calculate Australian import GST correctly.
Original PR description
It was price_include before and got removed with the changes from https://github.com/odoo/odoo/commit/be308e106ce9699f99efe133976c40519d6128f9 Re-add them 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#223260
Point of Sale payments marked as Force Done now follow the auto-validation setting as expected. This ensures cashiers are automatically taken to the receipt screen when terminal payment auto-validation is enabled, reducing checkout friction.
Original PR description
When doing a force done on a terminal payment, if the auto validation was turned on, it would not be triggered after clicking on the force done button. Steps to reproduce: ------------------- * Turn on the auto validation for terminal payments * Create a new order and add a product * Select a terminal payment method (You can fake the force done state as I did in the tour) * Click on the "Force Done" button > Observation: You are not redirected to the receipt screen. opw-4954406 Forward-Port-Of: odoo/odoo#223282 Forward-Port-Of: odoo/odoo#222867
The accounting dashboard now displays amounts awaiting review with the correct currency handling for journals using a foreign currency. This prevents users from seeing a misleading currency symbol next to a company-currency amount, improving trust in dashboard figures.
Original PR description
Steps to reproduce: - create a new journal with foreign currency - create an invoice (amount:100) with this journal and set it "to check" - Go to dashboard Issue: check balance is in company currency amount but the symbol is the one from the currency of the journal Solution: Chkl: <strike>Misc and Sales/Purchase Journals should display all amounts in company currency</strike> Eventually, we decided that it would be better for the stable versions to keep the currency displayed as the one from the journals. We therefore use the same logic as for the bill/invoices opw-4349684 Forward-Port-Of: odoo/odoo#215512 Forward-Port-Of: odoo/odoo#203475
This fix prevents a hidden search sorting field from being accidentally removed while editing website pages. It helps avoid save-time errors and keeps website search forms working reliably after content edits.
Original PR description
Problem: In Website, the `order_by` hidden input stores the selected sort order for search. This input can currently be deleted via `oDeleteBackward`, which may break the form behavior. Solution: Make `order_by` input unremovable to ensure form integrity. Steps to reproduce: - Add a "Title" text block - Insert a search element before the text - Delete all the text - Use backspace to delete the header block - Save - > A traceback occurs because the `order_by` input was deleted opw-4863089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220107
Fixes a display issue where collaborator avatars could overlap the form status buttons while scrolling long records. The status area now spans the full form width and only shows its shadow while scrolling, improving readability without adding unwanted horizontal scrolling.
Original PR description
User avatars displayed in collaborative mode overlap with buttons when scrolling. This commit extends the statusbar to take the full width, independently of the sheet's one. Also, to avoid an ugly shadow when not scrolling, it only adds it when the scroll is actually performed. Steps to reproduce: - open a task with two users - write in the description in collaborative mode -> user avatars should be displayed - make sure the description is long enough for the sheet to scroll - scroll for one of the avatars to reach the sticky statusbar => overlap between the avatar and the statusbar task-4907797
Purchase orders now recalculate the Company Total when the order currency is changed. This prevents outdated totals from being shown and helps users see accurate company-currency values after exchange rate changes.
Original PR description
**Steps to reproduce:** 1. Create a Purchase Order (PO) with a non-company currency (e.g., EUR if the main currency is USD). 2. Add at least one order line so the "Amount Total" is greater than zero. 3. Change the currency of the PO to a different one and save the record. **Expected behavior:** The `Company Total` field is recomputed using the new currency's exchange rate. **Actual behavior:** The `Company Total` remains unchanged, still showing the value in the original currency. **Fix:** Add `currency_id` to the `@api.depends` decorator of the `_amount_all` compute method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220501
Customer invoices can now be sorted by the Status and Sent columns in the invoice list. This makes it easier for accounting users to organize invoices and quickly find records by payment or sending state.
Original PR description
**Issue** Users were unable to sort invoices by the "Status" and "Sent" columns in the customer invoices list view. **Steps to Reproduce** 1. Go to Accounting > Customers > Invoices 2. Try sorting by the "Status" or "Sent" columns 3. Observe that sorting is not functional for these fields **Root Cause** Both `status_in_payment` and `move_sent_values` are computed (non-stored) fields. Odoo cannot sort by non-stored fields unless a SQL representation is provided using the `_field_to_sql` method. Opw-4976838 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222357
This fix prevents an error that could occur when a user removed a product from the parts list on a repair order and then changed the customer. Repair orders can now be edited and saved normally in this scenario, improving reliability for repair workflows.
Original PR description
When User removes the product from parts in repair order and tries to change the partner, A traceback will appear. Steps to reproduce the error: - Install ``repair`` module - Create new repair order > Add a line > Add a product in parts > Save - Remove product from parts > change customer > Save Traceback: ``` AssertionError: precision_rounding must be positive, got 0.0 ``` https://github.com/odoo/odoo/blob/122dece7eeedbf670254aebd2a2d69642b381547/addons/repair/models/repair.py#L319 When user removes the product from parts, ``precision_rounding`` becomes 0.0 Which results in the above traceback. sentry-6650889934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223224 Forward-Port-Of: odoo/odoo#212577
The point of sale preparation display no longer crashes when a restaurant uses only one preparation stage and marks it as Reset or Done. This keeps kitchen workflows running smoothly for simpler setups and avoids an interruption previously reported through Sentry.
Original PR description
This error occurs when we try to mark a single stage as `Reset` or `Done` in the preparation display. Steps to reproduce: --- - Install the `pos_restaurant` module - Create a New `Preparation Display` with one stage - Open `Preparation Screen` - Now `Reset` or `Done` the stage in the other tab Traceback: --- `IndexError: tuple index out of range` At [1], an error occurs because it tries to access a `position` that doesn't exist in the tuple. This happens because at [2], the code attempts to retrieve the second-to-last (-2) stage position, but only one stage is being used. [1]- https://github.com/odoo/enterprise/blob/285cca92a52f7b79de1d020558aa9b116cd7e44a/pos_enterprise/models/pos_prep_stage.py#L21-L22 [2]- https://github.com/odoo/enterprise/blob/285cca92a52f7b79de1d020558aa9b116cd7e44a/pos_enterprise/models/pos_prep_state.py#L72 sentry-6681171781
The accounting reports export now handles account codes or values that look like infinity without crashing. This ensures users can download Trial Balance spreadsheets even when account codes contain very large scientific-notation-like text.
Original PR description
_set_xlsx_cell_sizes tries to convert each cell into a float if it's possible. If the cell contains "inf", "1e1000" (or any value such that float(value) = float("inf")), then there is an OverflowError which is not catch by the try/except.
To reproduce, set an account code as "1E1000", make this account appearing in the trial balance (by creating a move) and export it as XLSX.
opw-4981385
Forward-Port-Of: odoo/enterprise#91686Dutch tax payment wizards now use the Omzetbelastingnummer when it is available, instead of always relying on the company VAT number. This ensures the payment communication is generated correctly, reducing the risk of payment matching issues with tax authorities.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_nl - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an invoice with tax for previous…
**Steps to reproduce:** - Install Accounting and l10n_nl - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an invoice with tax for previous month - Confirm the invoice - Go to "Accounting / Reporting / Statement Reports / Tax Return" - Select previous month - Create "Closing Entry" and post it - On "Miscellaneous Operations" journal in Accounting dashboard, click on "Pay tax: [date]" link - A wizard will appear fot the VAT payment **Issue:** The value of the "Communication" field is incorrect. **Cause:** The "Communication" field is always computed from the VAT of the company. However, when the "Omzetbelastingnummer" field is set, it should be used instead of the VAT. **Solution:** Use the "Omzetbelastingnummer" field to compute the "Communication" of the VAT payment when it is set. This is done through an overridden method because "Omzetbelastingnummer" is defined in an independent module. opw-4836615 Forward-Port-Of: odoo/enterprise#92563 Forward-Port-Of: odoo/enterprise#92407
Odoo Studio now handles cases where a button refers to a server action that has been deleted. Instead of showing an error and blocking users from editing the form, the missing action is ignored so users can continue working normally.
Original PR description
The error is triggered when a user configures a button to execute a serveraction, deletes the associated server action, and then attempts to edit the button. This causes a failure at the line `self.env.ref(str_action)` due to the missing external ID. **Steps to reproduce:** * Install `crm` and `web_studio` * crm > Form View> Studio > `Add a button`> Run a server Action > Enrich * Settings > Technical > Actions > Server Actions > `Enrich` > Delete it * crm > Form View > Studio `ValueError: External ID not found in the system: crm_iap_enrich.action_enrich_mail` **Solution:** * Return `False` when the referenced server action cannot be found or has been removed. **Sentry-6608495874** Forward-Port-Of: odoo/enterprise#89218
The Planning app no longer shows the auto-plan option for shifts that do not yet have a start or end date. This prevents an error when users work with unscheduled shifts from sales orders, keeping the planning workflow stable.
Original PR description
**Step to reproduce:** 1. Install sale_planning module 2. Create a product (Sales -> Products): - Set Product Type to Service - Enable Plan Services - Assign both a Planning Role and resources. 3.…
**Step to reproduce:**
1. Install sale_planning module
2. Create a product (Sales -> Products):
- Set Product Type to Service
- Enable Plan Services
- Assign both a Planning Role and resources.
3. Create a sales order for this product.
4. Confirm the Sales Order.
5. Click the "To Plan" button.
6. Switch to List View.
7. Open the Unscheduled Shifts (None) section.
8. Try to generate an Auto Plan.
**Issue:**
A traceback is raised during auto-planning when the start_datetime or end_datetime on the planning slot is missing.
`AttributeError: 'bool' object has no attribute 'astimezone'`
**Cause:**
The `auto_plan_ids()` method assumes that shifts have valid start_datetime and end_datetime.
However, for unscheduled shifts, these fields can be empty (i.e., False), causing the error.
https://github.com/odoo/enterprise/blob/42d829ea6e6a98f251cfffc8fb67b5320a5ada12/planning/models/planning.py#L1076-L1077
**Solution:**
we hide the auto-plan button, in case we do not have startdate or enddate
opw-4812509
co-authored by: Ajit Singh (aksi@odoo.com)
Forward-Port-Of: odoo/enterprise#89383Upsell orders for subscriptions now prevent users from changing the commission plan when the original order has Freeze Plan enabled. This avoids misleading changes that would not affect the actual commission purchase order, keeping expectations aligned with billing behavior.
Original PR description
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the…
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the Subscriptions and partner_commission modules. 2) Create a subscription SO with a referrer_id and set a recurrence. 3) Enable the Freeze Plan option and create a commission plan from the view 4) Add a rate of 50 and product category as service in the commission rules. 5) In SOL add a subscription product contains recurrence with unit price of 100 6) Confirm the SO → Create Invoice → Confirm → Pay. 7) Go back to the SO and create an upsell for it. 8) Change the commission plan rate to 30 by creating a new plan. 9)Repeat step 4. **Issue:** When you navigate to the referrer record from the SO and open the Purchase Order via the smart button, you will see two Purchase Order lines both showing a value of 50, even though the upsell order had a new commission plan with a rate of 30. **Cause:** When the invoice is marked as paid, a Purchase Order with POL is created using values from the commission plan. For subscription orders, the system intentionally uses the subscription’s original commission plan instead of the updated one. https://github.com/odoo/enterprise/blob/03a5efc04538fce380ec3ea993e7586047fe117e/partner_commission/models/account_move.py#L197-L203 However, the problem is that the commission plan field remains editable in upsell SOs even when the parent SO has Freeze Plan enabled, misleading users into thinking the new commission plan will be applied. **Solution:** Make the commission plan field read-only for upsell SOs when the parent SO has Freeze Plan enabled. opw-4954307 Forward-Port-Of: odoo/enterprise#92157
The Journal Audit report no longer crashes if its underlying Journal Report has had all lines removed. Instead of showing an error, the system safely stops processing empty report data, helping accountants continue working without interruption.
Original PR description
Currently, error occurs when user try to open Journal Audit with no lines. Steps to replicate: - Install `accountant`. - Navigate to `Accountant > Configuration > Accounting reports`, search for `Journal Report` and open it. - Under the Lines tab, delete all the records and save. - Open the `Journal Audit` report, and the error will appear. Error: `IndexError: list index out of range` Cause: - An error occurred because the user deleted all the lines from the report, and the code tried to access the first element [1] of those lines (`lines[0]`) which caused the error. Solution: - Added a check if lines are present, if not then returned from the function. [1]: https://github.com/odoo/enterprise/blob/5670a73ef63d313f6c3df2b1ceeec7f7d6cd6a1b/account_reports/models/account_journal_report.py#L167 sentry-6795898305 Forward-Port-Of: odoo/enterprise#91979
14 changes
Resolved issues and error corrections
This update keeps the Belgian point of sale certification module compatible with the latest Odoo version by replacing an outdated internal component. It helps prevent errors in POS category handling after upgrading to version 19.0.
Original PR description
Starting from 19.0, odoo.osv is depreciated, so we need to use odoo.fields.Domain instead. [Runbot-230364](https://runbot.odoo.com/odoo/error/230364)
The Journal Audit report no longer crashes when its underlying Journal Report has had all lines removed. Instead of showing an error, the system safely stops processing empty report data, improving reliability for accounting users.
Original PR description
Currently, error occurs when user try to open Journal Audit with no lines. Steps to replicate: - Install `accountant`. - Navigate to `Accountant > Configuration > Accounting reports`, search for `Journal Report` and open it. - Under the Lines tab, delete all the records and save. - Open the `Journal Audit` report, and the error will appear. Error: `IndexError: list index out of range` Cause: - An error occurred because the user deleted all the lines from the report, and the code tried to access the first element [1] of those lines (`lines[0]`) which caused the error. Solution: - Added a check if lines are present, if not then returned from the function. [1]: https://github.com/odoo/enterprise/blob/5670a73ef63d313f6c3df2b1ceeec7f7d6cd6a1b/account_reports/models/account_journal_report.py#L167 sentry-6795898305 Forward-Port-Of: odoo/enterprise#91979
The Sign button is now hidden once a document has been fully signed from the chatter. This avoids confusion for users by removing an action that is no longer needed after signing is complete.
Original PR description
Before this fix, even after a user signed a document from the chatter and The document was fully signed, and the Sign button was still visible. In this PR, the button is hidden once the document is fully signed. Forward-Port-Of: odoo/enterprise#92597
The Swiss payroll wage type view no longer shows the discussion panel after messaging support was removed from the related record. This prevents users from seeing a non-working or irrelevant communication area, keeping the screen clearer and avoiding confusion.
Original PR description
After mail thread was removed from the model, the chatter is still present in the view and should be removed Forward-Port-Of: odoo/enterprise#92316
This change adjusts an internal test so it stays aligned with a recent spreadsheet component update. It helps keep automated quality checks reliable without changing the user-facing document spreadsheet experience.
This update fixes an internal accounting test so it automatically uses the correct year when checking payment references. This helps keep the test suite stable over time and avoids avoidable build failures when dates change.
Original PR description
In `test_matching_rules_with_empty_aml_move_name`, the payment `move_id.name` was hard-coded to use the year "25" in the sequence prefix (e.g. MOVE25/00004). This caused ValidationErrors when the mocked posting date in the test environment belonged to a different year, as the sequence mixin enforces alignment between the move date and sequence year. The test now derives the year suffix dynamically from the actual `move_id.date` to ensure it always matches the posting date used in the test context. This makes the test stable regardless of the current (or mocked) date, removing the need for manual adjustments when fiscal years or test setup dates change. build_error-230659 Forward-Port-Of: odoo/enterprise#92080
The Planning app now validates shift template start and end hours before creating the display name. This prevents a system error when users enter an invalid hour, replacing it with a proper validation message so the form can be corrected safely.
Original PR description
Currently, an error occurs when entering an invalid end hour in the shift template. Steps to Reproduce: - Install the `planning` module. - Go to `Shift Templates`. - Create a new `shift template` and…
Currently, an error occurs when entering an invalid end hour in the shift template. Steps to Reproduce: - Install the `planning` module. - Go to `Shift Templates`. - Create a new `shift template` and enter an `invalid end hour (greater than or equal to 24)` > `save`. `ValueError: hour must be in 0..23` This error occurs after [this commit](https://github.com/odoo/enterprise/commit/a0bb61f5871fe02a0a32691f33dabfb06c9d2ce2), which added the _get_name method to generate the display name without validating the data.when a user enter invalid value in the end hour while creating or editing shift template. The compute method is then triggered, which attempts to generate the display name [1] based on the formatted time. During the formatting of the end time, the hour value is invalid for the time function,and raise the error [2]. This commit ensures that if the start hour or end hour is invalid, it raises a validation error, similar to [this commit](https://github.com/odoo/enterprise/pull/67580/commits/fa566f9de1b8f75510cbc01837fb3ff4764eccdf). [1]- https://github.com/odoo/enterprise/blob/3009d64c72ef3f4e6bae64ddb9e24f48a4f778a5/planning/models/planning_template.py#L54 [2]- https://github.com/odoo/enterprise/blob/3009d64c72ef3f4e6bae64ddb9e24f48a4f778a5/planning/models/planning_template.py#L74-L78 sentry-6792658060 Forward-Port-Of: odoo/enterprise#91779
The Knowledge and Helpdesk Knowledge test tours were adjusted to match updated media dialog behavior from a related accessibility improvement. This helps keep automated checks reliable and reduces the risk of regressions in article editing and file block workflows.
Original PR description
This commit is linked to the [MediaDialog accessibility improvement PR] in community. [MediaDialog accessibility improvement PR]: https://github.com/odoo/odoo/pull/220737 task-3680626
The Planning app now hides the auto-plan option when a shift has no start or end date. This prevents users from triggering an error while working with unscheduled shifts created from sales orders.
Original PR description
**Step to reproduce:** 1. Install sale_planning module 2. Create a product (Sales -> Products): - Set Product Type to Service - Enable Plan Services - Assign both a Planning Role and resources. 3.…
**Step to reproduce:**
1. Install sale_planning module
2. Create a product (Sales -> Products):
- Set Product Type to Service
- Enable Plan Services
- Assign both a Planning Role and resources.
3. Create a sales order for this product.
4. Confirm the Sales Order.
5. Click the "To Plan" button.
6. Switch to List View.
7. Open the Unscheduled Shifts (None) section.
8. Try to generate an Auto Plan.
**Issue:**
A traceback is raised during auto-planning when the start_datetime or end_datetime on the planning slot is missing.
`AttributeError: 'bool' object has no attribute 'astimezone'`
**Cause:**
The `auto_plan_ids()` method assumes that shifts have valid start_datetime and end_datetime.
However, for unscheduled shifts, these fields can be empty (i.e., False), causing the error.
https://github.com/odoo/enterprise/blob/42d829ea6e6a98f251cfffc8fb67b5320a5ada12/planning/models/planning.py#L1076-L1077
**Solution:**
we hide the auto-plan button, in case we do not have startdate or enddate
opw-4812509
co-authored by: Ajit Singh (aksi@odoo.com)
Forward-Port-Of: odoo/enterprise#89383A small cleanup removes an unused internal parameter in the Belgian POS blackbox module. This reduces confusion in the code without changing how users work with the point of sale.
Original PR description
An unnecessary parameter has been added and mistakenly not removed. This commit removes it. Forward-Port-Of: odoo/enterprise#92554
Upsell orders for subscriptions now prevent changes to the commission plan when the original order has Freeze Plan enabled. This avoids misleading sales users into choosing a new plan that would not be used for the resulting commission purchase order.
Original PR description
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the…
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the Subscriptions and partner_commission modules. 2) Create a subscription SO with a referrer_id and set a recurrence. 3) Enable the Freeze Plan option and create a commission plan from the view 4) Add a rate of 50 and product category as service in the commission rules. 5) In SOL add a subscription product contains recurrence with unit price of 100 6) Confirm the SO → Create Invoice → Confirm → Pay. 7) Go back to the SO and create an upsell for it. 8) Change the commission plan rate to 30 by creating a new plan. 9)Repeat step 4. **Issue:** When you navigate to the referrer record from the SO and open the Purchase Order via the smart button, you will see two Purchase Order lines both showing a value of 50, even though the upsell order had a new commission plan with a rate of 30. **Cause:** When the invoice is marked as paid, a Purchase Order with POL is created using values from the commission plan. For subscription orders, the system intentionally uses the subscription’s original commission plan instead of the updated one. https://github.com/odoo/enterprise/blob/03a5efc04538fce380ec3ea993e7586047fe117e/partner_commission/models/account_move.py#L197-L203 However, the problem is that the commission plan field remains editable in upsell SOs even when the parent SO has Freeze Plan enabled, misleading users into thinking the new commission plan will be applied. **Solution:** Make the commission plan field read-only for upsell SOs when the parent SO has Freeze Plan enabled. opw-4954307 Forward-Port-Of: odoo/enterprise#92217 Forward-Port-Of: odoo/enterprise#92157
AI prompt field selection now avoids showing unnecessary separators when inserting properties. Boolean fields also correctly treat False as a valid value, preventing misleading warnings for users.
Original PR description
Bug === The `False` value is a valid value for boolean type, and the warning should not be displayed for that type. When inserting properties in an AI prompt, the property separator should not be visible. Task-4896271 Forward-Port-Of: odoo/enterprise#92699 Forward-Port-Of: odoo/enterprise#88483
Dutch VAT payment instructions now use the Omzetbelastingnummer when it is available, instead of always relying on the company VAT number. This ensures the payment communication shown to users matches Dutch tax reporting requirements and reduces the risk of incorrect tax payment references.
Original PR description
**Steps to reproduce:** - Install Accounting, l10n_nl and l10n_nl_reports_sbr_ob_nummer - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an…
**Steps to reproduce:** - Install Accounting, l10n_nl and l10n_nl_reports_sbr_ob_nummer - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an invoice with tax for previous month - Confirm the invoice - Go to "Accounting / Reporting / Statement Reports / Tax Return" - Select previous month - Create "Closing Entry" and post it - On "Miscellaneous Operations" journal in Accounting dashboard, click on "Pay tax: [date]" link - A wizard will appear fot the VAT payment **Issue:** The value of the "Communication" field is incorrect. **Cause:** The "Communication" field is always computed from the VAT of the company. However, when the "Omzetbelastingnummer" field is set, it should be used instead of the VAT. **Solution:** Use the "Omzetbelastingnummer" field to compute the "Communication" of the VAT payment when it is set. This is done through an overridden method because "Omzetbelastingnummer" is defined in an independent module. opw-4836615 Forward-Port-Of: odoo/enterprise#92691 Forward-Port-Of: odoo/enterprise#92407
This fixes an internal test setup issue for Australian payroll accounting by giving the test user the access rights needed for accounting and HR records. It helps ensure automated checks run reliably without affecting day-to-day users.
Original PR description
[FIX] l10n_au_hr_payroll_account: missing groups The common test file is accessing models in account and hr modules but the user miss groups to have access to them. runbot-230965
12 changes
Resolved issues and error corrections
The Italian accounting localization now includes the missing 0% EU tax for exported services. This ensures invoices can show the correct legal note for these service exports, helping businesses stay compliant with Italian tax requirements.
Original PR description
Description of the issue this commit addresses: The export tax for services is missing in the italian localization. It's required because it has a different legal note than the usual 0% EU tax. --- Desired behavior after this commit is merged: The italian localization has a 0% EU S for exported services in EU with the right legal note. --- task-4715771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223423 Forward-Port-Of: odoo/odoo#205521
This fix protects a hidden search setting from being accidentally removed while editing website content. It prevents save errors and keeps website search forms working reliably after page edits.
Original PR description
Problem: In Website, the `order_by` hidden input stores the selected sort order for search. This input can currently be deleted via `oDeleteBackward`, which may break the form behavior. Solution: Make `order_by` input unremovable to ensure form integrity. Steps to reproduce: - Add a "Title" text block - Insert a search element before the text - Delete all the text - Use backspace to delete the header block - Save - > A traceback occurs because the `order_by` input was deleted opw-4863089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220107
This update fixes internal spreadsheet test utilities so they can handle sorted data consistently. It helps improve the reliability of spreadsheet-related testing, reducing the chance of regressions reaching users.
Original PR description
Task: 4962837 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 fix ensures invoice sending options and extra electronic invoicing choices are handled consistently across accounting and localization modules. It reduces the risk of duplicate or incorrectly processed sending methods when generating or sending electronic invoices.
Original PR description
It seems pretty straight forward. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an inconsistent automated test failure in the sales stock area by ensuring the test product has the expected stock behavior and quantity. It helps keep validation reliable when localization modules affect inventory rules.
Original PR description
Steps to reproduce the bug: - Install l10n_ke_edi_oscu_stock -Try to run the test: test_package_with_moves_to_different_location_dest Problem: A user error is raised: “There is nothing eligible to put in a pack. Either there are no quantities to put in a pack or all products are already in a pack.” This happens because when only sale_stock is installed, the product type is Consumable, so the move gets assigned directly. However, with l10n_ke, the product becomes Storable, and when assigning the move, the system checks whether there is enough quantity available in stock. Solution: Force the product to remain Storable in all cases and update its stock quantity accordingly. [runbot-108414](https://runbot.odoo.com/odoo/runbot.build.error/108414) Forward-Port-Of: odoo/odoo#222940
Payroll advice reports now use the selected payslips to determine the payroll period instead of relying on the current date. This prevents incorrect or missing period information when generating advice for past payroll runs.
Original PR description
Generating a payroll advice would use the current date in order to find other payslips that are for the current period and use this to fill in the period on the advice. However, if you do this for a past payslip, it will either not find any or get the incorrect period. Changed the behavior to use the actual payslips and get the period from those payslips to fill in the period on the report. opw-4582990
This update makes an automated test for embedded PDF handling work consistently whether an optional file-detection library is installed or not. It helps keep the Documents and Accounting integration stable across different deployment and testing environments without changing user-facing features.
Original PR description
The test `test_embedded_pdf` fails when the magic lib is installed. modified cherry-pick of 22cbdb477 Adapted to work with or without the lib as the lib is not required in version < 19.0.
The French VAT report configuration has been updated to use the 2025 reporting year. This keeps the report aligned with the latest official version and avoids automated server test failures while leaving the VAT export content unchanged.
Original PR description
The version for 2025 is out. As far as we can see, the changes don't concern the export of VAT report. So we just change the value to 2025. (2024 non blocking for prod is still accepted in 2025 but it fails for the server test). task-4617663 Forward-Port-Of: odoo/enterprise#92542
The Planning app no longer shows the auto-plan action for shifts that do not yet have a start or end date. This prevents users from triggering an error when working with unscheduled shifts from sales planning.
Original PR description
**Step to reproduce:** 1. Install sale_planning module 2. Create a product (Sales -> Products): - Set Product Type to Service - Enable Plan Services - Assign both a Planning Role and resources. 3.…
**Step to reproduce:**
1. Install sale_planning module
2. Create a product (Sales -> Products):
- Set Product Type to Service
- Enable Plan Services
- Assign both a Planning Role and resources.
3. Create a sales order for this product.
4. Confirm the Sales Order.
5. Click the "To Plan" button.
6. Switch to List View.
7. Open the Unscheduled Shifts (None) section.
8. Try to generate an Auto Plan.
**Issue:**
A traceback is raised during auto-planning when the start_datetime or end_datetime on the planning slot is missing.
`AttributeError: 'bool' object has no attribute 'astimezone'`
**Cause:**
The `auto_plan_ids()` method assumes that shifts have valid start_datetime and end_datetime.
However, for unscheduled shifts, these fields can be empty (i.e., False), causing the error.
https://github.com/odoo/enterprise/blob/42d829ea6e6a98f251cfffc8fb67b5320a5ada12/planning/models/planning.py#L1076-L1077
**Solution:**
we hide the auto-plan button, in case we do not have startdate or enddate
opw-4812509
co-authored by: Ajit Singh (aksi@odoo.com)
Forward-Port-Of: odoo/enterprise#89383Opening the list side panel in spreadsheets now works even when a saved sort refers to a field that was later removed or renamed. This lets users access the panel and remove the invalid sorting instead of being blocked by a crash after an upgrade.
Original PR description
If a list is sorted on an invalid field and you try to open the list side panel, it crashes. It should open to allow the user to remove the sorting. A list with an invalid sorting field if the spreadsheet was created in a given version, then upgrades to a version where that field has been removed or renamed. Task: 4962837
WhatsApp template previews no longer mistake underscores inside links or similar text for italic formatting. This prevents portal links and other URL values from being displayed incorrectly, while normal italic formatting with spaced underscores still works as expected.
Original PR description
Steps to reproduce: 1. Go to a WhatsApp template, for e.g. Sale Order. 2. Update the sample value for the Portal Link variable to include an underscore. 3. Click on Preview Issue: Due to the current…
Steps to reproduce: 1. Go to a WhatsApp template, for e.g. Sale Order. 2. Update the sample value for the Portal Link variable to include an underscore. 3. Click on Preview Issue: Due to the current regex, we will apply italic to any underscore we find which is not ideal, mostly when we work with URLs that can contain underscores like "acces_token" which we will try to apply italic to it too. Solution: Following the most common logic for italic formatting, we will only apply italic formatting when the underscore is surrounded by whitespace. This is the same way it already behaves in Whatsapp. If we write it like_this_for example, it will not apply italic formatting, but if we write it like this _this_ it will apply italic formatting. So this for example: **"If we write it like_this_for example"** Will be like - before the fix: **"If we write it like<i>this</i>for example"** Will be like - after the fix: **"If we write it like_this_for example"** opw-4720017 Forward-Port-Of: odoo/enterprise#91217
Currently an exception is generated due to the variables translated into the `Spanish (Latin America)` language. `KeyError: 'tipo'` This commit fixes the issue by using the original variable name instead of translated terms. sentry-6046430921
Original PR description
Currently an exception is generated due to the variables translated into the `Spanish (Latin America)` language. `KeyError: 'tipo'` This commit fixes the issue by using the original variable name instead of translated terms. sentry-6046430921