Daily updates from Odoo
Wednesday, August 27, 2025
51 changes
16 changes
Resolved issues and error corrections
The Belgian payroll SD Worx export now works with the updated employee version model in saas-18.4. This prevents an error when generating the export file, helping payroll teams complete their reporting workflow reliably.
Original PR description
#### Steps to Reproduce Payroll -> Reporting -> Export Work Entries to SDWorx -> Generate Export File #### Issue In saas-18.4, contracts have been merged into employee versions (`hr.version`) and the contract states (open/close) were removed ([REF] hr_contract: Merge contracts into versioned employee model). The method `_get_versions_with_contract_overlap_with_period` no longer supports the `states` keyword. Passing it caused a traceback when generating the SD Worx export. #### Fix This commit removes the argument to ensure compatibility with the new versioned model. task-5022173
This update adds test coverage to ensure bank statement reconciliation keeps working when no payment account is configured. It helps prevent regressions in accounting workflows that could disrupt finance teams reconciling bank statements.
Original PR description
Add a test to previous fix: https://github.com/odoo/enterprise/commit/582e3ee22cba404ff38782534e76569bc93a44ef opw-5039931 opw-5039807 Forward-Port-Of: odoo/enterprise#93182
This fix prevents an error when refunding Point of Sale orders that include a global discount line under the Mexican localization. Businesses can now process these refunds from the back end without interruption, improving reliability for store operations.
Original PR description
**Steps to reproduce:** ``` - Install PoS mexican localization - Activate PoS setting Global Discounts - Navigate to PoS and create an order with a discount line - Go to back end and try to refund this order - Notice an error pops-up ``` **Cause:** Bad fw-port In the original commit `json.lines` is an array and accessing index "2" of the array was not a problem (https://github.com/odoo/enterprise/pull/84331/files#diff-63a117ed6751a8aae4fcb11d867177f5d0feb78cc1e2f3461f425babc10b5016R15) From 18.0 we are accessing the record `currentOrder` itself and `currentOrder.lines` is an PosOrderline object which doesn't have a property named "2". **Fix:** Remove index access `[2]` opw-4899501 Forward-Port-Of: odoo/enterprise#93042 Forward-Port-Of: odoo/enterprise#90410
This fix prevents the Point of Sale from showing an error when an order is unavailable or has not been loaded. It helps keep payment settlement workflows stable and avoids disruptions for staff using POS.
Original PR description
Before this commit, accessing the order amount caused an error if the order was not defined. opw-5027426 Forward-Port-Of: odoo/enterprise#92928 Forward-Port-Of: odoo/enterprise#92736
This fix ensures negative Swiss payroll lines are posted to the correct opposite accounts. It helps keep payroll accounting entries accurate, reducing manual corrections and improving financial reporting reliability.
Original PR description
…r 2050 Invert accounts for negative payslip line Forward-Port-Of: odoo/enterprise#93074
The Belgian POS Blackbox integration now shows clearer messages when the device cable is faulty or the Blackbox sends an invalid response. This helps store staff understand connection problems faster and supports better issue logging for troubleshooting.
Original PR description
This PR adds some explicit messages to invalid responsed from the Blackbox. We will now log and inform the user when the cable is malfunctioning or the blackbox isn't responding with a valid message Forward-Port-Of: odoo/enterprise#90570 Forward-Port-Of: odoo/enterprise#90436
This update fixes an automated guided tour used in the Field Service reporting area so it waits for the correct button before continuing. This helps keep quality checks reliable and reduces false failures during testing, with no expected impact on day-to-day users.
Original PR description
In this commit, we fix the tour industry_fsm_tour by removing "body:not(.modal-open) nav.o_main_navbar" (this trigger is always true) from trigger to let only button[name="action_generate_new_template"]. Forward-Port-Of: odoo/enterprise#93169 Forward-Port-Of: odoo/enterprise#91771
When an employee signs a salary contract and is assigned as a future driver, the related car or bike is no longer incorrectly shown as available. This helps HR and fleet teams avoid double-booking vehicles and keeps fleet planning accurate.
Original PR description
Issue: When a contract was signed and a future driver was assigned to a vehicle, the car still remained marked as available. Fix: Once the first signature is completed and the future driver is assigned, the vehicle is correctly marked with plan_to_change_car = False (the same applies to the bike). Related task: 4926335. Forward-Port-Of: odoo/enterprise#89774
This fix prevents appointment video call links from failing when several calendar events are processed at once. It helps ensure users are redirected correctly to their video appointments without interruption.
Original PR description
When computing `videocall_redirection`, the method `get_base_url()` was called directly on a recordset containing multiple `calendar.event` records. Since `get_base_url()` expects a singleton, this raised the error: Traceback: --- `ValueError: Expected singleton or no record: calendar.event(4, 6, 1, 5)` This commit ensures the computation is done per record, avoiding the singleton issue and allowing correct videocall redirection values to be set on multiple events. Reference review: https://github.com/odoo/enterprise/pull/53569#discussion_r1543135425 sentry-6819406171 Forward-Port-Of: odoo/enterprise#92717
Employee appraisal skill records now keep extra information, such as justification notes, when a skill level is updated or copied. This prevents important context from being accidentally erased during normal appraisal updates.
Original PR description
Allow models that inherit the hr_individual_skill mixin to specify additional fields to be included/preserved/carried-over when writing/creating new skill records. This was already an issue in the `hr_appraisal_skill` module where the `Justification` field was not included when copying/creating new skills. As a result, the field was "erased" on every skill level change task-4984689
This fixes an issue where changing a product image layout in the website editor could stop the Add to cart button from working for rental and subscription products. The checkout form is now found correctly even when the page layout places the button outside its usual position, helping shoppers complete purchases without interruption.
Original PR description
## Version saas-18.4+ ## Steps to reproduce - Open the shop; - Select any product; - Open the Editor: - Select the product's main image; - Change the image width to either `100 percent` or `None`,…
## Version
saas-18.4+
## Steps to reproduce
- Open the shop;
- Select any product;
- Open the Editor:
- Select the product's main image;
- Change the image width to either `100 percent` or `None`, then save;
- Click on `Add to cart`.
## Issue
Commit eac892a4ad7373d18f954afbbcd2f1213ac5f281 introduced a UI update that reorganizes the layout of the product configurator, placing the `Add to cart` button next to the form rather than below it.
Although the button remains inside the form in the original template, using the Editor to adjust the layout can result in the button being saved outside the `<form>` element in the final DOM.
This breaks the logic that relies on `closest('form')` to locate the surrounding form, since the button is no longer a descendant of the form element.
## Solution
Find the first product form relative to the button, since it may be a sibling rather than an ancestor in the DOM.
opw-4942986
See also:
- https://github.com/odoo/odoo/pull/218902A missing setup field was added to Point of Sale enterprise tests so they run correctly when the module is installed. This helps keep automated checks reliable and prevents false build failures without changing customer-facing behavior.
Original PR description
steps to reproduce: 1. install pos_enterprise 2. run the test `test_should_not_affect_other_pos_config` or `test_is_header_or_footer_to_false` this commit adds the missing_field `account_tax_return_journal_id` to the test build_error-230301 Forward-Port-Of: odoo/enterprise#90995
Document link previews now open the correct video when users preview multiple YouTube links. This prevents confusion by ensuring each saved link shows its own preview rather than reusing the most recently added one.
Original PR description
**Steps to reproduce:** 1. Go to Documents > Click ⬇ beside Upload > Add a Link 2. Add two different YouTube video URLs with above steps 3. Preview the first link, then the second **Issue:** Previewing individual YouTube links always displays the preview of the *last* added video, regardless of which one was clicked. **Cause:** When a document has no `attachment_id`, the preview fallback logic defaults incorrectly, causing all documents to share the same preview source. **Solution:** Updated `getRecordAttachment` to prioritize `attachment_id` but gracefully fallback to `rec.resId` and `rec.data.name` when missing. This ensures document preview works even when the record has no linked attachment. opw-4906808 Forward-Port-Of: odoo/enterprise#92491 Forward-Port-Of: odoo/enterprise#90388
This fixes a checkout issue where changing a product image layout in the website editor could make the Add to Cart and wishlist buttons stop working. The storefront now finds the correct product form even when the page layout places the button outside its usual position, helping customers complete purchases reliably.
Original PR description
## Version saas-18.4+ ## Steps to reproduce - Open the shop; - Select any product; - Open the Editor: - Select the product's main image; - Change the image width to either `100 percent` or `None`,…
## Version
saas-18.4+
## Steps to reproduce
- Open the shop;
- Select any product;
- Open the Editor:
- Select the product's main image;
- Change the image width to either `100 percent` or `None`, then save;
- Click on `Add to cart`.
## Issue
Commit bbb2d98d9ab97ce729d59b9858b63daccf5434e2 introduced a UI update that reorganizes the layout of the product configurator, placing the `Add to cart` button next to the form rather than below it.
Although the button remains inside the form in the original template, using the Editor to adjust the layout can result in the button being saved outside the `<form>` element in the final DOM.
This breaks the logic that relies on `closest('form')` to locate the surrounding form, since the button is no longer a descendant of the form element.
## Solution
Find the first product form relative to the button, since it may be a sibling rather than an ancestor in the DOM.
opw-4942986
See also:
- https://github.com/odoo/enterprise/pull/90631This fix prevents certain IoT-connected printers from disappearing when their connection method briefly changes during availability checks. Businesses can keep printing reliably because the system recognizes the printer by its IP address and preserves the existing print queue entry.
Original PR description
Some printers (`lpd...PASSTHRU`s for example) tend to disappear when checking available printers list. They are often switching between one time `lpd...PASSTHRU` and the second time `socket...` protocols. As we get ip addresses for printers, we now check if the new protocol still correspond to the same printer, and if so, we keep the old one. As the printer will still be in the cups queue list, it will still be able to print through it.
This fix prevents users from seeing an error when they complete a scheduled activity linked to an approval rule that has since been deleted. It keeps the activity workflow stable in Web Studio by safely handling cases where no approval rules remain.
Original PR description
An error occurs when a user attempts to mark a scheduled activity as done after the associated approval rule has been deleted. **Steps to Reproduce:** 1) Install Sales and Web Studio modules. 2) Log…
An error occurs when a user attempts to mark a scheduled activity as done after the associated approval rule has been deleted. **Steps to Reproduce:** 1) Install Sales and Web Studio modules. 2) Log in as Admin and use Studio to add an approval rule to the Sale Order’s Preview button. >- Set Allowed Group to Access Rights. >- Set Responsible User to Mitchell Admin. 3) In the Incognito Tab, login as Demo, open the same sale order and click on preview to create activity in chatter. 4) Delete the Approval Rule in the original tab. 5) Switch back to Demo and click Mark Done under Planned Activity in chatter. **Error:** `SyntaxError: syntax error at or near ')'` `LINE 1: SELECT id FROM studio_approval_rule WHERE id IN () FOR UPDAT. ^` **Root Cause:** The error occurs because the SQL query at [1] includes an empty tuple of rule IDs `(all_rule_ids)`. An empty `IN ()` clause in SQL results in a syntax error. [1]- https://github.com/odoo/enterprise/blob/7ea45724e7689a0df11d20ace9c562788f5d19e3/web_studio/models/studio_approval.py#L366 **Solution:** This commit avoids the error by ensuring that the SQL query only runs when `all_rule_ids` is not empty. sentry-6306636466 Forward-Port-Of: odoo/enterprise#86982
9 changes
Resolved issues and error corrections
The scheduled subscription invoicing process now looks beyond the initial batch before deciding whether more work should be triggered. This prevents eligible subscriptions from being skipped when earlier records in the batch are not ready to invoice, helping invoices run on time.
Original PR description
Change was introduced here https://github.com/odoo/enterprise/pull/82340 that caused the cron trigger to not be activated if any of the 31 in the batch of subscriptions found was not to invoice. This is problematic because there could be other subscriptions that meet the domain requirements and the to invoice requirements that are not being seen because the limit is on the search before we check invoiceability. Added a limit to _get_subscriptions_to_invoice instead of on the search in order to take into account both filters for next cron triggers. opw-4850884 Forward-Port-Of: odoo/enterprise#92690 Forward-Port-Of: odoo/enterprise#89787
Appointment video call redirection now works correctly when several calendar events are processed at once. This prevents an error that could block or break video call link setup for multiple appointments.
Original PR description
When computing `videocall_redirection`, the method `get_base_url()` was called directly on a recordset containing multiple `calendar.event` records. Since `get_base_url()` expects a singleton, this raised the error: Traceback: --- `ValueError: Expected singleton or no record: calendar.event(4, 6, 1, 5)` This commit ensures the computation is done per record, avoiding the singleton issue and allowing correct videocall redirection values to be set on multiple events. Reference review: https://github.com/odoo/enterprise/pull/53569#discussion_r1543135425 sentry-6819406171 Forward-Port-Of: odoo/enterprise#92717
Fixes an error that could occur when setting a Pricer Sales Pricelist on a product variant. Users can now update this field without interruption, including while working with newly created product records.
Original PR description
Steps to Reproduce: ---------------------------------- - Open the product variant form - Set the Pricer Sales Pricelist field - Traceback Issue: ---------------------------------- - `TypeError: ProductPricelist._compute_price_rule() takes 3 positional arguments but 4 were given` Cause: ---------------------------------- - `_get_product_price()` was calling `_compute_price_rule()` with positional args instead of named quantity - If the product record is not yet created (`product._origin` is False), it skips price computation logic Fix: ---------------------------------- - Pass `quantity=1.0` explicitly to `_compute_price_rule()` to resolve the argument mismatch - Handle case where `product._origin` is False by falling back to `product` itself Task-4888983 Forward-Port-Of: odoo/enterprise#92702 Forward-Port-Of: odoo/enterprise#88321
This fixes a crash that could happen when a user marked a planned activity as done after its related Studio approval rule had been deleted. Users can now complete those activities without being blocked by an error, improving reliability in approval workflows.
Original PR description
An error occurs when a user attempts to mark a scheduled activity as done after the associated approval rule has been deleted. **Steps to Reproduce:** 1) Install Sales and Web Studio modules. 2) Log…
An error occurs when a user attempts to mark a scheduled activity as done after the associated approval rule has been deleted. **Steps to Reproduce:** 1) Install Sales and Web Studio modules. 2) Log in as Admin and use Studio to add an approval rule to the Sale Order’s Preview button. >- Set Allowed Group to Access Rights. >- Set Responsible User to Mitchell Admin. 3) In the Incognito Tab, login as Demo, open the same sale order and click on preview to create activity in chatter. 4) Delete the Approval Rule in the original tab. 5) Switch back to Demo and click Mark Done under Planned Activity in chatter. **Error:** `SyntaxError: syntax error at or near ')'` `LINE 1: SELECT id FROM studio_approval_rule WHERE id IN () FOR UPDAT. ^` **Root Cause:** The error occurs because the SQL query at [1] includes an empty tuple of rule IDs `(all_rule_ids)`. An empty `IN ()` clause in SQL results in a syntax error. [1]- https://github.com/odoo/enterprise/blob/7ea45724e7689a0df11d20ace9c562788f5d19e3/web_studio/models/studio_approval.py#L366 **Solution:** This commit avoids the error by ensuring that the SQL query only runs when `all_rule_ids` is not empty. sentry-6306636466 Forward-Port-Of: odoo/enterprise#86982
Employee appraisal skill records now keep important extra information, such as the justification text, when skill levels are changed or copied. This prevents appraisal details from being unintentionally erased and helps maintain a complete employee evaluation history.
Original PR description
Allow models that inherit the hr_individual_skill mixin to specify additional fields to be included/preserved/carried-over when writing/creating new skill records. This was already an issue in the `hr_appraisal_skill` module where the `Justification` field was not included when copying/creating new skills. As a result, the field was "erased" on every skill level change task-4984689 Forward-Port-Of: odoo/enterprise#91772
Reopening a selection or numeric global filter in spreadsheets now replaces the current side panel instead of opening an extra one. This creates a more consistent editing experience and avoids confusing duplicate panels for users working with spreadsheet filters.
Original PR description
This commit aligns the behaviour of reopening the global filter side panel with the imp introduced in commit: https://github.com/odoo/enterprise/pull/92483/commits/60ceb8bd1188fdd14fdf72bac46a445e688f3683 Current behavior before PR: - Reopening a selection/numeric global filter side panel showed the previous behaviour (opening a new panel instead of replacing it). Desired behavior after PR is merged: - The same behaviour as in the commit applied: reopening side panel from a child now replaces the current one instead of opening a new side panel. Task: 5034264
Fixes an issue where adjusting the checkout time from the weekly Attendance view could save the current time instead of the time selected by the user. This helps keep employee attendance records accurate when managers edit checkout times in the Gantt interface.
Original PR description
Steps to Produce: - Go to the Attendance interface and select week. - Drag the second half of the column to adjust checkout. - Save the change. Issue: - Dragging on half cell deletes the checkout value from the context. - As a result, the system sets the checkout time to the current time instead of the dragged value. - This leads to incorrect attendance records. Fix: - Ensure the checkout value remains in the context when dragging the cell. - Preserve the modified checkout time so it reflects the user's intended change instead of defaulting to the current time. Task-4958060 Forward-Port-Of: odoo/enterprise#93092 Forward-Port-Of: odoo/enterprise#91119
Fixed an issue in Odoo Sign where initials selected in the Add Initials dialog could be added but not shown on multi-page PDFs. Users now see their initials immediately on the document, whether applied to one page or all pages.
Original PR description
Issue: * When uploading a multi-page PDF and choosing an option in the `Add Initials` dialog, the initials were not visible. * This happened because the old `postRender` used to call `refreshSignItems`, but that code was removed in a recent refactor. Fix: * Call `refreshSignItems()` directly after inserting the initials. * Ensures initials appear immediately whether added on one page or across all pages. Impact: * Users now see their initials properly rendered on the document after making a choice in the dialog.
This fix prevents the Point of Sale from showing an error when an order is unavailable while checking the amount due. It helps cashiers continue their workflow smoothly in edge cases where order data is missing.
Original PR description
Before this commit, accessing the order amount caused an error if the order was not defined. opw-5027426 Forward-Port-Of: odoo/enterprise#92928 Forward-Port-Of: odoo/enterprise#92736
26 changes
Resolved issues and error corrections
This fix ensures inherited property fields are correctly recalculated from their linked source after cached data is missing. It helps prevent incorrect or missing values from appearing in business records that rely on inherited properties.
Original PR description
inherited properties should be computed from its related field after cache miss 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#224359
Manufacturing orders created from sales for products with an empty bill of materials now stay in draft instead of being automatically confirmed. This prevents users from ending up with confirmed orders that have nothing to produce or track, giving them time to add any needed details first.
Original PR description
Issue Before This Commit: ============================ Currently, if a BOM has `no components or operations` and is triggered via `MTSO`, the generated Manufacturing Order (MO) is automatically set to a `confirmed` state. This behaviour is inconsistent and not meaningful, as there's nothing to produce or track. Steps to Reproduce: ============================ - Install the `mrp and sale` module. - Enable MTSO route. - Create a product with a BOM that has `no components or operations`. - Create a sale order for that product. MO is created in a `confirmed` state. With This Commit: ============================ This commit ensures that MOs triggered via `MTO(Already worked) or MTSO` are created in draft state if their BOM has no components and no operations. This allows the user to manually add required details before confirming the MO. supporting custom use cases. TaskID:- 4920195
Fixes form save warnings so they can open the intended follow-up action with the correct extra information. This helps users resolve save-blocking issues directly from the warning instead of being left in a broken or incomplete flow.
Original PR description
Have a web_save that raises a RedirectWarning which has the ID of an action and an additional context in its parameters. Trigger the warning in the form view by clicking on the save button in the form view. Before this commit, this feature did not work like at all. - The additional context was not taken into account - the path taken by clicking on the form's save button was not able to handle interacting with the main form view - The error dialog did not handle going into an action in target other than new After this commit, all this is fixed and the whole flow, that allow an error to be enriched such that the user could do the correct action to correct the error now works. opw-4742952 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#223198
Fixed an issue in Point of Sale restaurants where combo items could lose their link to the main combo product after table synchronization. This helps ensure orders remain accurate and easier for staff to manage when customers or order details are updated.
Original PR description
When one of the combo line is marked as "Dirty", it would be synched but it would remove it's link to the combo parent. Steps to reproduce: ------------------- * Create a combo product * Open a PoS restaurant * Open a table, and add the combo product * Leave the table to synchronize the order with the backend * Go back on the table and select a partner * This will mark the combo line as "dirty" * Leave the table again to synchronize the order with the backend * Go back on the table > Observation: The combo now appears as a normal product, not linked to the combo parent. Why the fix: ------------ When marking a line as "dirty", we now make sure to also mark it's combo parent as "dirty" so that it will be synchronized correctly. And keep the link to the combo parent. opw-4950262
Fixes an error that could interrupt users editing a sales order when multiple linked invoices are shown on the form. This makes the sales order editing experience more reliable for customers using Studio customizations with invoice information.
Original PR description
**Step to reproduce** - create a SO - link 2+ invoices to it - using studio, add invoice_ids to the SO Form - trigger a onchange (ex. change the product from SOL) - we receive a traceback…
**Step to reproduce** - create a SO - link 2+ invoices to it - using studio, add invoice_ids to the SO Form - trigger a onchange (ex. change the product from SOL) - we receive a traceback **Traceback:** ```ValueError: Expected singleton: account.move(<NewId origin=35>, <NewId origin=31>, <NewId origin=32>, <NewId origin=33>, <NewId origin=34>)``` **Issue:** - from `onchange` triggers chain,`_compute_duplicated_ref_ids` is invoked calling `_fetch_duplicate_reference` for the related moves (invoice_ids) such that as they are in create/edit mode - at this time `convert_to_write(moves[field_name], moves)` fails as moves has more than 1 record and `recordset[field]` is not valid syntax in such case https://github.com/odoo/odoo/blob/3966753eb5a8534c8b5b8a16e626f5250c9013cf/addons/account/models/account_move.py#L1868-L1884 - hence, we receive valueError, expecting a singleton **Fix;** - we adapt the method to accept multiple moves which may be in create/edit mode opw-4959528 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where older point-of-sale refunds that combined items from multiple original orders could fail after upgrading. Businesses can now view those refund orders and complete upgrades without this data compatibility error blocking the process.
Original PR description
In saas~17.1, the field `refunded_order_id` was changed from a Many2Many to a Many2One, as refunding lines from different orders with the same order was no longer possible. The problem is that there were no changes applied to the existing data to account for this, so databases with those kind of refunds will trigger an error when the field is computed: ``` ValueError: Wrong value for pos.order.refunded_order_id ``` This behaviour can also break upgrades if the error happens during the mock crawl test after the upgrade. To reproduce: - In 17, create an order refunding products from different orders. - Upgrade to 18. - Try to view the refunding order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Submitting a website “Send Email” form without a recipient email now avoids an error that previously blocked the form. This makes website forms more reliable for users configuring email actions through the website editor.
Original PR description
Currently, an error occurs when submitting the 'Send Email' form. **Steps to Reproduce:** - Install the `website` and `web_studio` modules. - Go to `website` > Click on `Edit` > `Drag and drop form`.…
Currently, an error occurs when submitting the 'Send Email' form. **Steps to Reproduce:** - Install the `website` and `web_studio` modules. - Go to `website` > Click on `Edit` > `Drag and drop form`. - Click the `form` and in `Actions` select the `more models`, and select `outgoing mails(mail.mail)` model and `save`. - Fill out the form and `Submit`. **Error:** `KeyError: 'website_form_signature'` **Cause:** This error occurs after [this commit](https://github.com/odoo/odoo/commit/70fa5af872524ea271113851c050297ef50efa45), when submitting the "Send Email" form from the website. If the form is saved without entering the recipient's email (email_to). As a result, the `email_to` field is not present in the form. The `website_form_signature` is added from [1], but due to the condition at [2], the code at [1] is not executed. And when it is accessed at [3], KeyError is raised. [1]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252 [2]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236 [3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88 **Fix:** This commit ensures that 'website_form_signature' is used if it is available in kwargs. sentry-6746753251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A CRM interface test that could fail under simulated time settings is now skipped in that mode. This keeps automated testing more reliable without changing how users experience CRM features.
Original PR description
When using the faketime mode for testing, the crm_rainbowman tour fails because the underlying SQL query is using `CURRENT_DATE`. Unfortunately, this SQL keyword cannot be replaced globally by a function easyly (like it was done for the NOW function in faketime mode). ~~With this commit, the SQL query is adapted to use the SQL NOW function instead.~~ With this commit, the tour will be skipped in faketime mode Forward-Port-Of: odoo/odoo#223909
The debug Data view no longer crashes when a record includes custom property fields. This helps administrators and support teams inspect record information reliably during troubleshooting, including in CRM forms with added property fields.
Original PR description
Example Steps: - Install `crm` - Add a random field properties in a random form view - Enable debug mode - Open debug menu - Select Data - Traceback ```py raise ValueError(f"Invalid field…
Example Steps:
- Install `crm`
- Add a random field properties in a random form view
- Enable debug mode
- Open debug menu
- Select Data
- Traceback
```py
raise ValueError(f"Invalid field {field_name!r} on model {self._name!r}")
ValueError: Invalid field 'properties.xyz' on model 'x.y'
```
There are two causes for this problem.
First, we use orm.read to retrieve data from records, which does not directly handle sub-field properties. We only need to use `definition_property` (which contains the overall schema of the JSON field).
Second, when displaying the data, we use JSON.stringify with `replacer`:
```js
get content() {
const record = this.props.record;
return JSON.stringify(record, Object.keys(record).sort(), 2);
}
```
In this case, replace contains all the keys present in record, sorted. The problem is that the properties fields are themselves objects that contain the keys: `name`, `string`, `type`, `default`, `value`.
And giving an array to replace in `JSON.stringify` will filter the keys and keep only those that are whitelisted in it.
```js
// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify
const foo = {
foundation: “Mozilla”,
model: “box”,
week: 45,
transport: “car”,
month: 7,
};
JSON.stringify(foo, [“week”, “month”]);
// ‘{“week”:45,“month”:7}’, only keep ‘week’ and “month” properties
```
This will ignore the keys of the properties fields.
The fix is therefore to sort the object before stringifying it, without using replace.
Thanks to these two fixes, the data is displayed as expected, regardless of whether there are field properties or not.
opw-5017425This fix prevents errors and unwanted visual effects when website blocks use both gradient and image backgrounds. Users can now switch image display modes such as repeat pattern or parallax without causing console errors or making gradients repeat incorrectly.
Original PR description
*=website Target: 17.0 to saas-18.3 Issue: This issue applies to any block where multiple backgrounds are present (gradient + image). Steps to Reproduce: 1. Drop a masonry snippet onto the page. 2.…
*=website Target: 17.0 to saas-18.3 Issue: This issue applies to any block where multiple backgrounds are present (gradient + image). Steps to Reproduce: 1. Drop a masonry snippet onto the page. 2. Select a block and change the background color to the gradient. 3. Add background image. 3. Change the image position from "Cover" to "Repeat Pattern." 4. Observe the traceback in the console. Reason: The issue occurred due to incorrect parsing of CSS background values when multiple background layers were applied (e.g., a gradient + image). When both are set, the element ends up with multiple background-related properties. Previously, In setValue method, Inside MultiUserValueWidget when value = "100px, 100px", the resulting values array was ['100px,', '100px'], which included an extra comma. This has now been corrected to properly handle such cases. Other edge cases fixed: 1. Gradient was repeating along with the image. 2. Switching to parallax after repeat-pattern causes gradient to repeat. 3. Removing image kept repeat class, causing gradient to repeat. Fix Summary: 1. We updated `selectStyle` and _computeWidgetState to correctly handle multi-layer background-size and repeat styles. In selectStyle, we set the height and width values from options and apply them only to the image layer (not gradient), keeping the gradient layer unchanged. In `_computeWidgetState`, we fetch the background-size from the target and, if multiple layers are present, return only the first one (image layer), since height and width options apply only to that. Now, setValue receives only single-layer values like `100px 50px`, ensuring correct behavior. Set background-size 'cover' to gradient which ensures only the image repeats while the gradient remains fixed. 2. Remove `o_bg_img_opt_repeat` and reset background-size when - Image is removed. - Switching to parallax. task-4577864 Forward-Port-Of: odoo/odoo#207757
A broken Vimeo video used in the website editor has been replaced with an available one. This keeps the related website editing dialog working as expected and avoids disruption for users configuring website content.
Original PR description
This commit replaces an unavailable vimeo video with a new one to maintain the dialog structure. This commit is a backport of [1], which was merged only into master, but is also necessary in the stable versions. [1]: https://github.com/odoo/odoo/commit/ad6f8716ea7e886b6dd3b657309d7cc51e5eb50f Forward-Port-Of: odoo/odoo#224054
This update improves how Odoo handles cases where a browser used during automated testing unexpectedly disconnects. Instead of waiting for timeouts or attempting cleanup on an already closed connection, the system now reports the failure sooner and more accurately, helping teams investigate test instability faster.
Original PR description
As far as I can tell this can occur if the ws connection gets closed while we're in a `recv`: in that case `recv` will mark the connection as closed (`connected=False` and `sock=None`) and raise…
As far as I can tell this can occur if the ws connection gets closed while we're in a `recv`: in that case `recv` will mark the connection as closed (`connected=False` and `sock=None`) and raise `WebSocketConnectionClosedException`, then any attempt to `send` will fail with `WebSocketConnectionClosedException`. Here this likely is an issue because in `_receive` `WebSocketConnectionClosedException` goes through the generic exception handler, which sees that: - it's not a `ConnectionResetError` - the result is not set - and the ws is not connected So `_receive` just cancels the result and `return`s, and when whatever's waiting on a future finally times out it tries to cleanly shut down and hits a connection that's already closed. Handle a connection closed in that context more properly: - unset `ws` so we don't try to clean it up, as we know it's closed - set the result as being in error - cancel every future in order to immediately go to the tour failure step rather than wait for timeouts Note that this will not really *fix* any error per se, because every time this happens it means the browser abruptly closed the WS connection (possibly straight up died), so this should mostly properly attribute the error so we can investigate it. https://runbot.odoo.com/odoo/error/229793 Forward-Port-Of: odoo/odoo#224023
Creating a child menu in Website settings now keeps it under the selected parent menu instead of moving it to the main menu. This prevents incorrect website navigation structure and reduces manual cleanup for administrators.
Original PR description
Steps to reproduce: - Have a database with only the website module installed --> Turn on the developer mode. - Go to Configuration ---> Menus - Create a Menu (Parent) and a child menu (Child) in that. - Upon saving, the following behaviour is observed: the child menu is converted to the main menu. Issue: Before this commit, when we create a child menu for single website then it takes the website.menu_id.id as the parent_id. Which is wrong because it gives the parent_id of the websites' top menu. Solution: With this commit, we have passed the correct parent_id from vals to solve this issue. task-4231974 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222615
File downloads now open in a separate browser context instead of navigating the current page. This prevents unnecessary page-leave prompts or interruption warnings, making downloads smoother for users.
Original PR description
In this commit, we use browser.open(url, "_blank") when the action is a download instead of window.location.assign(url). This latest dispatch a "beforeUnload" event and we want to avoid it.
Odoo now refreshes the registration status of Peppol users even when they are already registered. This helps keep company e-invoicing access aligned with updates made by the access point server, reducing the risk of outdated status information.
Original PR description
Registered users state never gets fetched from AP API when the user is already registered. This is not great when user state somehow gets updated by AP server (for whatever reason). no-task Forward-Port-Of: odoo/odoo#223418
The New Zealand tax report now avoids counting zero-rated sales twice in the Total Sales and Income section. This makes reported sales totals more accurate for businesses using 0% tax invoices.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_nz - Switch to a New Zeland company (e.g. NZ Company) - Create an invoice with a 0% tax - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "Tax Report (NZ)" and the period of the invoice **Issue:** The amount of the invoice with the 0% tax is included twice in `Total Sales and Income` section. Cause: The formula for `Total Sales and Income` is `BOX5 + BOX6 + BOX9`. However, the value of BOX6 is already included in BOX5 as seen in its description `[BOX 6] Zero-rated supplies in Box 5`. opw-3883198 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224095 Forward-Port-Of: odoo/odoo#171595
Messages in Discuss are no longer sent when a user presses Enter to select an IME text suggestion. This helps users who type with input methods for languages such as Chinese, Japanese, or Korean avoid sending incomplete or unintended messages.
Original PR description
Before this commit, pressing ENTER to pick a composition suggestion from IME in a discuss channel composer would send a message with the current content of composer. This is definitely not the intended behavior: it should change the composing text by the IME software but the send on ENTER press should not happen while the text is in composing. This commit fixes the issue by adding condition for composing text. Task-5043396 Forward-Port-Of: odoo/odoo#224265
Stopping a timesheet timer now uses the user's local date instead of UTC when matching entries. This prevents time from being added to the previous or next day for users working across time zones.
Original PR description
Before this commit, if you were to log time on a timesheet using the timer start and stop buttons, you could potentially log time for the previous day's or the upcoming day's timesheet entry. This is because we were searching for previously-created timesheet entries based on the UTC Date of the timer's "stop" time. This fix uses the client's local time to get the Date of the timer stop. With this, we'll only find timesheet entries with the `date` field matching the client's local Date. opw-4967487 Forward-Port-Of: odoo/enterprise#93010 Forward-Port-Of: odoo/enterprise#92569
Planning notification emails now send portal users to the correct planning page instead of the general portal dashboard. This helps external users access their published shifts directly from email without confusion or extra navigation.
Original PR description
### Steps to reproduce: - Install Planning app - Create a portal user and an employee for this user - Create a shift for this user and Publish it - Go to the email that has been sent and click on…
### Steps to reproduce: - Install Planning app - Create a portal user and an employee for this user - Create a shift for this user and Publish it - Go to the email that has been sent and click on View Your planning - Notice you are redirected to the portal dashboard home ### Cause: Since this commit diff we removed the check if the user is having planning group https://github.com/odoo-dev/enterprise/commit/72afe1e14703f0a3eafd0cfaec10c67462db73ce#diff-293bc9f44292d19793981abbafbe2a55642d170bda5e3bf17d7654f7bffcbedaL62-L64 When getting the planning url that will be share in the email we don't check if the user is portal or not so we set the url with /odoo path and if a portal user is accessing a /odoo path it will redirect him to /my https://github.com/odoo/odoo/blob/1acf4b2ce2bdad27e7d32d1227698968148a5935/addons/portal/controllers/web.py#L25-L26 ### Fix: We check if the user is portal we set the url with /planning path which will redirect the portal user to the correct planning view opw-5045746
Rental orders settled through Point of Sale now keep the delivered quantity accurate when items are returned. This prevents returned rental products from being counted as delivered more than once, improving order accuracy and reducing manual corrections.
Original PR description
**Issue:** Before this commit, the qty_delivered was wrong when using the Return button when a Picking was made in PoS **Cause:** The `_compute_qty_delivered` method in `pos_sale` adds `pos_line.qty`…
**Issue:** Before this commit, the qty_delivered was wrong when using the Return button when a Picking was made in PoS **Cause:** The `_compute_qty_delivered` method in `pos_sale` adds `pos_line.qty` to the related `sale_line` each time it runs When there is no PoS order, the method add 0 to the line, so the expected behavior work But when you have a PoS Picking, a quantity was added to `qty_delivered` each time the `rental.order.wizard` is used The issue also occured earlier when the `flush_all()` is called in `_process_order()` **Fix:** There is already a `_compute_qty_delivered` method in `pos_sale_stock_renting` that override the `qty_delivered` But it's restricted by `_are_rental_pickings_enabled()` That's not necessary because we don't use any `stock.picking` in the `_compute_qty_delivered` function, only `stock.move` so we removed that verification To make the code working, we also need to extend the _get_outgoing_incoming_moves() results Because there were also block by a `_are_rental_pickings_enabled()` condition even if there is only moves here We need all the moves to calculate `qty_delivered` properly **Steps to reproduce:** - Create a New Product "Rental PoS" that Can be Rented - Create and confirm a New Rental Order, with any customer and your product - Open a PoS Session - Click on Quotation/Order - Choose the last Order and Settle the order - Click on Yes (to confirm import to PoS) - Click on Payment, select Cash and Pay - Go in the Backend, and to your RO - Click Return and Validate - Before the fix, the Delivered should be 2.0 opw-4877019 Forward-Port-Of: odoo/enterprise#90510
The Estonian tax XML export now combines the two 22% VAT report line balances into a single transaction entry. This prevents duplicate transaction22 lines in submitted XML reports while preserving the underlying report lines for the tax rate transition.
Original PR description
Before this pr: - There are two transactions22 entries were introduced because we are having two report lines for 22% tax computation, one with '1' tag, which is valid till 31 June 2025, and another one with '1_2' tag, which is valid from 1 July 2025. After this pr: - The balance computation during export to XML is now adding the balance of both line '1' and '1_2' into line '1' only. - So now we do not need an extra transactions22 entry in the XML tax report. - We are keeping both report lines for now, but the XML report will have only one entry with the total sum of balances in both report lines Related PR: https://github.com/odoo/enterprise/pull/91364 Forward-Port-Of: odoo/enterprise#93197 Forward-Port-Of: odoo/enterprise#92662
Users can now complete scheduled activities even if the related Studio approval rule was deleted in the meantime. This prevents an unexpected error and keeps the sales workflow moving smoothly.
Original PR description
An error occurs when a user attempts to mark a scheduled activity as done after the associated approval rule has been deleted. **Steps to Reproduce:** 1) Install Sales and Web Studio modules. 2) Log…
An error occurs when a user attempts to mark a scheduled activity as done after the associated approval rule has been deleted. **Steps to Reproduce:** 1) Install Sales and Web Studio modules. 2) Log in as Admin and use Studio to add an approval rule to the Sale Order’s Preview button. >- Set Allowed Group to Access Rights. >- Set Responsible User to Mitchell Admin. 3) In the Incognito Tab, login as Demo, open the same sale order and click on preview to create activity in chatter. 4) Delete the Approval Rule in the original tab. 5) Switch back to Demo and click Mark Done under Planned Activity in chatter. **Error:** `SyntaxError: syntax error at or near ')'` `LINE 1: SELECT id FROM studio_approval_rule WHERE id IN () FOR UPDAT. ^` **Root Cause:** The error occurs because the SQL query at [1] includes an empty tuple of rule IDs `(all_rule_ids)`. An empty `IN ()` clause in SQL results in a syntax error. [1]- https://github.com/odoo/enterprise/blob/7ea45724e7689a0df11d20ace9c562788f5d19e3/web_studio/models/studio_approval.py#L366 **Solution:** This commit avoids the error by ensuring that the SQL query only runs when `all_rule_ids` is not empty. sentry-6306636466 Forward-Port-Of: odoo/enterprise#86982
Restoring an uploaded spreadsheet that has no folder now saves a clear default value instead of an undefined one. This prevents inconsistent document search panel behavior after files are moved to trash and restored.
Original PR description
Steps to reproduce: - Go to documents and upload an XLSX file - Move the XLSX file to the trash - Restore the XLSX file Current behavior before PR: - The key 'searchpanel_documents_document' was set to undefined, When the file had no folder Desired behavior after PR is merged: - Files without a folder now store 'false' as the default search panel folder_id Task: [5005319](https://www.odoo.com/odoo/2328/tasks/5005319)
This fix ensures negative Swiss payroll entries are posted to the appropriate reversed accounts. It helps keep payroll accounting records accurate and reduces the risk of incorrect balances for affected payslips.
Original PR description
…r 2050 Invert accounts for negative payslip line Forward-Port-Of: odoo/enterprise#93074
Refreshing a document that was sent for signature no longer causes an error. The signing page now keeps the needed document state in the URL so users can reload the page without losing access or interrupting their workflow.
Original PR description
Version: - 18.0 Steps to reproduce: - Open document which is send for signature. - Refresh the browser. Before: - Refreshing the page caused a traceback error. - The requestItemStates value was loaded from the context, which is only available when navigating from go_to_document. - On refresh, the context was lost, leading to the error. After: - Added requestItemStates to the URL query string. - On page refresh, the data is retrieved from the URL as a fallback instead of relying on the context. Impact: - Fixes the error that occurred on page refresh. - Ensures a smoother and more stable user experience when viewing documents. task-4805166
Brazilian invoices using Avalara no longer add exempt ICMS taxes as extra journal item amounts when Avalara marks them as not accounting-relevant. This prevents invoice totals from being overstated while still keeping a visible record of the ignored tax in the invoice chatter.
Original PR description
### Steps to reproduce:
- Install l10n_br_edi, switch to Brazilian company
- Set up Avalara
- Create an invoice with the tax "ICMS Exemption Incl." which is included in price
- Click "Generate taxes" to compute the taxes with Avalara
- In "Journal Items" we can see a line for "ICMS Exemption Incl.", its value appear as excluded
### Cause:
The result from Avalara included a value for this tax:
```
'tax': 1.44,
'taxImpact': {
'accounting': 'none',
'impactOnFinalPrice': 'Included',
'impactOnNetAmount': 'Included',
},
```
But the untaxed amount is computed without this tax. Odoo keeps the untaxed amount from the response and add a line for the tax. As a result the tax is added to the amounts like an excluded tax would.
### Solution:
In the response from Avalara, we don't want to create a line for the tax `icmsDeson` when there is `'accounting': 'none'`.
We also log this tax in the chatter to keep a trace of it.
opw-4964315