Wednesday, August 20, 2025
42 changes · saas-18.4
Enhancements to existing features
The accounting tax helper documentation was improved to make it clearer which capabilities are available in point-of-sale JavaScript code and which are only available on the server side. This helps teams avoid confusion when maintaining tax-related logic across different parts of the system.
Original PR description
Since some of them are copy pasted javascript side, adding such docstring is helping to distinguish what is available directly js-side from point_of_sale from what is only accessible python-side. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223330 Forward-Port-Of: odoo/odoo#223258
Point of Sale and related payment, loyalty, restaurant, and self-order modules now produce clearer diagnostic logs. This helps support and development teams identify where POS issues occur faster, reducing investigation time without changing the customer-facing checkout flow.
Original PR description
*: pos_adyen, pos_loyalty, pos_online_payment, pos_restaurant, pos_stripe Improve console logging in the Point of Sale and related modules. By using the `logPosMessage` utility function more…
*: pos_adyen, pos_loyalty, pos_online_payment, pos_restaurant, pos_stripe Improve console logging in the Point of Sale and related modules. By using the `logPosMessage` utility function more informations are now included in the console logs, such as the module name, function name, and a message. This makes it easier to track down issues and understand the flow of the application. Also when unfolding the console logs, some additional context is provided: - Variable values (if given to the console method) - Call stack trace (if available) Example of a log message: [IndexedDB]: put - Processing 40 items in store pos.order.line ### With its call stack: logPosMessage @ pretty_console_log.js:13 (anonymous) @ indexed_db.js:113 promises @ indexed_db.js:92 create @ indexed_db.js:193 synchronizeLocalDataInIndexedDB @ data_service.js:182 ..... ## Screenshots: <img width="779" height="764" alt="image" src="https://github.com/user-attachments/assets/6be024e4-e849-478b-9cdd-653300fc015a" /> https://github.com/user-attachments/assets/2342ca52-719c-4368-94e6-1e692faf12e0 Forward-Port-Of: odoo/odoo#222339
Users now receive a clear warning when enabling WhatsApp debug mode. This helps prevent surprises by explaining that media files will stop being received while debug mode is active.
Original PR description
#### Step to reproduce: - go to WhatsApp > Configuration > WhatsApp Buisness Account - enable debug mode #### Previous behavior: - active debug mode #### Expected behavior: - active debug mode - warn user that WhatsApp debug mode will stop medias from being received Other solutions would include the use of: - warning. They are triggered only on `onchange` methods. However, debug_logging is updated through buttons which do not trigger `onchange`. Therefore, to update it through a field it requires some changes in the XML which aren't appropriate for stable. - confirm using a wizard. It would require a new view which is not stable either. opw-4678542 Forward-Port-Of: odoo/enterprise#89995
The website generator now checks whether a provided URL can be reached before starting the scraping step. This helps avoid failed generation attempts and gives users a smoother setup experience when entering website addresses.
Original PR description
This commit checks that the URL is reachable before making the scraper request.
Point of Sale and related localization, IoT, enterprise, and mobile modules now produce clearer console logs with more context. This helps support and development teams diagnose POS issues faster without changing day-to-day user workflows.
Original PR description
*: l10n_de_pos_cert, l10n_de_pos_res_cert, l10n_it_pos, pos_enterprise, pos_iot, pos_mobile Improve console logging in the Point of Sale and related modules. By using the `logPosMessage` utility…
*: l10n_de_pos_cert, l10n_de_pos_res_cert, l10n_it_pos, pos_enterprise, pos_iot, pos_mobile Improve console logging in the Point of Sale and related modules. By using the `logPosMessage` utility function more informations are now included in the console logs, such as the module name, function name, and a message. This makes it easier to track down issues and understand the flow of the application. Also when unfolding the console logs, some additional context is provided: - Variable values (if given to the console method) - Call stack trace (if available) ## Example of a log message: [IndexedDB]: put - Processing 40 items in store pos.order.line ### With its call stack: logPosMessage @ pretty_console_log.js:13 (anonymous) @ indexed_db.js:113 promises @ indexed_db.js:92 create @ indexed_db.js:193 synchronizeLocalDataInIndexedDB @ data_service.js:182 ..... ## Screenshots: <img width="779" height="764" alt="image" src="https://github.com/user-attachments/assets/6be024e4-e849-478b-9cdd-653300fc015a" /> https://github.com/user-attachments/assets/2342ca52-719c-4368-94e6-1e692faf12e0 Forward-Port-Of: odoo/enterprise#92021
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
Code cleanup and technical improvements
This change moves tab block testing into the HTML builder area so it can be checked without pulling in broader website builder dependencies. It helps keep internal test coverage better organized and makes future validation faster and more focused, with no expected impact on end users.
Original PR description
**Description of the issue/feature this PR addresses:** The block_tab test module was located within website/builder tests, creating unnecessary dependencies when testing html_builder. **Current behavior before PR:** - block_tab tests are part of the website_builder test suite - Testing html_builder requires loading website dependencies - **Desired behavior after PR is merged:** - block_tab tests are located within html_builder tests and run successfully - html_builder can be tested independently without website_builder dependencies --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
This change updates the Adhoc corporate contributor agreement record by adding new members. It keeps the project's legal contributor documentation current, with no expected impact on product features or users.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223312
Miscellaneous changes
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
Design Themes: https://github.com/odoo/design-themes/pull/1059 Enterprise: https://github.com/odoo/enterprise/pull/84782 Forward-Port-Of: odoo/odoo#208609
Original PR description
Design Themes: https://github.com/odoo/design-themes/pull/1059 Enterprise: https://github.com/odoo/enterprise/pull/84782 Forward-Port-Of: odoo/odoo#208609
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#209110
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209110
Community: https://github.com/odoo/odoo/pull/208609 Design Themes: https://github.com/odoo/design-themes/pull/1059 Forward-Port-Of: odoo/enterprise#84782
Original PR description
Community: https://github.com/odoo/odoo/pull/208609 Design Themes: https://github.com/odoo/design-themes/pull/1059 Forward-Port-Of: odoo/enterprise#84782